Break-Glass Access

Break-glass access is an emergency operating procedure, not simply an administrator account with a powerful password. It defines when exceptional access is justified, who may activate it, how responders authenticate, which actions they can perform, and how access is removed afterward. Typical triggers include a failed identity provider, an incorrect access policy that locks out administrators, or a security incident requiring permissions that normal operators do not hold.

In the cloud, establish the access path before an incident. Preprovision emergency identities or role trust relationships, protect their authentication factors, and verify that responders can reach the required consoles and APIs. An emergency route intended to survive a federation outage must not rely on that same federation service. Similarly, keeping its only recovery instructions or credentials in a vault accessible solely through the failed identity provider creates a circular dependency. Maintain independently accessible runbooks and secure credential custody without turning emergency credentials into routinely shared secrets.

Emergency authorization should match the expected recovery tasks. For example, a responder might need to quarantine a compromised workload, preserve evidence, repair an identity policy, or restore logging. Separate containment permissions from broader account-recovery permissions where practical, and restrict access to the affected accounts and resources. Predeploy security tooling and evidence collection so responders do not have to build them during an outage. For workloads requiring AWS Shield Advanced protections, configure the relevant protections and response arrangements ahead of time; emergency administrative access is not a substitute for prepared defenses.

AWS implementations often use an independently authenticated emergency identity to assume designated IAM roles through AWS Security Token Service. Prefer temporary sessions over permanent access keys, require strong authentication appropriate to the access path, and configure short session durations. Document how to stop new sessions and revoke or deny existing role sessions when necessary. Temporary credentials remain usable until expiration unless an applicable revocation or policy control blocks their use; ending a browser session alone is not sufficient.

Root access requires a separate decision. Most incident response tasks should use IAM roles rather than the AWS account root user. Where root credentials are retained, protect them with MFA, avoid root access keys, secure the account email and recovery channels, and establish controlled custody and recovery procedures. AWS Organizations supports centralized root access management for member accounts through IAM. Organizations can remove member-account root credentials and use authorized, short-lived, task-scoped root sessions for supported privileged operations. These sessions are not unrestricted replacements for every root activity. The management account's own root credentials still require protection and a tested recovery procedure.

Break-glass access does not automatically override policy enforcement. An emergency administrator role remains subject to applicable explicit denies, service control policies, permissions boundaries, and other authorization controls. Service control policies also constrain root access in member accounts. If an incident involves an organization-level deny, the recovery plan needs an authorized path to repair that policy rather than assuming a member-account administrator can bypass it.

The principal trade-off is availability versus privileged-access risk. An independent emergency identity can survive normal authentication failures, but it also creates another credential set that attackers may target. Mitigate that risk through secure custody, strong MFA, immediate activation alerts, protected audit logs, and individual attribution. Approval controls should be fast enough for the incident severity and should not depend exclusively on unavailable systems.

Test the full procedure periodically, including identity-provider failure, unavailable authentication devices, restrictive policies, and responder handoffs. Record activation time, operator identity, approvals, and actions taken. After recovery, remove temporary grants, terminate access as appropriate, rotate exposed credentials, reconcile emergency changes with infrastructure definitions, and review whether the procedure achieved recovery without unnecessarily expanding the blast radius.