Prefer SSO sign-in. AWS's IAM guidance says human users should use federation and temporary credentials, and the AWS CLI can get them through IAM Identity Center with aws sso login. Long-lived access keys remain a standing secret on disk, so keep them for cases that truly need them.
What AWS recommends
The IAM security best practices page opens with two requirements. First, require human users to use federation with an identity provider to access AWS using temporary credentials. Second, require workloads to use temporary credentials with IAM roles. It also tells you to update access keys when needed for use cases that require long-term credentials.
For a developer on a laptop, the first point applies. You should not need a permanent key pair in ~/.aws/credentials to run the CLI.
How SSO works in the CLI
The AWS CLI user guide describes configuring IAM Identity Center authentication with the aws configure sso wizard, which creates a profile and an sso-session section. You then sign in with:
aws sso login --profile my-dev-profile
You can also name the session with --sso-session, or use --use-device-code for a device code flow. The login retrieves temporary credentials. As long as you remain signed in to IAM Identity Center and the cached credentials have not expired, the CLI automatically renews expired AWS credentials when needed. After that, you sign in again.
The guide also mentions a legacy non-refreshable configuration, which does not use the sso-session option. Prefer the session based setup the guide labels as recommended.
Side by side
| Aspect | SSO sign-in | Long-lived access key |
|---|---|---|
| Lifetime | Temporary, renewed while signed in | Until you rotate or delete it |
| Stored on disk | Cached short-lived tokens | A key pair in plain text |
| Offboarding | Disable the person in the identity provider | Hunt down every copy of the key |
| MFA | Handled at sign-in | Not part of the key |
The last row of the AWS list, requiring multifactor authentication, is easier to meet when sign-in happens through your identity provider.
Migration steps
- Ask your AWS administrator for IAM Identity Center access and a permission set for your role.
- Run
aws configure ssoand follow the prompts. - Test with
aws sts get-caller-identity --profile my-dev-profile. - Point your tools at the profile, for example through the
AWS_PROFILEenvironment variable. - Delete the old access key from
~/.aws/credentials, then deactivate and delete it in IAM. - Check your shell history and project files for pasted copies of the old key.
When a long-lived key is still needed
Some older tools and third party integrations cannot use SSO. If you must use an access key, grant the narrowest permissions, set a reminder to rotate it, and store it in your password manager or a secrets manager rather than a project file. Workloads running in AWS should use roles instead of keys.
Where Safeguard fits
Safeguard works on the dependency and code side of your software: SBOM and dependency scanning, reachability analysis and policy gates. It does not store or manage credentials, so keep using your password manager, secrets manager or cloud identity for that. You can run a free scan of a project at gold.safeguard.sh/scan.
Quick check
Does SSO login work in a container?
The CLI guide mentions a device code option, which suits terminals without a browser. Check your setup.
Does the CLI renew credentials by itself?
The guide says it renews expired AWS credentials automatically while your Identity Center session and cached credentials remain valid.
What do I do with my old key?
Delete it from your files, then deactivate and delete it in IAM.
Sources
Last reviewed: 19 October 2026.
