Comparison
Break-glass vs. standing admin vs. a shared root password
Emergency access options compared: a standing administrator, a shared emergency or root credential, a manual grant, and time-bound break-glass approval.
With an incident open and nobody answering, a team does one of four things. In the moment they feel about the same. The next morning they could not be more different.
The short answer: a standing admin removes the emergency by making it permanent; a shared root or emergency credential works but cannot say who used it; a manual grant has no end date; and time-bound break-glass lets the requester proceed after a wait, tells everyone, and expires on its own. Only the last leaves nothing behind.
The axis worth comparing them on is not how fast they are at 2am — all four are fast enough. It is what is still true a week later if nobody does anything, because on the morning after an incident, nobody does anything.
The four things teams actually do
1. Keep a standing admin, just in case
The on-call engineer, or the team lead, or everybody senior, simply holds the privilege. There is no emergency path because there is no gate to get past. It is the most common answer by a wide margin, and it is popular for a good reason: it is the only one with literally zero friction when the pager goes off.
What it leaves behind: nothing changes, and that is the problem. The emergency access is not used during an emergency and then put away; it is switched on every hour of every day, on accounts that read email, browse the web and install things. Every day is an emergency access day. It is the arrangement zero standing privilege exists to end, and the "just in case" is almost always the reason it has not ended.
2. Open the shared root password
The emergency account, the AWS root user, the breakglass@ Global
Administrator whose credentials are in a safe. This is the correct tool when sign-in
itself is broken, and the vendors are clear about how it should be kept: Microsoft wants
emergency access accounts
permanently active, in separate safes, alerted on every sign-in and drilled every ninety
days; AWS says not to use the
root user
for anything that does not require it, and suggests splitting its password and its MFA
between two groups of administrators so that no one person can sign in alone.
Read that last recommendation again with a 2am incident in mind. It is exactly right for a credential that can do anything, and it is exactly why that credential is the wrong answer to an approver who is merely asleep: using it properly takes two people and a safe, and using it improperly defeats the reason it was sealed.
What it leaves behind: a credential that is now known to at least one more person and has to be rotated — a new password, a reissued key, a changed safe combination — and an audit trail that names the account, not the human. If the rotation does not happen, the sealed account is no longer sealed, and nothing about the next use of it will look unusual.
3. Grant it by hand, and mean to take it off later
Somebody with admin rights is awake. They add the engineer to the right group in the console, tell them to go ahead, and go back to bed. It is fast, it is attributed — the directory log says who added whom — and it feels responsible, because a person made a decision.
What it leaves behind: a group membership with no end date. Removing it depends on the person who added it remembering, the next day, to undo a favor they did half asleep. That is how access creep happens one incident at a time: each grant was right when it was made, and none of them had a reason to end.
4. Time-bound break-glass
The request goes in as normal. If nobody decides it within a set wait, the person who raised it may approve it themselves — with a written reason, behind a deliberate confirmation — and the approvers and owners are told the moment they do. The grant goes through the ordinary path, so it carries the ordinary expiry.
What it leaves behind: an email in several inboxes and a row in a report. The access itself is gone by the time anyone reads either. That is the whole difference, and it is why the expiry is the part of break-glass that matters.
Side by side
| Standing admin | Shared root / emergency account | Manual grant | Time-bound break-glass | |
|---|---|---|---|---|
| Friction at 2am | None | High if run properly: a safe, often two people | Needs an awake admin | The configured wait, then two confirmations |
| Attributed to a person | Yes | No — the log names the account | Yes | Yes, with their stated reason |
| Who finds out, and when | Nobody; nothing happened | Whoever watches the sign-in alert, if one is set up | Whoever reads the directory log, if anyone does | Approvers and owners, by email, immediately |
| A week later | Still admin | A credential to rotate | Still a member | Access already removed |
| How it fails | Quietly, every day, as standing privilege | Rotation skipped; the seal is gone and nothing says so | Removal forgotten; becomes access creep | Enabled by a team that did not mean to make approval optional |
| Works if sign-in is down | No | Yes — its reason to exist | No | No |
The last row is there on purpose. Three of the four are useless if your identity provider is down, and time-bound break-glass is one of those three. It is not a replacement for the sealed account; it is what stops the sealed account being opened for the wrong emergency.
Which one belongs to which emergency
- Sign-in is broken. The sealed emergency account, used the way its vendor describes, and rotated afterwards. Nothing else on this page works, and nothing else should be tried first.
- Sign-in works and the approver does not answer. Time-bound break-glass. This is the case the other three are usually pressed into, and every one of them leaves something behind.
- The same person needs the same access every week. None of them. That is not an emergency, it is a role that has been scoped wrong. Give them a properly scoped role and review it — the just-in-time access guide covers when elevation is the wrong tool.
- An approver really is always awake. Then you may not need break-glass at all, and a product that offers it should let you leave it off. An around-the-clock approver rota is a better control than any bypass; it is just rarer than people assume.
Time-bound break-glass turns "requires approval" into "requires approval, or the wait". Anyone who can request a package can eventually hold it without anyone agreeing, and that includes whichever package grants admin rights. What bounds it is the expiry and the noise, not a block. For a team whose real alternative is option 1, that is strictly better. For a team that thought approval meant nobody gets in without a yes, it is a surprise — which is why it should be off until someone decides otherwise, in a setting that says this in plain words.
How TemprBac handles it
TemprBac implements option 4 as an org-level setting, off by default: a wait of 5 to 60 minutes, the glass offered only to the requester and only when they could not otherwise approve, a required reason, email to the package's approvers and the org's admins, and a dedicated report. Because it writes an ordinary approval rather than using a grant path of its own, the access expires on the package's normal window like everything else. The details, and the reasoning behind each number, are in break-glass access, without leaving the glass broken.