Public mode

No access to your tenant or devices. Every item links to its source. What this means

Some sources or documents need attention: 258/260 feeds/APIs · 416/439 docs · checked 22:55 UTC Customize Public modeDiscuss ChangeIntel on Discord

Microsoft's edit ·

Merge main into jayrusso/emergency-access-uuf-fixes

Microsoft's commit message in MicrosoftDocs/entra-docs · commit 57289cc · +61 −94 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/06/2026
4 +ms.date: 04/22/2026
55 ms.topic: how-to
6 −ms.custom: it-pro, sfi-ga-nochange, sfi-image-nochange
7 −ai-usage: ai-assisted
6 +ms.custom: it-pro, sfi-ga-nochange
87 ms.reviewer: mwahl
98 ---
109
⋯ 23 unchanged lines
3433
3534 :::image type="content" source="./media/security-emergency-access/create-emergency-access-account.png" alt-text="Screenshot of creating an emergency access account in Microsoft Entra ID." lightbox="./media/security-emergency-access/create-emergency-access-account.png":::
3635
37 −1. Select one of these passwordless authentication methods for your emergency access accounts. These methods satisfy the [mandatory multifactor authentication requirements](../authentication/concept-mandatory-multifactor-authentication.md).
36 +1. Choose one of these passwordless authentication methods for your emergency access accounts. These methods satisfy the [mandatory multifactor authentication requirements](../authentication/concept-mandatory-multifactor-authentication.md).
3837
3938 - [Passkey (FIDO2)](../authentication/concept-authentication-passkeys-fido2.md) (Recommended)
4039 - [Certificate-based authentication](../authentication/concept-authentication-passkeys-fido2.md) if your organization already has a Public Key Infrastructure (PKI) setup
4140
42 −1. [Configure your emergency access accounts](#configuration-requirements) to use passwordless authentication.
41 +1. Register credentials for the authentication method you chose in the previous step.
4342
44 − - [Enable passkeys (FIDO2) for your organization](../authentication/how-to-authentication-passkeys-fido2.md)
45 − - [Register a passkey (FIDO2)](../authentication/how-to-register-passkey-with-security-key.md)
46 − - [Configure certificate-based authentication](../authentication/concept-certificate-based-authentication.md)
43 + - **Passkey (FIDO2)**: [Enable passkeys (FIDO2) for your organization](../authentication/how-to-authentication-passkeys-fido2.md), then [register a passkey (FIDO2)](../authentication/how-to-register-passkey-with-security-key.md)
44 + - **Certificate-based authentication**: [Configure certificate-based authentication](../authentication/concept-certificate-based-authentication.md)
4745
48 −1. Verify that emergency access accounts are excluded from any Conditional Access policy that blocks or restricts sign-in. The phishing-resistant authentication method registered in the previous step protects the account; an enforced Conditional Access policy could prevent sign-in during the exact emergency the account is designed for. Report-only policies don't block access and don't require an exclusion. For details, see [Conditional Access considerations](#conditional-access-considerations).
46 +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.
4947
48 + > [!IMPORTANT]
49 + > 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.
50 +
5051 1. [Store account credentials safely](#store-account-credentials-safely).
5152
5253 1. [Monitor sign-in and audit logs](#monitor-sign-in-and-audit-logs).
⋯ 24 unchanged lines
7778
7879 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.
7980
80 −## Conditional Access considerations
81 −
82 −Exclude emergency access accounts from Conditional Access policies that block or restrict sign-in. Report-only policies don't block access and don't need to exclude emergency accounts. If an emergency access account is subject to a Conditional Access policy that requires MFA, a compliant device, or another control, the account might be unusable during the exact emergency scenarios it's designed for.
83 −
84 −When planning your Conditional Access deployment, consider the following:
85 −
86 −- Create a dedicated security group for your emergency access accounts (for example, **EmergencyAccess**) and exclude this group from Conditional Access policies that block or restrict sign-in.
87 −- Regularly test (for example, every quarter) that emergency access accounts can sign in successfully with your current Conditional Access configuration.
88 −- Create contingency Conditional Access policies that can be enabled during an outage to restore access for critical users. For more information, see [Create a resilient access control management strategy](~/identity/authentication/concept-resilient-controls.md).
89 −
90 −For more information about planning Conditional Access exclusions, see [Plan a Conditional Access deployment](~/identity/conditional-access/plan-conditional-access.md).
91 −
92 −## Security guardrails summary
93 −
94 −The following checklist summarizes the security requirements for emergency access accounts:
95 −
96 −- Maintain at least two emergency access accounts for redundancy.
97 −- Use cloud-only accounts (`.onmicrosoft.com` domain) with no dependency on federated identity providers.
98 −- Use phishing-resistant authentication methods (FIDO2 security keys or certificate-based authentication) that are different from your normal admin accounts.
99 −- Ensure credentials and devices don't expire and aren't subject to automated cleanup.
100 −- In Privileged Identity Management, assign the Global Administrator role as permanent active (not eligible) for emergency accounts.
101 −- Require the use of a designated secure workstation or [Privileged Access Workstation](/security/privileged-access-workstations/privileged-access-deployment) when using emergency access accounts.
102 −- Store credentials in separate, secure, fireproof locations accessible to authorized individuals.
103 −- Exclude emergency access accounts from Conditional Access policies that block or restrict sign-in. Report-only policies don't require an exclusion.
104 −- Monitor all sign-in and audit log activity for emergency access accounts with alerts to detect unnecessary or unauthorized use.
105 −- Validate account functionality at least every 90 days.
106 −
107 −## Auditability and compliance
108 −
109 −Organizations in regulated industries might need to demonstrate that the use of emergency access accounts is properly governed. The monitoring and validation practices described in this article support auditability:
110 −
111 −- **Sign-in and audit log monitoring** — Configure alerts for every use of an emergency access account. Capture sign-in logs and audit logs for review. For details, see [Monitor sign-in and audit logs](#monitor-sign-in-and-audit-logs) in this article.
112 −- **Post-mortem review** — After any use of an emergency access account, conduct a review to determine whether the use was authorized and whether the actions taken were appropriate. For details, see [Prepare a post-mortem team](#prepare-a-post-mortem-team-to-evaluate-each-emergency-access-account-credential-use) in this article.
113 −- **Regular validation** — Perform account validation drills at least every 90 days, including reviewing the authorized-user list and testing sign-in and administrative task functionality. For details, see [Validate accounts regularly](#validate-accounts-regularly) in this article.
114 −- **Compliance mapping** — If your organization must comply with HIPAA regulations, Microsoft provides guidance on how emergency access accounts map to HIPAA emergency access procedure requirements. For more information, see [HIPAA access controls](~/standards/hipaa-access-controls.md).
115 −
11681 ## Monitor sign-in and audit logs
11782
11883 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.
⋯ 18 unchanged lines
137102
138103 1. Sign in to the [Azure portal](https://portal.azure.com) as at least a [Monitoring Contributor](/azure/role-based-access-control/built-in-roles#monitoring-contributor).
139104
140 −1. Browse to **Monitor** > **Log Analytics workspaces**.
105 +1. Search for and open **Monitor**.
141106
142 −1. Select a workspace.
107 +1. In the left menu, select **Alerts**.
143108
144 −1. In your workspace, select **Alerts** > **New alert rule**.
109 +1. Select **+ Create** > **Alert rule**. The **Create an alert rule** page opens.
145110
146 − 1. Under **Resource**, verify that the subscription is the one with which you want to associate the alert rule.
147 − 1. Under **Condition**, select **Add**.
148 − 1. Select **Custom log search** under **Signal name**.
149 − 1. Under **Search query**, enter the following query, inserting the object IDs of the two emergency access accounts.
111 +1. On the **Scope** tab:
112 + 1. In the **Select a resource** pane, find and select your Log Analytics workspace.
113 + 1. Verify that the subscription matches the workspace you configured in the prerequisites.
114 + 1. Select **Apply**.
115 +
116 +1. On the **Condition** tab:
117 + 1. From the **Signal name** drop-down, select **Custom log search**.
118 + 1. Set the **Query type** to **Aggregated logs**.
119 + 1. Under **Search query**, enter one of the following queries, inserting the object IDs of the two emergency access accounts.
150120
151121 > [!NOTE]
152122 > For each additional emergency access account you want to include, add another `or UserId == "ObjectGuid"` to the query.
123 + >
124 + > The table name in these queries depends on your workspace type. Use `SigninLogs` for standard Log Analytics workspaces, or `AADSignInLogs` for Microsoft Sentinel workspaces.
153125
154126 Sample queries:
155127 ```kusto
156128 // Search for a single Object ID (UserID)
157129 SigninLogs
158 − | project UserId
159130 | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"
131 + | project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
160132 ```
161133
162134 ```kusto
163135 // Search for multiple Object IDs (UserIds)
164136 SigninLogs
165 − | project UserId
166137 | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
138 + | project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
167139 ```
168140
169141 ```kusto
170142 // Search for a single UserPrincipalName
171143 SigninLogs
172 − | project UserPrincipalName
173144 | where UserPrincipalName == "[email protected]"
145 + | project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription
174146 ```
175 −
176 − ![Add the object IDs of the emergency access accounts to an alert rule](./media/security-emergency-access/query-image1.png)
177147
178 − 1. Under **Alert logic**, enter the following:
179 −
180 − - Based on: Number of results
181 − - Operator: Greater than
182 − - Threshold value: 0
183 −
184 − 1. Under **Evaluated based on**, select the **Period (in minutes)** for how long you want the query to run, and the **Frequency (in minutes)** for how often you want the query to run. The frequency should be less than or equal to the period.
185 −
186 − ![alert logic](./media/security-emergency-access/alert-image2.png)
187 −
188 − 1. Select **Done**. You can now view the estimated monthly cost of this alert.
189 −
190 −1. Select an action group of users to be notified by the alert. If you want to create one, see [Create an action group](#create-an-action-group).
148 + 1. Under **Measurement**, set how to summarize the results of the query:
149 + 1. Select the **Measure**.
150 + 1. Select the **Aggregation type**.
151 + 1. Select the **Aggregation granularity**.
152 + 1. Under **Split by dimensions**, select the **Resource ID column**.
153 + 1. Under **Alert logic**:
154 + 1. Set the **Threshold type** to **Static**.
155 + 1. Set the **Operator** to **Greater than**.
156 + 1. Set the **Threshold value** to **0**.
157 + 1. Set the **Frequency of evaluation** to how often you want the query to run.
191158
192 −1. To customize the email notification sent to the members of the action group, select actions under **Customize Actions**.
159 + :::image type="content" source="./media/security-emergency-access/alert-logic.png" alt-text="Screenshot of Alert logic settings with example values for Threshold type, Operator, Threshold vlaue, and Frequency of evaluation." lightbox="./media/security-emergency-access/alert-logic.png":::
193160
194 −1. Under **Alert Details**, specify the alert rule name and add an optional description.
161 + 1. Select **Next** to proceed.
195162
196 −1. Set the **Severity level** of the event. We recommend that you set it to **Critical(Sev 0)**.
163 +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).
197164
198 −1. Under **Enable rule upon creation**, leave it set as **yes**.
165 +1. On the **Details** tab:
166 + 1. Select the **Severity** of the event. We recommend **0 - Critical**.
167 + 1. Enter the **Alert rule name** and add an optional description.
168 + 1. Select the **Region**.
169 + 1. Select which **Identity** to use when running the log query.
170 + 1. Under **Advanced options**, select **Enable upon creation**.
171 + 1. Select **Next** to proceed.
199172
200 −1. To turn off alerts for a while, select the **Suppress Alerts** check box and enter the wait duration before alerting again, and then select **Save**.
173 +1. On the **Tags** tab, add any tags you want to associate with the alert rule.
201174
202 −1. Select **Create alert rule**.
175 +1. Select **Review + create**, then select **Create**.
203176
204177 ### Create an action group
205178
206179 1. Select **Create an action group**.
207180
208 − ![create an action group for notification actions](./media/security-emergency-access/action-group-image3.png)
181 + :::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":::
209182
210 −1. Enter the action group name and a short name.
183 +1. On the **Basics** tab, enter the following:
211184
212 −1. Verify the subscription and resource group.
185 + - **Subscription** and **Resource group**: Select where the action group will be stored.
186 + - **Region**: Select the region for the action group.
187 + - **Action group name**: Enter a descriptive name.
188 + - **Display name**: Enter a short name (maximum 12 characters) that appears in notifications.
213189
214 −1. Under action type, select **Email/SMS/Push/Voice**.
190 +1. Select **Next: Notifications**.
215191
216 −1. Enter an action name such as **Notify Global Administrator**.
192 +1. Under **Notification type**, select **Email/SMS message/Push/Voice**.
217193
218 −1. Select the **Action Type** as **Email/SMS/Push/Voice**.
194 +1. Enter a notification name such as **Notify Global Administrator**.
219195
220 −1. Select **Edit details** to select the notification methods you want to configure and enter the required contact information, and then select **Ok** to save the details.
196 +1. Select **Edit details**, configure the notification methods and contact information, and then select **OK**.
221197
222 −1. Add any additional actions you want to trigger.
198 +1. Add any additional notifications you want to trigger.
223199
224 −1. Select **OK**.
200 +1. Select **Next: Actions** to configure any additional automated actions, or select **Review + create** to finish.
225201
226202 ### Prepare a post-mortem team to evaluate each emergency access account credential use
227203
⋯ 31 unchanged lines
259235 - [Securing privileged access for hybrid and cloud deployments in Microsoft Entra ID](security-planning.md)
260236 - [Configure additional protections for privileged roles in Microsoft 365](/microsoft-365/enterprise/protect-your-global-administrator-accounts), if you're using Microsoft 365
261237 - [Start an access review of privileged roles](../../id-governance/privileged-identity-management/pim-create-roles-and-resource-roles-review.md) and [transition existing privileged role assignments to more specific administrator roles](permissions-reference.md)
262 −
263 −## Related content
264 −
265 −- [Create a resilient access control management strategy](~/identity/authentication/concept-resilient-controls.md)
266 −- [Security operations for privileged accounts](~/architecture/security-operations-privileged-accounts.md)
267 −- [Plan a Privileged Identity Management deployment](~/id-governance/privileged-identity-management/pim-deployment-plan.md)
268 −- [Plan a Conditional Access deployment](~/identity/conditional-access/plan-conditional-access.md)
269 −- [HIPAA access controls](~/standards/hipaa-access-controls.md)
270 −- [Microsoft Entra customer considerations under DORA](/compliance/dora/dora-entra)

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.

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 20 Oct 22:55 UTC · 258 of 260 readable · 256 fully read · documentation 416/439 current