A break-glass account (or emergency credential) is the last resort to regain administrative access when normal access is blocked: IdP down, corporate MFA unavailable, misapplied policies, or an incident that forces systems to be isolated.
The important nuance is operational: a break-glass is not “another admin account.” It is a deliberate exception to the usual flow (SSO, centralized MFA, approval workflows) and for that very reason it requires different controls and stricter discipline. If it is left to live like just another account, it becomes a stable bypass to everything that is costly to maintain.
What a break-glass really is (and why it exists)
In companies with SSO, conditional policies, and delegated administration, it is relatively easy to build a castle… and also lock yourself inside it. I have seen deployments where a policy change (for example, requiring an MFA method the team cannot enroll because of a provider outage) leaves operations unable to roll back. The break-glass exists for that kind of scenario: restore control without depending on the system that just broke.
It also exists due to continuity pressure: during an incident response it may be necessary to access the console or elevated privileges when the IdP is isolated for containment, or when the usual approvals channel is frozen to limit impact. In those minutes, a well-designed emergency credential reduces “time to recover” and avoids improvised decisions (like sharing credentials over chat) that later are impossible to audit.
The risk is that its purpose is exceptional but its existence is permanent. If nobody defines when it is used, how it is authorized, and what evidence it leaves, the “emergency account” ends up being “the convenient account.” That cultural shift happens faster than it seems, especially in environments with on-call rotations, SLA pressure, and staff turnover.
What went wrong in abuse cases: patterns that repeat
Abuses rarely start as a spectacular attack. They start with a shortcut: “just today I’ll log in with the break-glass because SSO is slow” or “I need to bypass approval to apply a hotfix.” When that becomes normalized, the account stops being a last resort and becomes a parallel, low-friction route, and that’s where the real problem appears: loss of traceability and effective control.
In internal incidents (malice or negligence), the break-glass is attractive for two reasons: it usually has broad privileges and it is usually outside the mechanisms that trigger alerts (for example, outside the IdP, outside PAM, outside the ticket flow). I have seen scenarios where someone uses the break-glass to elevate permissions, create a new persistent identity, and then “close the door again”; the damage is not the one-off access, but the persistence that was planted.
- Credentials shared among several people
- Use without formal record (no ticket, no approval, no justification)
- Silent exemption from MFA or weak factors “for emergency”
When a break-glass is shared, any later audit degrades into assumptions: you can know what the account did, but not who operated it. And in practice this prevents hard decisions: if you cannot attribute, it is difficult to correct behaviors or close cultural gaps.
Use without formal record is often the prelude to dependency. The organization gets used to resolving quickly, but the cost comes later: incidents without a reliable timeline, inability to demonstrate control in an audit, and a “shadow admin” that nobody wants to touch because “if you break it, we get locked out.”
MFA exemption is the point of no return. Many modern breaches do not require sophistication if a high-privilege credential with weak authentication exists. And even if it has MFA, if the second factor lives in the same place as the password (a shared manager without controls, a vault without separation of duties), the risk becomes systemic again.
Early signs that your break-glass is already a backdoor
Most organizations do not “lose” a break-glass in a day: the degradation is gradual. The first sign is usually social, not technical: when someone mentions the account as a standard solution (“if it fails, we use the emergency one”) rather than as an exception you fear using.
The second sign is operational: if it is used for repeatable tasks (user provisioning, routine IAM changes, deployments), it means the normal access model is failing or is too friction-heavy. And then the team starts optimizing around the exception, not around the control.
- Activity outside emergency windows
- Logins from locations or networks “unlikely” for a rescue
- Changes that increase surface area: new keys, new roles, disabling logs
Activity outside an emergency window is not always malice; many times it is operational debt. But it must trigger mandatory review, because if it is not corrected, the exception becomes normalized. A simple criterion is to require that each use has a verifiable “story”: what broke, what was done, how the normal flow was restored, and what action was taken so it does not happen again.
Unlikely locations or networks usually indicate that the credential is more widely distributed than you think or that someone is using it from an uncontrolled context (personal device, home network, hop via a third-party VPN). In real emergencies, the access pattern is usually very consistent (specific teams, known IPs, bastions), and that is why deviations are a strong signal.
And changes that increase surface area (creating access keys, elevating privileges, touching logging) are the real focus: a break-glass should be used to restore control, not to weaken the system. If it happens, it is an indicator that your “rescue” is being used to build persistence.
How to do it in practice: guardrails that actually work (with an example in AWS)
Operating a break-glass well is not putting it in a vault and forgetting it; it is designing a complete procedure: creation, custody, activation, evidence, and closure. In cloud, you also need to assume that real control is who can use it and what gets recorded, because the perimeter is fuzzy.
In AWS, a common pattern is to have an emergency user or role with high privileges, protected by MFA, and with credentials stored in a corporate vault with access control and logging. The important thing: not to depend exclusively on the IdP if the IdP is the point of failure you are mitigating, but to require that use leaves a trail in CloudTrail and in the secrets management system.
Concrete actions you can execute:
- Create a separate and minimal emergency identity
- Configure strong MFA and custody with dual control
- Enforce traceability and mandatory post-use review
Creating a separate identity means it must not share email, device, or lifecycle with normal administrators. In AWS, if you use an IAM user, avoid permanent access keys unless you have an extremely justified reason; prioritize interactive access with MFA. If you use a role, clearly define the assumption path and which entity can assume it in an emergency (and that that path is also governed).
For MFA and custody, the dual control approach works: that nobody can extract and use the credential without another person enabling it. In practice, this is implemented with a vault that records who accesses, approval by two people (or two groups), and credential-access expiration times. If the organization cannot sustain dual control 24/7, at least require explicit approval and record the reason, because what is not recorded ends up becoming habit.
For traceability, in AWS validate that CloudTrail is enabled in all regions, that logs are sent to a bucket with protection against deletion (for example, policies that prevent DeleteObject except for specific break-glass, and even then with alarms) and that detection of use exists: alerts for ConsoleLogin by the break-glass user or for AssumeRole by the emergency role. The practical verification here is not “I think it’s there”: it is to review recent events, simulate a controlled login, and confirm that the alert reaches the correct channel (SOC/on-call) with sufficient context.
A very common anti-pattern is “storing the password in an encrypted document in a shared drive.” Even if the intent is good, in practice there is no separation of duties, there is no useful audit, and distribution becomes uncontrollable. The typical consequence is that, after staff turnover or an incident, you no longer know who still has access.
Recommendations for corporate environments
The break-glass is not negotiable in real organizations: systems fail, providers go down, and misapplied policies exist. What is negotiable (and critical) is turning that need into a controlled operational mechanism, with a “usage circuit” that is stricter than normal access, not looser.
If today your emergency account is used for routine work, if its credentials are shared without attribution, or if you cannot demonstrate (with logs and evidence) who used it, when, why, and what changed, then you no longer have a break-glass: you have a backdoor. Returning to a healthy state requires discipline: custody with control, alert on every use, and require a post-use review that closes the loop and prevents recurrence.
When it is operated well, the emergency account fulfills its function without eroding the security model. When it is operated “to get by,” it becomes the preferred bypass and, sooner or later, the weakest point of the entire environment.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.