Break glass accounts expose the real problem in emergency access

At a glance

What this is: This article explains break glass accounts as emergency access identities and shows how weak governance can turn them into a breach accelerator.

Why it matters: It matters because IAM teams must treat emergency access as a governed control plane across NHI, human admin, and incident response workflows, not as an exception that sits outside review.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Zluri's guidance on break glass accounts and emergency access

Context

Break glass accounts are emergency identity controls, but they become dangerous when they sit outside normal access governance. In practice, they are high-privilege credentials that should exist only for tightly defined recovery scenarios, not as a permanent backdoor for convenience.

The governance gap is not the existence of emergency access itself. The problem is whether those credentials are isolated, monitored, periodically tested, and constrained so they can restore control without becoming a parallel privileged pathway through the identity stack.

Key questions

Q: What breaks when break glass accounts are treated like everyday admin access?

A: When emergency access is treated like routine administration, it stops being an emergency control and becomes standing privileged access. That increases the chance that a single exposed credential can bypass normal governance, spread across multiple systems, and outlive the incident it was meant to contain. The control only works when use is rare, logged, and tightly scoped.

Q: Why do break glass accounts need separate governance from normal IAM controls?

A: They need separate governance because their whole purpose is to bypass broken controls during recovery, which means they operate outside standard access paths by design. If they are not isolated, monitored, and periodically reviewed, the exception path becomes an attacker shortcut. That is especially true when the account can reach privileged cloud, collaboration, and security systems.

Q: How can security teams tell whether emergency access is actually under control?

A: Look for clear ownership, documented activation criteria, vault-based storage, logging, and periodic drills that prove the account still works under stress. If the team cannot show who holds it, when it is used, and how it is revoked after use, the control is not governed. It is just a hidden admin account with better branding.

Q: Who should be accountable for break glass access when a breach occurs?

A: Accountability should sit with the identity, security, and incident response owners jointly, because break glass access sits at the intersection of privileged access, incident recovery, and system restoration. The organisation should be able to name who approved the emergency account, who used it, and who verified its return to dormancy after the event.

Technical breakdown

Break glass accounts and privileged access boundaries

Break glass accounts are privileged identities reserved for exceptional recovery events such as MFA outages, lockouts, or active compromise. Their technical purpose is to bypass broken control layers when ordinary authentication or conditional access cannot be trusted. That only works if the account is isolated from day-to-day administration, stored separately from standard admin secrets, and protected with clearly defined ownership and logging. The article also shows why these accounts often become a hidden tier of privilege rather than a true emergency control when they are reused too broadly or left outside lifecycle discipline.

Practical implication: define break glass access as a separate privileged tier and subject it to lifecycle, ownership, and logging controls.

Why hardcoded credentials turn recovery accounts into breach paths

The Uber example in the article shows the failure mode clearly: an attacker found hardcoded admin credentials in a PowerShell script, then used that access to move across high-value systems. That is not just a password problem. It is a secret governance failure in which emergency access and ordinary operational access are not cleanly separated. When credentials are embedded in code or shared too widely, a recovery mechanism becomes an attack surface that can survive the original compromise and extend it across cloud, collaboration, and security tooling.

Practical implication: eliminate embedded secrets and keep emergency credentials out of scripts, repos, and shared operational tooling.

Testing emergency access without normalising it

A break glass account should be available when control planes fail, but availability alone is not enough. The account must be tested on a schedule, with evidence that it works under emergency conditions and that the organisation can still see, trace, and revoke its use afterwards. The article’s advice to review accounts every 90 days points to the right governance pattern, but the deeper issue is whether testing preserves emergency-only use. If testing becomes routine access, the control has already lost its boundary.

Practical implication: test break glass access in controlled drills and verify that the account remains emergency-only, not operationally normal.

Threat narrative

Attacker objective: The objective was to seize and sustain broad administrative control across critical internal systems while preventing security teams from intervening.

1. Entry occurred when the attacker gained access to Uber's internal network and discovered hardcoded privileged credentials in a script.
2. Escalation followed when those credentials provided domain admin-level access that could reach multiple internal services and control systems.
3. Impact came from the attacker taking over collaboration, cloud, security, and code environments while blocking defenders from regaining control.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Break glass accounts are only safe when they remain outside normal privilege reuse. The article treats emergency access as a last resort, but its own Uber example shows what happens when that boundary erodes. If the same credentials, tools, or admins that run day-to-day operations also hold emergency access, the control stops being contingency and becomes latent standing privilege. Practitioners should treat separation of duties as the core design assumption, not a nice-to-have.

Hardcoded emergency credentials are a secret lifecycle failure, not just a scripting mistake. The breach example in the article demonstrates that a single exposed admin secret can traverse cloud, collaboration, and security tooling in one move. That is why emergency access must be governed as a secret with explicit issuance, storage, rotation, and revocation rules. The relevant failure mode is secret persistence across operational surfaces, and practitioners should read it as a lifecycle problem, not an isolated compromise.

Break glass governance collapses if the account can be used like ordinary admin access. The article’s recommendation to disable MFA and conditional access for these accounts may restore reachability during an outage, but it also creates an exception path that attackers will target first. The governance assumption that breaks is that bypass credentials can remain harmlessly outside normal controls once issued. They cannot. The implication is that emergency access needs stricter containment, not looser treatment.

Emergency access testing is meaningful only when it proves recoverability without normalising use. The article’s 90-day review cadence is directionally right, but the real question is whether the organisation can validate emergency access, prove it is observable, and then return it to dormancy. A break glass process that is not rehearsed becomes theoretical. A process that is rehearsed too casually becomes routine privileged access. Practitioners should measure whether the account remains recoverable, auditable, and genuinely exceptional.

Break glass accounts expose the identity model's weakest premise: that privileged access can be made safe by exception handling alone. Once an attacker reaches the recovery tier, they do not need to defeat normal IAM workflows. They need only exploit the one place where governance was relaxed to preserve availability. That makes break glass a disciplined identity pattern, not an emergency shortcut. Practitioners should govern it with the same seriousness as any other privileged non-human identity.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Only 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to NHI Mgmt Group research.
• For a broader control baseline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding discipline.

What this signals

Break glass governance should now be treated as part of the privileged identity lifecycle, not as an exception process. The more emergency access is separated from normal operations, the more clearly teams can define ownership, rotation, and revocation. The governance question is no longer whether break glass exists, but whether it is provably dormant until needed and visible when activated.

The article's breach example reinforces a broader NHI lesson: a single privileged secret can become a cross-platform incident if it is stored or reused poorly. That is why emergency access should be reviewed alongside the wider secret inventory and admin account estate, not in isolation. Teams that already struggle with visibility into non-human identities will find break glass accounts especially difficult to govern.

Break glass access is a control test for identity maturity. If an organisation cannot show that emergency accounts are isolated, auditable, and recoverable after use, then its privileged access model is still too dependent on trust. The practical signal is whether the team can connect emergency access to lifecycle management, logging, and post-use revocation without manual heroics.

For practitioners

• Separate emergency access from operational administration Create dedicated break glass identities that are never used for daily administration, never shared with general admins, and never embedded in operational scripts or repositories.
• Remove hardcoded privileged secrets from operational code Scan scripts, config files, CI/CD systems, and admin tooling for embedded credentials and move recovery secrets into controlled vaults with explicit issuance and retrieval logging.
• Test recovery access as a governed drill Run periodic emergency access exercises that prove the account works during an outage, confirm access is logged, and verify revocation paths after the drill ends.
• Define break glass ownership and approval boundaries Assign named owners, define exactly when emergency access can be activated, and document which systems are allowed to bypass normal access controls during recovery.
• Review privileged access after every emergency event Treat each use of break glass access as a post-incident governance event and revalidate whether the account still needs the same privileges, storage method, and monitoring coverage.

Key takeaways

• Break glass accounts solve availability problems only if they do not become permanent privileged backdoors.
• The Uber example shows how hardcoded credentials and broad admin access can turn recovery identity into an attacker’s fastest route across systems.
• Effective emergency access depends on separation, testing, logging, and post-use review, not on the label attached to the account.

Key terms

• Break Glass Account: A break glass account is an emergency privileged identity used only when normal access controls fail or are unavailable. It exists to restore control during incidents, outages, or lockouts. Because it bypasses standard controls, it must be tightly isolated, monitored, and governed as a high-risk access path.
• Standing Privilege: Standing privilege is access that remains continuously available rather than being granted only when needed. In emergency access design, standing privilege becomes dangerous when the same identity can be used for routine administration and incident recovery. Good governance reduces the time and scope that privilege remains active.
• Secret Lifecycle: Secret lifecycle is the end-to-end governance of credentials, tokens, keys, and certificates from creation through storage, use, rotation, and revocation. For emergency access, lifecycle discipline determines whether a recovery credential stays controlled or becomes a persistent exposure point across code, vaults, and admin tooling.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Zluri: Access Management Break Glass Accounts, Emergency Access to Bypass Lockouts. Read the original.