Those Who Hold the Keys: Break-Glass Accounts Done Right

Alright, Guardians. A few weeks ago I told you how I locked myself out of everything with a single Conditional Access click. If you read that post, you know the moral of the story: the account that saves you is the one you set up before the fire starts.

Every castle in Westeros has a postern gate. It's small, it's hidden, and almost nobody uses it. But when the main gates are sealed and the walls are breached, it's the only way the people who matter get in or out. In Destiny terms, it's your Last City contingency plan: you hope you never call on it, and you drill it anyway.

In Entra ID, that postern gate is your emergency access account, better known as the break-glass account. Most tenants I walk into have one. Far fewer have one that would actually work on the worst day. Let's fix that.

What a break-glass account is (and isn't)

A break-glass account is a highly privileged cloud-only account that exists for one job: getting you back into your tenant when your normal admin path is broken. It is not a spare admin account, a service account, or the shared login for the helpdesk.

Microsoft calls out several situations where you'll need one:

• Federation or your identity provider goes down. If Entra redirects sign-ins to an on-prem IdP that's offline, synced admins can't get in.
• MFA is unavailable. A cell outage, a lost phone or a service issue stops admins from completing MFA or activating a role.
• The last Global Admin leaves. Entra won't let you delete the last Global Admin but nothing stops that account from being disabled or deleted on-prem.
• A PIM dead end. Every Global Admin and Privileged Role Admin is eligible, activation needs approval, and no approver is left to approve it.
• A Conditional Access mistake. Ask me how I know.

If any of those happen and you don't have a working emergency account your next call is to Microsoft support and you'll be proving tenant ownership while your realm sits unguarded.

Forging the keys: how to build them right

These are the non-negotiables from Microsoft's current guidance plus why each one matters in the field.

1. Create at least two. One account is a single point of failure. Two gives you redundancy if a key is lost or an account gets locked.
2. Cloud-only, on the .onmicrosoft.com domain. No federation, no sync from on-prem AD. If your on-prem IdP is the thing that broke, an account that depends on it can't save you.
3. Global Administrator, permanent active. In PIM, set the assignment to active, not eligible. An account that needs activation can get stuck behind the same broken approval chain it's meant to bypass.
4. Phishing-resistant, passwordless authentication. Microsoft now recommends passkeys (FIDO2) first, or certificate-based authentication if you already run a PKI. Both satisfy mandatory MFA for the admin portals.
5. Use a different method than your daily admins. If your admins live in Microsoft Authenticator, put the break-glass accounts on FIDO2 security keys. An Authenticator outage shouldn't take out both paths.
6. Tie them to no person and no personal device. No one's phone number, no one's personal email for SSPR, no one's laptop.
7. Don't let them expire or get cleaned up. Check your inactive account cleanup scripts, access reviews, and lifecycle workflows. A dormant account is exactly what those tools are built to remove.

If you've been following along since the SMS post, notice the theme: the strongest gate is the one with no dependency on a phone network.

Conditional Access: excluded, not exposed

Exclude your emergency access accounts (or their group) from every Conditional Access policy, regardless of what the policy is doing. Microsoft's guidance only calls for excluding them from policies that block or restrict sign-in, but my time in the field has made me stricter than that. Requiring MFA, a compliant device, or a trusted location can make the account useless during the exact emergency you built it for.

"But Kev, isn't an excluded Global Admin a giant hole?" Fair question. The exclusion is safe because the other layers hold:

• The account signs in with a FIDO2 key or certificate, not a password someone can phish or spray.
• The key sits in a safe, not on a desk.
• Every sign-in fires an alert (next section).
• The account is unlicensed so no mailbox threat.
• The account credentials should never be saved to a device to avoid credential caching.

To make this manageable, put both accounts in a dedicated group, something like BG_Accounts, and exclude that group instead of the individual users. New policy? Add the exclusion as part of your build checklist. One missed exclusion is all it takes.

One more tip: draft a few contingency Conditional Access policies in report-only mode now, so you can switch them on during an outage instead of writing them under pressure.

Beyond Conditional Access: close the side doors

Conditional Access isn't the only policy that touches these accounts. Microsoft Learn doesn't spell this part out, but the same BG_Accounts group belongs in a few more places.

Authentication methods. Exclude the group from every method the accounts don't use: SMS, voice call, email OTP, software and hardware OATH tokens, and Microsoft Authenticator. Keep it in scope for passkeys (FIDO2) or certificate-based authentication. An exclusion wins over an inclusion, so nobody can register or use a weak method on these accounts, even by accident.

• Check the method they do use. Confirm the group sits in a passkey profile that allows your specific key model.
• Decide on Temporary Access Pass. You need it to register the first key, but it's also a way into the account. I exclude the group once both keys are registered.
• Exclude the group from the registration campaign. Once the snoozes run out, that nudge can force a registration in the middle of an emergency sign-in.

Self-service password reset. SSPR has no group exclusion, so this one takes two moves:

• User SSPR. If it's set to All, switch it to a Selected group that doesn't contain the emergency accounts.
• Admin SSPR. Admins fall under a separate two-gate policy that's on by default and can't be scoped to a group. With it on, a FIDO2-only emergency account can be prompted to register Authenticator and a phone number at sign-in. Microsoft also notes that this policy doesn't depend on the Authentication methods policy, so the exclusions above don't close it.

The only switch for admin SSPR is tenant-wide:

Connect-MgGraph -Scopes Policy.ReadWrite.Authorization
Update-MgPolicyAuthorizationPolicy -AllowedToUseSspr:$false

That turns self-service reset off for every admin, so make sure your admins are passwordless or can reset each other before you run it. The change can take up to 60 minutes to apply.

Watching the gate: alert on every sign-in

A break-glass account should be quiet. Any sign-in is either a planned drill, a real emergency, or someone who shouldn't be there. All three deserve an alert.

The Microsoft-documented approach uses Azure Monitor:

1. Send Entra sign-in logs to a Log Analytics workspace through diagnostic settings. (I walk through this exact setup in my video. Without it, your sign-in history ages out of Entra.)
2. Grab the Object IDs of both emergency accounts from the Entra admin center.
3. Create a log search alert rule on the workspace with a query like this:

SigninLogs
| where UserId == "<object-id-1>" or UserId == "<object-id-2>"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

4. Set the threshold to greater than 0, severity 0 - Critical, and attach an action group that emails, texts, or calls more than one admin.

Match on Object ID rather than UPN, so a renamed account doesn't silently fall out of the alert. Then add a second rule on AuditLogs for changes to the accounts such as new auth methods or role changes. If you run Microsoft Sentinel, build these as analytics rules instead.

When an alert fires, treat it like an incident: preserve the logs, find out who used it and why, and review every action taken during the session.

Storing the keys and drilling the plan

A key nobody can find is the same as no key. Store the FIDO2 keys in secure, fireproof safes in separate physical locations, with access limited to a short, named list of people. When someone on that list leaves, change the safe combinations.

Then drill it. Microsoft's guidance is to validate the accounts at least every 90 days, and again after IT staff changes or subscription changes. A good drill covers:

• [ ] Tell the SOC a drill is happening so the alert doesn't trigger a real incident
• [ ] Review the list of people authorized to use the accounts
• [ ] Confirm the break-glass runbook is current and the right people know it
• [ ] Retrieve the key, sign in from a designated secure workstation, and perform an admin task
• [ ] Confirm the Critical alert fired and reached every recipient
• [ ] Check that nobody registered personal MFA or SSPR details on the accounts

Put it on the calendar like a raid night. If the fireteam never practices the encounter, nobody knows the mechanics when it counts.

Common mistakes I see in the field

These show up in tenants of every size, from SMB to enterprise:

• Only one account. One lost key or one lockout and you're back to square one.
• Synced from on-prem AD. It looks fine until the on-prem outage that you needed it for.
• PIM-eligible instead of active. The gate is there but it's locked from the inside.
• A password and SMS for MFA. This fails both the security test and the resilience test.
• The admin's phone is the MFA method. That admin goes on vacation, changes phones, or leaves the company.
• Missing from one CA policy. Usually the newest one, built in a hurry.
• No alert, or an alert to one inbox. If the only person notified is the person who left, nobody hears the bell.
• Never tested. The first time anyone tries the key is during the outage, and the key is in a drawer at an office nobody can reach.

The Guardian's checklist

Before you close this tab, check your tenant against this list:

• [ ] At least two emergency access accounts
• [ ] Cloud-only, on .onmicrosoft.com, not federated or synced
• [ ] Global Administrator, permanent active in PIM
• [ ] FIDO2 passkeys or certificate-based auth, different from daily admin MFA
• [ ] No personal devices, phone numbers, or SSPR details attached
• [ ] Excluded from every CA policy, regardless of what the policy is doing, through a dedicated group
• [ ] Excluded from every authentication method the accounts don't use, and from the registration campaign
• [ ] Out of scope for user SSPR, with a decision made on admin SSPR
• [ ] Sign-in logs flowing to Log Analytics, with a Critical alert on any sign-in
• [ ] Keys stored in separate secure locations
• [ ] Validated at least every 90 days, with a documented runbook

The walls of Winterfell didn't fall because nobody built them. They fell because the enemy found the gap. Build your postern gate now, guard it, and test it, so the day your main gates seal shut is an inconvenience, not a catastrophe.

Got a break-glass horror story, or a drill process that works for your team? Drop it in the comments. And if you want to see the Log Analytics setup in action, watch the walkthrough and subscribe on YouTube.

Thanks for reading, and for taking the time to guard your realm the right way. I appreciate every one of you who shows up for these posts.

Eyes up, Guardians.

Sources: Manage emergency access accounts in Microsoft Entra ID and Password policies and account restrictions: administrator reset policy differences (Microsoft Learn)