Entra ID emergency access accounts: set them up without creating a back door

Why these accounts exist

An Entra ID tenant can lock itself out. A badly targeted Conditional Access policy, an MFA provider outage, an unavailable federation service, the departure of the only Global Administrator: in each case, nobody can open the portal to fix things. Emergency access accounts — "break-glass" accounts — are the key kept behind the glass for these situations.

The problem is that a permanent Global Administrator, excluded from the usual controls and rarely used, is also exactly what an attacker is looking for. The whole point is to keep the key usable without leaving it in the door.

The ground rules

• Two accounts, not one. If one becomes unusable (lost key, configuration error), the other takes over.
• Cloud-only accounts on the *.onmicrosoft.com domain, never synchronized from Active Directory: an on-premises compromise or outage must not be able to reach them.
• Global Administrator assigned permanently, not eligible through PIM: in the middle of a crisis, PIM activation itself may be blocked.
• No link to a person: no employee name, no mailbox in use, no licence required.

Strong but independent authentication

The historical practice was a long password split into two halves held by two people. That is no longer enough: Microsoft now enforces multifactor authentication for access to the admin portals, and a plain password remains the ideal target for a spray attack.

Current good practice is a phishing-resistant method — FIDO2 security keys or certificate-based authentication — that depends neither on an employee's phone nor on a service likely to be down at the same moment. Each account gets at least two keys, stored in different physical locations, with a written check-out and return procedure.

Exclude from Conditional Access with care

Emergency accounts should be excluded from policies that can cause a lockout: compliant device requirements, location restrictions, risk conditions that depend on a third-party service. The exclusion goes through a dedicated group, and that group must itself be protected: if any group manager can add a member, they have just created a universal Conditional Access bypass. A role-assignable group, whose membership can only be changed by a privileged role, closes that door.

Watch every sign-in

An emergency account almost never signs in, so every sign-in is an event. Entra ID sign-in logs sent to Log Analytics or Microsoft Sentinel allow a simple alert rule: any authentication attempt — successful or failed — on one of these accounts triggers an immediate notification to several recipients. A series of failures is as important a signal as a success.

Test it, or it will not work on the day

A procedure that has never been tested is only an assumption. Schedule a regular test — every quarter, and after any significant Conditional Access change: check out the keys, sign in, verify the rights, return the keys, confirm the alert fired. The test validates both the access and the monitoring.

What an audit checks

• The number of permanent Global Administrators, and which of them really are emergency accounts.
• The account type (cloud or synchronized) and the domain used.
• The authentication methods registered on these accounts.
• The Conditional Access policies that exclude them, and who can change the exclusion group.
• Whether an alert exists on their sign-ins.

Two well-configured accounts are worth more than five "just in case" accounts forgotten for three years. Emergency access should be rare, visible and tested.