Break-Glass Accounts: Microsoft's Rules per Tenant

Microsoft's rules for emergency access accounts

Microsoft's guidance comes down to nine rules. Each one below is from Manage emergency access accounts in Microsoft Entra ID (updated 5 June 2026).

How many: "Create two or more emergency access accounts", for redundancy.
Where they live: cloud-only, on the tenant's *.onmicrosoft.com domain, "not federated or synchronized from an on-premises environment".
Role: Global Administrator, with the assignment "active permanent rather than eligible" in Privileged Identity Management. An eligible assignment needs PIM to work, which may be the thing that's broken.
Authentication: a passkey (FIDO2) is recommended, or certificate-based authentication if you already run a public key infrastructure (PKI). Use methods that differ from your other admin accounts. Microsoft says these "satisfy the mandatory multifactor authentication requirements".
Conditional Access: exclude the accounts, through a dedicated group such as EmergencyAccess, from policies that "block or restrict sign-in". Report-only policies don't need the exclusion.
No owner: "Don't associate emergency access accounts with any individual user", and don't tie them to anyone's phone.
Storage: "Store credentials in secure, fireproof safes that are in secure, separate locations", known only to the people authorized to use them.
Alerting: send Entra sign-in logs to Azure Monitor and alert on every use, at severity "0 - Critical" with a threshold of 0.
Testing: validate the accounts "at least every 90 days", and again after a change in IT staff (a termination or a change of role) and when the organization's Entra subscriptions change.

Do break-glass accounts need MFA?

Yes. Excluding an account from Conditional Access is not the same as excluding it from MFA. Microsoft's mandatory MFA page says break-glass accounts "are also required to sign in with MFA once enforcement begins", and its FAQ lists no exception for them.

Enforcement came in two phases. Phase 1 covered sign-in to the Azure portal, the Entra admin center and the Intune admin center from October 2024, and the Microsoft 365 admin center from February 2025. Phase 2 covered Azure CLI, PowerShell, infrastructure-as-code tools and the REST API from 1 October 2025, and the last postponement date Microsoft offered for it, 1 July 2026, has passed.

Plenty of guidance written before 2025 still describes break-glass accounts as the accounts that "bypass" MFA. If a client's break-glass accounts were set up that way, they either fail when you need them or they've already been converted without anyone updating the runbook. Both are worth finding out before the emergency.

An account exempt from the controls everything else follows is also what attackers look for. The Midnight Blizzard attack Microsoft disclosed in January 2024 started with a password spray against "a legacy, non-production test tenant account" that "did not have multifactor authentication (MFA) enabled" (Microsoft's guidance for responders). A break-glass account with a password and no second factor is the same kind of account, with Global Administrator attached.

What Microsoft's rules cost across 40 client tenants

Microsoft writes the rules for one organization. Applied to every client tenant you administer, they multiply. For 40 tenants:

Accounts: 2 per tenant x 40 = 80 permanent Global Administrator accounts.
Scheduled tests: 80 accounts x 4 a year = 320 test sign-ins a year, about six a week.
Unscheduled tests: all 80 again whenever a technician who knew the process leaves or changes role, and a tenant's two whenever that client's subscriptions change.
Alerts: 40 tenants' sign-in logs to route to Azure Monitor, each with an alert on every use.
Storage: 80 sets of credentials and hardware keys, each in a safe in a separate location, each known only to authorized people.

At 20 tenants that's 40 accounts and 160 scheduled tests a year; at 100 tenants, 200 accounts and 800.

In practice three things slip first:

The 90-day test. Nobody owns it, so it lapses, and nobody knows whether the accounts still work until the day they're needed.
The re-test after a departure. Microsoft ties it to staff changes, not the calendar, so it never makes the schedule.
The safe. "Separate locations" becomes one envelope in the office safe, or a shared note that every technician can open.

None of this is a reason to skip break-glass accounts. It's a reason to treat them as 80 privileged accounts that need an owner, a record and a schedule, not as two accounts you set up once per client.

Should break-glass accounts be in PIM?

Not as eligible. Microsoft says to make the Global Administrator assignment "active permanent rather than eligible", because the account has to work when PIM, Conditional Access or your identity provider doesn't. That makes the break-glass account the one standing privilege Microsoft tells you to keep.

That fits a zero standing privilege model rather than breaking it. Everyday admin work moves to just-in-time access, where an account is enabled for a task and switched off after, so the break-glass accounts become the only permanent Global Administrators left in the tenant. They're easy to list, easy to alert on and easy to audit, because nothing else looks like them. The eight phases from discovery to endpoint privilege are walked through in zero standing privilege: the PAM journey for MSPs; break-glass accounts touch four of them: discovery, vault, rotation and audit.

What should a break-glass account be named?

Microsoft doesn't prescribe a naming convention. Its page suggests a security group named EmergencyAccess for the Conditional Access exclusion and says nothing about the account names themselves. Pick a convention, use it in every tenant and record it, because the alert rule and the 90-day test both depend on finding the accounts quickly. Whether the name should announce what the account is, is a judgment call: an obvious name helps your own team and also helps anyone reading the tenant's directory.

On-premises Active Directory and hybrid tenants

Keep them separate. Microsoft says emergency access for on-premises systems and for cloud services should be "distinct, with no dependency of one on the other". The cloud-only rule above exists for the same reason: a synced account fails when the sync, the federation server or the domain fails.

An on-premises break-glass account is usually a domain admin, and passkeys don't help there. It has a password, so it needs what any privileged password needs: one place it's stored, a record of who accessed it, and rotation after it's used. The same goes for a local administrator fallback on a server you can't reach any other way; on Windows, Windows LAPS and a PAM platform are the two usual answers.

Where a PAM platform fits, and where it doesn't

A passkey or a certificate on a hardware key can't go in a password vault. It stays in the safe. If every client's break-glass accounts sign in with passkeys only, the vault argument is weak, and what's left is finding the accounts, keeping a record and proving they're tested.

Most MSPs aren't there. Some client tenants still have passwords on their break-glass accounts; hybrid clients have an on-premises domain admin; and someone has to know, across every client, which Global Administrators exist and which of them are meant to. That's where Panthera fits:

Finding them: Panthera continuously finds privileged identities in each client, from admin accounts to service accounts, identities used by AI agents and break-glass accounts, so the Global Administrators in a tenant are a list you can check against the two you expect.
Storing them: credentials go in a zero-knowledge vault that restricts each one to authorized technicians and logs who accessed it.
Rotating them: on demand, after a drill or a real use, or on a schedule, without the secret leaving the vault.
Connecting to each client: each client's tenant is connected separately, so one compromised connection doesn't expose every other client.
Everyday access: technicians work through dedicated just-in-time accounts that are disabled by default and enabled for a task, with an optional second approval, so the break-glass accounts are the only standing Global Administrators left.

For alerting on a break-glass sign-in, use Microsoft's Azure Monitor alert as described above.

Break-glass checklist for each client tenant

Set up once per tenant:

Create two cloud-only accounts on the tenant's *.onmicrosoft.com domain, not synced and not federated.
Assign Global Administrator as active permanent in PIM.
Register a passkey (FIDO2) or certificate for each account, using methods your other admin accounts don't use.
Add both accounts to a dedicated group and exclude that group from every Conditional Access policy that blocks or restricts sign-in.
Store the credentials and keys in separate secure locations; record who is authorized.
Send the tenant's sign-in logs to Azure Monitor and create an alert on any sign-in by either account, severity 0, threshold 0.
Record the accounts, their owner on your side and the next test date in your documentation.

Then, for every tenant:

Test both accounts at least every 90 days, following your written procedure.
Re-test all of them after any technician who knew the procedure leaves or changes role.
Re-test a client's accounts when that client's Entra subscriptions change.
After any real use, review what happened and rotate any password the account has.

Frequently asked questions

Should a break-glass account have MFA?

Yes. Microsoft's mandatory MFA applies to break-glass accounts with no exception. Use a passkey (FIDO2) or certificate-based authentication, which Microsoft says satisfy the requirement, and keep them different from your other admin accounts' methods.

How many break-glass accounts do I need?

Microsoft says two or more per tenant. For an MSP that means two in every client tenant you're responsible for, not two in your own.

Should break-glass accounts be in Privileged Identity Management?

Their Global Administrator role should be active permanent, not eligible, so the account still works when PIM or Conditional Access is the problem.

How often should I test break-glass accounts?

At least every 90 days, after IT staff changes such as a termination or a change of role, and when the organization's Entra subscriptions change.

What should I name a break-glass account?

Microsoft doesn't set a naming convention. It suggests a group such as EmergencyAccess for the Conditional Access exclusion. Use one convention in every tenant and record it.

Sources (checked 21 October 2026): Microsoft Learn, Manage emergency access accounts in Microsoft Entra ID (updated 5 June 2026); Microsoft Learn, Planning for mandatory Microsoft Entra multifactor authentication (updated 3 April 2026); Microsoft Security, Midnight Blizzard: guidance for responders on nation-state attack (25 January 2024).