What is a break-glass procedure?
Glassbreak Team · Published 2026-07-16
A break-glass procedure is a controlled process that grants emergency access to a critical secret or system when the normal access path is broken, offline, or too slow for the situation — for example, when your SSO provider is down, an on-call engineer is locked out of a production credential, or a key person is unreachable during an incident. The name comes from the physical glass-fronted box that houses a fire alarm or a spare key: you break the glass only in an emergency, and doing so is visible, deliberate, and leaves a record. A good break-glass procedure applies that same discipline to digital access — it isn't a bypass of your security controls, it's a defined, audited path through them for the moment normal access fails.
Why teams need one
Every access-control system has a failure mode: the identity provider goes down, a device is lost, a key holder is on a plane, or the one person who remembers the database password has left the company. Without a deliberate break-glass path, teams improvise — sharing a password over chat, storing a credential in a spreadsheet "just in case," or discovering during a real outage that nobody actually has access to the thing they need to fix it. Each of those improvisations trades a small amount of convenience for a much larger, harder-to-see risk: a shared secret with no audit trail, no expiry, and no record of who used it or why.
A defined break-glass procedure removes the improvisation. It answers, in advance, four questions your team would otherwise have to answer under pressure: what counts as an emergency, who is allowed to declare one, what has to happen before access is granted, and what gets logged afterward.
The four parts of a break-glass procedure
A defined trigger. What situation justifies breaking glass — an ongoing incident, a key person unreachable for a set period, or an infrastructure component that's failed. Vague triggers ("if it seems urgent") lead to inconsistent use.
An authentication or approval step. Who has to sign off, and how many of them. The strongest designs use quorum-based approval — a threshold of independent, authorized people (for example, 2 of 4 designated approvers) who must each approve before access is decrypted or granted. Below that threshold, nobody — including the service operating the system — can produce the access. This is meaningfully stronger than a single shared password, because no individual account compromise or insider action is enough on its own.
Time-boxed, scoped access. Emergency access should be narrower and shorter-lived than routine access, not broader. Good implementations grant exactly what's needed for the incident and expect it to be revoked or rotated afterward.
An audit trail. Every trigger, approval, and access — successful or not — should be logged with who, when, and (where relevant) why. This is what turns break-glass from "an exception to security" into "a monitored extension of it." Reviewing that trail after the fact, even when the access was entirely legitimate, is part of the procedure, not an optional extra.
How Glassbreak implements break-glass
Glassbreak is built around this pattern rather than treating it as an add-on. Secrets are encrypted client-side and stored so that Glassbreak itself never holds anything it could decrypt; recovering a team secret requires a quorum of authorized members to approve, using threshold cryptography rather than a shared password or a support-desk override. You can read the full cryptographic design, including the specific algorithms and the threshold model, on the security page.
Alongside secret recovery, Glassbreak provides the rest of the emergency-access chain: emergency messaging and call trees to reach the right people fast, playbooks that turn a break-glass trigger into a concrete sequence of steps instead of tribal knowledge, and escalation rules that bring in additional responders automatically if the first ones don't answer in time. Every trigger, approval, and access is recorded in an audit trail your team can review afterward. The how it works page covers the infrastructure behind this — including why it runs across two independent cloud providers, so an outage at one provider doesn't also take down your emergency-access path.
Getting started
Glassbreak's Free plan supports a single team with up to 5 members, 3 encrypted contacts, and encrypted chat and calls — enough to define a real break-glass procedure and test it before you need it. Paid Team ($15) and Business ($39) plans add unlimited teams and contacts, playbooks, and escalation rules, billed per responder seat; members who only receive and acknowledge alerts stay free and unlimited on every plan. Paid billing is rolling out during early access — you can request early access to a paid plan today, and the Free plan has no time limit while you wait. Enterprise plans are custom-priced for larger organizations.
The best time to define your break-glass procedure is before an incident forces you to improvise one.
Frequently asked questions
- Is break-glass the same as a master password?
- No. A master password is a single credential anyone holding it can use at any time. A break-glass procedure is a process — it defines who can trigger emergency access, what approval (if any) is required, and what gets logged. Some break-glass implementations use a shared secret as part of that process, but the process, not the secret, is what makes it break-glass.
- Who should be able to trigger a break-glass procedure?
- As few people as your team can operate with. Most teams designate a small set of on-call responders or incident commanders as the only accounts that can initiate an emergency request, with everyone else limited to acknowledging or approving it. Widening the trigger list defeats the purpose — you're building a fast, audited emergency path, not a shortcut around normal access controls.
- Does a break-glass procedure need quorum approval, or can one person do it alone?
- It depends on what's behind the glass and how much damage a single wrong or malicious trigger could cause. For low-stakes access, a single authorized responder with logging may be enough. For high-value secrets — production database credentials, root cloud access, encryption keys — most teams require a quorum: two or more independent approvers before access is granted, so no one person can break glass alone.
- How is break-glass different from a normal incident response runbook?
- A runbook describes the steps responders follow during an incident — who to page, what to check, when to escalate. Break-glass is specifically the mechanism for the moment a runbook needs access that isn't available through normal channels: a locked-out admin account, an offline SSO provider, or a secret only decryptable with peer approval. Break-glass is usually one step inside a broader incident response plan, not a replacement for it.