- › Emergency access accounts are excluded from multi-factor and conditional access policies on purpose, so somebody can still sign in when those controls break.
- › That makes them the most privileged and least controlled accounts in the environment, and they are rarely used, rarely reviewed, and often known to people who have left.
- › Many are also stored somewhere that depends on the very systems they exist to recover, such as a password manager behind single sign-on.
- › Keep two, cloud-only, protected by hardware keys held in separate physical locations, with every sign-in alerting leadership through a channel outside the identity provider.
- › Test them on a schedule, write down when they may be used, and make sure they are the only accounts on every policy's exclusion list.
Picture the last slide of a zero trust rollout. Every user signs in with multi-factor authentication, every device has to pass a compliance check, sign-ins from unexpected countries are blocked, and administrators need a phishing-resistant key. It is a genuine improvement, and the project team has earned the celebration.
Now open any of those policies and scroll to the bottom, where the exclusions are listed. There are two accounts, usually with names like emergency-admin-01 and emergency-admin-02, excluded from every rule on the slide. They hold the highest privilege in the tenant, and signing in to them takes nothing but a password.
That exclusion is correct design, and every serious identity deployment needs something like it. It also describes exactly what an attacker would want, which is why these accounts deserve more care than they usually get.
Why the Exception Has to Exist
Identity controls fail in ways that lock everybody out at once. An administrator publishes a conditional access policy with a mistake in it and blocks every admin from the console. The multi-factor service has an outage. A federation certificate expires overnight and nobody can complete a sign-in. Each of these has happened to real organizations, and each turns a configuration error into a business stoppage.
Emergency access accounts, often called break-glass accounts, are the way back in. They sit outside the policies that broke so that a person can sign in and fix the mistake without opening a support case with the identity provider while the business waits. Identity vendors generally recommend keeping them, and a zero trust program without them is one bad policy away from an outage nobody can undo.
So the question is never whether to have them. It is what keeps them from becoming the softest way into the most important system you run.
Why They Are the Best Target in the Environment
Look at them the way an attacker would, starting with the fact that they hold global administrative rights. They are exempt from multi-factor authentication and every conditional access rule by design, so a single password is the whole defense. And because they are used rarely, there is no normal pattern of activity to compare against, which means a sign-in that should alarm everybody often alarms nobody.
The credential tends to age badly. It was set during the rollout by an engineer who may since have left, and it has been read by the help desk lead who once used the account to fix a stuck policy at two in the morning. It is excluded from access reviews because everybody agrees it is special, and in many organizations it has not been rotated since the day it was created. We described this pattern for ordinary accounts in identity and access management: what to fix first, and these accounts carry it at maximum privilege.
They are also easy to find. Anyone who gains read access to your identity configuration can see exactly which accounts each policy excludes, so an attacker who lands in the tenant with modest rights does not need to guess which accounts skip the controls.
The Recovery That Depends on What Failed
There is a second failure that only shows up on the day you need the account. Where is the password kept?
In a surprising number of organizations, the answer is a password manager that the administrators reach through single sign-on, or a vault that authenticates against the same identity provider. On the day the identity provider is the thing that is broken, the emergency credential is locked inside it. We made the same point about recovery credentials in the backups were fine and you still lost a week, and it applies with even more force here.
The same trap catches accounts that are synchronized from an on-premises directory. If the account depends on federation or directory synchronization, it fails when those fail. An emergency account has to depend on as little as possible.
How to Keep Them Without Leaving a Door Open
The controls that work here are a mix of technical protection, physical custody, and visibility. None of them is expensive, and all of them can be in place within a quarter.
Keep exactly two, and keep them cloud-only
Two accounts give you a fallback if one is compromised or its credential is lost, and more than two is more to watch. Create them directly in the identity provider, with no synchronization from on-premises, no mailbox, and no license beyond what they need, so that they depend on nothing that might be part of the outage.
Protect them with hardware keys held in separate places
Excluding an account from conditional access does not have to mean a password alone. Where your identity provider allows it, register phishing-resistant hardware security keys directly to each account and store them in separate physical safes, ideally in different buildings. The account then depends on a physical object that no remote attacker can phish, and on nothing that is likely to fail in the same outage.
If a password is also required, split custody of it. Two sealed envelopes held by two different people, each with half, means no single person can use the account alone.
Alert on every sign-in, through a channel that survives the outage
There is no routine, silent use of an emergency account, so every sign-in should page security leadership immediately. Send that alert through a path that does not depend on the identity provider, such as a monitoring service with its own credentials that sends a text message, because the day the account is legitimately used is the day the normal alert path may be down. Review every use afterward, even the legitimate ones, and record who used it, why, and what changed.
Test them on a schedule
An emergency account that has never been tested is an assumption. Every quarter, have the named custodians retrieve the keys, sign in, confirm the account still has the access it needs, sign out, and document it. Rotate any password component after each test, and replace the keys if anybody who knew where they were kept has left.
Write down when they may be used
A short policy is enough: the accounts are used only when normal administrative access is impossible, a named person authorizes the use, and every use triggers a review. Without it, the account slowly becomes the help desk’s shortcut for anything awkward, and that is how a password ends up known by half the IT team.
Make sure they are the only exclusions
Read the exclusion list on every conditional access policy. It should contain the two emergency accounts and nothing else. In practice, exclusion lists collect “temporary” entries: an executive who could not get a key working before a flight, a service account that broke, a scanner that could not do multi-factor. Each of those is a risk somebody accepted without saying so, and the risk nobody remembers accepting covers how to put an owner and an end date on every one.
Trust You Cannot Remove, So You Watch It
Zero trust means no account is trusted because of where it sits or what it is called. The emergency account is the one deliberate exception, the place where you choose to trust a credential because the alternative is being locked out of your own environment.
You cannot control that account with policy, because escaping policy is its job. What you can do is make it physically hard to use, impossible to use quietly, and regularly proven to work. Our guidance on zero trust for the estate you actually have argues for starting where the real exposure is, and for most environments these two accounts are a far better place to start than another policy for the people who already pass every check.
Chris Armour is Director of Information Security at Grab The Axe.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
