Break-Glass Access
Every control needs a route around it for when the control itself fails. Designing that route deliberately, rather than discovering it during an outage.
Procedure
A PAM deployment that cannot be bypassed will be bypassed anyway, informally, during the first serious incident. Designing the bypass is the alternative.
Why it is necessary
The vault will be unavailable at some point.
Identity infrastructure fails, and it is exactly what administrators need to fix.
Network partitions isolate systems from the broker.
The failure may be the incident, so the recovery path must not depend on the thing being recovered.
An undesigned bypass is a permanent exception created under pressure by someone who will not document it.
What a break-glass account is
A local account on the target system, not dependent on the directory or the vault.
Highly privileged, because it exists to fix things.
Rarely used, with use itself being an alerting event.
Credential held offline, in a form retrievable without the systems that may be down.
Designing it
One per critical system or platform, not one universal account.
Credential split where the consequence justifies it โ two halves held by two people, so retrieval requires two.
Stored physically in a safe, or in a system with an entirely independent dependency chain.
Documented: which system, where the credential is, who may retrieve it, what authorisation is needed, and who to notify.
Alerting on use, to a destination that does not depend on the affected system and to people other than the retriever.
Rotated after every use, without exception.
The procedure
A defined authorisation: who can approve retrieval, and what happens if they are unreachable, which is the case that matters.
A record made at the time, even if brief, covering who, when and why.
A review afterwards: was it necessary, what was done, was the credential rotated, what should change so it is not needed next time.
Speed over ceremony. A procedure requiring three approvals during an outage will be ignored. Authorise quickly and review thoroughly afterwards.
Testing it
The step almost everyone skips.
Test annually, at minimum.
Test that the credential works, because passwords expire and accounts get disabled by cleanup scripts.
Test that the physical retrieval works, including out of hours.
Test that the alert fires.
Test the rotation afterwards.
An untested break-glass procedure is a plan, not a capability, and it will fail at the only moment it is used.
Keeping the population small
Break-glass accounts accumulate and become ordinary accounts nobody remembers are privileged.
Maintain a register of every one.
Review annually: is this still needed, is it still correct, has it been used, was it rotated.
Remove the ones no longer justified.
Alert on any break-glass account authenticating without a corresponding retrieval record, which indicates either an undocumented use or something worse.
The cloud case
Cloud tenants need the same thing and the shape differs.
An emergency account outside federation, so a failure of the identity provider does not lock everyone out.
Excluded from conditional access policies that could block it, which is uncomfortable and necessary.
Strong authentication of its own, independent of the federated path.
Monitored aggressively, because it is both the most privileged and the least constrained identity in the tenant.
The register
Break-glass accounts accumulate and quietly become ordinary accounts nobody remembers are privileged.
One row per account: system, purpose, where the credential is held, who may retrieve it, who authorises, who is alerted.
Last tested date and last used date.
Last rotated date.
Reviewed annually, removing what is no longer justified.
Cross-checked against authentication logs, so an account authenticating without a corresponding retrieval record is investigated.
Held in the same place as the degraded-mode documentation, which is where someone will look for it.
Split custody
For the highest consequence accounts, requiring two people to retrieve one credential.
The credential is divided, with each half held separately.
Neither holder can use it alone.
Both retrievals are logged and alerted.
Deputies named for each half, or the scheme fails when one person is unreachable.
Tested, including with a deputy standing in, because that is the realistic case.
Appropriate for tier zero and rarely elsewhere, since the operational cost is real and applying it broadly guarantees it will be circumvented.