Password Policies

A password policy defines the requirements that passwords must satisfy and the procedures used to manage them throughout their lifecycle. Common controls include minimum length, character requirements, restrictions on previously used passwords, checks against compromised passwords, and secure recovery processes. Not every identity platform supports every control. Engineers must distinguish organizational requirements from the settings a particular platform can actually enforce.

Length and uniqueness are important because short passwords are easier to guess, while reused passwords expose accounts to credential-stuffing attacks after unrelated breaches. A practical policy encourages long, unique passwords generated and stored in an approved password manager. Where supported, rejecting common or known-compromised passwords helps prevent predictable choices. Character-composition rules alone do not guarantee strength: a predictable word with a number and symbol can satisfy complexity requirements while remaining easy to guess.

Cloud password policies apply at an identity boundary, not automatically across every resource in an organization. For example, an AWS Identity and Access Management account password policy governs passwords for IAM users in that AWS account. It does not govern the AWS account root user's password, federated workforce passwords, application user passwords, or database passwords. Organizations using federation normally manage workforce password requirements at the identity provider that authenticates those users. Each separate identity store needs its own appropriate controls.

Passwords must also be distinguished from access keys. An IAM user password supports interactive AWS Management Console sign-in. An AWS access key ID and secret access key support authenticated programmatic requests, such as requests made through an SDK or the AWS CLI. Changing a password policy does not rotate, expire, or otherwise secure access keys. For workloads, prefer IAM roles and temporary credentials over embedded long-term access keys; for workforce access, federation can similarly provide temporary credentials.

Expiration and reuse settings require deliberate trade-offs. Some compliance requirements mandate periodic password changes, and identity platforms may support configurable password age and password history. However, frequent forced changes can encourage predictable variations and increase support requests. Modern guidance generally favors strong, unique passwords and changes when compromise is suspected or confirmed rather than arbitrary periodic changes. Apply mandatory expiration where required, and document the rationale. Check how policy changes affect existing credentials rather than assuming every current password is immediately revalidated.

Secure credential storage complements password rules but solves a different problem. An application needing a database password can retrieve it from AWS Secrets Manager, which supports managed rotation for supported integrations and custom rotation workflows. AWS Systems Manager Parameter Store can hold sensitive configuration as encrypted SecureString parameters, but it does not provide the same built-in secret-rotation workflows. Neither service establishes the IAM account password policy. Applications that verify their own users' passwords should normally store salted, purpose-built password hashes rather than recoverable plaintext passwords.

Finally, password policies are only one layer of authentication security. Multifactor authentication reduces reliance on a password alone, while rate limiting, monitoring, and secure recovery processes address other attack paths. Authentication establishes identity; authorization determines what that identity may do. A strong password does not grant permissions or compensate for excessive privileges.