If you manage Active Directory (AD) or Entra ID, you’ve probably encountered break-glass or emergency access accounts—special accounts held in reserve for worst-case scenarios. These accounts serve as your administrative lifeline when your normal identity systems fail. But, just like a fire extinguisher, an emergency account is only valuable if it’s charged, reachable, and tested.
The Purpose of Emergency Accounts
Emergency accounts exist for one simple goal: to ensure administrative access to critical systems in the event of catastrophic failure. Commonly referred to as “break-glass” accounts, these emergency accounts must be outage resistant, fully isolated, and disaster ready.
An emergency account must be able to authenticate without dependency on external identity providers. This means the accounts must originate from the system they protect. In the case of AD, an emergency account must reside locally to the domain. For Entra ID, emergency accounts must be cloud-only and not federated or synchronized with another identity provider.
Administrators should carefully evaluate any reliance on external sources or security protections that could also fail during an outage. This includes Conditional Access policies, MFA providers, and network connectivity. Successful implementation of an emergency account maximizes outage resilience by ensuring usability under degraded conditions.
Emergency accounts have a long history in the hybrid identity space. As the threat landscape has changed over the years, so have the best practices that surround the proper implementation of emergency accounts. Migrating from a legacy practice to a more modern approach is not only an important security control; it improves the resiliency of an organization during an emergency.
From Legacy AD Habits to Modern Hygiene
Historically, protecting the built-in AD Administrator account was about obscurity and rotation — renaming the account and resetting the password. More security-minded organizations might even disable the Administrator account, but others may still allow this account to log in anywhere in the domain.
New Microsoft guidance makes it clear that the Administrator account should only be used when no other account can be used. The guidance even goes so far as to recommend that logon rights be tightly restricted only to domain controllers via GPO. The recent security practices also encourage the use of the Account is sensitive and cannot be delegated, and Smart card is required for interactive logon flags for the built-in Administrator account. These restrictions assume that physical access to at least one domain controller will be available during a recovery scenario. Infer
Microsoft guidance is built on the understanding that organizations maintain at least one physical domain controller. In hybrid environments, domain controllers are often virtualized or cloud-hosted in Azure or AWS. Such a configuration works fine in normal circumstances, but what happens when the virtual or cloud environment is unavailable? Carefully consider any out-of-band communication channels required to connect to a domain controller. In the case where no physical domain controller exists, outage risk should be shared amongst multiple hosting platforms or hypervisors. Reliance on any external system, especially cloud architectures, puts emergency access at risk and must be re-evaluated.
Updated Guidance for the Cloud
Unlike on-premises AD, an Entra ID tenant has no built-in Administrator account. Instead, administrators must create emergency access accounts more intentionally. Best practice for emergency access accounts in Entra has evolved over the years. Early guidance focused primarily on a global administrator account that could bypass common security controls enforced for other privileged accounts. Two cloud-only (onmicrosoft.com) global administrator accounts—excluded from Conditional Access policies and exempt from MFA requirements—were the extent of previous recommendations.
Current Microsoft guidance still emphasizes two cloud-only emergency access accounts, but these accounts are no longer exempt from the mandatory MFA requirement. Instead, the recommendation is that emergency access accounts should utilize phishing-resistant authentication methods. Previous Practical 365 articles discuss the specifics of the mandatory MFA phase 1 and phase 2.
Intriguingly, this Microsoft documentation lacks explicit language reinforcing Conditional Access exclusions — an apparent oversight, as these accounts should be excluded from most, if not all, Conditional Access policies. If organizations don’t exclude these accounts, they risk a circular dependency that locks out administrators during the very scenarios in which these accounts are needed.
Common Misconfigurations and Modern Nuances
Emergency accounts are deceptively simple, but subtle missteps can neutralize their value. Let’s unpack a few common mistakes.
AD Directory Services Restore Mode (DSRM) Password
Some organizations might rely on the DSRM password for emergencies. The reason that Microsoft guidance primarily focuses on the Administrator account rather than the DSRM account is that a DSRM account only provides local access to a single domain controller in Directory Services Restore Mode and cannot authenticate across the domain. In large environments, the built-in Administrator account provides domain-wide authority, making it a more effective lifeline for recovery.
Not All MFA is Created Equal
Phishing-resistant methods like passkeys and certificate-based authentication offer best-in-class security but are also the best choice when it comes to authentication resiliency, as they can function offline. Other common choices for MFA are subpar. Methods such as SMS are subject to carrier outages, and Microsoft Authenticator solutions may depend on access to a user’s personal device. More information on resilient credentials is available here.
Why Two Accounts?
Maintaining two separate emergency accounts isn’t bureaucracy — it’s flexibility. Two independent accounts reduce single-point-of-failure risk, as one account may be rendered unusable or inaccessible. Ideally, separate custodians, in different locations, are each responsible for one of the accounts.
Conditional Access Considerations
While not explicitly stated in the guide for configuring emergency accounts in Entra, excluding these accounts from Conditional Access policies is still extremely important. A few examples of this appear in the recommended policies for blocking legacy authentication and privileged access implementation. Applying restrictions to emergency access authentication (aka failure to exclude them from all policies) is not recommended.
Shared vs. Individually Assigned
A designated emergency account serves one purpose and exists only for emergency use. Human-assigned privileged accounts, by contrast, are used daily and are prone to exposure. A shared, documented, and secured emergency account minimizes standing risk while still granting interactive control when necessary. The use of a dedicated emergency account also allows for a dedicated alert process upon use. It also encourages more strict controls around human-assigned accounts such as PIM eligibility, privileged access workstations, and other security controls used daily.
Credential Access Controls
Proper management of the emergency accounts’ passwords and MFA devices is important. Ideally, passwords are set as a long random string. Store the passwords and MFA devices offline in a physical safe, instead of the same enterprise password vault used on a regular basis. After an emergency account is used, its password must be rotated and secured.
Testing & Awareness
The number-one failure associated with emergency access is a lack of testing. Organizations create emergency accounts, lock the credentials away, and never validate them again. When Conditional Access or sync failures occur, organizations often discover that their emergency accounts are disabled, expired, or misconfigured. Just like a fire extinguisher with no pressure, an emergency account that hasn’t been tested is functionally useless.
Practical Checklist: Before Breaking Glass
Active Directory
- Maintain one built-in Administrator account for each domain with local logon rights to all domain controllers.
- Ensure the Account is sensitive and cannot be delegated flag is configured and tested.
- Ensure the Smart card is required for interactive logon flag is configured and tested.
- Ensure GPOs are configured to restrict logon to domain-joined systems.
- Test credentials by logging in directly at a domain controller console (no network dependency).
Entra ID
- Maintain two independent emergency accounts, each protected with phishing-resistant MFA.
- Ensure accounts are cloud-only, not synchronized or federated.
- Exclude accounts from Conditional Access to prevent dependency.
- Assign active membership to the Global Administrator role.
Both Environments
- Set a strong password and store credentials securely (split storage across offline safes/locations).
- Document every step of your recovery plan and store copies offline.
- Run semi-annual “fire-drills” to practice credential retrieval and sign-in from a controlled test device under simulated outage conditions.
- After using an emergency account, conduct a full post-incident review and reset all emergency credentials.
- Integrate emergency account sign-in alerts to a SIEM or otherwise configure alarms on sign-in.
- Train your incident response team on where, when, and how to use emergency accounts.
- Document every dependency these accounts have and work to remove them.
Keep Pace and Keep Testing
Technology shifts faster than documentation can keep up. In 2025, Microsoft made major updates to its security recommendations, subtly changing guidance on how best to secure emergency accounts.
Emergency access presents a paradox: it must save the organization while remaining dormant and secure. Treat these accounts as living controls— review, test, and modernize them with every architectural change.
If your federation fails, Conditional Access locks everyone out, or your domain trust collapses, you’ll want confidence that your fire extinguisher works as a lifeline and not a liability.
