Topic starter
16/04/2026 6:38 pm
TL;DR: AWS IAM changes can take seconds to propagate, and OFFENSAI’s notyet tool shows how an attacker with valid credentials can exploit that window to restore privileges and outlast common containment steps. The core problem is that incident response playbooks still assume privilege removal is immediately durable, according to Sonrai Security’s analysis.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “Fighting Eventual Consistency-Based Persistence - An Analysis of notyet”.
Key questions
Q: What breaks when IAM revocation is not immediately enforced?
A: The compromised identity can observe the change, recreate permissions, or shift into a fresh credential path before containment completes.
Q: Why do local IAM changes fail against eventual consistency persistence?
A: They fail because the compromised identity still has a short period in which the old permissions can be used or rebuilt.
Q: How can security teams tell whether an AWS quarantine control is actually working?
A: A quarantine control is working only if the identity cannot undo it from within the same account and cannot regain privileges during propagation.
Practitioner guidance
- Quarantine privileged identities with org-level controls Use AWS Organizations SCPs to deny the compromised principal’s actions from outside the member account, because account-local revocation can be reversed during IAM propagation.
- Redesign incident response for propagation latency Assume that IAM changes may take seconds to become durable and that an attacker can poll and react within that window, so containment workflows must account for enforcement delay.
- Test containment against active reversion Exercise playbooks with an adversarial loop that attempts to recreate roles, reattach policies, and regenerate credentials after every revoke so you can see which actions hold.
Bottom line: AWS IAM eventual consistency creates a real containment gap because privilege removal is not always immediate across the control plane.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/10/2026 2:36 am
Eventual consistency turns containment into a race, not a state change: AWS IAM assumes privilege updates will converge quickly enough for normal response actions to succeed. That assumption fails when the compromised identity can observe the change and restore itself before convergence completes. The implication is that cloud incident response must be designed around enforcement latency, not around the moment an API call returns success.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams do when a compromised AWS identity keeps restoring access?
A: Treat the behaviour as a containment design failure, not a one-off cleanup problem. Move the response to an account-level or organisation-level restriction the identity cannot detach, then retest the playbook against credential recreation and policy reattachment loops before relying on it in production.
👉 Read our full editorial: Eventual consistency persistence exposes a cloud IAM containment gap