- Newest
- Most votes
- Most comments
I believe a support case should've been automatically raised in your account when the initial action involving attaching the policy to the user was taken by AWS. By default, the root email address of the account would be notified of the ticket. The ticket is raised because it contains instructions that you are required to take to release the user from quarantine.
Are you not seeing a support ticket about the quarantining in your account?
There are a few potential reasons why an access key could be quarantined by the AWSCompromisedKeyQuarantineV2 policy without you being notified:
Automated Detection of Suspicious Activity:
The AWS security systems have algorithms in place to automatically detect suspicious or anomalous use of access keys.
If the system detects activity that indicates the access key may have been compromised, it can proactively quarantine the key as a precautionary measure, even if there's no clear evidence of a leak.
Insufficient Audit Logging or Monitoring:
If your AWS account's logging and monitoring configurations are not set up properly, suspicious activity may go unnoticed, leading to a silent quarantine of the access key.
Ensure that you have comprehensive CloudTrail logging, Amazon CloudWatch alarms, and other security monitoring measures in place to detect and be notified of such events.
Compromised AWS Account or Credentials:
If your AWS account, root user credentials, or other privileged credentials have been compromised, an attacker could potentially use your access keys without your knowledge.
In such a scenario, the AWS security systems may quarantine the access key as a protective measure, even if you're unaware of the breach.
Lack of Proactive Key Rotation:
If you don't have a regular process for rotating your access keys, they may become outdated or exposed over time, leading to a silent quarantine by the AWS security systems.
To address this issue and prevent future occurrences, consider the following steps:
Review CloudTrail Logs: Carefully review your CloudTrail logs to look for any suspicious activity or unauthorized access attempts that may have triggered the quarantine.
Enable Comprehensive Logging and Monitoring: Ensure that you have robust logging and monitoring configurations in place, including CloudTrail, CloudWatch, and other relevant security services. This will help you detect and be notified of any future suspicious activity.
Rotate Access Keys Regularly: Implement a regular process for rotating your access keys, ensuring that any potentially compromised keys are replaced in a timely manner.
Review and Secure Your AWS Account: Thoroughly review your AWS account, including the root user credentials, IAM users, and other privileged access. Ensure that all credentials are secure and that your account is not compromised.
Contact AWS Support: If you have limited information about the quarantine and the reasons behind it, consider contacting AWS Support. They may be able to provide more details and guidance on the specific incident and any necessary remediation steps.
By taking these actions, you can better understand the root cause of the access key quarantine, strengthen your AWS security posture, and be better prepared to respond to any future security incidents.
Relevant content
- asked 2 months ago
- asked 4 years ago
- asked 3 years ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 2 years ago

No. I don't see any support ticket at all. That is my question.
I have also tried searching the CloudTrail event history to see when and how the quarantine policy was added but couldn't find any related information.
@dansoonie All changes to IAM in the main commercial partition of AWS are made in the us-east-1 region. If the policy attachment was logged by CloudTrail, you'll only find it in the logs for the us-east-1 region. The default trail that you can access via the Event history view in the CloudTrail console allows searching events for the past 90 days.
@Leo K Thank you for the helpful comment. I did not think of that. However, unfortunately I was unable to find any related event(checked all regions too). From the console I was able to find the time and date when the policy was attached to the user of the access key (IAM > Users > [user] page, from the permissions tab, edited time colum). So I know exactly when to search for the event(about a week ago).