It's 9:12pm and the only admin's phone is dead — the one with the only authenticator app on it. The billing run is tomorrow morning. Somewhere between "we'll figure it out" and the vendor's two-day identity-recovery queue is the difference between an annoyance and a small business outage. The teams that recover in five minutes all have one thing in common: an emergency admin account that was built, sealed, and tested before the bad night.
We just published the full Break-Glass Account Checklist on our ops notes — here's the shape of it.
What it is: one cloud-only admin identity per provider (Microsoft 365, Google Workspace), named for the job — bg-emergency@ — never after a person. It's exempt from conditional access and federated SSO on purpose, documented, so it still works on the day the identity provider itself is the problem. That exemption is also what makes it the credential attackers want most, which is why the checklist is mostly about keeping it asleep.
The seal. The 20+ character 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." Print it, envelope it, signature across the flap, safe. The envelope holds the backup codes and the TOTP seed or spare hardware key too. Two copies, two locations, two named custodians. No SMS, ever.
The sleep rules: zero daily use, zero parked browser sessions, zero "temporary" API tokens. An alerting rule where any sign-in pings both custodians 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.
The trigger list, in writing: primary admin unreachable 30+ minutes during an incident; departed admin; IdP outage blocking all admin sign-ins; confirmed admin compromise. A written list is the difference between a controlled emergency tool and a convenience login for Friday afternoons.
Using it: verify the lockout is real before the envelope opens (phishers ride lockout panic), log who/when/why/what as you go, then rotate everything and re-seal the same day — anyone who saw the screen has effectively seen the credentials.
The quarterly test — fifteen minutes: sign in for real, confirm the roles survived the quarter's policy changes, check the backup codes and the safe device's TOTP, log it, re-seal it. An untested break-glass account is a myth with a password.
And if you're locked out right now with no such account: both major vendors have identity-recovery paths, and they move as fast as your proof of domain control (registrar login, DNS TXT access, billing records). Verify the story while you recover — and build the account the same week you get back in. The day after, not the day of.
The full checklist — including the two-person rule, the post-use rotation, the annual tabletop ("the only admin resigned effective immediately"), and the audit of the lockout window — is free on the site:
📄 Break-Glass Account Checklist for Small Business
Related reading: the MFA device lost runbook, the MFA rollout checklist, and the first 30 minutes of incident response.
If you want the whole ops library as ready-to-use templates — SOPs, incident runbooks, access reviews — the paid kits live at hive80lab.gumroad.com.
MDEEOF
/usr/bin/python3 - <<'PYEOF'
import json, urllib.request
key = open('/Users/haroonqamer/Swarm/hive/state/secure/devto_api_key.txt').read().strip()
body = open('/tmp/devto_body_95.md').read() if False else None
payload = {"article": {
"title": "The Break-Glass Account: Build the Emergency Admin Login Before the Lockout",
"published": True,
"tags": ["security", "smallbusiness", "devops", "infosec"],
"canonical_url": "https://hive80-lab.github.io/ops-notes/break-glass-account-checklist.html",
"body_markdown": open('/tmp/devto_body_95.md').read(),
}}
note: file written below is devto_body_95.md via separate cat
PYEOF
echo "body-lines:$(wc -l < /tmp/devto_body_95.md 2>/dev/null || echo MISSING)"
Top comments (0)