Break-glass access that does not depend on the thing that broke.
The credentials you need during an identity-provider outage cannot be stored behind that identity provider. Everyone knows this. Almost nobody has actually untangled it.
The circular dependency
The cloud root account is in the password manager. The password manager authenticates through Okta. Okta is down. The runbook explaining the manual failover is in Confluence, which also authenticates through Okta.
What usually happens next is that someone remembers a personal note, or a printout in a drawer, or texts a former colleague. That is the actual disaster recovery plan, and it is nobody’s fault — it is what happens when the emergency path is a subset of the normal path.
What to put in
- Cloud root / global admin credentials and their MFA recovery codes
- Entra ID or Okta break-glass accounts, and the procedure for using them
- Domain registrar and DNS provider logins — the ones that can undo a hijack
- Out-of-band contact details for the people who can authorise a failover
- The runbook itself, as a playbook that can be followed without your wiki
A 2-of-4 quorum across the on-call rotation means any two engineers awake at the same time can get in, and no individual — including a compromised individual — can.
The 2am test
Schedule a monthly drill. It opens a practice incident, pages the real on-call rotation through the real call tree, and walks the real playbook — without touching a live secret or an external contact. If the SMS does not arrive, you find out on a Tuesday afternoon rather than during the outage. That is the entire value proposition, and it is why drills are on every paid plan rather than reserved for enterprise.