An AWS Access Key Can Outlive the Workload That Needed It

An AWS IAM user access key does not expire because nobody uses it anymore.

It remains valid until someone explicitly deactivates or deletes it.

That creates a surprisingly common lifecycle failure. The workload disappears, the migration finishes, the CI pipeline is replaced, or the original owner moves on. The credential survives.

It is still a valid authentication path.

And if that credential leaks, automated discovery can turn exposure into active abuse within minutes.

The problem is bigger than rotation age

A typical control might say:

Rotate access keys every 90 days.

That is useful, but it answers only one question:

How old is this credential?

It does not answer:

• Does the credential still need to exist?
• Who owns it?
• Which workload currently uses it?
• Where is it stored?
• When was it last used?
• Are its permissions still appropriate?
• What will eventually replace it?

A freshly rotated persistent key can still leak tomorrow.

An old key can remain dormant for months and then become useful to whoever finds it.

The deeper issue is not just credential age.

It is credential persistence.

What a five-minute exposure window looks like

Palo Alto Networks Unit 42 documented this risk in the EleKtra-Leak campaign.

The actor continuously scanned public GitHub repositories for AWS IAM credentials. In Unit 42's controlled leaks, a plaintext key was detected and used within five minutes, followed by attempts to create EC2 capacity for cryptocurrency mining.

Between August 30 and October 6, 2023, the researchers observed 474 distinct miners that appeared to run on actor-controlled EC2 instances. The campaign had been active since at least 2020.

That is not a rotation-calendar failure in isolation. It is automated infrastructure waiting for a valid authentication path to appear. Prevention, detection, and revocation all have to account for that machine-speed window.

Prefer removing the credential

Where possible, the strongest lifecycle improvement is not faster rotation.

It is eliminating the long-lived secret entirely.

AWS supports temporary credentials through mechanisms such as IAM roles and federated identity. CI/CD systems and external workloads can also use approaches such as OIDC to obtain short-lived sessions instead of storing permanent AWS credentials.

That changes the model from:

Create secret → store secret → rotate secret forever

to:

Establish identity → obtain temporary session → let it expire

There are fewer persistent authentication paths to discover, inventory, rotate, and eventually forget.

Treat long-lived keys as exceptions

Not every environment can remove IAM user keys immediately.

Legacy applications and integrations may still depend on them.

When that happens, the key should become an explicit exception rather than invisible infrastructure.

For every persistent key, record:

1. A named owner.
2. The workload and purpose.
3. The approved lifetime.
4. The required permissions.
5. Expected usage.
6. Creation and last-use information.
7. Known storage locations.
8. The replacement strategy.
9. A retirement condition.

The last item matters most. Without an exit condition, an exception has a tendency to become permanent.

Look beyond the obvious storage locations

Long-lived credentials can survive in more places than the application currently using them.

Look beyond the live application. Review:

• source repositories;
• Git history;
• container layers;
• CI/CD variables;
• environment files;
• backups;
• old deployment configurations.

A credential can be removed from the current application while an older valid copy remains somewhere else.

This is another reason rotation alone is not a complete lifecycle control.

Rotation should prove an outcome

For unavoidable persistent credentials, treat rotation as a state transition:

Create → Deploy → Verify → Deactivate → Monitor → Delete

Creating the new key is only the beginning.

You also need confidence that:

• every consumer received the replacement;
• workloads still function;
• the old credential is no longer being used;
• the old credential can be disabled safely;
• the old authentication path is eventually removed.

Otherwise rotation can leave two valid credentials behind. The opposite failure is disabling the old credential before every consumer has migrated.

A better review question

Instead of starting with:

When was this key last rotated?

Start with:

Why does this persistent credential still exist?

Then ask what evidence would allow you to remove it.

Rotation still has a place.

But it should manage the exceptions that cannot yet disappear, not justify keeping persistent credentials indefinitely.

Originally published on TokenTimer.