Break Glass Account Best Practices

Last Updated on August 8, 2026 by Arnav Sharma

Most tenant lockouts are not caused by attackers. They are caused by a Conditional Access policy scoped to All users when it should have been scoped to a pilot group, deployed on a Friday and enforced within minutes. Every administrator loses access at once. The recovery path, if one exists, is a break glass account.

The problem is that best practices for break glass accounts are widely published and thinly implemented. Across IAM programmes the pattern repeats, and break glass account management is where it shows: no emergency access account at all, a single account created years ago and never tested, or two accounts with no monitoring attached. The third state is the most dangerous, because it looks like compliance.

This guide sets out the best practices to secure emergency access, taking an architecture-first approach. It starts from the failure modes that actually lock organisations out, derives the configuration that survives each one, and resolves the question published guidance has left contradictory: exactly which Conditional Access policies you exclude a break glass account from, and which you do not.

What a break glass account is for, and what it is not

A break glass account is a cloud-only identity holding highly privileged access, and it exists for one purpose: to regain control of a tenant when every normal path has failed. These accounts are designed to be reserved for emergency use only. Microsoft documents the use of break glass accounts under the term emergency access accounts, and recommends you create emergency accounts (two or more) to reduce the impact of accidental loss of standard administrative access. This is core account management for any tenant.

Emergency or global admin accounts of this kind hold a unique identity and access profile. Three properties define them. They are not attached to any individual. Their authentication does not depend on any system that could itself be the thing that failed. They are never used for routine work.

Implementations fail in both directions. Teams either treat the emergency account as a convenience super-admin, destroying the audit signal, or lock it down so aggressively it cannot function during the emergency it was built for. An account that requires a compliant device, when the compliance service is the outage, is not a safety net. It is a decoration.

The design goal is narrow: a tested, auditable, monitored escape hatch with exactly one job, treated as critical infrastructure. Not a spare Global Administrator. Not a shared admin account with a long password. Whether break glass accounts exist at all is the first question an auditor will ask, and the answer carries significant security risks if it is no.

Start with the failure modes, not the control list

So much guidance produces broken implementations because it presents controls as a checklist without explaining what each defends against. An engineer deciding which items to skip then has no basis for the decision.

Work the other way. Enumerate the emergency scenarios in which normal access methods are unavailable, then derive the control that survives each one.

Lockout scenario	What fails	Control that survives it
Conditional Access misconfiguration blocks all admins	Policy evaluation, correctly	Account excluded from blocking policy classes
Identity provider or federation outage	On-premises AD FS, third-party identity provider	Cloud-only account on the default domain, not federated or synchronised
MFA service disruption or lost device	Push notification, SMS, authenticator app	Hardware security keys held in a safe, not on a person
Custom domain or DNS failure	Vanity domain resolution	UPN on the .onmicrosoft.com domain
Last Global Administrator leaves or is disabled on-premises	Human availability, directory sync	Account with no employee attached, cloud-mastered
Admin accounts compromised, clean recovery needed	The trust boundary of every normal admin credential	Separate credential path with independent authentication method
PIM activation unavailable or deadlocked	Role activation workflow	Permanent active role assignment, not eligible
Regional outage or natural disaster	A physical site	Second account, second physical storage location

Read the right-hand column as a specification for the security controls you need. Each exists so you can regain access when its matching failure occurs. Every item on it exists because something on the left can fail. Nothing on it is optional, because each control is the only thing standing between you and one specific scenario.

The deadlock nobody plans for

One lockout path is entirely self-inflicted and almost no independent guidance covers it. Microsoft documents it: if every Global Administrator and Privileged Role Administrator assignment is eligible rather than active, activation requires approval, and no approvers are selected, nobody can approve an activation. Active Global Administrators and Privileged Role Administrators are the default approvers when none are specified, so if none are active, tenant administration is locked.

This is a pure governance deadlock: no outage, no attacker, just a well-intentioned privileged access management design that closed the last door behind itself. It is the clearest argument for permanent active role assignment, covered below.

Break glass account best practices: the core configuration

Two accounts, deliberately asymmetric

Everyone says create two cloud-only accounts. Almost nobody says configure them differently, and this design flaw runs through published guidance on break-glass accounts across the industry. The two accounts must be distinguishable in more than name.

If both accounts use the same hardware key vendor, sit in the same safe, hold the same exclusions and were created by the same script on the same day, they are one account with two names. A firmware defect, a fire in that building, or a single policy error takes both out at once. Correlated failure is not redundancy. Break glass accounts across a tenant should never share a failure domain. Design the second account to fail differently from the first.

Dimension	Account 01	Account 02	Why they differ
Hardware security key vendor	Vendor A	Vendor B	Survives a firmware defect or vendor supply issue
Credential storage location	On-site safe or secure server room	Off-site: second office, bank deposit box	Survives a site-level physical event
Conditional Access posture	Excluded from all blocking policies, retains phishing-resistant authentication requirement	Same authentication requirement, plus an additional session control policy	Survives a policy error affecting one posture
Validation drill schedule	Offset by 45 days	Offset by 45 days	Guarantees at least one recently verified account at any time

The offset schedule is the cheapest of these and the most frequently ignored. Test both on the same day every ninety days and, eighty-nine days later, you have two accounts of equally unknown status. Stagger them and one was always proven working within the last forty-five days.

Cloud-only, unlicensed, on the default domain

Emergency accounts in Microsoft Entra ID must be cloud-only, created directly in the tenant, never synchronised from Active Directory and never federated. Accounts in Microsoft Entra that depend on an on-premises identity provider inherit its failure modes. The reasoning follows directly from the failure table: if an on-premises identity provider is the thing that broke, an account that depends on it cannot rescue you. Keep emergency access for on-premises systems and emergency access for cloud services entirely distinct, with no dependency of one on the other.

Use the .onmicrosoft.com domain rather than a custom domain. A DNS misconfiguration, an expired registration, or a botched domain verification change can render a custom domain unusable for sign-in while the tenant is perfectly healthy. The default domain cannot be broken from outside the tenant.

Leave the accounts unlicensed. An unlicensed account has no Microsoft 365 mailbox, no OneDrive and no SharePoint presence, which removes an entire class of attack surface and data exfiltration path. Note the common misconception here: licensing has no bearing on Conditional Access enforcement. An unlicensed account is still subject to every policy in the tenant unless it is explicitly excluded. Licensing controls feature availability, not policy scope.

Permanent active roles, never eligible

Assign global administrator access to your break glass accounts as a direct, permanent, active role. In Microsoft Entra Privileged Identity Management, this means active permanent rather than eligible.

This feels wrong to anyone who has internalised just-in-time privileged access, and that instinct is correct in every other context. It is wrong here because PIM activation is a workflow, and workflows have dependencies: MFA, approval, an authentication context that a policy is currently mishandling. Each is a thing that can be broken during the emergency. The account whose purpose is to function when other things are broken cannot depend on a workflow.

Count these accounts toward your total Global Administrator population. The common guideline is a maximum of four, and two slots are now consumed. That is not a constraint worth fighting, since Global Administrator is rarely the right role for daily operations anyway.

Naming: stop hiding them

Older guidance recommended disguising emergency accounts with innocuous names so they would not stand out during reconnaissance. Some published advice still suggests naming them after films or products. Discard this.

Obscurity buys nothing. An attacker who can enumerate directory objects can enumerate role assignments, and a permanently active Global Administrator with no manager, no licence and no sign-in history is the most conspicuous object in the tenant regardless of its name. Attackers target privilege, not names.

The cost, meanwhile, lands entirely on the defenders. Your SOC cannot write a high-fidelity detection rule for an account whose identity is a shared secret. Your on-call engineer at 2am cannot find the account they were told to use. Your auditor cannot verify the control exists.

Name each break glass user plainly: break-glass-01 and break-glass-02, or emergency-access-01 and emergency-access-02, on the .onmicrosoft.com domain. Then protect them with controls that work whether or not the attacker knows the name.

Authentication: what survives an emergency

The old approach of excluding emergency accounts from MFA entirely no longer works. Microsoft’s Secure Future Initiative enforces multifactor authentication for administrative portals and command-line tools, so an account with only a password cannot reliably sign in even when every Conditional Access policy is bypassed. The password-only break glass account is now a broken one.

Microsoft’s current guidance is explicit: configure a passwordless authentication method that satisfies the mandatory authentication requirements. Passkey (FIDO2) is the recommended option. Certificate-based authentication is viable if the organisation already operates a PKI.

Evaluate authentication methods by asking a single question: what does this method depend on, and can that dependency be the emergency?

Authentication method	Hidden dependency	Suitable for break glass?
Password only	No second factor available	No. Fails mandatory MFA enforcement for admin portals
Authenticator app push	Named individual’s phone, mobile network, push service	No. Person-bound and network-bound
SMS or voice call	Mobile carrier, phone number, telephony network	No. Weakest method and network-dependent
Time-based one-time passcode	Seed availability, device clock, enrolled device	Marginal. Only viable if the seed itself is stored in the safe
Certificate-based authentication	PKI availability, certificate expiry, revocation checking	Yes, if the PKI is genuinely independent of the failure domain
Passkey (FIDO2) hardware security keys	The physical key and its PIN, nothing else	Yes. Recommended. No network, service or person dependency

FIDO2 security keys are the correct default: they collapse the dependency chain to a physical object you can put in a safe. Phishing-resistant, no scheduled expiry, no connectivity requirement, and not bound to an employee who might be unreachable, on leave, or gone.

Two implementation details make the difference.

Store account credentials securely in a physical safe, with limited access granted only to named personnel. The credential and the device must not expire, and must not be in scope of any automated cleanup process that removes unused authentication methods. An emergency credential is, by definition, an unused credential. A hygiene job that reaps stale methods will happily delete the one thing you were relying on.

Use a different authentication method from the one your regular admin accounts use. If standard admin accounts authenticate with the Microsoft Authenticator app, emergency accounts should use hardware security keys. A shared method means a shared failure domain, defeating the point of a separate credential path.

If you use passkey profiles, scope a dedicated profile to the emergency accounts and restrict it to the AAGUID values of the key models you have issued, then exclude those accounts from every other authentication method policy. The result is an identity that can authenticate using approved physical hardware and by no other means.

The Conditional Access exclusion question, settled

This is where published guidance actively contradicts itself. One set of articles says to exclude accounts from all Conditional Access policies. Another says never to exclude them from all access management policies. Both statements appear in top-ranking results, and neither offers a rule for deciding.

The confusion comes from treating Conditional Access as one thing. Policies fall into classes, and the exclusion decision differs by class. The rule: exclude the account from any policy that can prevent sign-in based on a condition that could itself be the emergency, and retain any policy that raises the security bar without introducing an external dependency.

Policy class	Example	Exclude break glass account?	Reasoning
Device compliance or hybrid join required	Require compliant device for all users	Yes, exclude	The compliance service, MDM enrolment or device could be the failure. Emergency access must work from any device
Location or country blocking	Block sign-in outside approved countries	Yes, exclude	Geolocation of IP addresses is imperfect and has caused wide misclassification incidents. A false positive here removes your recovery path
Sign-in risk or user risk based	Block or require step-up on high risk	Yes, exclude	Risk scoring is probabilistic. An unfamiliar sign-in from a safe location during an incident looks exactly like risk
Approved client application or app protection	Require approved app	Yes, exclude	Introduces an application-layer dependency during recovery
Sign-in frequency and persistent browser session	Reauthenticate every hour	No, retain or apply a dedicated policy	Adds no external dependency. Short sessions limit token exposure on the highest-privilege account in the tenant
Phishing-resistant authentication strength	Require FIDO2 passkey	No, retain via a dedicated policy	This is the control protecting the account. Removing it leaves a permanently active Global Administrator with a password
Report-only policies	Any policy in report-only mode	Not required	Report-only policies do not block access and therefore need no exclusion

The pattern is now visible. You are not excluding the account from Conditional Access. You are excluding it from conditions that can fail, while keeping the authentication requirement that makes it safe to have such an account at all.

Implement this as two dedicated policies targeting a security group containing only the emergency accounts: one requiring your custom phishing-resistant authentication strength across all cloud resources, one setting a short sign-in frequency and a non-persistent browser session. Exclude that same group from every other policy in the tenant.

Validate rather than trust. Run the What If tool against each account. Those two policies should be the only ones applying. Anything else is a lockout waiting to happen. Repeat after every new policy, because one scoped to All users silently captures your emergency accounts unless the exclusion is added deliberately.

Protecting the accounts from your own administrators

A break glass account is a user object and its group is a group object. By default, both can be modified, disabled or deleted by anyone with sufficient directory permissions. That is an uncomfortable property for your last line of access: an insider or compromised administrator can quietly remove the recovery path before doing anything else.

Restricted Management Administrative Units close this access control gap and give you a properly managed break glass design. Place the emergency accounts, and the group containing them, inside a Restricted Management Administrative Unit. Objects inside such a unit cannot be managed by tenant-level administrative roles. Only holders of a role scoped explicitly to that unit can touch them.

The design that follows from this:

• Create a role-assignable security group containing only the emergency accounts. Role-assignable groups can be modified only by a Group Owner or a Privileged Role Administrator.
• Place both the accounts and the group inside a Restricted Management Administrative Unit.
• Create a custom role containing only the permissions needed to manage users and groups within that unit. Avoid broad built-in roles here.
• Assign that custom role through Privileged Identity Management with strict activation requirements: a short maximum duration, an authentication context, approval, and justification.
• Enforce phishing-resistant authentication and a compliant device on the authentication context used for that activation.

Changing anything about your emergency access design then becomes a deliberate, approved, time-limited, fully audited event rather than something a Global Administrator can do on a whim. It is one of the highest-value upgrades available to an existing deployment, and absent from most.

Monitoring and alerting on break glass account usage

Monitoring and alerting are where break glass accounts are critical to get right. An unmonitored emergency account is worse than none, because it presents a permanently active Global Administrator credential to any attacker who finds it.

You must monitor sign-in and audit logs for every break glass account usage. The rule is unambiguous: these accounts should never sign in silently. Using break glass accounts always produces a signal. Every authentication event is either a scheduled validation drill or an incident. There is no third category, which makes this one of the few detection rules with a genuinely zero false-positive baseline. Set severity to critical and the threshold to any activity at all.

Route Microsoft Entra sign-in logs and audit logs to a Log Analytics workspace through diagnostic settings, then build the Azure Monitor alert rule on top. This tells you when the accounts are used. You do not need Microsoft Sentinel: it adds incident workflow and automated response if you already run it, but a Log Analytics alert rule with an action group achieves the same detection outcome far more cheaply.

Retrieve the object ID of each emergency account from the Entra admin center, then alert on both sign-in and audit activity:

let BreakGlassAccounts = dynamic([
    "<object-id-account-01>",
    "<object-id-account-02>"
]);
SigninLogs
| where UserId in (BreakGlassAccounts)
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, AppDisplayName, ResultType, ResultDescription

Three points separate a working alert from a decorative one.

Alert on audit activity as well as sign-in activity. Sign-in monitoring tells you the account was used; audit monitoring tells you it was changed, and modification by someone else is a far stronger indicator of compromise. Query for events where the emergency account is the target resource, not only the initiator.

Run the rule under a managed identity rather than the default behaviour, which depends on the permissions of whoever last modified the rule. That identity needs Log Analytics Reader on the workspace and Reader on the resource group holding the action group. A rule that silently stops evaluating because someone changed jobs is a common and avoidable failure. Route notifications to a monitored shared mailbox, never to an individual alone.

Prepare a post-mortem process before you need it. When the alert fires, preserve the logs, establish whether the use was a drill, a genuine emergency, or unauthorised, and examine what actions were taken. In regulated environments, that review record is your evidence.

Testing: what a real validation drill covers

Most organisations test the wrong thing. They sign in, confirm it works, and sign out. That validates one link in a chain of seven.

Microsoft recommends validating functionality at least every 90 days, and additionally after a change in IT staff or tenant subscriptions. Treat that as the floor. A complete drill covers all of the following.

1. Notify the security team first. An unannounced drill that triggers a critical alert and mobilises incident response is a useful test exactly once, and expensive every time after.
2. Sign in end to end using the stored credential. Retrieve the hardware key from its actual storage location. If the key is already on the tester’s desk, the drill has not tested credential retrieval, the step most likely to fail in a real emergency.
3. Confirm the role is active, not eligible. A PIM configuration change can silently convert a permanent assignment.
4. Perform a real administrative action. Sign-in proves authentication, not authorisation. Make a reversible change that requires Global Administrator.
5. Verify the alert fired. Almost everyone omits this. Confirm the rule triggered, the action group executed, and the notification arrived. An untested alert rule is not a control.
6. Run a Conditional Access What If evaluation. Confirm only your two intended policies apply. Policies created since the last drill are the most common source of drift.
7. Review the authorised-user list and documentation. Remove anyone who has left or changed role, and change safe combinations after any departure.

Record the outcome. In a regulated environment, the drill record is the audit evidence that the control is not merely present but operational.

What break glass accounts cannot do

Honest boundaries matter more than an exhaustive control list, because they tell you where to put the next control.

These accounts do not protect you from tenant deletion, from a hostile Global Administrator who removes them before acting, or from a compromised safe. They do not help if the recovery procedure exists only in the head of someone who has left.

They are also no substitute for a resilient access design. If a single Conditional Access change can lock out every administrator in your tenant, break glass limits the blast radius but does not address the cause. Report-only mode, staged rollout rings, and What If evaluation before enforcement are what prevent the lockout. Break glass is what you have left when prevention failed. Treat it as the last control in the chain, not the first, and design the chain so you rarely reach for it.

Implementation checklist

• Two or more accounts, asymmetric in key vendor, storage location and validation schedule.
• Cloud-only, unlicensed, on .onmicrosoft.com, with no federation or synchronisation dependency.
• Global Administrator assigned permanent active, never eligible, and counted in the tenant total.
• Named plainly and identifiably. No obscurity.
• A passkey (FIDO2) hardware key registered on each, from different vendors, via a passkey profile restricted to approved AAGUID values.
• Authentication method differs from regular admin accounts and is exempt from automated credential cleanup.
• A dedicated security group holds the accounts and is excluded from every policy blocking sign-in on device, location, risk or client app.
• Two dedicated policies apply: phishing-resistant authentication strength, and short sessions.
• What If evaluation confirms only those two policies apply.
• Accounts and group sit in a Restricted Management Administrative Unit, managed only via a scoped custom role activated through PIM.
• Logs flow to Log Analytics with a critical-severity alert on any activity, running under a managed identity, notifying a monitored shared mailbox.
• Credentials and PINs stored in two separate physical locations, independent of online documentation.
• Drills run at least every 90 days, staggered, covering retrieval, role activation, an administrative action, alert firing and policy evaluation.
• A documented post-mortem process exists for any unplanned use.