Break glass access is an emergency login that works even when single sign on is down. It should be held by very few people, stored offline, alarmed on use, tested on a schedule, and rotated after every use. Without one, an identity outage can lock you out of recovery.
The problem
Many teams reach cloud accounts and admin consoles only through an identity provider. If that provider is down, misconfigured, or compromised, nobody can sign in to fix things. A disaster plan that assumes everyone can log in is incomplete.
What AWS says
AWS documentation on security credentials says to save the sign in credentials for your Emergency Access IAM user, and any access keys created for programmatic access, in a secure location. It also recommends requiring multi-factor authentication on the account root user and all IAM users, and says to avoid everyday use of the root user, keeping it for tasks only that user can do. It strongly recommends temporary credentials from roles and federated principals over long term credentials. And it notes that if you forget or lose the root password, you need access to the email address on the account to reset it.
That last point is easy to overlook: your emergency route may depend on a mailbox, which in turn may depend on the same identity provider. Check the chain.
Design rules
Few accounts, few holders. One or two emergency accounts per critical system, held by named people, with a documented reason for each.
Separate from daily identity. The emergency account must not depend on the identity provider, the same mailbox domain, or the same phone number as daily logins, or it fails with them.
Strong factors, stored apart. Use hardware keys or another strong factor. Keep the password and the second factor in different physical places, such as two sealed envelopes in separate safes, so no one person can use it alone.
Alarm on use. Any sign in with an emergency account should page a security contact at once. Silent use is a sign of abuse.
Least needed, not all powerful. Give it the permissions you need to recover access and restore service. Where a service lets you cap permissions with organization level policy, consider doing so, bearing in mind AWS notes IAM policies cannot explicitly deny the root user, while service control policies can limit it.
Rotate after use. Treat every use as a credential exposure. Change the password and factors afterwards and record the event.
Test on a schedule. Once a quarter, a named person signs in with the emergency account, confirms it works, then rotates. A break glass account that fails when needed is worse than none.
Write the procedure
A one page procedure should state: who may invoke it, how to request approval if time allows, where the credentials are, what to do on sign in, who to tell, and what to rotate afterwards. Keep a copy offline, because the wiki may be behind the same login.
Do not forget the people
Keep an off platform contact list. If chat and email run through the same provider, you cannot reach the person who holds the envelope.
Quick check
Can the root user be our emergency account?
AWS advises avoiding everyday root use and protecting it with MFA. A dedicated, alarmed emergency account with limited scope is easier to govern.
How often should we test break glass access?
Regularly, such as quarterly, and rotate the credentials after every test or real use.
Sources
Last reviewed: 19 October 2026.
