The alarm goes off at 2:17 AM. Your AWS root account is locked, production is down, and customer data may be at risk. This is when “break glass” access stops being theory and becomes survival.
Break glass access in AWS is a controlled, temporary elevation of privileges used only in emergencies. Done right, it can save your systems. Done wrong, it can destroy trust, lose data, and break compliance.
Why break glass exists
Even the best permission models cannot predict every incident. Misconfigured IAM roles, failed federations, SSO downtime, or malicious access blocks can freeze a team out of its own environment. Break glass procedures give a small, audited path into AWS when all normal access controls fail.
Core principles for AWS break glass access
- Isolation: Keep emergency credentials entirely separate from day‑to‑day accounts. Store them in a secure, offline vault.
- Least privilege: Even in a break glass scenario, provide only the exact privileges needed to restore service. Limit to specific AWS services or resources.
- Multi-factor authentication: Require MFA even for break glass accounts. Hardware tokens are more resilient than app-based MFA during outages.
- Expiration: Access must expire quickly after activation—minutes or hours, not days.
- Audit logging: Log every action in CloudTrail. Ship logs to an immutable store or an account that cannot be altered by the break glass credentials.
Designing your break glass path in AWS
- Create an emergency IAM user with tightly scoped permissions.
- Disable by default with no active keys or passwords unless activated.
- Document activation steps and store them in a secure, out-of-band location that is tested.
- Test quarterly. Simulate actual failure conditions. Ensure your team can restore access under time pressure.
- Automate alerts so that any use of break glass triggers immediate notifications to on‑call engineers and security leads.
Reducing blast radius
A break glass account is a loaded weapon. Limit the regions, restrict destructive API calls, and ensure every action by that account is tagged and traceable. Combine AWS SCPs with IAM conditions to further shrink any accidental damage.
Compliance and governance
Regulations like SOC2, HIPAA, and ISO 27001 expect emergency access channels to exist—but also to be provably secure. Strong audit trails, review sessions after every use, and signed approvals help meet these requirements.
Bring it to life now
If your AWS break glass procedure lives in a wiki that no one has tested, it’s already stale. Design it. Test it. Automate it. See real‑time, secure break glass access control and auditing in minutes at hoop.dev.