Yes. Give new hires federated sign in through your identity provider and temporary credentials, not personal long term access keys. AWS's own guidance recommends this for human users. Access expires on its own, nothing sits in a dotfile for years, and suspending the identity ends access without a hunt for keys.
The difference in plain words
A long term key is a password with no expiry that lives in a file. It can be copied, committed by accident, or forgotten on a laptop. A temporary credential is issued after sign in, works for a limited time, and is requested again when it lapses.
AWS's best practices state that human users should use an identity provider and temporary credentials to access AWS, and that IAM Identity Center is recommended for centralized access management. It also says workloads should use IAM roles so there is no need to distribute long lived IAM user keys to them.
Why it helps onboarding and offboarding
| Concern | Long term keys | Temporary credentials |
|---|---|---|
| Day one setup | Create user, generate key, send securely | Add to group, person signs in |
| Leaked key impact | Valid until someone notices | Valid until it expires |
| Leaver | Find and delete each key | Suspend identity |
| Audit trail | Shared or ambiguous keys possible | Tied to the signed in person |
| Rotation burden | Manual | Automatic by design |
How to set it up for a new developer
- Connect your identity provider to your cloud accounts through a central access service.
- Create permission sets by role: developer sandbox, read only logs, and so on.
- Map identity provider groups to permission sets. The new hire joins a group, nothing else.
- Install the command line tooling and teach the sign in command. A short page in your onboarding guide is enough.
- Set session lengths that balance safety and annoyance. Shorter is safer for sensitive roles.
- Require MFA at the identity provider, preferably phishing resistant methods such as passkeys or security keys, which AWS recommends where possible.
- Verify by asking the new hire to list a resource using only the temporary session.
When you still need long term keys
AWS acknowledges cases that need them, such as workloads that cannot use roles, some third party clients, and certain service specific credentials. If you must, then: scope narrowly, name the key for the owner and purpose, set a review date, and record it in a register. Rotate on staff change.
Beyond cloud
The same idea applies elsewhere. Prefer single sign on and short lived tokens for source hosts, registries and internal tools. Where tokens must be personal, set expiry and require approval, then limit what they can reach.
Common objections
"It is slower." Sign in takes seconds and removes a setup step you would otherwise do per person.
"Our scripts break." Move them to roles or a CI identity so they do not depend on a person at all.
Quick check
Do temporary credentials remove the need for MFA?
No. Require MFA at sign in, ideally with a phishing resistant method.
What about CI pipelines?
Give pipelines their own role based identity, so they do not borrow a person's credentials.
Safeguard's agent identity and policy features support the same principle for AI agents and automation: named, scoped identities that you can review. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
