Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

AWSCompromisedKeyQuarantineV3 is an AWS-managed, action-specific quarantine policy that AWS applies in response to compromised or publicly exposed IAM credentials. It denies selected actions to limit potential fraud-related damage, but it is not a universal kill switch: it does not by itself revoke every credential, secure an account, or investigate what an attacker already did. If AWS has attached it during an incident, leave it in place and follow the instructions in the related AWS Support case.

What AWSCompromisedKeyQuarantineV3 does

AWS describes this policy as a way to limit potential damage from fraud-related activity that could lead to unauthorized charges, while avoiding impact to existing resources. It can be attached to IAM users, groups, and roles. Its deny statements target selected actions rather than blocking every AWS API operation.

The AWS policy reference lists version v3 as the default version, last edited March 16, 2026. The default policy version is the one AWS evaluates. Its published actions include examples such as iam:CreateAccessKey, iam:CreateRole, iam:UpdateAssumeRolePolicy, ec2:RunInstances, lambda:CreateFunction, and selected S3 operations. These examples show the kinds of credential, role, compute, and data operations that can be restricted; they are not a complete list, and the policy can change.

The policy documentation gives affected customers this instruction: “Do NOT remove this policy. Instead, please follow the instructions specified in the support case created for you regarding this event.” Do not treat the policy as a customer-run switch to attach, edit, or remove without AWS’s incident-specific guidance.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
#1 Best Overall

What the quarantine does not settle

A denial limits selected future actions; it does not establish that the exposed credential has been deleted, that all existing sessions have stopped working, or that resources created before containment have been removed. Nor does it show whether data was accessed or changed, whether another principal was compromised, or whether charges have accrued. Those questions require separate credential handling and investigation.

AWS Support’s Exposed Access Keys check looks for exposed keys in popular public code repositories and irregular EC2 use that might indicate compromise. AWS says the check cannot guarantee that it will identify every exposed key or compromised EC2 instance. AWS may temporarily limit creation of some resources to help protect against excessive charges, but AWS explicitly warns that this does not make the account secure and only partially limits unauthorized usage that can incur charges.

Respond to a long-term IAM user access key exposure

  1. Follow the AWS Support case. If AWS has applied AWSCompromisedKeyQuarantineV3, keep it attached and use the case instructions for the event rather than improvising policy changes.
  2. Delete the affected access key as soon as possible. AWS Support recommends deleting the exposed key. Long-term IAM-user keys do not expire on their own, so deleting or deactivating the compromised key is a separate containment action from leaving the quarantine policy in place.
  3. Inspect the account for unauthorized changes and resources. Check service consoles for suspicious resources, especially EC2 instances and Spot requests, newly created access keys, and IAM users. Also inspect billing and usage for unexpected activity.
  4. Investigate likely persistence and impact paths. Use the checklist below to look beyond the original key and examine what permissions or resources may have been changed.

Choose containment based on credential type

“Revoke the credentials” does not mean the same operation for every AWS credential. Long-term keys, role sessions, Identity Center sessions, and root credentials have different controls.

Credential or session Containment path Scope and caveat
Long-term IAM user access key Delete the affected access key; follow AWS Support’s case directions if the quarantine policy is attached. The key does not expire on its own. Removing the key does not investigate resources or changes already made.
Temporary role credentials Remove the effective permissions or revoke temporary credentials for the role. Revoking credentials role-wide affects all sessions for that role and can interrupt legitimate users. Condition keys or resource-based policies can help target particular sessions or principals.
IAM Identity Center permission-set session Revoke the user’s active permission-set session through IAM Identity Center. Permission-set roles are not edited like ordinary IAM roles; use the Identity Center procedure.
Root credentials Secure the root credential and follow AWS’s root-credential guidance for the incident. IAM policies cannot explicitly deny the root user. AWS Organizations service control policies can limit root permissions; long-term root credentials do not expire.

For temporary credentials, distinguish the credential itself from the permissions it can exercise. AWS evaluates permissions on each request, and requests using a temporary credential fail once all its permissions have been removed. Policy changes may take a few minutes to take effect. If a resource-based policy independently grants access, an explicit deny there may also be necessary; otherwise an identity-policy change alone may not remove that access path.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Investigate what the compromised identity could have changed

AWS Security Hub describes several possible IAM exposure paths. They are investigation leads, not proof that any particular attacker used them:

  • Privilege or boundary changes: Check whether permission boundaries or other restrictions were removed or weakened.
  • New identities or credentials: Look for new IAM users and access keys, including credentials created for other principals.
  • Role trust changes: Review role trust policies for changes that could let an unauthorized principal assume a role.
  • Unauthorized compute: Check for new EC2 instances, Spot requests, or other compute created with a privileged role, as well as existing compute invoked through its role.
  • Data impact: Examine relevant S3 and other data-service activity for possible encryption, deletion, or unauthorized access.
  • Financial impact: Compare billing and usage with expected activity and investigate unexpected resource consumption.

Use the affected key’s permissions and account activity to prioritize the review. A policy denial is a containment signal, not a substitute for checking for persistence, data changes, and resources that may have been created before it took effect.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Read detection and status signals cautiously

AWS Support says the Exposed Access Keys check refreshes several times daily. Account changes may take a few hours to appear, and synchronization showing resolution can take up to a week. Those timings are not a guarantee that detection is immediate or complete. A clean or updated Trusted Advisor result therefore does not prove that every exposed key or compromised instance has been found, or that the account is safe.

Reduce the chance of another exposure

  • Prefer temporary credentials. AWS recommends using IAM roles and federated principals instead of long-term IAM-user access keys where possible.
  • Manage credentials that remain. AWS recommends processes for managing keys and changing passwords. Long-term IAM-user and root credentials do not expire automatically.
  • Enable MFA. AWS describes MFA as an additional layer if credentials are compromised, not a replacement for revoking an exposed key or completing incident response.
  • Use rotation as prevention, not remediation. AWS Security Hub’s IAM-user exposure guidance mentions rotating keys every 90 days as a preventive recommendation. That interval does not replace immediate response to an exposed key.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.