Break-Glass Account Checklist

A break-glass account is one emergency admin identity that exists for exactly one day: the day nobody can get in. The only admin's phone died with the only authenticator on it. The only admin left and nobody can say why. The identity provider itself is having an outage. Ransomware is on the clock. On that day, a working emergency login is the difference between a five-minute recovery and a two-day vendor-support hostage negotiation. On every other day, that same account is the credential an attacker wants most — which is why this checklist is mostly about keeping it asleep.

1. The lockouts this account is for

• The lost-factor lockout. The admin's phone — with the only TOTP app, the only SIM, the only hardware key — is gone. The MFA device lost runbook gets the person back; the break-glass account is what keeps the company admin plane alive until they're re-enrolled.
• The departed-admin lockout. One person held all the admin ropes and their employment ended badly, abruptly, or both. The offboarding checklist prevents this; the break-glass account is the airbag when it happened anyway.
• The vendor-and-outage lockout. Conditional access or the SSO provider rejects everyone, including admins. An account that bypasses the normal login path still works. This is also the scenario that decides how the account must be built — see below.
• The disaster clock. Ransomware doesn't wait for password resets. The first 30 minutes runbook is calmer when one clean admin credential is sealed in a safe.

2. Build it right on day one

• One per provider, named for the job. A cloud-only admin identity in Microsoft 365 and Google Workspace each — named bg-emergency@yourdomain, never after a person. Person-named emergency accounts get inherited, guessed, or reused by whoever holds the title now. The provider-specific mechanics live in the Microsoft 365 checklist and the Google Workspace checklist.
• Cloud-only, and exempt from the login rules. The account must not sync from or depend on the identity provider it exists to rescue — no federated SSO, no conditional-access policies that can lock it out with everyone else. Exempt it deliberately and document the exemption, because an undocumented exemption looks exactly like an attacker's back door to your next auditor.
• Least-privilege by scenario, not by tradition. Give it the admin roles the disaster actually needs — user admin plus the provider's top-level role — and nothing else. No mailbox, no licenses unless the provider requires them, no group ownerships that accumulate.
• MFA on it anyway — but the survivable kind. No SMS. TOTP on a dedicated second device that lives with the sealed credentials, or a hardware key, plus the provider's backup codes printed alongside. An emergency account without a second factor is the door you left propped open; an emergency account whose second factor lives on the admin's daily phone is the door you bricked shut. The MFA rollout checklist explains why never-exactly-one-factor applies double here.

3. Seal it — offline, outside the vault it may need to rescue

• The password does not live in the password manager. One of the lockout scenarios this account exists for is "nobody can get into the password manager." Storing the rescue key inside the thing it rescues is a circle, not a plan. The password manager rollout covers day-to-day secrets; this one is different on purpose.
• Print it. Envelope it. Safe it. The envelope holds: the generated 20+ character password, the provider backup codes, the TOTP seed or spare hardware key, and one index card saying what this is, which provider, and the three-line use runbook. Two copies, two locations (office safe + a second custodian's sealed copy), because a single sealed copy in a single burning building is not a backup.
• Seal means tamper-evident. Signature across the flap, dated on the outside. You want to know when the envelope was opened, not wonder.
• Name two custodians, not one. The owner plus one senior person who knows the envelope exists and where it lives. Custodians change; the register (below) is how the knowledge moves with them.

4. Keep it asleep: the hardening rules

• Zero daily use, zero tokens. The account signs in only during the quarterly test and real emergencies. No browser sessions parked, no mobile apps enrolled, no API tokens minted "just while we set things up." Dormancy is its armor.
• Alert on every sign-in. An audit-log alerting rule where any bg-emergency sign-in pings the owner and the second custodian immediately. Every sign-in is an incident until someone explains it — including the quarterly test, which gets logged so the alert has a matching entry.
• Include it in every access review. The annual security review and any quarterly access walk must show: roles still least-privilege, exclusion still documented, custodians still correct, envelope still sealed with an intact signature.
• Log the register. One page — the same instinct as the key inventory register: when the envelope was created, re-sealed, rotated, and tested; who the custodians are; where both copies live. The register is public internally; the contents never are.

5. The trigger list: what counts as the emergency

• Write the triggers down before you need them. "Primary admin unreachable for 30+ minutes during an active incident." "Primary admin's access terminated and re-entry impossible." "Identity provider outage blocking all admin sign-ins." "Confirmed compromise of the primary admin account." A written list is the difference between a controlled emergency tool and a convenience login for Friday afternoons.
• Two-person rule for planned use. Any non-active-incident use requires the owner plus one custodian agreeing in writing (a message is fine). Emergencies bypass the rule; the log then explains why.
• Convenience is the enemy. The moment the break-glass account is the easiest way to do something ordinary, it has become the weakest link with a name tag. If a workflow keeps needing it, fix the workflow.

6. The runbook for using it

• Verify reality first. The same reflex as the lost-device runbook: is the lockout real, or is the "locked out admin" a phisher? One out-of-band check before the envelope opens — a lockout is a social-engineering stage set.
• Log the entry as you go. Who opened the envelope, when, why, what was signed in to, what was changed. If the emergency turns out to be a breach, this is your incident timeline's spine, not a reconstruction from memory.
• Fix, then rotate, then re-seal. After any real use: rotate the password, regenerate the backup codes, re-enroll or re-seed the TOTP, new envelope, new signature, register updated the same day. Anyone who saw the screen during the emergency has effectively seen the credentials — treat them as shared.
• If the use was breach-shaped, the account inherits the incident. Run the first 30 minutes runbook against it: the credentials are burned, the audit log for the account's whole dormant history is now evidence, and the post-incident review asks why the trigger fired.

7. The fifteen-minute quarterly test

• Sign in, for real. Once a quarter: open the sealed envelope, sign in with the password and the second factor, confirm the admin roles are intact, sign out. An untested break-glass account is a myth with a password — expired seeds, rotated policies, and dead hardware keys are only discovered in the drill.
• Check the envelope against reality. Backup codes still unused? Safe device still charged, and the TOTP still generating accepted codes? Exclusion from conditional access still in place after the quarter's policy changes? Anything drifted, fix it during the test.
• Log it, re-seal it. Register entry: date, tester, result, re-seal signature. A test without a register entry is indistinguishable from an unexplained sign-in alert.
• Once a year, rehearse the whole disaster. A tabletop: "the only admin resigned effective immediately." The team walks the runbook end to end — trigger list, envelope, recovery, rotation, re-seal — using the offboarding checklist for the human side. The first real emergency should be your second time through.

8. Locked out right now, with no break-glass account?

• Use the vendor's identity-recovery path — but gather proof first. Both major providers have account-recovery processes for exactly this; they take hours to days and hinge on proof you control the domain. Before you start: registrar login, DNS access for a TXT verification record, business registration, recent billing records. The recovery goes as fast as your evidence.
• Verify the story even now. Especially now. "We're locked out" and "someone locked us out" look identical from the inside, and phishers ride lockout panic. If the lockout followed a personnel event or a suspicious email, treat it as a possible compromise and run the first 30 minutes in parallel with the recovery call.
• When you're back in, build the account the same week. This checklist exists so "the day after, not the day of" stops being the story you tell. Recovery without the follow-through is just the first act of a repeat.
• Audit the window. Whoever held the door during the lockout did things with it. Pull the audit log for the whole lockout period before you consider it closed.