Skip to main content
Identity Authority
Category: Privileged Access

Break-Glass Access

Also known as: Break-Glass Procedure, Emergency Access
Simply put

Break-glass access is an emergency procedure that lets an authorized person gain elevated access rights they do not normally have, so they can respond to a crisis when standard access is insufficient. It works by temporarily bypassing the usual access controls, typically using pre-staged emergency accounts. The goal is to enable an effective response to emergencies without permanently weakening an organization's security.

Formal definition

Break-glass access is a controlled privileged-access mechanism that grants a principal elevated authorization rights in emergency situations by bypassing normal authorization controls that would otherwise deny or restrict that access. In most deployments it is implemented through pre-staged emergency accounts (as described in Source 4) that are held in reserve and made available with limited administrative overhead when standard access paths are unavailable or insufficient. This is an authorization-layer construct concerned with what elevated permissions are granted under exceptional conditions; the authentication of the individual invoking the procedure, along with associated logging, approval, time-bounding, and post-use review, are typically governed separately by organizational break-glass procedures and are out of scope for the core definition. The specific controls, account management practices, and safeguards vary by vendor, platform, and deployment context.

Why it matters

Break-glass access exists to resolve a fundamental tension in privileged access management: the same tight authorization controls that protect critical systems during normal operations can obstruct legitimate emergency response when standard access paths fail or prove insufficient. Without a pre-defined emergency mechanism, responders may resort to ad hoc workarounds, sharing credentials, disabling controls, or improvising elevated access, that leave no reliable trail and create lasting security gaps. A deliberate break-glass procedure lets an organization respond effectively to a crisis without permanently weakening its security posture.

Because break-glass by design bypasses the authorization controls that ordinarily deny or restrict elevated access, the mechanism itself becomes a high-value target and a potential single point of failure. Pre-staged emergency accounts hold powerful permissions and, if left unmonitored, can be misused or compromised. This is why the surrounding governance, authentication of the person invoking the procedure, approval, logging, time-bounding, and post-use review, matters as much as the access grant itself, even though those safeguards are governed separately from the core authorization construct.

For organizations operating under regulatory or contractual obligations, break-glass procedures often need to be documented, controlled, and auditable. In healthcare contexts, for example, emergency access to critical systems containing electronic protected health information (ePHI) is commonly managed through pre-staged emergency accounts precisely so that access can be granted quickly under exceptional conditions while remaining accountable after the fact.

Who it's relevant to

Privileged Access Management (PAM) engineers
Those who design and operate PAM tooling own the implementation of pre-staged emergency accounts and the controls that govern them. They must ensure break-glass grants are usable under crisis conditions while enforcing time-bounding, session recording, and revocation so that the bypass of normal authorization controls does not become a standing weakness.
Security architects
Architects weigh the trade-off between emergency responsiveness and long-term security when placing break-glass mechanisms into the overall access model. They are responsible for ensuring the emergency path does not become an unmonitored single point of failure and that its authorization scope is deliberately bounded.
Incident responders and system administrators
These are the principals who actually invoke break-glass access when standard access is insufficient during a crisis. They need clear, documented procedures so emergency access can be obtained quickly and correctly without resorting to ad hoc workarounds that leave no reliable trail.
Compliance officers and auditors
Because break-glass procedures bypass normal controls, they are frequently subject to regulatory and audit scrutiny, for example, emergency access to systems containing ePHI in healthcare settings. Compliance stakeholders rely on the logging, approval, and post-use review surrounding break-glass to demonstrate that emergency access remained accountable.
Identity governance leads
While break-glass is a runtime authorization construct, governance leads oversee the lifecycle of the emergency accounts themselves, how they are provisioned, kept in reserve, periodically reviewed, and reconciled after use, so that dormant privileged accounts do not accumulate risk over time.

Inside Break-Glass Access

Emergency Access Account
A pre-provisioned, highly privileged account reserved for exceptional situations where normal authentication or authorization paths are unavailable. It is typically excluded from routine access reviews as a distinct, monitored exception, and its use is expected to be rare and deliberate.
Trigger Conditions
The defined circumstances under which break-glass access is permitted, such as identity provider outages, failure of MFA infrastructure, or loss of standard administrative access. These conditions should be documented so that use outside them is treated as a policy violation.
Credential Protection and Custody
The controls that keep break-glass credentials secured until needed, such as sealed storage in a vault, split knowledge, or dual-control retrieval. Because these accounts often bypass normal step-up or MFA flows depending on configuration, the custody model becomes the primary compensating control.
Monitoring and Alerting
Real-time detection that fires whenever a break-glass account is retrieved or authenticated, ensuring that any use is immediately visible to security operations. This is a runtime enforcement and detection concern, distinct from periodic governance certification.
Audit Trail and Post-Use Review
The logging of who accessed the account, when, why, and what actions were taken, followed by a governance review after each activation. This supports accountability and links the runtime event back to identity governance processes.
Credential Reset and Reseal Procedure
The process to rotate the credential and restore protective custody after each use, so that the account returns to a known, secured state and prior knowledge of the credential is invalidated.

Common questions

Answers to the questions practitioners most commonly ask about Break-Glass Access.

Is break-glass access just a backdoor or a way to bypass security controls?
No. While break-glass access does provide an exception path around normal access constraints, it is not an uncontrolled backdoor. In most deployments it is a deliberately designed, tightly governed mechanism intended for emergencies where standard authentication or authorization paths are unavailable. The distinguishing characteristic is accountability: break-glass procedures typically require pre-provisioned emergency accounts or elevated grants, heightened logging, and mandatory post-use review. A true backdoor lacks these controls. Treating break-glass as equivalent to a backdoor understates the governance, monitoring, and after-the-fact certification that legitimate break-glass designs depend on.
Does break-glass access mean skipping authentication entirely?
Generally no. Break-glass access changes the authorization path, granting elevated or exceptional entitlements, but it does not typically eliminate the need to verify who is acting. In well-designed implementations the person invoking break-glass still authenticates, often through a dedicated emergency credential, and their identity is bound to the session for accountability. Conflating break-glass with anonymous or unauthenticated access is a common error. The point of break-glass is that authorization is expanded under emergency conditions while identification and authentication ideally remain intact so the action can be attributed to a specific principal. Where a shared emergency account is used, additional compensating controls are usually needed to preserve individual attribution.
How should break-glass credentials be stored and protected?
Practices vary by deployment, but break-glass credentials are commonly held in a privileged access management (PAM) vault or secured escrow, sometimes with split-knowledge or dual-control requirements so no single person can retrieve them alone. Some organizations use sealed physical or offline storage as a fallback for scenarios where the identity infrastructure itself is unavailable. The goal is to keep the credential retrievable in a genuine emergency while ensuring retrieval is itself an auditable, deliberate act. Rotation after each use is typical, since the credential is generally considered compromised once exposed.
What monitoring and alerting should accompany a break-glass event?
Because break-glass use is expected to be rare, its invocation is usually treated as a high-priority signal. In most deployments, retrieval of the credential and any subsequent session activity should generate immediate alerts to security operations and relevant approvers, ideally through channels independent of the system being accessed. Session logging, and, where feasible, session recording, supports later reconstruction. The intent is to detect misuse quickly and to ensure that every emergency invocation triggers a defined response workflow rather than passing silently.
How does break-glass access fit with segregation of duties and access certification?
Break-glass grants often intentionally violate normal least-privilege and segregation-of-duties constraints, which is precisely why they belong under governance oversight. In most IGA programs, break-glass accounts and their entitlements are inventoried and subjected to periodic access reviews, and each actual use is reviewed after the fact to confirm it was justified. This post-use certification is where the exceptional authorization is reconciled with policy. Keeping break-glass entitlements out of routine certification scope is a common gap that undermines accountability.
What should a post-incident review of a break-glass event cover?
A post-use review typically confirms who invoked the access, when, under what stated justification, and what actions were taken during the session. Reviewers generally compare the logged activity against the declared emergency to verify the scope was appropriate and that no unauthorized changes occurred. Credential rotation and closure of the emergency session are usually validated as part of the review. Depending on configuration and applicable compliance obligations, findings may feed into audit records or trigger corrective action. The review closes the accountability loop that distinguishes governed break-glass from an ungoverned bypass.

Common misconceptions

Break-glass accounts are just spare admin accounts kept around for convenience.
They are intended strictly for defined emergency conditions where normal access paths fail. Routine use undermines their purpose and typically constitutes a policy violation; convenience access should be handled through standard privileged access mechanisms instead.
Excluding a break-glass account from MFA or conditional access makes it insecure.
These accounts are frequently exempted from certain runtime controls precisely so they remain usable when that infrastructure is down. The risk is managed through compensating controls such as secured custody, dual control, monitoring, and mandatory post-use review rather than through the same enforcement applied to everyday accounts.
Once configured, a break-glass account can be left untouched until needed.
Break-glass accounts require ongoing operational discipline, including periodic validation that the account still works, verification of monitoring and alerting, and credential rotation and reseal after any use. Neglect commonly leads to accounts that fail at the moment they are needed.

Best practices

Document the specific trigger conditions that authorize break-glass use, and treat any activation outside those conditions as a reportable policy violation.
Protect the credentials with strong custody controls such as sealed vault storage, split knowledge, or dual-control retrieval, since these accounts often bypass normal MFA or step-up flows depending on configuration.
Configure real-time alerting so that any retrieval or authentication of a break-glass account immediately notifies security operations, keeping detection separate from periodic access certification.
Rotate the credential and restore protective custody after every use so the account always returns to a known, secured, and sealed state.
Conduct a governance review after each activation to confirm the use was justified, capture the actions taken, and feed findings back into access governance processes.
Periodically test that the break-glass account still functions and that its monitoring and alerting fire as expected, so it is reliable at the moment it is actually needed.
Promotional banner for the Pentest Readiness checklist download