IAM Emergency Access Pattern

Break-glass access for emergencies.

Setup

Every production system needs a way to recover when normal access is broken. The SSO is down, the cloud account's IAM is misconfigured, the on-call's phone is dead during an outage. Without a planned emergency access path, the team improvises under pressure, which produces both worse outcomes and audit-quality control failures. The solution is a deliberate break-glass account with strong controls.

What setting up emergency access correctly involves:

• Special account, tightly controlled.: A dedicated account (or a small set) with elevated privileges, used only for emergencies. Not the daily admin account, not the on-call's regular login, a separate identity reserved for break-glass scenarios. Its existence is documented; its credentials are sealed.
• Outside normal SSO.: The break-glass account does not depend on the SSO that the rest of access flows through. If SSO is the failure mode, you cannot rely on SSO to recover. The credentials live in a sealed envelope, a hardware security key in a safe, or a password manager that is independently authenticated.
• Strong MFA, no exceptions.: The account requires hardware-key MFA. Not SMS, not TOTP that the SSO would normally proxy. The MFA factor is independent and physically controlled. The setup is more friction than normal but the account is rare-use.
• Multi-person to use.: The credentials and the MFA are split across two or more people. Using the account requires both. This is the property that makes the audit story strong: no single person can use the break-glass account alone.
• Documented in the runbook.: The procedure for using break-glass is in the incident runbook, with the conditions under which it is appropriate, the people who must approve, and the post-use recovery steps. The team has practiced reading the runbook even though they have not used the account.

Setup is the discipline. Once the account exists with proper controls, the rest of the practice is about how it is used and what happens after.

Usage

The break-glass account exists for emergencies. Defining what counts as an emergency, requiring approval before use, and creating a heavy audit trail when it is used together prevent the account from being used routinely.

• Only for emergencies.: The legitimate uses are narrowly defined: SSO is down, primary admin account is compromised, normal access has failed in a way that prevents incident response. Routine work, even urgent work, that could go through normal channels does not qualify.
• Requires explicit approval.: Use of the break-glass account requires a documented approval at the moment of use. The on-call manager or a security leader signs off. The approval is captured in the incident channel; there is no ambiguity later about whether the use was sanctioned.
• Audited heavily.: Every action taken with the break-glass account is logged. The session is recorded if technically feasible. The audit log is preserved permanently and reviewed by the security team afterward. This is the level of forensic detail that makes the use defensible later.
• Time-bounded.: The break-glass session has a hard time limit (typically 1 to 4 hours). After the limit, the credentials auto-expire even if the user has not logged out. The account is not a sustained access path; it is a momentary one.
• Notification to the broader org.: When the break-glass account is used, security and engineering leadership get notified within minutes. The notification is automatic, not a courtesy. Anyone watching can see the use happen and ask questions in real time if it looks wrong.

The use discipline is what makes the existence of the account safe. An account with broad privilege and no oversight is a backdoor; an account with the same privilege and rigorous oversight is a recovery mechanism.

Rotate

The third leg of the practice is rotation. Every use of the break-glass account is followed by full credential rotation. This is what prevents the account from accumulating risk over time and what cleans up after every use.

• After any use, rotate all credentials.: Password, MFA token, API keys, anything the account had access to. Rotated to new values, with the old ones invalidated. The rotation is documented in the same incident record as the use.
• No persistent access.: The break-glass account does not maintain standing access to anything. After rotation, it is reset to its sealed state. The next use will require fresh approval and fresh setup.
• Rotation as a follow-up task.: The rotation is a non-negotiable post-incident action. It goes in the incident retro action items. Skipping it is a security violation, not an oversight. The discipline holds because nobody on the team is willing to be the one who skipped rotation and got the account compromised.
• Quarterly verification.: Even when the account has not been used, the security team verifies quarterly that the seal is intact, the controls are in place, the runbook is current, and the team can still execute the procedure if needed. The drill is part of the practice.
• Annual review of need.: Once a year, review whether the break-glass account is still necessary, whether the privileges granted to it are still the right scope, and whether there are alternative recovery mechanisms that have matured. Some teams retire break-glass accounts as their primary access mechanisms become more reliable.

The break-glass pattern is one of the highest-leverage operational disciplines a security program can implement. It costs almost nothing to maintain and produces the recovery path that prevents incidents from cascading into total loss-of-control situations. Nova AI Ops watches for break-glass account activity, surfaces the audit trail to security leadership in real time, and tracks the post-use rotation to make sure the discipline is actually being followed.