Credential Management

Credential management governs how authentication material is issued, protected, used, replaced, and retired. In cloud environments, this includes credentials for engineers, administrators, applications, automation pipelines, and emergency access. Authentication establishes who is making a request; authorization determines what that identity may do. A securely stored credential can still be dangerous if its identity has excessive permissions, so credential management must work alongside least-privilege access policies.

Different credentials serve different purposes. An AWS IAM user can have a console password and, separately, access keys for programmatic requests. An access key consists of an access key ID and a secret access key. Temporary AWS credentials also include a session token and expire automatically. Changing a console password does not rotate access keys, and deleting an access key does not remove console access. Engineers must inventory and manage each authentication method independently.

Prefer temporary credentials over long-lived access keys wherever possible. A workload running on an AWS compute service can obtain role credentials through its supported credential mechanism rather than embedding keys in code. Developers can use federated sign-in and role sessions instead of maintaining individual long-lived keys. AWS SDK credential providers can retrieve and refresh role credentials automatically. Temporary credentials reduce persistent exposure, but they remain sensitive and can be abused until they expire or access is otherwise restricted.

When an application needs a database password or external API token, store it in a dedicated secret store rather than source code, container images, shared documents, or logs. For example, a workload can use its IAM role to retrieve a database password from AWS Secrets Manager. AWS Systems Manager Parameter Store also supports encrypted SecureString parameters. Secrets Manager provides managed rotation capabilities for supported integrations and customizable rotation workflows; Parameter Store does not provide equivalent built-in secret rotation. Encryption at rest alone is insufficient: restrict retrieval permissions, protect decryption access, and prevent applications from exposing retrieved values.

Password policies establish requirements such as minimum length, complexity, and reuse restrictions. AWS IAM account password policies apply to IAM user console passwords, not root user passwords, access keys, or passwords managed by an external identity provider. Configure workforce password controls in the system that actually authenticates those users. Use unique passwords and multifactor authentication rather than relying on complexity alone. Enabling MFA for console sign-in does not automatically require MFA for every request signed with an IAM user's long-lived access keys.

Root user protection deserves separate controls because root has highly privileged account capabilities. Do not use root for everyday administration, and do not create root access keys. Protect the root password with a strong, unique value, enable MFA, and secure the associated email account and recovery channels. Restrict access to root credentials, monitor root activity, and reserve root sign-in for tasks that require it. Where AWS Organizations centralized root access management is configured, eligible member accounts can have long-term root credentials removed; the management account still requires its own root protection.

Rotation and revocation must be operationally safe. When replacing a long-lived key, update its consumers, verify that they use the replacement, and then deactivate and delete the old key. For a leaked credential, revoke or disable it promptly and investigate its use; removing it from a repository does not invalidate it. Secret retrieval adds cost, latency, and availability dependencies, while caching reduces requests but can delay adoption of rotated values. Design refresh behavior, monitoring, and incident procedures around these trade-offs.