Why Long-Lived AWS Access Keys Are Dangerous (and What to Use Instead)

Simple explanation

When you create an IAM user and generate an access key, AWS gives you two strings: an access key ID (starts with AKIA) and a secret access key. Together, they work like a username and password for the AWS API. Scripts, CLI tools, and applications use them to authenticate.

The problem is that these credentials are permanent. Unlike a browser session that expires when you log out, an access key stays valid for months or years until someone remembers to delete it. If that key ends up somewhere it should not be (a Git commit, a log file, a Slack message), anyone who finds it gets the same access as the IAM user who owns it.

Temporary credentials, issued through AWS STS, solve this by expiring automatically. A leaked temporary credential is useless after a few hours. A leaked access key is usable forever.

Why long-lived access keys are dangerous

Four properties make long-lived access keys uniquely risky:

• No automatic expiry. A password session ends. An STS credential expires. An access key stays valid until someone manually deactivates or deletes it. Keys created years ago and forgotten are still fully functional.
• Usable from anywhere. There is no IP restriction by default. An attacker with your key can make API calls from any network, any country, at any time. AWS cannot distinguish their request from yours.
• Full IAM user permissions. The key inherits every policy attached to the IAM user. If the user has AdministratorAccess, the attacker has administrator access to your entire account.
• Easy to leak. Access keys are short strings that end up in code, config files, Docker images, environment variables, CI/CD logs, and third-party tools. Every copy is another place the key can escape.

How access keys get leaked

Key leaks follow predictable patterns. Understanding them is how you prevent them.

Committed to Git repositories

This is the most common leak. A developer puts AWS_ACCESS_KEY_ID in a .env file for local testing. The file gets committed and pushed to GitHub. Automated scanners, both legitimate (GitHub Secret Scanning, AWS) and malicious (credential harvesting bots), find the key within minutes.

Hardcoded in application source code

Instead of using environment variables or Secrets Manager, a developer writes client = boto3.client(‘s3’, aws_access_key_id=‘AKIA…’) directly in the source. This ends up in build artifacts, Docker images pushed to public registries, or log output.

Exposed in CI/CD logs

Access keys passed as environment variables to CI/CD jobs appear in build logs when a step prints all environment variables on failure, or when the key is embedded in a URL or command argument. See managing secrets in CI/CD pipelines for how to handle this correctly.

Stored in S3 buckets or public snapshots

Credential files copied to S3 buckets with overly permissive access policies, or EC2 AMIs and EBS snapshots shared publicly while containing ~/.aws/credentials files, are found regularly by automated scanners.

Shared with third-party services

Access keys given to third-party SaaS tools (monitoring, analytics, deployment services) give those tools ongoing access to your account. If the third party is breached, your key is exposed. Use cross-account role assumption instead when the tool supports it.

Passed through chat and documentation

Keys shared in Slack messages, Confluence pages, support tickets, or email are stored in systems you do not control and cannot force-expire. Treat any key shared through a communication channel as compromised.

What attackers do with leaked keys

The gap between a key being leaked and being exploited is often measured in minutes. Automated bots continuously scan public repositories, paste sites, and other sources for the AKIA prefix pattern. When a key is found, it is tested within seconds.

Common attacker actions:

• Crypto mining. Spin up large EC2 instances in every available region. Bills reach tens of thousands of dollars within hours.
• Data exfiltration. Download data from S3 buckets, DynamoDB tables, RDS databases, and Secrets Manager.
• Backdoor creation. Create new IAM users or roles with AdministratorAccess for persistent access, even after the original key is rotated. This is why post-compromise cleanup requires checking for suspicious activity beyond the key itself.
• Ransomware and destruction. Delete backups, snapshots, and databases, then demand payment.
• Cross-account movement. If the compromised user has cross-account role trust, the attacker can pivot into other AWS accounts.

How it works: why IAM roles and STS are safer

The fundamental difference is credential lifetime.

IAM users vs IAM roles

An IAM user has permanent credentials: a password for console access and optionally one or two access keys for API access. These credentials persist until manually changed.

An IAM role has no permanent credentials at all. When a service (EC2, Lambda, ECS) or external identity (GitHub Actions, an on-premises server) assumes a role, AWS STS issues a set of temporary credentials: an access key ID starting with ASIA, a secret access key, and a session token. These expire automatically, typically within 1 to 12 hours.

Why expiry matters

A leaked long-lived key gives an attacker unlimited time. A leaked temporary credential gives them hours at most, and often less because the credential may already be near expiry when found. This dramatically reduces the blast radius of any leak.

Why roles reduce operational burden

With access keys, you need to store the secret securely, distribute it to the right systems, rotate it periodically, and revoke it when no longer needed. Each step is a potential failure point.

With roles, AWS handles credential issuance and rotation automatically. There is no secret to store, no rotation schedule to manage, and no key to revoke. The workload assumes the role, and STS handles the rest. This is why least privilege is easier to maintain with roles: you scope the role’s permissions and let AWS manage the credentials.

When to use long-lived access keys

Long-lived access keys are not the default choice. They are a fallback for situations where temporary credentials are not available.

Narrow cases where long-lived keys may be appropriate

• Local development when IAM Identity Center (SSO) is not set up and you need CLI access from your laptop.
• On-premises workloads that cannot use IAM Roles Anywhere because of certificate infrastructure constraints.
• Third-party integrations that require static credentials and do not support role assumption or OIDC.

In all three cases, scope the key to the minimum permissions needed, set a rotation policy, and monitor usage through CloudTrail.

When you should not use long-lived keys

• EC2 instances - use an instance profile (IAM role).
• Lambda functions - use an execution role.
• ECS and EKS workloads - use task roles or IAM Roles for Service Accounts (IRSA).
• GitHub Actions - use OIDC federation. See GitHub Actions for AWS.
• Other CI/CD systems - use OIDC where supported, or STS AssumeRole with short-lived credentials. See secure CI/CD pipelines.
• Any workload running inside AWS - a role is always available.

Long-lived access keys vs safer alternatives

Example: replacing access keys in GitHub Actions with OIDC

Instead of storing AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as GitHub Secrets, you configure GitHub to present an OIDC token that AWS exchanges for temporary credentials. No secrets to store, nothing to rotate.

# .github/workflows/deploy.yml
jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeployRole
          aws-region: us-east-1

The IAM role’s trust policy grants GitHub’s OIDC provider permission to assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:*"
        }
      }
    }
  ]
}

With this setup, no access key exists. There is nothing to leak, nothing to rotate, and nothing stored in GitHub Secrets. For a deeper walkthrough, see GitHub Actions for AWS deployments.

How to audit and remove existing access keys

If your account already uses long-lived access keys, follow this sequence to migrate away safely.

1. Inventory all keys

aws iam generate-credential-report
aws iam get-credential-report \
  --query 'Content' --output text | base64 --decode > credential-report.csv

2. Find unused or old keys

# List all access keys for all users
for user in $(aws iam list-users --query 'Users[*].UserName' --output text); do
  echo "=== $user ==="
  aws iam list-access-keys --user-name "$user" \
    --query 'AccessKeyMetadata[*].[AccessKeyId,Status,CreateDate]' \
    --output table
done

Focus on keys with a CreateDate older than 90 days, and any key with Status: Active that has not been used recently.

3. Check what each key is used for

aws iam get-access-key-last-used \
  --access-key-id AKIAIOSFODNN7EXAMPLE

The LastUsedDate and ServiceName fields tell you which AWS service the key accessed most recently. Use this plus CloudTrail logs to identify the workload that depends on the key.

4. Replace with roles or temporary credentials

For each workload using a key, pick the right replacement:

5. Deactivate, verify, delete

# Deactivate first, do not delete immediately
aws iam update-access-key \
  --user-name deploy-bot \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive

# Wait and verify no workloads break (1-2 weeks recommended)

# Once confirmed safe, delete
aws iam delete-access-key \
  --user-name deploy-bot \
  --access-key-id AKIAIOSFODNN7EXAMPLE