Skip to main content
INS // Insights

Rotate Long-Lived AWS Credentials — Or Eliminate

Updated September 2026 · 8 min read
Rotate Long-Lived AWS Credentials — Or Eliminate

Rotate long-lived AWS credentials if you must survive the week. Eliminate them if you want the finding to stay closed. IAM user access keys and leftover CLI keys in laptops are bearer secrets. Rotation is a calendar. Federation is an architecture. AWS itself recommends IAM roles and identity federation over long-term access keys for most use cases (IAM best practices).

Rutagon's default engagement is "stop rotating, start eliminating." We will rotate a key as a containment step when it is already exposed. We will not sell a rotation Lambda as the destination. The destination is roles assumed by humans via IAM Identity Center and by workloads via OIDC.

Why Rotation Programs Never End

A 90-day rotation policy looks mature in a handbook. In production it creates:

  • Dual keys during overlap (the old key stays valid "just in case")
  • Copies in GitHub secrets, local ~/.aws/credentials, and a vendor's form
  • A scanner that goes green while the copy in a forgotten Lambda stays live
  • A service account nobody wants to touch because the last rotation broke billing

CISA's operational directive family and secure-by-design guidance keep pushing toward phishing-resistant, short-lived credentials for people; the same physics apply to machines (CISA). A rotated key is still long-lived relative to an STS session.

Rotate Long-Lived AWS Credentials Only as a Bridge

Containment checklist when a key is live and scary:

  1. Disable (not delete) the key.
  2. Watch CloudTrail for the principal — if production breaks, you have the caller.
  3. Issue a replacement only if federation cannot land the same day.
  4. Put an expiry on the replacement in the ticket, not in a wiki.
def contain_iam_user_key(iam, user_name, key_id):
    iam.update_access_key(UserName=user_name, AccessKeyId=key_id, Status="Inactive")
    # CloudTrail lookup on AccessKeyId over the last 7 days
    # If silent for the watch window, delete the key and then the user

If the caller is a human, the replacement is Identity Center, not a new key. If the caller is CI, the replacement is workload identity federation. If the caller is a vendor that only accepts a key, it goes on the exception register with an owner — same pattern as eliminate service account passwords.

The Cutover Checklist We Run

Humans

  • Identity Center permission sets replace console IAM users
  • AWS CLI uses SSO (aws sso login), not access keys
  • Break-glass is a separate, reviewed path — see break-glass AWS access review

Workloads

  • OIDC or instance/task roles
  • No AWS_ACCESS_KEY_ID in environment variables
  • Permission boundaries on deploy roles

Proof

  • IAM credential report shows no active user keys except documented exceptions
  • Access Analyzer unused access findings are triaged, not ignored (IAM Access Analyzer)
  • A CloudTrail metric filter alarms on CreateAccessKey

We have run this to completion on Rutagon's own multi-account org and on a production SaaS platform: zero long-lived deploy keys as the target, not as a slide. Capability: security automation.

What Auditors Do With This

SOC 2 CC6 and related logical-access criteria care that access is appropriate and removed. A rotation log is weak evidence if the key class should not exist. A credential report plus a federation trust policy is stronger. We still do not claim Rutagon holds SOC 2. We claim your key count can be a number you can defend.

Diagnostic

We pull the credential report, the GitHub secret names, and a week of CloudTrail GetSessionToken / AssumeRole vs access-key-signed calls. You get a kill list, not a rotation calendar. If the report still shows active keys after the first wave, we treat that as an open exception with an owner — not as a completed rotation program.

Laptop-local keys are the copy everyone forgets. A developer ran aws configure three years ago, the IAM user was "temporarily" left for a vendor demo, and the access key is still in ~/.aws/credentials on a machine that sometimes has production VPN. Federation for CI does not clean that up. We add a human pass: Identity Center for daily work, a credential-report diff each week, and a written expectation that local access keys are a finding, not a convenience.

Third-party "AWS connectors" in SaaS products are the other copy. A marketing tool that asks for an access key to write to S3 should get a dedicated role via the vendor's modern assume-role flow if it has one, or a tightly scoped user on the exception register if it does not. Sharing the same key the CI used to use is how a browser extension becomes production admin.

Root account access keys are a special case. If they exist, they are not a rotation item — they are an emergency. We disable them, turn on hardware MFA on the root user, and move every daily action to Identity Center. The credential report's root row is the first line we read, not the last.

STS session duration is the other half of "short-lived." A federated role that issues twelve-hour tokens with AdministratorAccess is better than a ten-year IAM user key and still too much. We set duration to the job: CI deploy roles in the tens of minutes, human permission sets to a working day, break-glass shorter and ticketed. CloudTrail AssumeRole events become the evidence that sessions existed and ended.

Finally, we put CreateAccessKey and UpdateAccessKey into a metric filter with an alarm that pages the owner of the security account. Rotation programs that quietly mint new keys after the "elimination" sprint are how the finding reopens in the next observation window. The alarm is the control that keeps the kill list dead.

Talk to us about your credential elimination pilot →

907-841-8407 · contact@rutagon.com

Frequently Asked Questions

How fast should we rotate a leaked AWS key?

Disable immediately. Delete after you confirm what broke. Rotation without disable leaves the leaked value valid. Federation is the follow-up so you are not here again next quarter.

Are IAM user keys ever acceptable?

Rare vendor constraints and some break-glass designs. Both need an owner, monitoring, and a review cadence tighter than ordinary access. They are not a default for employees.

Does Secrets Manager rotation solve IAM user keys?

Secrets Manager rotates stored secrets. It does not remove the need for the IAM user. Prefer eliminating the user. If you must keep a vendor password, rotation there is a different problem.

What about access keys on EC2?

They should not exist. The instance role is the credential. If a bootstrap script wrote keys to disk, that is an incident-shaped cleanup, then a role.

Can we keep keys for Terraform state backends?

No. Terraform should assume a role via OIDC or a runner role. State access is high blast radius. A long-lived key there is a standing admin.