Rarely. AWS recommends roles with temporary credentials for workloads and keeps long term access keys for cases that cannot use federation. If your CI platform can present an OIDC token, use that. If you must keep a key, scope it tightly, rotate it and watch its use.
What AWS says
The IAM best practices page tells you to require workloads to use temporary credentials with IAM roles. It adds that workloads outside AWS, including managed CI/CD platforms, can still use temporary credentials, and lists ways to deliver them: a certificate based option, a SAML assertion exchange, a web identity token exchange, and a device option over mutual TLS.
The roles page lists use cases where an IAM user with long term keys is still appropriate. Among them are workloads that cannot use roles, third party clients that do not support federation or Identity Center, and certain legacy service credential cases. It also lists emergency access, tightly controlled and protected with multi factor authentication.
That list is shorter than most teams assume. "We have always done it this way" is not on it.
A decision guide
| Your situation | Suggested path |
|---|---|
| CI platform issues OIDC tokens | Use federation with a role |
| Self hosted runners on cloud compute | Use the instance or workload role |
| Runners on your own hardware | Consider a certificate based roles option |
| Third party tool with no federation support | Key, tightly scoped, rotated, monitored |
| Break glass access | Key or user with MFA, stored offline, alarmed |
If you must keep a key
- Create a dedicated IAM user for exactly one pipeline. Never share a key across pipelines.
- Attach a narrow policy with specific actions and resources.
- Add conditions where possible, such as limiting source network ranges.
- Store the secret in your platform's secret store, never in the repository or in the image.
- Rotate on a schedule and whenever someone with access leaves. AWS recommends updating keys when needed, such as when an employee leaves, and using access last used information to update and remove them safely.
- Alert on use from unexpected places and on any use outside deploy hours.
- Set a date to remove it, and put the date in a ticket.
Detecting stale keys
Use last used information to find keys nobody has used in 90 days and disable them. Disable first and wait a release cycle before deleting. AWS recommends regularly reviewing and removing unused users, roles, permissions and credentials.
Why the exception list is short
A long lived key has three properties that federation avoids: it works from anywhere, it works until someone revokes it, and it is easy to copy. Pipelines are exactly where keys get copied, into build logs, caches, forked repositories and developer laptops. A token that expires after a job leaves much less to steal.
If your reason for keeping a key is "migration is hard", that is a project, not a policy. See our guide on moving CI from access keys to OIDC.
Quick check
Can a CI pipeline run on AWS without access keys?
Yes in most cases. AWS says managed CI/CD platforms can use temporary credentials, for example through a web identity token exchange.
Should I delete an unused key immediately?
Disable it first and wait one release cycle. Delete once nothing breaks.
Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. Free scan: gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
