The Break Glass Account Checklist: Emergency Access That Is Not a Backdoor

A break glass account is the one identity in a Microsoft 365 tenant that has to work when everything else fails: Conditional Access misfires, a federation outage, an MFA provider having a bad day. That same property makes it the most dangerous account in the tenant if it is set up casually. This checklist covers how we recommend creating, protecting, and monitoring emergency access accounts, based on the questions MSPs ask about them most.

The baseline pattern, which matches Microsoft's own guidance: create two break glass accounts, and exclude exactly one of them from all Conditional Access policies in the tenant. Everything below builds on that split.

How should the accounts be created?#

Get the identity attributes right at creation and the accounts stay invisible to attackers and untouched by daily operations:

• Not tied to a person. Never associate a break glass account with an individual or with any account that signs in daily for work tasks like answering email or chatting in Teams.
• Named to be unguessable. Skip the obvious choices that show up in password spray lists and stand out in a directory dump. Do not use breakglass@domain.com or emergencyaccess@domain.com. A convention like svr_ea_01@domain.onmicrosoft.com works well.
• Cloud-only. In a hybrid environment, do not let this user sync up from local Active Directory. A synced account is more exposed to lateral movement and gives an attacker two places to compromise it.
• On the default .onmicrosoft.com domain, not the organization's custom domain, to avoid domain and federation issues at exactly the moment you need the account.
• Unlicensed. The account's only function is regaining access during a lockout. It needs no license.

What does the password setup look like?#

You have to set a password at creation, so make it count:

• Generate a password of 32 characters or more. Entra technically accepts up to 256 characters at user creation; 32 is a practical floor.
• Set the password to never expire. Password expiration should already be off tenant-wide, but verify it for these accounts specifically.
• Split the password across two storage locations. Older guidance says to split the password into physical envelopes in a fireproof safe, and that still works. A digital version of the same idea: store one half in your documentation tool (Hudu, IT Glue) and the other half in Azure Key Vault. If the documentation tool is breached, the attacker holds only a fragment.

Do break glass accounts still get MFA?#

Yes, and this is the most common misconception we hear. Excluding an account from MFA policies is not the same as leaving it without MFA. Register MFA on both accounts when they are first configured, before adding any exclusions:

• Only one of the two accounts gets excluded from Conditional Access. The other account keeps MFA enforced, so it needs strong methods registered.
• Use phishing-resistant MFA, specifically FIDO2. YubiKeys are our go-to here. Even on the excluded account, the sign-in options flow lets you authenticate without ever typing a username and password, which closes off man-in-the-middle attacks against these accounts. It also gives you a detection signal: any sign-in from this account that used a password instead of the key deserves immediate scrutiny.
• Register multiple YubiKeys per account so a lost key is an inconvenience, not an emergency.

• Avoid weaker MFA like SMS and voice. Beyond the usual SIM swapping and social engineering exposure, phone-based methods can simply be down during a natural disaster, which is precisely when break glass accounts get used. We would not use those methods for anyone, break glass or otherwise.

Which account gets excluded, and which gets admin rights?#

The Conditional Access and role assignments are where the two-account split earns its keep:

• Exclude the account directly in each Conditional Access policy rather than through a group. A group exclusion works, and we do not hold a strong opinion against it, but direct exclusion keeps the total population of excluded users smaller and easier to audit.
• The excluded account is PIM-enabled and eligible for Global Admin, not permanently assigned. This departs slightly from Microsoft's documentation, but we do not want the account that bypasses every Conditional Access policy to also carry perpetual Global Admin rights. Just-in-time activation through PIM shrinks that standing attack surface.
• The permanent Global Admin assignment lives on the other account, the one still covered by Conditional Access and protected with phishing-resistant MFA.
• PIM requires Entra ID P2 licensing, which makes this harder to implement in many customer environments. At roughly $9 per month for a single P2 license, we would eat the cost for this extra layer if the customer will not, though passing it through is always the first ask.
• Configure PIM to require MFA on activation. Some argue this raises the lockout risk if you cannot satisfy the MFA prompt in a crisis. We take the extra protection; the second account is the fallback.

How do you know when a break glass account is used?#

Legitimate use of these accounts should be close to zero, which makes monitoring simple: alert on everything.

Microsoft's emergency access documentation (opens in new tab) walks through configuring alerts on activity from these accounts. As a side note, setting up Azure Monitor is worth doing regardless, because it retains sign-in logs beyond the default 30-day rolling window.

Build the alert rule so that any detected activity generates a ticket in your PSA tool. That turns break glass monitoring from a thing someone remembers to check into a workflow that catches malicious use or compromise the day it happens.

Reviewing break glass accounts across every customer#

Checking this list once is easy. Keeping it true across dozens of tenants is the hard part, and it is exactly the kind of quiet drift that turns an emergency access account into a liability. CloudCapsule reports on this directly, showing you:

• All Global Admins in the account
• Break glass accounts being excluded from Conditional Access
• Last sign-in time for break glass accounts
• MFA methods registered on break glass accounts

You can run a free assessment to see what this looks like in your environment.