Topic starter
24/10/2026 8:49 pm
TL;DR: Truffle Security's analysis of AWS quarantine policies finds that 894 of 929 quarantined keys still held dangerous grants, including access to secrets, commands, databases, and other roles. Quarantine can narrow access, but it does not end a leaked key's utility, so revocation remains the decisive control.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “AWS Key Quarantine is Not Revocation”.
By the numbers:
- The article says 894 of the 929 quarantined keys still had dangerous grants outside AWS quarantine deny lists.
- Truffle Security reports that 738 keys had an older quarantine policy listed without V3.
- Creation dates were available for 926 keys, and their median age was 3.6 years.
Key questions
Q: Why do leaked cloud keys still create risk after a deny policy is attached?
A: Because effective access in AWS is determined by more than one policy layer.
Q: How should teams prioritise revocation versus partial containment for exposed AWS keys?
A: Revocation should come first, because containment only reduces the set of usable actions while revocation ends the credential's utility.
Q: What breaks when AWS quarantine is used instead of actual key revocation?
A: Quarantine can leave the credential active, so the leaked key may still authenticate and use any permissions that sit outside the deny list.
Practitioner guidance
- Revoke exposed keys, do not just quarantine them Treat quarantine as temporary containment and immediately remove the credential from active use, including any linked sessions, trust paths, and dependent applications.
- Inventory the surviving permissions on each leaked key Check the exact grants that remain outside the deny list, including secret reads, command execution, data access, and any assume-role path that can extend reach.
- Standardise on the current quarantine policy version Compare all quarantined keys against the newest deny rules and reapply policy where older versions leave gaps in the restriction set.
Bottom line: AWS quarantine policies can narrow access without actually ending a leaked key's usefulness.
Glossary terms: AWS key quarantine, Credential Revocation, Residual permission path, Long-Lived Secret
What's in the full report
Truffle Security's full post covers the operational detail this analysis intentionally leaves for the source:
- The full list of uncovered AWS actions that quarantine leaves available, including secret access, command execution, and data operations.
- The policy-version comparison showing how the original, V2, and V3 quarantine definitions differ in practice.
- The dataset methodology behind the 929 quarantined keys and how the authors matched policy names to AWS definitions.
- The deeper examples of how S3, DynamoDB, RDS snapshots, Lambda packages, and role trust paths remain reachable.
👉 Read Truffle Security's analysis of AWS quarantine gaps and exposed key revocation →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago 2 times by NHI Mgmt Group
25/10/2026 11:13 am
Quarantine without revocation is a control illusion: The article shows that AWS can block selected actions while leaving the underlying credential alive and still useful. That is not the same as ending exposure, because the identity remains capable wherever the deny list does not reach. The practitioner lesson is that partial restriction can reduce noise without reducing the real attack surface.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should security teams check before assuming a quarantined key is harmless?
A: They should verify the exact policy version attached, the remaining grants on the IAM user, and any role trust or resource-based permission that still permits use. A quarantined key can still reach data or commands if another control layer allows it. Harmlessness has to be proven, not inferred from the quarantine label.
👉 Read our full editorial: AWS quarantine leaves exposed keys active and privileged
This post was modified 7 days ago by NHI Mgmt Group