Emergency access accounts
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/entra-docs · commit f907107 · +32 −31 lines · also on GitHub
11
---
22
title: Manage emergency access admin accounts
33
description: This article describes how to use emergency access accounts to help prevent being inadvertently locked out of your Microsoft Entra organization.
4
−ms.date: 05/20/2026
4
+ms.date: 06/04/2026
55
ms.topic: how-to
66
ms.custom: it-pro, sfi-ga-nochange
77
ms.reviewer: mwahl
8
+ai-usage: ai-assisted
89
---
910
1011
# Manage emergency access accounts in Microsoft Entra ID
1112
12
−It's important that you prevent being accidentally locked out of your Microsoft Entra organization because you can't sign in or activate a role. You can mitigate the impact of accidental lack of administrative access by creating two or more *emergency access accounts* in your organization.
13
+It's important to prevent accidentally locking yourself out of your Microsoft Entra organization because you can't sign in or activate a role. You can reduce the impact of accidental lack of administrative access by creating two or more *emergency access accounts* in your organization.
1314
14
−User accounts with the Global Administrator role have high privileges in the system, this includes emergency access accounts with the Global Administrator role. Emergency access accounts are limited to emergency or "break glass" scenarios where normal administrative accounts can't be used. We recommend that you maintain a goal of restricting emergency account use to only the times when it's absolutely necessary.
15
+User accounts with the Global Administrator role have high privileges in the system, and this role includes emergency access accounts with the Global Administrator role. Use emergency access accounts only for emergency or "break glass" scenarios where normal administrative accounts can't be used. Restrict emergency account use to only the times when it's absolutely necessary.
1516
1617
This article provides guidelines for managing emergency access accounts in Microsoft Entra ID.
1718
⋯ 1 unchanged line
1920
2021
An organization might need to use an emergency access account in the following situations:
2122
22
−- The user accounts are federated, and federation is currently unavailable because of a cell-network break or an identity-provider outage. For example, if the identity provider host in your environment has gone down, users might be unable to sign in when Microsoft Entra ID redirects to their identity provider.
23
−- The administrators are registered through Microsoft Entra multifactor authentication, and all their individual devices are unavailable or the service is unavailable. Users might be unable to complete multifactor authentication to activate a role. For example, a cell network outage is preventing them from answering phone calls or receiving text messages, the only two authentication mechanisms that they registered for their device.
24
−- The person with the most recent Global Administrator access has left the organization. Microsoft Entra ID prevents the last Global Administrator account from being deleted, but it doesn't prevent the account from being deleted or disabled on-premises. Either situation might make the organization unable to recover the account.
23
+- The user accounts are federated, and federation is currently unavailable because of a cell-network break or an identity-provider outage. For example, if the identity provider host in your environment goes down, users might be unable to sign in when Microsoft Entra ID redirects to their identity provider.
24
+- The administrators register through Microsoft Entra multifactor authentication, and all their individual devices are unavailable or the service is unavailable. Users might be unable to complete multifactor authentication to activate a role. For example, a cell network outage is preventing them from answering phone calls or receiving text messages, the only two authentication mechanisms that they registered for their device.
25
+- The person with the most recent Global Administrator access leaves the organization. Microsoft Entra ID prevents the last Global Administrator account from being deleted, but it doesn't prevent the account from being deleted or disabled on-premises. Either situation might make the organization unable to recover the account.
2526
- Unforeseen circumstances such as a natural disaster emergency, during which a mobile phone or other networks might be unavailable.
26
−- If role assignments for Global Administrator and Privileged Role Administrator roles are eligible, approval is required for activation, but no approvers are selected (or all approvers are removed from the directory). Active Global Administrators and Privileged Role Administrators are default approvers. But there will be no active Global Administrators and Privileged Role Administrators and administration of the tenant will effectively be locked, unless emergency access accounts are used.
27
+- All Global Administrator and Privileged Role Administrator role assignments are eligible (not active), activation requires approval, and no approvers are selected (or all selected approvers were removed from the directory). Active Global Administrators and Privileged Role Administrators are the default approvers when none are selected, but because none are active, no one can approve activation and tenant administration is effectively locked.
2728
2829
## Create emergency access accounts
2930
⋯ 14 unchanged lines
4445
1. Review your Conditional Access policies for administrators and ensure that emergency access accounts are explicitly excluded from all policies, including [phishing-resistant multifactor authentication](../conditional-access/policy-admin-phish-resistant-mfa.md) requirements.
4546
4647
> [!IMPORTANT]
47
− > Emergency access accounts must be excluded from all Conditional Access policies. Because these accounts are used when normal sign-in methods or policies are failing, a Conditional Access policy could block access at exactly the moment it's needed. Security is instead enforced through the phishing-resistant authentication method registered directly on the account in the previous step.
48
+ > Exclude emergency access accounts from all Conditional Access policies. You use these accounts when normal sign-in methods or policies fail, so a Conditional Access policy could block access when you need it most. The phishing-resistant authentication method you registered in the previous step secures the account instead.
4849
4950
1. [Store account credentials safely](#store-account-credentials-safely).
5051
⋯ 3 unchanged lines
5455
5556
## Configuration requirements
5657
57
−When you configure these accounts, the following requirements must be met:
58
+When you configure these accounts, ensure the following requirements are met:
5859
59
−- In most organizations, emergency access accounts aren't associated with any individual user in the organization. Credentials are in a known secure location available to multiple members of administration team and not connected with any employee-supplied devices such as phones. This approach is commonly used to unify emergency access accounts management: most organizations need emergency access accounts not only for Microsoft Cloud infrastructure, but also on-premises environment, federated SaaS applications, and other critical systems.
60
+- Don't associate emergency access accounts with any individual user in the organization. Store credentials in a known secure location that's available to multiple members of the administration team. Don't connect these accounts with any employee-supplied devices, such as phones. This approach unifies emergency access account management. Most organizations need emergency access accounts not only for Microsoft Cloud infrastructure, but also for on-premises environments, federated SaaS applications, and other critical systems.
6061
6162
Alternatively, you can choose to create individual emergency access accounts for administrators. This solution promotes accountability and allows administrators to use emergency access accounts from remote locations.
6263
63
−- Use strong authentication for your emergency access accounts and make sure it doesn't use the same authentication methods as your other administrative accounts. For example, if your normal administrator account uses the Microsoft Authenticator app for strong authentication, use a FIDO2 security key for your emergency accounts. Consider the [dependencies of various authentication methods](~/architecture/resilience-in-credentials.md), to avoid adding external requirements into the authentication process.
64
+- Use strong authentication for your emergency access accounts and make sure it doesn't use the same authentication methods as your other administrative accounts. For example, if your normal administrator account uses the Microsoft Authenticator app for strong authentication, use a FIDO2 security key for your emergency accounts. To avoid adding external requirements into the authentication process, consider the [dependencies of various authentication methods](~/architecture/resilience-in-credentials.md).
6465
6566
- The device or credential must not expire or be in scope of automated cleanup due to lack of use.
6667
67
−- In Microsoft Entra Privileged Identity Management, you should make the Global Administrator role assignment active permanent rather than eligible for your emergency access accounts.
68
+- In Microsoft Entra Privileged Identity Management, make the Global Administrator role assignment active permanent rather than eligible for your emergency access accounts.
6869
69
−- Individuals authorized to use these emergency access accounts must utilize a designated, secure workstation or similar client computing environment, such as a Privileged Access Workstation. These workstations should be employed when interacting with the emergency access accounts. For more information about configuring a Microsoft Entra tenant where there are designated workstations, see [deploying a privileged access solution](/security/privileged-access-workstations/privileged-access-deployment).
70
+- Individuals authorized to use these emergency access accounts must utilize a designated, secure workstation or similar client computing environment, such as a Privileged Access Workstation. Use these workstations when interacting with the emergency access accounts. For more information about configuring a Microsoft Entra tenant where there are designated workstations, see [deploying a privileged access solution](/security/privileged-access-workstations/privileged-access-deployment).
7071
7172
## Federation guidance
7273
73
−Some organizations use Active Directory Domain Services and Active Directory Federation Service (AD FS) or similar identity provider to federate to Microsoft Entra ID. The emergency access for on-premises systems and the emergency access for cloud services should be kept distinct, with no dependency of one on the other. Mastering and or sourcing authentication for accounts with emergency access privileges from other systems adds unnecessary risk in the event of an outage of those systems.
74
+Some organizations use Active Directory Domain Services and Active Directory Federation Service (AD FS) or similar identity provider to federate to Microsoft Entra ID. Keep the emergency access for on-premises systems and the emergency access for cloud services distinct, with no dependency of one on the other. Mastering or sourcing authentication for accounts with emergency access privileges from other systems adds unnecessary risk if an outage occurs in those systems.
7475
7576
## Store account credentials safely
7677
77
−Organizations need to ensure that the credentials for emergency access accounts are kept secure and known only to individuals who are authorized to use them. For example, you might use [FIDO2 security keys](../authentication/how-to-authentication-passkeys-fido2.md) for Microsoft Entra ID or smartcards for Windows Server Active Directory. Credentials should be stored in secure, fireproof safes that are in secure, separate locations.
78
+Ensure that the credentials for emergency access accounts are kept secure and known only to individuals who are authorized to use them. For example, you might use [FIDO2 security keys](../authentication/how-to-authentication-passkeys-fido2.md) for Microsoft Entra ID or smartcards for Windows Server Active Directory. Store credentials in secure, fireproof safes that are in secure, separate locations.
7879
7980
## Monitor sign-in and audit logs
8081
81
−Organizations should monitor sign-in and audit log activity from the emergency accounts and trigger notifications to other administrators. When you monitor the activity for emergency access accounts, you can verify these accounts are only used for testing or actual emergencies. You can use Azure Monitor, Microsoft Sentinel, or other tools to monitor the sign-in logs and trigger email and SMS alerts to your administrators whenever emergency access accounts sign in. This section illustrates using Azure Monitor.
82
+Monitor sign-in and audit log activity from the emergency accounts and trigger notifications to other administrators. When you monitor the activity for emergency access accounts, you can verify these accounts are only used for testing or actual emergencies. You can use Azure Monitor, Microsoft Sentinel, or other tools to monitor the sign-in logs and trigger email and SMS alerts to your administrators whenever emergency access accounts sign in. This section illustrates using Azure Monitor.
8283
8384
### Prerequisites
8485
⋯ 74 unchanged lines
159160
1. On the **Actions** tab, select an action group to be notified by the alert. If you want to create one, see [Create an action group](#create-an-action-group).
160161
161162
1. On the **Details** tab:
162
− 1. Select the **Severity** of the event. We recommend **0 - Critical**.
163
+ 1. Select the **Severity** of the event. Use **0 - Critical**.
163164
1. Enter the **Alert rule name** and add an optional description.
164165
1. Select the **Region**.
165166
1. Select which **Identity** to use when running the log query.
⋯ 10 unchanged lines
176177
177178
:::image type="content" source="./media/security-emergency-access/create-action-group.png" alt-text="Screenshot of the Create an action group screen open to the Basics tab." lightbox="./media/security-emergency-access/create-action-group.png":::
178179
179
−1. On the **Basics** tab, enter the following:
180
+1. On the **Basics** tab, enter the following information:
180181
181
− - **Subscription** and **Resource group**: Select where the action group will be stored.
182
+ - **Subscription** and **Resource group**: Select where to store the action group.
182183
- **Region**: Select the region for the action group.
183184
- **Action group name**: Enter a descriptive name.
184185
- **Display name**: Enter a short name (maximum 12 characters) that appears in notifications.
⋯ 6 unchanged lines
191192
192193
1. Select **Edit details**, configure the notification methods and contact information, and then select **OK**.
193194
194
−1. Add any additional notifications you want to trigger.
195
+1. Add any other notifications you want to trigger.
195196
196197
1. Select **Next: Actions** to configure any additional automated actions, or select **Review + create** to finish.
197198
198199
### Prepare a post-mortem team to evaluate each emergency access account credential use
199200
200
−If the alert is triggered, preserve the logs from Microsoft Entra and other workloads. Conduct a review of the circumstances and the results of the emergency access account usage. This review will determine whether the account was used:
201
+If the alert is triggered, preserve the logs from Microsoft Entra and other workloads. Conduct a review of the circumstances and the results of the emergency access account usage. This review determines whether the account was used:
201202
202203
- For a planned drill to validate its suitability
203204
- In response to an actual emergency where no administrator could use their regular accounts
204
−- Or as a result of misuse or unauthorized usage of the account
205
+- As a result of misuse or unauthorized usage of the account
205206
206
−Next, examine the logs to determine what actions were taken by the individual with the emergency access account to ensure that those actions align with the authorized use of the account.
207
+Next, examine the logs to determine what actions the individual with the emergency access account took to ensure that those actions align with the authorized use of the account.
207208
208209
## Validate accounts regularly
209210
210
−In addition to training staff members to use emergency access accounts, you should also have an ongoing process to validate the emergency access accounts remain accessible to authorized staff. Regular drills should be conducted to validate the functionality of the accounts and to confirm that monitoring and alerting rules are triggered in case an account is subsequently misused. At a minimum, the following steps should be performed at regular intervals:
211
+In addition to training staff members to use emergency access accounts, have an ongoing process to validate that authorized staff can access the emergency access accounts. Regularly conduct drills to validate the functionality of the accounts and to confirm that monitoring and alerting rules are triggered in case an account is misused. At a minimum, perform the following steps at regular intervals:
211212
212
−- Ensure that security-monitoring staff is aware that the account-check activity is ongoing.
213
+- Ensure that security-monitoring staff are aware that the account-check activity is ongoing.
213214
- Review and update the list of individuals authorized to use the emergency access account credentials.
214215
- Ensure that the emergency break glass process to use these accounts is documented and current.
215216
- Ensure that administrators and security officers who might need to perform these steps during an emergency are trained on the process.
216
−- Validate that the emergency access accounts can sign-in and perform administrative tasks.
217
−- Ensure that users haven't registered multifactor authentication or self-service password reset (SSPR) to any individual user's device or personal details.
217
+- Validate that the emergency access accounts can sign in and perform administrative tasks.
218
+- Ensure that users didn't register multifactor authentication or self-service password reset (SSPR) to any individual user's device or personal details.
218219
- If the accounts are registered for multifactor authentication to a device, for use during sign-in or role activation, ensure that the device is accessible to all administrators who might need to use it during an emergency. Also verify that the device can communicate through at least two network paths that don't share a common failure mode. For example, the device can communicate to the internet through both a facility's wireless network and a cell provider network.
219
−- Change the combinations on any safes after someone with access leaves the organization, as well as on a regular basis.
220
+- Regularly change the combinations on any safes and after someone with access leaves the organization.
220221
221
−These steps should be performed at regular intervals and for key changes:
222
+Perform these steps at regular intervals and for key changes:
222223
223224
- At least every 90 days
224
−- When there has been a recent change in IT staff, such as after termination or position change
225
−- When the Microsoft Entra subscriptions in the organization have changed
225
+- When there's a recent change in IT staff, such as after termination or position change
226
+- When the Microsoft Entra subscriptions in the organization change
226227
227228
## Next steps
228229
⋯ 5 unchanged lines
Microsoft's Markdown source from MicrosoftDocs/entra-docs, © Microsoft Corporation, under MIT. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 04:17 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.