Break-glass access — the org-admin or root-equivalent path reserved for genuine emergencies — is one of the highest-risk permission sets in any AWS environment, and it's also one of the most commonly under-reviewed. Companies build the break-glass path carefully, then forget to build an equally careful review process for who can use it and whether they still should.
Why Break-Glass Needs a Separate Review Cadence
A quarterly access review that treats break-glass the same as routine developer access misses the point. Break-glass accounts are used rarely by design, which means a standard "have they used this in the last 90 days" heuristic doesn't apply — the whole point is that they sit dormant until an emergency, so usage-based deprovisioning logic would incorrectly flag legitimate break-glass accounts as inactive and revoke exactly the access you need available in a crisis.
The Dual-Control Pattern We Build
Instead of usage-based review, we build a recertification workflow specifically for break-glass paths:
- Monthly, not quarterly, recertification — because the blast radius of a stale break-glass grant is high enough to warrant tighter cycles than routine access
- Two-person sign-off required to recertify, not one — typically the security/compliance owner and the engineering leader who'd actually authorize emergency use
- Automatic notification on every login event to the break-glass identity, regardless of whether it's expected, routed to a Slack channel and logged separately from routine CloudTrail noise
- A living roster, not a static document — the recertification tool queries current IAM Identity Center or IAM user assignments directly rather than relying on someone's memory of who has access
import boto3
from datetime import datetime
def check_breakglass_activity_and_flag_review(breakglass_role_arns):
"""Flags break-glass identities for recertification and reports last-use timestamp
without treating dormancy as a revocation signal."""
ct = boto3.client("cloudtrail")
results = []
for role_arn in breakglass_role_arns:
events = ct.lookup_events(
LookupAttributes=[{"AttributeKey": "ResourceName", "AttributeValue": role_arn}],
MaxResults=10,
)
last_used = events["Events"][0]["EventTime"] if events["Events"] else None
results.append({
"role_arn": role_arn,
"last_used": last_used,
"review_due": True, # monthly cadence regardless of usage
"checked_at": datetime.utcnow().isoformat(),
})
return results
What This Produces for an Audit
Rather than a screenshot of an IAM console showing who currently has break-glass access, the evidence pack includes the monthly recertification record, the two approvers for each cycle, and a login-event log showing every actual use — three separate artifacts that together demonstrate ongoing, dual-controlled oversight of the riskiest access path in the environment. Auditors reviewing privileged access controls (commonly mapped to CC6.1 and CC6.3) respond well to this because it shows a deliberate process, not an ad hoc one.
Why This Matters More Than It Looks
Break-glass access is exactly the kind of finding that turns into a management letter comment if handled poorly — not because the access itself is wrong, but because an unreviewed emergency path is indistinguishable from an unreviewed backdoor from an auditor's perspective. The fix isn't complicated engineering; it's building a review cadence that fits how break-glass access is actually used, instead of forcing it into the same usage-based logic that works for routine developer access.
Frequently Asked Questions
How is break-glass access typically implemented in AWS?
Common patterns include a dedicated IAM role with a strong MFA requirement and session duration limits, or a separate emergency-access account entirely, depending on the organization's Identity Center architecture and risk tolerance.
Why not just use usage-based review for everything?
Usage-based review works well for routine access because inactivity is a genuine signal something should be revoked. For break-glass access, inactivity is expected and doesn't mean the access should be removed — it means the emergency hasn't happened yet.
What's a reasonable recertification frequency for break-glass access?
Monthly is a common baseline for organizations with meaningful compliance obligations; some tighten to bi-weekly for the highest-risk paths like organization-management-account root access.
Does dual-control slow down actual emergency use?
No — dual-control applies to the recertification of who's authorized to use break-glass access, not to using it during an actual incident. The access itself remains immediately available to authorized individuals when needed.
Ask us what your GRC platform isn't covering on privileged access → rutagon.com/contact or call 907-841-8407.