Break-glass access is a pre-defined emergency path that lets a small, named group get access they don’t normally hold, when the normal route is unavailable or too slow. Every use is alerted, time-limited and reviewed afterwards. For customer data, it’s how support reaches an account during an incident without anyone keeping standing access the rest of the time.
The name comes from the fire alarm behind glass: anyone can see when it’s been used. That’s the point. Break-glass access isn’t a faster way in. It’s a visible exception to a rule that otherwise says nobody holds access to customer data by default.
What is break-glass access?
Break-glass access is emergency access to a system through a separate, pre-built route, used only when the normal access process can’t be used. Primary sources describe it in similar terms:
- AWS’s Well-Architected Framework (opens in a new tab) calls it an emergency access process and recommends documenting which failure modes count as emergencies, pre-creating what the process needs, alerting on use and testing it periodically. It also warns that “break-glass procedures can be considered a backdoor”.
- Microsoft Entra’s guidance (opens in a new tab) reserves emergency access accounts for “break glass” scenarios where normal administrative accounts can’t be used. It recommends alerts on every use, a review after any use and validation at least every 90 days.
- NIST SP 800-53 control AC-2(2) (opens in a new tab) asks organizations to remove or disable emergency accounts automatically after a defined period, rather than when an administrator gets around to it.
- If you handle health data, the HIPAA Security Rule (opens in a new tab) lists an emergency access procedure as a required implementation specification for systems holding electronic protected health information.
Most of that guidance is about infrastructure, such as cloud accounts or directory admins. The same principles apply when the thing behind the glass is a customer’s account in your product.
How is break glass different from zero standing privileges and JIT?
Zero standing privileges is the default state: nobody holds privileged access until a specific request is approved. Microsoft describes its own version (opens in a new tab), zero standing access, as service personnel having no standing privileged access to production or to customer data. Just-in-time access is the normal way access is granted in that model. Break glass is the documented exception when the JIT route can’t respond in time.
| Standing access | Just-in-time access | Break-glass access | |
|---|---|---|---|
| Who holds access by default | Everyone with the role | Nobody | Nobody |
| How it’s granted | Already granted | Request and approval | Pre-authorized emergency path |
| Typical approval | None | Another person, before access | Self-invoked or fast-tracked, reviewed after |
| Duration | Indefinite | Short, chosen per task | Shorter still, no renewal |
| How often it’s used | Constantly | Routinely | Rarely, and each use is investigated |
Break glass only makes sense once you have zero standing access. If every agent can already open every account, there’s no glass to break. The just-in-time access guide covers the normal route.
When should support use break-glass access to customer data?
Use break-glass access only for situations you’ve written down in advance, where waiting for normal approval would cause real harm. AWS suggests defining an emergency process per failure mode, including when not to use it, partly to stop people overusing a general process.
Reasonable triggers for customer-account access:
- An active incident is corrupting or exposing a specific customer’s data, and you need to see the account to contain it.
- A security investigation needs to confirm what an attacker could see in an account, now.
- A critical customer is down, and nobody who can approve access is reachable.
Not reasonable: the approver is slow, the ticket is urgent for commercial reasons, or the ordinary request form feels like friction. AWS lists using emergency access in non-emergency situations as a common anti-pattern (opens in a new tab). If people break glass every week, your normal approval path is too slow. Fix that instead.
What should a break-glass path include?
A good break-glass path for customer data has these parts, decided before anyone needs them:
- A short, named list of people who can invoke it. On-call incident leads, not the whole support team. Review the list regularly.
- A reason and an incident reference. Link every use to an incident record so the review has context.
- Notification on every use. Post to a security or incident channel at the moment access starts, not when someone reads a log later.
- The narrowest useful scope. Start read-only. Make write access a separate, deliberate step.
- A short expiry with no silent renewal. If more time is needed, invoke again and leave a second record.
- Mandatory review afterwards. Someone other than the person who used it checks whether the use was justified and what was done. Microsoft’s guidance calls this a post-mortem after any use (opens in a new tab).
- Business audit events in your app. The access record explains why the session existed. Your application’s own events explain what happened inside it. See impersonation audit logs.
How do you test a break-glass path?
Run it as a drill, on a schedule. Microsoft recommends validating emergency access at least every 90 days, including reviewing who’s authorized. AWS suggests testing emergency access as part of incident response simulations.
Use a synthetic customer account in staging. These are pass conditions to check, not results we’ve run.
| Drill step | Pass condition |
|---|---|
| Someone not on the list tries to invoke the path | Refused, and the attempt is recorded |
| An authorized person invokes it with an incident reference | Access starts within minutes; the reason and reference are recorded |
| Access starts | The incident or security channel is notified straight away |
| A write is attempted in a read-only emergency session | Your backend rejects it |
| The time limit passes with the tab still open | The next API request is rejected |
| The session ends | Your app revokes its own credential, with or without an open tab |
| The review runs | A second person signs off, using the access record and your app’s audit events |
How does this map to Devora?
Devora has no dedicated break-glass feature. The closest mapping is administrator self-approval. An admin can request access and approve it at once. Devora records that as self-approved, separately from approval by another admin, as the FAQ on approval roles explains. Self-approval is on unless you turn it off, according to the Devora overview for teams (opens in a new tab).
That covers fast access with a record, but it isn’t a full break-glass path:
- It isn’t limited to emergencies. Any admin can self-approve their own request, for any reason, while the setting is on. Your review has to look at every self-approved session, not only those during incidents.
- There’s no separate emergency alert. Notifying your incident channel is part of your process.
- Recording is optional and off by default. Devora’s recording settings (opens in a new tab) apply to new sessions in general, not to emergencies only.
The rest of Devora’s controls still apply. The requester chooses a duration from 15 minutes to 2 days, so pick the shortest that fits. Read-only scope is enforced by the backend guard (opens in a new tab) on the routes you protect. An admin can end the session or revoke the approval, and Devora sends your backend a signed termination request (opens in a new tab) so your app revokes its credential, even if no tab is open.
If you’d rather keep two-person approval during incidents too, turn self-approval off and put an approver on call. AWS suggests secondary approvers when the primary ones are unavailable. That’s often the cleaner choice for a team that has more than one admin.
Write the procedure down, run the drill above in staging, then decide. To try the flow, create a Devora account and run one staging session as your first drill.
Sources
- AWS Well-Architected Framework: SEC03-BP03 Establish emergency access process (opens in a new tab)
- Microsoft Learn: Manage emergency access admin accounts (opens in a new tab)
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations (opens in a new tab)
- eCFR: 45 CFR 164.312, Technical safeguards (opens in a new tab)
- Microsoft Learn: Microsoft 365 service engineer access control (opens in a new tab)
- Devora: FAQ
- Devora: Overview for teams (opens in a new tab)
- Devora: Recording privacy and activity logs (opens in a new tab)
- Devora: Scope and security (opens in a new tab)
- Devora: Session lifecycle and cleanup (opens in a new tab)