Emergency access accounts
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/entra-docs · commit e4cb0d9 · +47 −5 lines · also on GitHub
⋯ 2 unchanged lines
33
description: This article describes how to use emergency access accounts to help prevent being inadvertently locked out of your Microsoft Entra organization.
44
ms.date: 06/04/2026
55
ms.topic: how-to
6
−ms.custom: it-pro, sfi-ga-nochange
6
+ms.custom: it-pro, sfi-ga-nochange, sfi-image-nochange
77
ms.reviewer: mwahl
88
ai-usage: ai-assisted
99
---
⋯ 32 unchanged lines
4242
- **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)
4343
- **Certificate-based authentication**: [Configure certificate-based authentication](../authentication/concept-certificate-based-authentication.md)
4444
45
−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.
46
−
47
− > [!IMPORTANT]
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.
45
+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).
4946
5047
1. [Store account credentials safely](#store-account-credentials-safely).
5148
⋯ 25 unchanged lines
7774
7875
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.
7976
77
+## Conditional Access considerations
78
+
79
+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.
80
+
81
+When planning your Conditional Access deployment, consider the following:
82
+
83
+- 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.
84
+- Regularly test (for example, every quarter) that emergency access accounts can sign in successfully with your current Conditional Access configuration.
85
+- 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).
86
+
87
+For more information about planning Conditional Access exclusions, see [Plan a Conditional Access deployment](~/identity/conditional-access/plan-conditional-access.md).
88
+
89
+## Security guardrails summary
90
+
91
+The following checklist summarizes the security requirements for emergency access accounts:
92
+
93
+- Maintain at least two emergency access accounts for redundancy.
94
+- Use cloud-only accounts (`.onmicrosoft.com` domain) with no dependency on federated identity providers.
95
+- Use phishing-resistant authentication methods (FIDO2 security keys or certificate-based authentication) that are different from your normal admin accounts.
96
+- Ensure credentials and devices don't expire and aren't subject to automated cleanup.
97
+- In Privileged Identity Management, assign the Global Administrator role as permanent active (not eligible) for emergency accounts.
98
+- Require the use of a designated secure workstation or [Privileged Access Workstation](/security/privileged-access-workstations/privileged-access-deployment) when using emergency access accounts.
99
+- Store credentials in separate, secure, fireproof locations accessible to authorized individuals.
100
+- Exclude emergency access accounts from Conditional Access policies that block or restrict sign-in. Report-only policies don't require an exclusion.
101
+- Monitor all sign-in and audit log activity for emergency access accounts with alerts to detect unnecessary or unauthorized use.
102
+- Validate account functionality at least every 90 days.
103
+
104
+## Auditability and compliance
105
+
106
+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:
107
+
108
+- **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.
109
+- **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.
110
+- **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.
111
+- **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).
112
+
80113
## Monitor sign-in and audit logs
81114
82115
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.
⋯ 149 unchanged lines
232265
- [Securing privileged access for hybrid and cloud deployments in Microsoft Entra ID](security-planning.md)
233266
- [Configure additional protections for privileged roles in Microsoft 365](/microsoft-365/enterprise/protect-your-global-administrator-accounts), if you're using Microsoft 365
234267
- [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)
268
+
269
+## Related content
270
+
271
+- [Create a resilient access control management strategy](~/identity/authentication/concept-resilient-controls.md)
272
+- [Security operations for privileged accounts](~/architecture/security-operations-privileged-accounts.md)
273
+- [Plan a Privileged Identity Management deployment](~/id-governance/privileged-identity-management/pim-deployment-plan.md)
274
+- [Plan a Conditional Access deployment](~/identity/conditional-access/plan-conditional-access.md)
275
+- [HIPAA access controls](~/standards/hipaa-access-controls.md)
276
+- [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.