Break-Glass Emergency Access: A 2026 Best-Practices Guide

A break-glass account is a pre-provisioned, high-privilege emergency credential that an organization holds in reserve to regain access to critical systems when the normal authentication path is unavailable — a production outage, an administrator lockout, an identity-provider or MFA-service failure, or a disaster-recovery event. In technology, "break glass" means deliberately invoking that pre-arranged emergency path when standard, governed access is impossible or too slow to help. The term borrows from the fire-alarm panel you physically break in an emergency: the action is meant to be rare, conspicuous, and fully accountable. The defining property is that the credential is always technically available but almost never actually used.

That "almost never used" property is the whole design challenge. A break-glass account is, by construction, a standing credential with enormous privilege — precisely the kind of dormant, high-value target attackers hunt for. The engineering problem is to keep it available for the genuine emergency while ensuring it cannot become a quiet back door for routine access or an unmonitored asset waiting to be compromised. This piece is the 2026 update of Avatier's original guide, Emergency Access Passwords, rebuilt as a practitioner reference around what the term actually means, when the pattern is the right tool, and the specific controls — approval, auditing, time-boxing, and rotation — that separate a governed break-glass capability from an ungoverned liability.

What "break glass" means in technology

The phrase is a direct metaphor. On a wall-mounted fire alarm, the glass exists so that pulling the lever is a deliberate, visible act — you cannot do it by accident, and once you have done it, everyone knows. Break-glass access in technology carries the same three properties into identity and access management: the invocation is intentional (you take an explicit action to request emergency privilege), it is visible (the act raises alerts and produces records), and it is accountable (a named person owns the decision and answers for it afterward).

Mechanically, a break-glass account differs from an ordinary privileged account in what it is for rather than what it can do. Both may hold domain-administrator, cloud-root, or mainframe-security-officer authority. The difference is that a normal privileged account is used through the standard governed workflow every working day, while a break-glass account sits sealed and is exercised only when that workflow cannot run. When you ask "what does break glass mean in technology," the shortest correct answer is: it is the controlled last resort for restoring access to critical systems when the usual identity and access-management path has failed.

It helps to be precise about what break-glass is not. It is not a convenience feature for skipping a slow approval — that problem belongs to just-in-time access, covered below. It is not a generic admin account that happens to be powerful. And it is not a synonym for "the root password in a vault." A vault entry with no approval gate, no session recording, and no rotation is a shared secret, not a break-glass control. The distinction matters because the word gets applied loosely, and the loose version is where most of the risk hides.

When a break-glass account is the right tool

Break-glass earns its place in exactly the situations where your normal access machinery is the thing that has broken. Four scenarios recur across 2026 enterprise environments.

The identity-provider or MFA-service outage. When the IdP is down or the MFA service is unreachable, ordinary users — including administrators — cannot authenticate through the usual path. A break-glass credential that does not depend on the failed component is what lets a responder get in to diagnose and restore it. This is the canonical case, and it is why break-glass authentication must be engineered to survive the failure of the systems it exists to recover.

The administrator lockout. A misconfiguration, an expired certificate, a botched conditional-access policy, or a deleted role assignment can lock every normal administrator out of a system. The break-glass account is the pre-arranged way back in that does not require the very access that was lost.

The production outage under time pressure. During a severe incident, the standard privileged-access workflow — request, wait for approval, receive a time-bounded credential — may itself be unavailable or too slow relative to the business impact. Break-glass provides the fast path, at the cost of heavier after-the-fact scrutiny.

Disaster recovery and greenfield rebuilds. When systems are being reconstituted from backups or stood up in a recovery region, the normal access controls may not exist yet. Break-glass credentials bootstrap the environment until governed access can be re-established.

The common thread is failure of the normal path, not slowness of it. If teams reach for break-glass because routine elevation is merely inconvenient, the honest fix is upstream — tune the least-privilege model and the JIT approval workflow so the governed path is fast enough that nobody is tempted to break glass for ordinary work. A break-glass account that gets used weekly is not a safety valve; it is a standing admin account with extra ceremony.

The break-glass account lifecycle

A governed break-glass capability is not a credential — it is a loop. Every legitimate invocation runs the same five stages, and the discipline is that each stage produces evidence. The request is tied to a named emergency; approval is obtained out of band from more than one person; the credential is issued for a hard-bounded window and the session is recorded; every action lands in a tamper-evident audit trail; and the secret is rotated the moment the incident closes, re-sealing the account.

The loop is the control: a break-glass invocation that skips request, approval, audit, or rotation is not emergency access — it is an unmanaged privileged session.

The lifecycle framing is what turns break-glass from a shared password into a governed exception. Treating it as a static credential — issued once, stored somewhere, occasionally used — is the root of most break-glass failures. Treating it as a repeatable, evidence-producing workflow means each of the five stages has an owner, a control, and an artifact you can hand an auditor. The temporary-password best practices that govern short-lived credentials elsewhere in the estate apply here with the volume turned up: the emergency credential should be the shortest-lived, most heavily instrumented secret you issue.

The controls that make break-glass safe

The reason break-glass makes security teams nervous is sound: you are deliberately provisioning a powerful credential and promising to only use it when things are already going wrong. What makes that promise credible is not trust — it is a small set of composed controls, each of which addresses a specific way the pattern goes bad.

Miss any one of the four and break-glass degrades into an unmonitored back door: approval stops unilateral misuse, MFA stops credential theft, logging stops silent abuse, rotation stops lingering exposure.

Multi-party approval. No single individual should be able to break the glass alone. Splitting the authorization — two responders, or a responder plus an approver who each hold part of what is needed — turns emergency access into a decision with a witness. This is the control that prevents a single compromised or malicious insider from turning the break-glass account into a personal tool.

Phishing-resistant MFA. A break-glass identity protected only by a static shared password is the exact asset an attacker wants: high privilege, rarely watched. Protect it with a FIDO2-compatible hardware authenticator held under physical dual control, so invoking the account requires possession of a physical factor, not just knowledge of a secret. The credential must still work when the primary IdP is down, which is why the hardware factor and its recovery path deserve deliberate engineering rather than a copy of the everyday MFA setup.

Comprehensive, tamper-evident logging. Every invocation must generate a complete record — who requested it, who approved it, the named incident, the time window, and every action taken — written to a store the break-glass account itself cannot alter. Pair the log with a real-time, high-priority alert so that breaking the glass is impossible to do quietly. If a break-glass session can happen without the security team knowing within minutes, the control is not real.

Rotation on use. The secret behind the break-glass account should be rotated immediately after the emergency closes. Rotation means that even if the credential was exposed during the incident — shoulder-surfed, logged in a screenshot, captured on a compromised host — the copy is already dead by the time anyone could reuse it. Rotation is also what re-seals the account and returns the lifecycle to its resting state.

These four compose into a single property: the break-glass credential is powerful but never unaccountable. Remove approval and one person can act unilaterally. Remove MFA and a stolen secret is enough. Remove logging and abuse is silent. Remove rotation and every past exposure is a live risk. The controls are load-bearing together, not individually.

Break-glass versus standing privileged access

It is tempting to think of a break-glass account as "just an admin account we keep for emergencies." That framing hides the actual security argument, which is about the shape of the risk over time rather than the raw power of the credential.

Same underlying privilege, very different exposure: standing access is live around the clock, while governed break-glass compresses the dangerous window to the minutes of an actual incident.

A standing privileged account is exploitable at every moment, whether the owner is working or asleep. Its blast radius is the full scope of its entitlement, all the time. A governed break-glass account holds the same entitlement but is sealed by default, so its exposure window is only the minutes during which it is genuinely invoked — and even that window is approved, recorded, alerted, and closed by rotation. This is the same logic that drives the broader industry shift toward just-in-time access and zero standing privilege: the dormant, always-on entitlement is the attack surface, and compressing it in time shrinks the surface.

The important caveat — and the reason this comparison is not simply "break-glass wins" — is that the break-glass account is still a standing credential. It exists continuously even when sealed. The contrast is favorable only to the degree that the controls actually hold. A break-glass account with no rotation and no alerting is functionally a standing privileged account that you have told yourself is safe. The diagram's right-hand column is a description of the governed pattern, not an automatic property of the label.

Common failure modes and anti-patterns

Break-glass programs fail in a small number of recognizable ways. Each is avoidable when treated as a design constraint and common when treated as an afterthought.

Break-glass as the default path. The most frequent failure is quiet drift: because the emergency credential is fast and unblocked, administrators start reaching for it whenever the normal workflow is slow. Over months, break-glass becomes the primary access method and the governed path atrophies. The mitigation is measurement — track the invocation rate, review every use, and treat a rising trend as an operational defect in the normal path, not as normal behavior.

The forgotten credential. A break-glass account provisioned during a project and never inventoried becomes an orphaned standing super-credential — no owner, no rotation, no monitoring, and often no memory that it exists. This is the classic overlap with service-account and non-human-identity governance: the emergency credential must be in the central inventory, with a named owner and a lifecycle, exactly like any other high-privilege identity.

Weak authentication in the name of availability. Teams sometimes reason that because break-glass must work in a crisis, it should have the fewest possible barriers — a shared password, no second factor. That reasoning inverts the risk. The correct design keeps the credential available under failure of the primary IdP while still requiring a phishing-resistant hardware factor; availability and strong authentication are not in tension if the emergency authentication path is engineered deliberately.

Untested procedures. A break-glass process that has never been exercised will fail in the one moment it is needed — the hardware token is missing, the approver list is stale, the recovery path assumes a system that is itself down. Periodic, scheduled tests that actually invoke the full lifecycle (in a controlled way) are what keep the capability real.

No post-incident review. Logging without review is theater. Every invocation should trigger a mandatory review that confirms the use was justified, the actions were appropriate, and the credential was rotated. The review is where the audit trail earns its keep.

What Avatier ships toward this pattern

Avatier Identity Anywhere approaches break-glass as a governance problem rather than a special credential. The emergency-access identities are provisioned, inventoried, and lifecycle-managed through the same Identity Anywhere Lifecycle Management workflows that govern the rest of the privileged estate — so a break-glass account has a named owner, a defined scope, and a place in the central inventory rather than living as an orphaned secret. The workflow engine supports the multi-party approval and time-boxed elevation the lifecycle requires, and it integrates with the dedicated privileged-access platforms covered in the PAM reference for vaulting, session brokering, and recording of the emergency session itself.

Recovery flows tie through Password Station for workflow-verified resets, which closes the social-engineering vector that otherwise defeats emergency-access controls — the attacker who cannot break the glass directly will try to talk the service desk into resetting it. For mainframe environments, Avatier's native RACF, ACF2, and Top Secret connectors bring emergency access to the mainframe security officers (RACF SPECIAL, ACF2 SECURITY, Top Secret MSCA) under the same governed lifecycle as modern-stack accounts, rather than leaving the mainframe break-glass path as a manual, unaudited exception. The authentication layer is FIDO2-compatible, so the emergency identity can be protected with a hardware factor rather than a shared password.

The Avatier Trust Center publishes our compliance posture — SOC 2 Type II with zero exceptions, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, CSA STAR Level 1, NIST 800-53 Rev. 5 aligned, FedRAMP-aligned, and CISA Secure-by-Design Pledge signatory. The design intent is deliberately unglamorous: an emergency credential should be the most boring, most instrumented, most auditable object in the environment, and the platform's job is to make the governed path the easy path so that break-glass stays what it should be — a rarely pulled lever, not a daily habit.

The honest closing

Break-glass is a genuinely useful pattern, and it introduces a genuine, permanent risk. That risk does not disappear when you implement the controls; it gets bounded. The uncomfortable truth is that a break-glass capability means you are choosing to keep a standing high-privilege credential in your environment — one that exists whether or not it is ever used, whose theft would be catastrophic, and whose safety depends entirely on approval, MFA, logging, and rotation continuing to hold every day it sits sealed.

That is an acceptable trade because the alternative — no emergency path, and therefore no way back in when the normal machinery fails — is worse. But it is a trade, not a solved problem. The organizations that get break-glass right are the ones that never let themselves believe the label makes the credential safe. They keep the inventory current, they measure how often the glass gets broken, they review every invocation, they rotate on use, and they test the whole loop before they need it. The pattern is only as strong as the discipline around the standing credential at its center — and that discipline is a practice you sustain, not a control you install once and forget.