Credential Rotation

Credential rotation replaces an authentication secret and retires its predecessor. A complete rotation changes the credential at the system that validates it, securely distributes the replacement to authorized consumers, verifies successful authentication, and invalidates the old value. Merely generating a new password or updating a secret in storage does not complete rotation if the target system still accepts the old credential.

In cloud environments, first distinguish long-lived credentials from temporary credentials. Long-lived credentials include IAM user access keys, database passwords, and many third-party API secrets. These require explicit lifecycle management. Temporary credentials have an expiration time and are obtained again when needed. For workloads accessing AWS, prefer IAM roles and temporary credentials over embedded IAM user access keys. Supported SDK credential providers can obtain and refresh role credentials without application code handling persistent secrets.

For an unavoidable IAM user access key, a practical rotation sequence is to create a second key, update authorized consumers, verify that requests use the replacement, deactivate the old key, and eventually delete it. An IAM user can have at most two access keys, including inactive keys, so available key slots affect the procedure. Access keys do not automatically expire because of an IAM password policy. Password policies govern IAM user console passwords, including configurable complexity, reuse prevention, and expiration settings; they do not rotate API credentials.

Database password rotation requires coordination between the database and its clients. For example, a rotation workflow can generate a new password, apply it to the database account, test access, and promote the new secret version for application retrieval. AWS Secrets Manager supports automatic rotation through managed integrations or Lambda-based workflows, depending on the secret and target service. Applications must refresh cached secrets appropriately and recover from authentication failures; otherwise, successful rotation can still interrupt connection establishment.

Secret storage and secret rotation are separate capabilities. A central store protects values, controls retrieval, and reduces hard-coded credentials in source repositories and deployment files. AWS Systems Manager Parameter Store can store encrypted SecureString parameters, but parameter expiration notifications or policies do not themselves change credentials in a database or external system. Rotation requires an integration or workflow that updates both the target and its stored value.

Choose rotation timing according to exposure risk, credential capabilities, compliance requirements, and operational constraints. Scheduled rotation can reduce the lifetime of an undiscovered leaked secret, but suspected compromise requires immediate containment rather than waiting for the next schedule. Replace or revoke affected credentials, investigate their use, and address the original exposure. Replacing a password or access key does not necessarily terminate sessions or invalidate temporary credentials already issued; those may need separate controls.

Availability and security can conflict during cutover. Brief overlap between old and new credentials can support a safe rollout when the target accepts both, but it also extends the old credential's usability. Single-password accounts may require carefully timed updates, retries, or an alternating-account strategy. Test failures, partial deployment, stale caches, and recovery procedures before production use. Restrict the rotation workflow's permissions, avoid logging secret values, and alert on failed or overdue rotations.

Finally, credential rotation is not the same as encryption-key rotation. Rotating an AWS KMS key's backing key material does not change database passwords, replace IAM access keys, or automatically re-encrypt existing data. Rotation also does not replace least privilege, multifactor authentication, secure storage, or incident response. For human passwords, arbitrary frequent changes are not a substitute for strong passwords and MFA; use applicable policy requirements and evidence of compromise to guide changes.