Emergency access accounts
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/entra-docs · commit d63befb · +47 −1 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: 02/10/2025
4
+ms.date: 05/06/2026
55
ms.topic: how-to
66
ms.custom: it-pro, sfi-ga-nochange, sfi-image-nochange
7
+ai-usage: ai-assisted
78
ms.reviewer: mwahl
89
---
910
⋯ 66 unchanged lines
7677
7778
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.
7879
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 all Conditional Access policies.
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 all Conditional Access policies.
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
+
79116
## Monitor sign-in and audit logs
80117
81118
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.
⋯ 140 unchanged lines
222259
- [Securing privileged access for hybrid and cloud deployments in Microsoft Entra ID](security-planning.md)
223260
- [Configure additional protections for privileged roles in Microsoft 365](/microsoft-365/enterprise/protect-your-global-administrator-accounts), if you're using Microsoft 365
224261
- [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 and DORA act](/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.