Emergency access accounts that still work during an outage

An emergency access account exists for the day you cannot sign in as an administrator. A Conditional Access policy locked everyone out. Federation broke. The multifactor provider is having an outage. Someone left and their account held the only Global Administrator role.

These accounts get created during a deployment, tested once, and then inherited. When they are eventually needed, a meaningful proportion do not work — usually because a later change included them in a policy they were supposed to be excluded from.

The threat: what actually goes wrong

Two opposite failures, and a good design has to address both.

The account does not work when needed. It is caught by a Conditional Access policy, its password has expired, it requires a multifactor method nobody can produce, its licence was removed, or it depends on the federation that has just failed. This is the common failure, and it is caused by drift rather than by design.

The account is abused. A highly privileged account with a static, shared credential and no multifactor requirement is an obvious target. If nobody notices its use, an attacker has a permanent administrator with no owner.

The design has to make the first impossible and the second detectable. It cannot make the second impossible, which is why detection carries so much weight here.

Exposure: where these accounts are usually weak

Look at your existing emergency access accounts against this list. In most tenants I have reviewed, at least two items fail.

• Only one account exists, so a single problem with it leaves no path.
• The account is synchronised from Active Directory, so an on-premises failure takes it out along with everything else.
• It uses a custom domain that depends on DNS you might not control during an incident.
• It is not excluded from every Conditional Access policy — usually because a policy created after the account was set up did not know to exclude it.
• Its password is in the same password manager that federates to the tenant you are trying to recover.
• Nobody has signed in with it in over a year, so nobody knows whether it works.
• Its use generates no alert.
• Its role is assigned as eligible in Privileged Identity Management rather than active, so activation requires the very approval workflow that may be unavailable.

Hardening: the configuration that holds up

Create at least two accounts. Two, so that a problem specific to one — a forgotten credential, a corrupted authentication method, an accidental deletion — does not remove the capability. Configure them differently from each other where you reasonably can, so a single systemic issue is unlikely to take both.

Cloud-only, always. Never synchronised from Active Directory. The scenario you are planning for explicitly includes your on-premises environment being unavailable or untrusted.

Use the onmicrosoft.com domain. Not a custom domain. A custom domain depends on DNS records and domain verification that may themselves be part of the problem. The default tenant domain has the fewest dependencies of any name you can choose.

Assign the Global Administrator role permanently and actively. This is the one place I would not use eligible assignment through Privileged Identity Management. Activation depends on Entra ID being able to run the activation workflow, possibly with approval from a person who may also be locked out. An emergency account with an eligible role is an emergency account with a dependency on the thing that is broken.

Exclude them from every Conditional Access policy. Every one, including policies created later. The reliable way to achieve this is a dedicated group that is in the exclusion list of every policy, so a new policy is created from a template that already carries it. Auditing this is a recurring task, not a one-off.

Do not let the password expire, and store the credential physically — a sealed envelope in a safe, or a split credential across two envelopes held by different people. The requirement is that it is retrievable without any system that depends on the tenant.

Give them a strong authentication method that does not depend on a single person or a single external service. A FIDO2 security key stored with the credential is a reasonable answer. The wrong answer is a method tied to one administrator’s phone, because that administrator will be on a flight.

Passwordless and multifactor requirements for these accounts are a genuine trade-off: every control you add is another thing that can fail at the moment you need the account. Resolve it deliberately, write down what you chose and why, and make detection do the rest.

Detection: this is the part that is usually missing

An emergency access account should never sign in during normal operations. That makes it one of the easiest high-fidelity alerts you will ever build: any sign-in at all is either an emergency or an incident.

Configure an alert on any successful sign-in by these accounts, routed somewhere a human reads out of hours — not an inbox nobody monitors overnight. Alert on failed sign-ins too: a failed attempt against a break-glass account is a strong signal.

Also alert on changes to the accounts themselves — role assignment changes, authentication method changes, and any modification to the exclusion group. An attacker who understands the design will target the exclusion group, because membership of it means exemption from every Conditional Access policy you have.

Route these alerts differently from ordinary security alerts. The whole point is that they are rare and they matter.

Validation: exercise them, on a schedule

An untested emergency access account is a belief, not a control. Test at least every 90 days, and always after any significant change to Conditional Access or authentication methods.

The test is a real sign-in, performed by a person who will plausibly be the one doing it for real, following the written procedure — including retrieving the credential from wherever it is actually stored. That last part is where tests fail: the account works fine and nobody can open the safe.

Record each test: who, when, what worked, what did not. When the account is eventually used in anger, that log is also what distinguishes a legitimate use from a compromise.

After the test, confirm the alert fired. An untested alert is the same problem one layer out.

Two further checks worth building into the cycle:

• Re-verify exclusion from every Conditional Access policy, including any created since the last test.
• Confirm the role assignment is still permanent and active, and that nobody has converted it to eligible during a Privileged Identity Management tidy-up.

Operations

Assign an owner. Not a team — a named person, with a named deputy, responsible for the testing cycle and the credential’s physical security.

Rotate the credentials after any use, and after any change in who has access to them. Someone leaving the organisation is a rotation trigger.

Document the procedure somewhere retrievable without the tenant. A runbook in SharePoint is a runbook you cannot reach during the incident it was written for. The same constraint applies to the Active Directory forest recovery plan, and for the same reason — the point is covered in forest recovery planning.

Keep the account count small and the membership of the exclusion group smaller. Every addition to that group is an account exempt from your entire Conditional Access baseline.

What this does not solve

Emergency access accounts get you back into the tenant. They do not tell you why you were locked out, and they do not help if the tenant itself is compromised rather than misconfigured — an attacker with Global Administrator can remove your emergency accounts along with everything else.

They also do not substitute for the broader privileged access design. They are the last resort within it, not a replacement for administrative tiering or for proper role governance.

Verification and limits

Microsoft’s guidance on emergency access accounts — two accounts, cloud-only, the onmicrosoft.com domain, exclusion from Conditional Access, permanent role assignment and monitoring for use — was checked against current documentation on 20 September 2026. The testing cadence and alerting design are my own practice.

No tenant configuration was performed for this article. Creating permanently privileged accounts is itself a security decision: implement the detection and the physical credential storage at the same time as the accounts, not afterwards, and confirm your own regulatory position on shared credentials before adopting the pattern.

References

• Manage emergency access accounts in Microsoft Entra ID
• Securing privileged access for hybrid and cloud deployments
• Conditional Access report-only mode
• Best practices for Microsoft Entra roles