Break Glass Accounts in Azure: Why You Need Them, How to Set Them Up, and What to Do When One Is Used

TL;DR

• A break glass account is a standalone, cloud-only Global Administrator account in Microsoft Entra ID, kept in reserve to regain control when normal admin access fails.
• You need at least two. They are not optional, and one untested account is worse than none.
• The old advice — one Global Admin with a long password, excluded from MFA — is outdated. Microsoft now mandates MFA for admin sign-in, so the modern setup uses phishing-resistant FIDO2 passkeys.
• The account isn't the risk. An unmonitored account is. The whole value lives in the process: alert on every use, then run a post-mortem to explain why it was used.
• Test the full flow at least every 90 days (Microsoft's floor); many practitioners run a 180-day cycle.

I used to think break glass accounts were dangerous

I'll be honest about where I started. The first time someone explained break glass accounts to me, my reaction was: you want me to create a permanent Global Administrator, give it the keys to the entire tenant, and deliberately weaken the controls around it? That's not a safety net, that's a backdoor I'm building for an attacker.

It felt reckless. A standing super-admin account that nobody logs into for months sounded like exactly the thing a security review would flag.

Then it clicked and the realization is the whole point of this post. The account was never the dangerous part. The absence of process around it is. A break glass account that nobody watches is a liability. A break glass account that triggers an instant alert the moment it's touched, and a mandatory review afterward, is one of the strongest controls you can have. Same account. Completely different risk profile.

That single shift in framing turned me from a skeptic into someone who now treats these accounts as critical infrastructure. This post is the full process I wish I'd had at the start: what the account is, why you need it, how to build it the modern way, how to monitor it, and what to do the moment it's used.

What is a break glass account?

Answer: A break glass account (also called an emergency access account) is a standalone, cloud-only Global Administrator account in Microsoft Entra ID that exists for one purpose: to get you back into your tenant when every normal path to administrative access has failed. It belongs to no individual, depends on no on-premises system, and is used only in genuine emergencies, never for day-to-day work.

The name comes from the little red boxes on a wall: in case of emergency, break glass. You don't open them on a normal Tuesday. They're there for the day everything else has gone wrong.

A few defining characteristics separate a break glass account from a normal admin account:

• It's not tied to a person. No employee owns it. Access can't depend on one administrator being reachable, available, or even still employed. As one practitioner puts it, it should still work if your only admin gets hit by a bus tomorrow.
• It's cloud-only. The account lives on your .onmicrosoft.com domain and is never federated or synchronized from on-premises. That independence is deliberate. More on why below.
• It holds Global Administrator permanently. Not eligible-through-PIM, not time-limited. Permanently active, so it works even when the systems that would normally grant access are down.
• It sits at the very last layer of access. Everything else is your first line of defense. This is the line behind the line.

Because it sits at that last layer, you treat it differently from everything else in your tenant. That's the thread running through the rest of this guide.

Why do you actually need one?

Answer: You need a break glass account because every normal way into your tenant can fail at once. A Conditional Access policy locks out all admins, your identity provider goes down, MFA becomes unreachable, or your last Global Administrator leaves. Microsoft Entra is designed around the assumption that you have an emergency way back in; without one, a single misconfiguration can lock you out of your own environment with no recovery path.

Here's the scenario most people imagine: a sophisticated attacker, a natural disaster, something dramatic. Those happen. But the most common reason break glass accounts get used in practice is far more mundane and far more likely to happen to you.

Someone deploys a Conditional Access policy a little too aggressively. It isn't scoped carefully, it isn't tested in report-only mode first, and within seconds every administrator in the tenant is locked out. No drama, no breach. Just a Tuesday-afternoon change that took down admin access for everyone. Without a break glass account, your next call is to Microsoft support, and you wait.

Microsoft's own documentation lists the situations an emergency account is meant to cover, and they're worth internalizing:

Scenario	What breaks	Why a normal admin can't get in
Over-aggressive Conditional Access	Sign-in is blocked for all admins	The policy applies to them too
Identity provider / federation outage	Federated sign-in fails	Entra redirects to an IdP that's down
MFA unreachable	Can't complete the second factor	Phones, networks, or the MFA service are unavailable
Last Global Admin leaves	The account is deleted or disabled on-prem	No one else holds the role
PIM activation deadlock	All admin roles are eligible, approval is required, no approvers exist	Nobody can approve the activation
Natural disaster	Devices and networks are unavailable	Personal authentication methods are unreachable

Notice the common thread: in every case, the normal controls are working exactly as designed and that's the problem. The break glass account is the one identity deliberately built to survive the failure of the very systems you rely on every other day.

That's also why it must be cloud-only and independent. If your emergency account depended on the same federation or MFA service that just went down, it would fail in precisely the moment you need it. The whole design principle is no shared failure modes.

So that settles why. The harder question and the one that turned me from skeptic to believer is how do you build one without creating the backdoor I was so worried about?

How do you set up a break glass account in Entra?

Answer: Create at least two cloud-only Global Administrator accounts on your .onmicrosoft.com domain, assign the role as permanent and active (not via PIM), and secure them with phishing-resistant FIDO2 hardware keys rather than passwords. Exclude them from Conditional Access policies that would block sign-in, but enforce a dedicated policy requiring their strong authentication. Lock down who can manage the accounts, and store the physical keys in two separate secure locations.

This is where modern guidance has changed the most, so let's be precise. Here is the setup, in order.

1. Create two accounts, not one.
Two accounts give you redundancy: if one key fails, is lost, or its storage location is inaccessible, you still have a way in. Use descriptive names: [e-mail], [e-mail]. The old habit of disguising these accounts with obscure names has fallen out of favor: security by obscurity buys you nothing against an attacker (who targets privilege, not names), and it actively hurts your own SOC analysts, who need to recognize these accounts instantly.

2. Assign Global Administrator as permanent and active.
Do not make these accounts PIM-eligible. Eligibility requires an activation workflow, and that workflow may be exactly what's broken during an emergency. The account has to work when everything else doesn't. Count these accounts toward your total Global Administrator headcount. Microsoft's guidance is to keep the number of standing Global Admins small (practitioners often cap it around four), so two break glass accounts leaves room for very few human Global Admins. That's fine; Global Administrator is rarely the right role for daily work anyway.

3. Secure them with phishing-resistant authentication. This is the big change.
For years the standard advice was: give the account a long, complex password and exclude it from MFA so nothing can block it. That advice is now outdated and risky. Microsoft's Secure Future Initiative enforces MFA for admin portals and CLI tools, so an account excluded from everything simply won't be able to sign in. The modern approach:

• Use FIDO2 passkeys on hardware security keys (YubiKey, Token2, and similar). They're phishing-resistant and don't depend on a person's phone, inbox, or PC.
• Use a different authentication method than your normal admin accounts use. If your daily admins use the Authenticator app, your break glass accounts use hardware keys. No shared failure mode.
• Use different key brands for each of the two accounts, so a firmware issue or recall affecting one vendor doesn't take out both.

4. Exclude from blocking policies, but enforce a dedicated one.
Exclude the accounts from any Conditional Access policy that would block or restrict sign-in (report-only policies don't block, so they don't need an exclusion). Then create dedicated policies that require your break glass authentication strength and keep sessions short-lived. The goal: when you run a What If evaluation against these accounts, only your intended break glass policies should apply. Anything else showing up is a bug to fix.

5. Lock down who can manage the accounts.
This is the step that finally killed my "it's just a backdoor" worry. By default, anyone with enough privilege could modify or delete these accounts. Place them and ideally a role-assignable security group containing them inside a Restricted Management Administrative Unit (RMAU), then delegate management through a tightly scoped custom role gated by PIM (short activation window, approval and justification required). Now the accounts can only be touched under strict, fully audited conditions.

6. Store the keys physically, in two places.
Each storage location should hold everything needed to use that account: the physical key and its PIN. Keep one in a secure on-site safe or server room, and the second at a genuinely separate location. Another office or a bank deposit box. The principle: always accessible when needed, never dependent on a single location, and never reliant on online documentation you might not be able to reach during an outage.

That's a robust, modern account. But notice what we haven't done yet and this is the part I'd argue matters most.

How do you monitor and alert on break glass accounts?

Answer: Send your Entra sign-in and audit logs to a Log Analytics workspace, then create an alert rule that fires on any activity from the break glass accounts. Threshold zero, checked as often as possible, routing a critical notification to a monitored shared mailbox. Every sign-in and every change to these accounts should produce an immediate, loud alert. You don't need a SIEM; a simple Log Analytics alert rule is enough for most organizations.

This is the step that converts the account from a liability into a control. An emergency account nobody is watching is the backdoor I feared. An emergency account that screams the instant it's touched is a tripwire working in your favor.

The setup, end to end:

1. Ship the logs. In the Entra admin center, go to Monitoring & health → Diagnostic settings, add a setting, and send the SignInLogs and AuditLogs categories to a Log Analytics workspace. Sign-in logs catch use; audit logs catch changes to the accounts or their group. (Give it time, logs can take up to 48 hours to flow consistently after you enable this.)
2. Grab the object IDs. In Entra ID → Users, open each break glass account and copy its Object ID. These are what you'll filter on.
3. Create an alert rule. In your Log Analytics workspace, go to Alerts → Create → Alert rule, choose Custom log search, and write a KQL query that matches activity where the user is one of your break glass object IDs (across both SigninLogs and AuditLogs).
4. Make it trigger on anything. Set the threshold to greater than 0, and the evaluation frequency as low as possible (1 minute is ideal). You want to know in minutes, not hours.
5. Route the notification. Attach an action group with email/SMS to a shared mailbox that's always monitored, not one person's inbox. Give the alert a clear subject line like [CRITICAL] Emergency Access Activity and set severity to Critical (0).
6. Use a managed identity. Set the rule to run under a system-assigned managed identity with Log Analytics Reader on the workspace and Reader on the action group's resource group, so it keeps working regardless of who last edited it.

A minimal sign-in alert query looks like this:

SigninLogs
| where UserId in ("EA01-Object-ID", "EA02-Object-ID")
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

For full coverage you'll want to union SigninLogs with AuditLogs so you also catch anyone modifying the accounts or their group.

If you already run Microsoft Sentinel, you can do the same thing as a scheduled analytics rule with a ~5-minute lookback and per-event grouping. But be clear: you do not need Sentinel for this. A Log Analytics alert rule is cheaper, simpler, and does the job for the vast majority of organizations, especially smaller ones. Don't let "we don't have a SIEM" become the excuse for having no monitoring at all.

Monitoring tells you that the glass broke. It doesn't tell you why. That's the final piece.

What happens after the glass breaks? (The post-mortem)

Answer: Every use of a break glass account must trigger a post-mortem. Preserve the logs, then determine which of three things happened: a planned test, a genuine emergency, or unauthorized misuse. Examine exactly what the account did and confirm those actions were appropriate. The account regaining access is the start of the incident, not the end of it. The review is what keeps the control trustworthy.

When the alert fires, someone has to ask and answer a simple question: why did this account just get used? There are only three possible answers, and you need to land on one of them:

1. A planned drill — you were testing the account on schedule (good, document it and move on).
2. A real emergency — normal access failed and someone legitimately broke the glass (capture what happened and feed it into your incident review).
3. Misuse or unauthorized use — nobody can account for this sign-in (now you have an active security incident).

The mechanics of the review:

• Preserve the evidence first. Capture the Entra sign-in and audit logs, plus logs from any other systems the account touched, before anything ages out.
• Reconstruct the actions. Walk the audit log to see exactly what the account did while signed in, and confirm every action aligns with what the emergency actually required. An account used to fix a Conditional Access lockout has no business creating new users or changing other credentials.
• Confirm authorization. Match the use against your list of people authorized to use these accounts. If the use doesn't map to an authorized person and a known reason, treat it as a breach.
• Reset and re-secure. After a genuine use, plan to rotate credentials and, if a physical safe was opened, change its combination. Especially if anyone with knowledge of it has since left.

And the post-mortem only works if the surrounding process is already in place, before the emergency:

• Test on a cycle. Validate the full flow. Can you sign in with the key, does the account still hold Global Admin, did monitoring capture it, did the alert fire? Microsoft's floor is every 90 days; many practitioners run a 180-day cadence as a pragmatic balance. Also re-test after any staff change.
• Document precisely. Record which accounts are the break glass accounts, where they're stored, and who is authorized to use them and protect that document as the privileged information it is.
• Train the right people. IAM admins and key stakeholders (CISO, CTO, and others as appropriate) should know what the accounts are, where they live, how to access them, and when they're allowed to be used. Fold it into onboarding for privileged roles.

Do this, and the account I was once afraid of becomes the opposite of a backdoor: a heavily guarded, loudly monitored, regularly rehearsed last resort.

Conclusion

I started out convinced break glass accounts were a danger I'd be foolish to introduce. I was half right. An unmonitored, untested emergency account is dangerous. But the account itself was never the problem. The missing process was.

Build it the modern way: two cloud-only accounts, permanent Global Admin, phishing-resistant FIDO2 keys, management locked behind an RMAU. Then wrap it in the process that makes it trustworthy: an alert on every single use, keys stored in two separate places, a test at least every 90 days, and a post-mortem the moment the glass breaks.

Your action for today, not someday: answer three questions honestly. Do you have at least two emergency access accounts? Have you tested them end to end recently? Would they actually get you back in if everything else failed right now? If you hesitate on any of them, you already know what your next task is.

---

I write regularly about exactly this kind of thing, the parts of Azure and cloud security nobody explains until they hurt.

Microsoft Azure MVP, Freelancer and the person teams call when their Azure setup needs to get secure.

Follow for more. And if this post raised a question for your own setup send me a message. I read and answer every one.

Comments

[Rahul S]

The "no shared failure modes" principle is exactly right for the account, but the place most setups forget to apply it is the alert path. If you're breaking glass because Entra sign-in or your IdP is down, an Azure Monitor alert that emails an M365 mailbox can be unreachable in the exact scenario the account exists for — the detection rides the same plane that just failed. Worth streaming the sign-in logs out of band (diagnostic settings to an Event Hub or a separate-tenant workspace, with SMS/PagerDuty notification that doesn't depend on Entra auth) so the "someone touched it" signal survives a tenant-wide outage. Same logic you applied to the credential, just extended to how you find out it got used.