Notifications
Clear all
Topic starter
18/08/2026 2:40 pm
TL;DR: AWS IAM eventual consistency leaves a roughly four-second window after key deletion or policy changes during which revoked credentials can still be used to create new access, according to OFFENSAI research, and AWS Organizations SCPs are the only reliable control in that interval. The lesson for IAM teams is that revocation without account-level containment is not a complete response.
NHIMG editorial — based on content published by OFFENSAI: AWS exploiting AWS IAM eventual consistency for persistence
By the numbers:
- AWS credentials are attempted within an average of 17 minutes after public exposure, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when AWS access keys are deleted during an active compromise?
A: Deletion is not immediate containment.
Q: Why do IAM revocation steps sometimes fail to stop an attacker right away?
A: They fail because the control plane is distributed and can lag behind administrative intent.
Q: How do security teams know whether containment is actually working?
A: They should test whether the identity can still execute privileged actions after revocation, not just whether the API call succeeded.
Practitioner guidance
- Contain compromised principals with account-level SCPs first Apply an AWS Organizations service control policy that denies all actions for the affected principal before you begin credential cleanup.
- Reorder incident response to assume propagation lag Update runbooks so revocation, policy cleanup, and access-key deletion are treated as delayed enforcement steps.
- Instrument detections for post-revocation activity Tune alerts for `ListAccessKeys`, `CreateAccessKey`, policy detachment, and role-assumption activity occurring immediately after a revocation event.
What's in the full report
OFFENSAI's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact AWS CLI sequence used to demonstrate key deletion, key recreation, and policy-change races.
- The retest findings that show which IAM operations still exhibit consistency delay beyond access-key deletion.
- The SCP containment example used to block compromised principals at the account boundary.
- The disclosure timeline and AWS acknowledgement details that matter for incident-response planning.
👉 Read OFFENSAI's analysis of AWS IAM eventual consistency and persistence →
AWS IAM eventual consistency: is your revocation process enough?
Explore further
18/08/2026 3:24 pm
Eventual consistency becomes a security problem the moment identity state is used for containment. IAM systems are usually designed to converge, not to stop an active attacker instantly. OFFENSAI’s finding shows that revocation, detachment, and profile changes can all trail the defender’s intent by enough time for an adversary to act again. The practitioner conclusion is that containment cannot depend on the same layer that is still propagating the compromise state.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which is why delayed containment assumptions are so risky.
A question worth separating out:
Q: Who is accountable when a revoked AWS principal still has access?
A: Accountability sits with the team that designed the response path and the control boundary. If the runbook relied on identity-level changes alone, then the containment model was too weak for a distributed IAM system, and account-level controls should be part of the operating standard.
👉 Read our full editorial: AWS IAM eventual consistency creates a persistence window
