AWS quarantine policy gaps: are exposed keys really revoked?

TL;DR: Truffle Security found that AWS quarantine policies can leave leaked keys active while preserving permissions to read secrets, run commands, delete databases, and move into other roles, with 894 of 929 quarantined keys still holding dangerous grants. Quarantine without revocation leaves the trust boundary intact, so the real control problem is credential invalidation, not partial restriction.

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: 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.

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.

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.

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 →