Which accounts qualify
This register is not for every account. It is for the short list where losing access, or having one person abuse access, is an existential event. In practice that means the cloud root account, the domain registrar, DNS, the IdP super admin, banking, code signing, and the payment processor. Everything else belongs in the coverage register.
Why a single custodian fails
A single custodian is the failure, not the feature. One person holding the only factor means the company's survival depends on one phone or one person's memory, and that person can act without anyone watching. Two named custodians fix both sides at once: no one can act alone, and no one leaving takes the access with them. The rule is simple to state and almost never followed, because it is easier to give the root account to the person who set it up than to find a second one.
The register
Six columns. The three rows below are examples showing a hardware key in a safe, a TOTP app on a company phone, and a split key held by two people.
| Account / service | Custodians | Authenticator | Authenticator location | Recovery code custody | Last successful test |
|---|---|---|---|---|---|
| AWS root account (1111-2222-3333) | Maria Keller, Daniel Weiss | Hardware key | Office safe, drawer 2 | Sealed envelope in the safe | 2026-07-01 |
| Domain registrar (example.com) | Maria Keller, Sofia Rossi | TOTP app | Company phone in the vault | Sealed envelope in the safe | 2026-06-15 |
| IdP super admin (break glass) | Daniel Weiss, Sofia Rossi | Hardware key, split | Two key halves, two custodians | Split custody across two safes | 2026-05-20 |
The Recovery code custody column is a pointer, never the code. The register tells you where the key is, not how to open the lock.
Column definitions
1 · Account / service
The account plus a stable identifier, such as the AWS account ID or the registrar domain. A bad entry is “the cloud” or “root”, because neither resolves to a login you can test. This column is the index; an ambiguous name means a row that can never be checked.
2 · Custodians
Two named people, and neither can be a team. A bad entry is a single name, which lets one person act alone, or a team name, which means nobody in particular. An auditor reads this column first, because two named custodians is the whole control.
3 · Authenticator
The factor type: a hardware key or a TOTP app. A bad entry is “MFA” with no detail. The type decides where the factor physically lives and how the quarterly test is run.
4 · Authenticator location
Where the factor physically is, down to the building and the drawer. A bad entry is “somewhere” or “the cloud”. A break glass factor you cannot locate does not exist when you need it, and the moment you need it is when the company is already down.
5 · Recovery code custody
A pointer to where the recovery codes are held, never the codes themselves. A bad entry is pasting the codes into a shared spreadsheet. Codes bypass MFA, so their custody has to be controlled and knowable, not written down next to the lock they open.
6 · Last successful test
The date of the last real login with these credentials. A bad entry is a blank, or a date older than the quarter. This is the honesty column: it is the difference between a break glass path and a note that says one exists.
The quarterly test
An untested break glass path is not a path. Every quarter, actually log in with the stored credentials, then reseal the envelope or relock the drawer. Test both custodians' routes, not just one, and write the date in the last column. A register where the test is skipped is a list of hopes, and a hope is not an emergency plan.
Physical storage
Where the factor physically lives matters as much as who holds it. A sealed envelope shows when it has been opened and costs nothing, but it is only as safe as the drawer it sits in. A safe adds physical access control. Split custody means two people each hold part of the factor, so no one can reassemble it alone. Record the choice in the register, because the auditor wants to see that you decided, not that you improvised.
Where it breaks
The register dies quietly. The test date goes stale, a custodian leaves and the row is not updated, the key moves to a new drawer and the location column lies. Nothing in a spreadsheet forces the test to run, so a row that says "last tested March" can silently become a document of confidence you no longer have. RecoveryCodes tracks custodian changes and surfaces stale entries, so the register reflects what is true instead of what was once written down.
Frequently asked questions
What is a break glass account?
An emergency access account used only when normal access fails. It is a root or super admin credential held outside daily use, so the company can still get in when the identity provider or the primary admin is unavailable.
Who should hold the AWS root account MFA?
Two named custodians, with the factor stored where one person cannot act alone. One person holding the only factor is the failure this register prevents: the company depends on one phone, and that person can act with nobody watching.
How often should break glass access be tested?
Quarterly, by actually logging in with the stored credentials and then resealing them. A path that has never been tested is a note, not a path, and the date of the last real login is the only honest evidence.
Should break glass credentials be kept on paper?
Paper sealed in an envelope that shows when it has been opened, held in a safe, is a common and defensible option. The medium matters less than custody and tamper evidence. What an auditor wants to see is that you decided and recorded the choice.
Download the register
No email gate, no form. The spreadsheet has the same columns plus tabs for the procedure and these column definitions.