Most Break-Glass Accounts Won't Work When They're Actually Needed
Most break-glass accounts are a tickbox. They fail on the day they're needed. Here is what working emergency access looks like on M365 and Google Workspace.
TL;DR
A break-glass account is the door you use when every other door has slammed shut. In most tenants we audit, it doesn’t work. Password expired. MFA on a phone that walked out with the previous IT manager. Credentials in a vault that’s behind the same SSO that just broke. A working setup is documented, excluded from every policy that could lock it out, behind a hardware key in a physical safe, tested quarterly. Two accounts. Two safes.
What is a break-glass account?
It’s the deliberately isolated administrator account you use when the normal route into your tenant is broken. Not the founder’s personal login with extra rights bolted on. A specific account, created on purpose, sitting idle 364 days a year and earning its keep on the 365th.
Two things matter from the start. First, the account must be cloud-only. If your on-prem Active Directory has gone offline and the break-glass account is synced from it, you don’t have a break-glass account; you have a politely worded outage. Second, there should be at least two. One is a single point of failure: lose the hardware key, lose the safe key, lose the engineer. Two accounts in two physically separate locations is the minimum that takes this seriously.
If you remember nothing else: two accounts, two locations, cloud-only.
Why do most break-glass accounts fail?
We audit a lot of tenants. The break-glass account, when it exists at all, is almost never tested and almost never functional.
The password has expired. Default password policies still apply because nobody thought to exclude the account. The reset prompt requires MFA. The MFA factor is on a phone the engineer no longer has. Round we go.
The credentials are in a vault behind the same SSO that just broke. This one takes thought to set up and the thought went in exactly the wrong direction. Everything in 1Password, 1Password federated to M365, M365 broken, vault unreachable. We have seen clients offline for 18 hours recovering from this.
A Conditional Access policy locks the account out. “Require Compliant Device” applied tenant-wide. Break-glass account not enrolled in Intune. Can’t satisfy the policy. Can’t sign in. We have walked into this exact failure four times, often because a second engineer added a seventh CA policy six months after the first six were configured and used a different exclusion group.
Nobody has tested it. The account was set up two years ago by an engineer who has since left. The credentials are in an envelope in a drawer. Nobody has opened the drawer. The day the tenant locks itself, the current team discovers the answer to all of the above at once, in the worst possible order.
There’s a sixth failure worth naming: the account exists, the credentials work, but nobody on the current team knows where they are. The bus-factor failure. Different from the others in that it requires organisational amnesia rather than technical negligence.
What a working break-glass setup looks like
Excluded from every Conditional Access or context-aware policy that could lock it out. Create a group (call it Group_BreakGlass), add both accounts, and apply that group as the exclusion on every CA policy. The “every policy” rule is the one people forget when they add a seventh or eighth policy six months later. Build exclusion of that group into your policy checklist the same way you build in report-only mode.
A FIDO2 hardware security key in a physical safe. YubiKey 5 NFC or YubiKey 5C NFC depending on whether the rescue laptop has USB-A or USB-C. Google Titan keys work just as well on the Workspace side. The key is registered against the break-glass account, locked in a fireproof safe at the company’s primary location. Combination held by named directors, not the IT team.
The password sealed in an envelope in a different physical safe. Long, random, written by hand, never typed into a password manager. Stored in a tamper-evident envelope, signed across the seal. Held in a second safe at a second location: a director’s home, an attorney’s safe, a bank deposit box. The holder of the FIDO2 key is not the holder of the password. That separation is the point.
Sign-in monitoring. Both accounts have alerts wired up. Any sign-in, successful or failed, fires an alert to named directors. If the account is being used and nobody authorised it, the right people know within a minute.
How it works on Microsoft 365
Two cloud-only Global Administrator accounts named breakglass-01@yourtenant.onmicrosoft.com and breakglass-02@yourtenant.onmicrosoft.com. The .onmicrosoft.com domain matters: if your custom domain’s DNS goes wrong, the .onmicrosoft.com route still works. Not synced from on-prem AD.
Both accounts excluded from every CA policy via Group_BreakGlass: the MFA policy, the compliant-device policy, the geo-restriction, the BYOD app protection policy, everything. The FIDO2 key registered against the account is phishing-resistant MFA, it just isn’t CA-enforced. The account is both “excluded from CA-enforced MFA” and “protected by phishing-resistant MFA at sign-in.” Document that in your CA notes so the auditor doesn’t tick the wrong box.
Monitoring alerts through Entra Sign-in Logs. Any sign-in, successful or failed, fires an alert to a named distribution list.
How it works on Google Workspace
Two super-admin accounts (Workspace’s equivalent of Global Administrator). They live inside the primary domain because Workspace has no .onmicrosoft.com equivalent, so domain-DNS health is a dependency to plan around.
Cleanest pattern: put the break-glass accounts in an OU where 2-step verification is “allowed but not enforced,” enrol them with a security key as primary factor and printed backup codes as fallback. Backup codes matter because Google’s super-admin recovery flow takes 24 to 72 hours and you do not want to be watching a “we’ll get back to you in three days” message while your tenant is locked.
Recovery phone: a physical SIM held by the company, not a personal mobile. Credentials, security key serial numbers and backup codes held by named directors. Updated whenever a director changes.
How to test without breaking your live tenant
Four steps. Run them quarterly.
Sign in. From a clean machine not enrolled in MDM, on a network that isn’t your office, retrieve the password and the FIDO2 key from their safes and sign in. If it fails, the test has done its job.
Verify access. Confirm the account can open the admin centre, view users, view policies, view licensing. No changes. Just confirm the rights are real.
Sign out. Browser closed, key removed.
Rotate the evidence. Reset the password, seal a new envelope, destroy the old one. Review the sign-in event in the audit log to confirm the alert fired and was acknowledged. Write down the date, who signed in, who held the password, who held the key, and any findings.
The whole exercise takes about 45 minutes. Rotate the test owner: Q1 IT manager, Q2 CFO, Q3 external advisor, Q4 a non-technical director. If the procedure only works when one specific person does it, that’s a single-point-of-failure wearing a break-glass costume.
Common failures from real audits
Password manager locked behind the broken SSO. 1Password federated to M365. M365 broken. Credentials unreachable. Customer was offline for 18 hours.
The FIDO2 key the previous IT manager took home and lost. Cloud-only, CA-excluded, correctly registered. One registered key. He left. Thought it was in his desk drawer. It wasn’t.
Break-glass excluded from MFA but not from device compliance. Added in a second CA policy six months later by a different engineer using a different exclusion group. The account couldn’t sign in.
Break-glass enrolled in PIM by accident. A PIM rollout swept everyone in, including the break-glass accounts. On test day they had no permanent rights and the elevation process required MFA. Break-glass is the one PIM carve-out: permanent Global Admin, by exception, documented.
Recovery phone pointing at a former director. Workspace. Set six years ago. Director had since left. Recovery took five days.
Not edge cases. We hit at least one on every other audit.
The actual cost
A YubiKey 5 costs around R900. A fireproof safe you probably already own. Forty-five minutes a quarter. The cost of not having it is your tenant: 18 hours of recovery time if you’re lucky, or the “sorry, we can’t recover that” call if you’re not.
The Workspace equivalent is in the Google Workspace Lockdowns guide.
Get a free break-glass audit
We’ll review your existing break-glass setup, test the procedure with you, and give you a written list of the gaps in plain language. No charge. One hour. You get a procedure document you can hand to your auditor or insurer.
Email support@osh.co.za or use the contact form. We respond with a calendar link the same business day.
