🧯 How to Break Glass (fast)

In every well-designed identity and access management (IAM) strategy, there should be a plan for emergencies, especially for scenarios where all privileged access may be lost due to misconfigurations, outages, or security incidents. That’s where break-glass admin accounts come into play.

In this post, I will walk you through the importance of emergency access accounts, Microsoft’s recommendations, and how I recommend implementing a secure and resilient setup. (TL;DR, Configuration at the end)

🔐 What is a Break Glass Account?

A break-glass account (or emergency access account) is a highly privileged account that can be used to regain administrative control over your tenant in situations where normal administrative access is unavailable.

Microsoft recommends that every organization should have at least two cloud-only emergency access accounts. These accounts should be isolated from normal operations and not be subject to Conditional Access, MFA registration policies, or automated cleanup processes.

⚙️ Break Glass Strategy

To ensure maximum availability and security, I would recommend the following structure:

🧑‍💼 1. Two Dedicated Cloud-Only Admin Accounts

Maintain two emergency access accounts (in case of accidental deletion) created natively in Microsoft Entra using the onmicrosoft.com domain (e.g., bob@indefent.onmicrosoft.com).
These accounts are:

• Cloud-only (not synced from on-premises)
• Not federated with any identity provider
• Isolated from groups in your production identity infrastructure
• 40+ character password
• Don't use names of celebrities like tom.cruise@indefent.onmicrosoft.com and don't use something like emergency@indefent.onmicrosoft.com or breakglass@indefent.onmicrosoft.com as they state the obvious

🥇 2. Permanent Global Administrator Role Assignment

Both accounts are assigned the Global Administrator role permanently.

This is critical: if PIM is unavailable, misconfigured, or requires MFA to activate roles, it could prevent access when you need it most. Permanent assignment ensures that admin rights are always active and available.

To mitigate risks of permanent high privilege, we compensate with strict controls (e.g., isolation, alerting, and physical key security).

🔐 3. FIDO2 Security Keys – Passwordless and Offline-Ready

Authentication is handled exclusively with FIDO2 security keys, offering:

• Phishing-resistant login
• Independence from phones or network-dependent MFA
• No reliance on passwords, mobile apps, or SMS

Use two different hardware key models to diversify hardware risk and avoid dependency from one.

📦 4. Geographically and Physically Separated Key Storage

The FIDO2 keys are stored in separate, secure locations:

• 🔐 One is stored in a locked, fireproof cabinet at our primary office
• 🧳 The second is held off-site, in a secure physical vault

So how does this could look with the break glass user bob@indefent.onmicrosoft.com:

So we technically we now don't have a "single point of failure":

Access locations are/should be documented in a sealed emergency procedure binder, reviewed quarterly.

So now if you think of the worst scenario you could get... This setup ensures full access continuity / even if Daisy and Alice were to vanish mysteriously into the IT abyss.

🚫 5. Exempt from all Conditional Access and Identity Protection

Both accounts are manually excluded from all Conditional Access (CA) policies (except CA for MFA and CA for Admin Portals MFA), ensuring:

• They are always able to sign in - even if CA rules become overly restrictive
• They are unaffected by MFA registration, device compliance, or network location restrictions

Also exclude these accounts from CAs where Identity Protection risk-based blocking to avoid false positives or lockouts --> So yeah, ALL Policies (except CA for MFA and CA for Admin Portals MFA)

🚨 6. Usage Alerts and Zero Daily Use Policy

These accounts are not used for any operational tasks.
Create a new Log Analytics Workspace and setup the Alert Rule with High Severity for it - So we achive:

• All sign-ins trigger an immediate alert via LAW
• Events are investigated and logged as high-priority incidents
• Audit logs are retained and regularly reviewed

This ensures that if one is ever used, we know why, when, and by whom.

🔄 7. Quarterly Validation and Maintenance

We conduct a quarterly break-glass test, which includes:

• Verifying successful login with both accounts and keys
• Checking account and role integrity
• Validating exclusions from CA policies
• Confirming access paths and recovery documentation

Runbooks are stored securely both digitally and physically, and include clear step-by-step instructions for emergency access scenarios.

✅ Microsoft’s Recommendations Recap

From Microsoft’s official guidance on Emergency access accounts:

• ✅ Have at least two emergency access accounts.
• ✅ Use cloud-only identities (not synced from on-prem).
• ✅ Exclude from all Conditional Access.
• ✅ Use strong authentication methods (like FIDO2).
• ✅ Store credentials offline and securely.
• ✅ Audit and alert on any sign-in.

🔄 Testing and Maintenance

Your emergency plan is only as strong as its last test:

• Perform a quarterly login test to ensure credentials, keys, and access paths are functional.
• Review and update documentation every quarter.
• Maintain an emergency runbook with access instructions under lock and key - both digitally and physically.

TL:DR, Configuration

🧑‍💼 1. Two Dedicated Cloud-Only Admin Accounts

• Create the User

🥇 2. Permanent Global Administrator Role Assignment

• Assign the Global Administrator role

🔐 3. FIDO2 Security Keys - Passwordless and Offline-Ready

• Login with the created account and navigate to the security-info registration:

My Sign-Ins

My Sign-ins

• Now setup both FIDO Keys and follow the instructions to set them up:

📦 4. Geographically and Physically Separated Key Storage

• 🔐 One FIDO should be stored in a locked, fireproof cabinet at your primary office
• 🧳 The second FIDO should be held off-site, in a secure physical vault

🚫 5. Exempt from all Conditional Access and Identity Protection

• Exclude from all CA's except Require MFA and Require MFA for Admin Portals

🚨 6. Usage Alerts and Zero Daily Use Policy

• Create a Log Analytics workspace

• Create the alert rule

• Create an action group with your point of contact(s) via Email and/or Message/Push/Voice

• Setup the Alert rule Details

🛡️ Final Thoughts

In the same way you wouldn’t run a data center without a fire suppression system, you shouldn’t run a Entra tenant without a recovery mechanism for privileged access.

By leveraging the native onmicrosoft.com domain, FIDO2 keys, and strict access controls, you will have a resilient and secure emergency access strategy that aligns with Microsoft best practices - and one we hope you’ll never have to use it for your own organization. ;)

For more detailed information, visit Microsoft’s documentation here:
🔗 Emergency Access Accounts in Entra ID

⚠️ Disclaimer

The configurations shared in this post reflect my personal approach to solving this specific challenge. Every environment is unique, so adapt these solutions to fit your needs.

Happy configuring! 😊