The Breakglass Account Nobody Audits

Every organization with a cloud environment has one. Usually it lives in a spreadsheet on a shared drive, or in a password manager that four different people have access to, or in a ticketing system comment from 2021 with a screenshot attached. The credentials were set during a weekend deployment by someone who was stressed and tired and has since left the company. Nobody has logged into it since. Nobody has checked whether it still works.

Meet your emergency access account. Your breakglass. The backdoor you built for yourself.

When the identity provider goes down and half the engineering team is locked out of production, this is the account that saves you. When a misconfigured conditional access policy blocks every administrator and the CEO is sending messages about the quarterly rollout, this account is what gets you back in. It exists for good reasons. Its security posture is usually a disaster.

What Breakglass Actually Is

Emergency access accounts are accounts designed to exist outside your normal identity controls. They do not authenticate through your SSO provider, because the scenario they exist to address is often "the SSO provider is broken." They bypass MFA, because the scenario they exist to address sometimes involves being locked out of the MFA infrastructure. They are granted the highest privilege levels available, because in the emergency they are designed for, you need to fix anything.

The vendor guidance on this pattern is clear and reasonable: maintain at least two emergency accounts, store the credentials in physically secure offline storage, do not federate them through your identity provider, assign them global administrator equivalent permissions, and monitor them closely because any login event represents either an emergency or a serious security incident.

That guidance describes the right approach. The average implementation looks nothing like it.

Where the Typical Implementation Falls Down

The accounts get created when the identity infrastructure is first set up, because somebody reads the documentation or gets burned by a lockout. Credentials go into a password manager under "emergency access - prod" and four people get access to that entry. Over the next three years, three of them leave the company.

The account does not get rotated because nobody wants to update the documentation and nobody is sure whether the documentation is current anyway. It does not get monitored because whoever set up the SIEM alerts decided emergency accounts were excluded from normal authentication monitoring, on the reasonable-sounding grounds that login events from those accounts are expected to be unusual and should not generate noise.

Here is the problem with that reasoning: the alert exclusion means that if an attacker gets the credentials, their activity also does not generate an unusual authentication alert. The very logic that was supposed to reduce false positives has created a blind spot around the highest-privileged account in the environment.

The credentials are old. The account may be a global administrator in Entra ID, a root account in AWS with no CloudTrail alerts configured for it, or a break-the-glass admin in Okta with a password nobody has reviewed since before two major acquisitions changed the security team entirely. In some environments, it is all three.

The Audit Nobody Prioritizes

When was the last time someone reviewed the credentials on the emergency access accounts? When was the last time someone tested that they still work? When was the last time someone checked the logs to confirm no unauthorized logins had occurred?

The answer in most organizations is that nobody knows. Sometimes the answer is never.

Emergency access accounts fall outside the normal access review cycle because they are not assigned to any user. Quarterly access reviews scan role assignments and flag stale accounts. An emergency account with no user assigned and no recent login date looks like an edge case in the tooling. It often gets deferred to the next review. It stays deferred.

The result is an account that bypasses MFA, bypasses your SSO controls, has the highest privilege level in the environment, has credentials that were set by someone no longer employed, and has not been verified functional or confirmed uncompromised in years.

If you are running a tabletop exercise and someone asks what a sophisticated attacker's ideal target looks like, the answer is usually "an account with full administrative access that is not being monitored." That description fits your breakglass account as typically implemented.

Fixing the Pattern

The actual credential storage should be offline and physically controlled. Print the credentials, put them in a sealed envelope, lock the envelope in a physical safe. Yes, this is inconvenient. It is also the right answer, because the threat model for emergency access credentials is not an opportunistic attacker scanning GitHub. It is someone with specific knowledge of the environment and time to prepare.

Two accounts minimum, in separate credential stores, with access controlled by different people. If both accounts need to be used simultaneously, that is a signal that you are in a serious incident, not just a routine lockout.

Rotate the credentials on a defined schedule. Quarterly is reasonable. Annually is the minimum. "When we get to it" is not a schedule and will not survive an audit.

Monitor every login event from these accounts as a high-priority alert. Every one of them. The argument that this will generate noise does not hold: if the accounts are managed correctly and used only in genuine emergencies, a login event should be notable. If you are seeing frequent logins from emergency accounts, that tells you something important about how your processes are actually running versus how you think they are running.

Test quarterly that the accounts work and that access is what you believe it to be. The two most common findings when someone actually tests a breakglass account are: the password was rotated without updating the documentation, and the account's permissions were changed as a side effect of a migration and it no longer has the access it is supposed to have.

Privileged access management tools handle emergency access with dedicated breakglass workflows that include session recording and approval workflows for access activation. If your organization has not evaluated PAM tooling and you have any meaningful cloud footprint, that evaluation is worth running. The breakglass workflow is often enough of a forcing function to make the business case on its own.

The emergency access account is not a detail. It is the account that every other control in your environment is designed to protect. Treating it with the same rigor as your normal access program - rotation schedules, access reviews, monitoring, documented procedures, tested annually - is not overhead. It is the baseline.