In nearly every tenant I look at, the emergency access account is still treated as a relic. People see it as a necessary evil, and it's often the only account with no Conditional Access and a questionable password. The days of "break-glass equals password only" are over, especially now that the Azure and Microsoft 365 admin portals require strong multi-factor authentication by default. Microsoft has made its position clear: emergency access FIDO2 or certificate-based methods are the new baseline. That matters for compliance, but it matters more for actually getting back in when the worst happens.

Microsoft now expects FIDO2 or certificates for emergency access

The bar has moved a lot in the past year. Since mandatory Azure MFA enforcement started reaching the admin portals in October 2024 (see my first-hand experience), there aren't many good arguments left for a break-glass setup that relies only on exclusions. Microsoft now recommends two emergency accounts, each with a different strong authentication method. Ideally one uses FIDO2 and the other certificate-based auth. The hardware tokens or smartcards for these accounts belong in physically separate safes and should never be within reach of normal admin routines. I know this can feel like compliance overkill. Still, I've seen it make a real difference when something goes badly wrong and you have to regain control quickly.

Break-glass accounts need narrow CA exclusions and enforced authentication strength

With break-glass, you want to exclude the accounts from Conditional Access just enough to guarantee access, but not so much that they become the weakest link. I usually create a dedicated group (e.g. "Emergency Access Accounts") and keep the CA policy exclusions limited to what's really necessary. Don't exclude these accounts from every policy. Enforce authentication strength explicitly and set it to "strong" (see FIDO2 passkey configuration or CBA for details). You can build separate policies that target only the break-glass group and require the right method. Microsoft's latest guidance is clear on this. In practice, though, I keep running into admins who have accidentally exempted break-glass from everything, and that's a dangerous mistake.

# Example: Create a group for emergency access accounts
# PowerShell 7, Microsoft.Graph module, Privileged Role Administrator role required
New-MgGroup -DisplayName "Emergency Access Accounts" -MailEnabled:$false -SecurityEnabled:$true -MailNickname "emergencyaccess"

Tip from the field: Give your break-glass group a generic name. If you call it "breakglass", attackers (and curious users) will find it straight away in the tenant explorer.

I set up two accounts with two methods in two safes

These days I always create two emergency accounts. One is secured with a FIDO2 token (YubiKey, Feitian, etc.), the other with certificate-based authentication. The tokens or smartcards go into separate safes, ideally at different locations. You can enable FIDO2 through the authentication methods policy. Don't register the tokens to an individual person. Use a secure admin workflow instead, with dual custody if you can manage it. These accounts must never be used for daily work, and weaker methods have no place on them. They exist for break-glass only and are not just another admin account.

Every break-glass sign-in should trigger an alert

The biggest risk with emergency accounts is use that nobody notices, whether it's an attacker or a well-meaning admin. Targeted Log Analytics alert rules take care of that. As a prerequisite, SigninLogs must be streamed to a Log Analytics workspace (this requires Entra ID P1 or higher and configured diagnostics). In the workspace, under Logs, the following KQL query catches any sign-in from your emergency accounts:

SigninLogs
| where UserId in ("<object-id-account-1>", "<object-id-account-2>")

Turning this query into an alert rule only takes a few minutes. I also recommend sending the notifications to a dedicated SOC mailbox or the on-call team. Monitoring doesn't replace regular testing, of course. At least once a quarter, check that access works end to end (tokens, group membership, CA policy).

The modern break-glass process runs from the safe to the alert

The diagram below shows the whole process for emergency access FIDO2 and CBA, from the trigger through to alerting:

flowchart TD
    Outage["Admin access lost"] --> Safe1["FIDO2 token from safe 1"]
    Outage --> Safe2["Smartcard from safe 2"]
    Safe1 --> FIDOLogin["Sign in with FIDO2"]
    Safe2 --> CBALogin["Sign in with CBA"]
    FIDOLogin --> CA["Conditional Access checks auth strength"]
    CBALogin --> CA
    CA --> Access["Admin access granted"]
    Access --> Monitoring["Sign-in monitoring: alert"]

Figure: Emergency access through separate methods, with CA enforcement and monitoring.

Emergency access has to become routine work

You can't set up break-glass accounts once and forget about them anymore. If you follow Microsoft's current recommendations, test access regularly and put proper monitoring in place, you close one of the last big gaps in your Microsoft 365 and Azure identity security. To be blunt, if your emergency access still depends on a password alone or the Authenticator app, you're behind. If you want to go further, have a look at my articles on emergency access accounts, mandatory MFA enforcement and authentication strengths in practice.