When creating our first break-glass set, we originally used a long password on a piece of paper inside an envelope. This worked in theory, but when shining a light through the paper, we could easily read the password without opening the envelope. These are the mistakes we made, how we fixed them and why we recommend each step.
We build two separate cloud-only Global Administrator accounts before we change normal administrator access. Each account has dedicated FIDO2 security keys. The keys and recovery material are sealed, stored at separate premises and tested. A successful sign-in raises an alert.
Microsoft calls these emergency access accounts. The industry calls them break-glass accounts. The identity baseline shows what we collect as audit evidence. The PIM guide covers the access used for normal administrator work.
Build these before PIM
PIM gives people just-in-time access. Break-glass is the exception that stays active. If every Global Administrator is eligible and nobody can approve an activation, the tenant can be locked out.
Create and test both emergency accounts first. Then move normal administrators into PIM.
- Create at least two accounts.
- Use cloud-only accounts on the .onmicrosoft.com domain.
- Don't synchronise or federate them from another identity system.
- Don't name them after an employee.
- Assign Global Administrator as permanent active, never eligible.
- Keep them outside automated inactive-account cleanup.
Use a key, not MFA turned off
Older break-glass advice made the account password-only. Microsoft now recommends a passwordless method. We use dedicated FIDO2 security keys because they don't rely on a phone or push notification.
We keep everyday administrator keys out of the pack. They travel with the laptop and can be lost, damaged or stolen. The emergency key stays in secure storage.
| Control | Normal administrator | Break-glass account |
|---|---|---|
| Authentication | Authenticator or a daily passkey | Dedicated FIDO2 security key |
| Conditional Access | Protected by the administrator policies | Excluded from policies that block or restrict sign-in |
| PIM assignment | Eligible and activated when needed | Global Administrator, permanent active |
| Use | Normal administration | Testing or a genuine emergency only |
Register and record the keys
We keep enough at each location to recover the tenant without opening the other safe. The register records the YubiKey model, serial number, firmware version, account and storage location. It never contains the PIN.
Set the FIDO2 PIN before sealing the key and test the full sign-in. A PIN doesn't turn NFC off. For USB-only use, disable FIDO2 over NFC in YubiKey Manager. Protect that setting with a configuration lock code. You can also buy a key without NFC.
- Register the key against the correct emergency account.
- Set and test the FIDO2 PIN.
- Choose whether NFC remains available and record the decision.
- Record the model, serial, firmware, account and location.
- Match the physical key against the register before sealing it.
Seal the recovery material properly
We now fold the paper so no printed face touches the outside and use an opaque security envelope. That fixed the problem we found with the first pack.
We use serial-numbered tamper seals because a plain sticker can be replaced. The external register records the seal number, account, date and person who sealed it. A replacement seal won't match that record.
This envelope and seal process is our operating standard, not a Microsoft requirement. The recorded number gives us something exact to check during each drill.
Separate the key, PIN and location
We store the sealed sets in fireproof safes at two separate premises. If one location is lost to fire, flood or burglary, the other copy remains.
We memorise the working PIN and keep a sealed recovery copy in the other location. That process is our design rather than a Microsoft requirement. It lets an authorised person recover from a forgotten PIN without putting the PIN in the asset register.
Make the account available when policies fail
Put both accounts in one named EmergencyAccess group. Exclude that group from every Conditional Access policy that blocks or restricts sign-in. Report-only policies don't need the exclusion.
The FIDO2 key protects the account. We remove the policy dependencies because a compliant-device rule or unavailable authentication service could block emergency access.
Check the complete sign-in path because an exclusion in one policy doesn't cover the rest of the tenant configuration.
Alert on every use
An emergency-account sign-in should make somebody aware straight away. Configure an alert for both account object IDs and preserve the sign-in and audit logs.
Review every alert and record whether the sign-in came from a drill, an incident or unauthorised use.
- Alert whenever either account signs in.
- Alert when its authentication methods, role or group membership change.
- Keep the object IDs in the monitoring rule rather than matching only the display name.
- Record who reviews the alert and what they do next.
Run the drill
Microsoft says to validate emergency access accounts at least every 90 days. Our existing process uses 180 days and another test after material changes. Businesses following the current Microsoft guidance should use the 90-day interval.
During the drill, we test the account, the physical pack, the alert and one safe administrative action. We then reseal the pack and record the new seal number.
- Tell the monitoring team that a drill is starting.
- Review the authorised holders and the written process.
- Inspect the envelope, seal number and key serial.
- Sign in from the designated secure workstation.
- Complete one safe administrative task.
- Confirm the sign-in alert reached the right people.
- Check that no personal MFA or SSPR method was added.
- Reseal the pack, record the new serial and write down what changed.
After a real use
Preserve the logs, confirm why the account was used and record what it changed. The emergency fixed the immediate problem, but the reason normal access failed still needs to be corrected.
If the key, envelope or PIN copy left controlled custody, replace the credential and reseal the pack. Don't put the same key back in the safe and call it done.
Build the recovery path before you need it
Create the two accounts, register the dedicated keys, store them separately and test the complete process. We call the build complete after an authorised person can find the pack and sign in. The sign-in must raise the alert and give them enough access to recover the tenant.
Record every decision. The key serial, seal number, location, account, test date and authorised holders should be clear before an incident starts.
Questions people ask
- Is a break-glass account an account with MFA turned off?
- No. Microsoft recommends phishing-resistant passwordless authentication. We use a dedicated FIDO2 security key instead of the method used by normal administrators.
- Why do we need two emergency access accounts?
- One account, key or storage location can fail. If one emergency account is unavailable, the second account can still recover the tenant.
- Why are break-glass accounts excluded from Conditional Access?
- A compliant-device rule or unavailable authentication service could block the emergency account. We exclude it from those policies and protect it with a dedicated FIDO2 key.
- Can we keep the credential in a password manager?
- Not as the only recovery path. A password manager that depends on the same tenant, identity provider or network may be unavailable during the incident. The emergency material needs to remain reachable when the normal systems aren't.
- Why not use the security key an administrator already carries?
- The everyday key travels with the administrator and can leave with their laptop. We seal the emergency key in secure storage, so it stays with the business when somebody changes roles or leaves.
- How often should emergency access accounts be tested?
- Microsoft currently says at least every 90 days. Test again after changes to administrators, authentication, Conditional Access or the emergency process.
- What is a contingency Conditional Access policy?
- It is a policy prepared in advance and kept off until an outage. Turning it on can restore access for critical users when an authentication service fails. You still need the emergency accounts.