Many familiar password rules create user friction without stopping modern attacks. Learn which controls current NIST, NCSC, and Microsoft guidance supports.
Password policy is often treated as a checklist: require a capital letter, a number, a symbol, and a change every 60 or 90 days. Those rules are visible and easy to audit, but visibility is not the same as effectiveness. Attackers exploit predictable human choices, reused credentials, weak recovery flows, and poorly protected password databases.
A useful policy should reduce those concrete risks while remaining usable enough that people do not work around it.
Minimum length
Length expands the search space, but only when the password is not a common phrase or predictable pattern. Current NIST guidance requires at least 15 characters when a password is the only authentication factor and permits a lower minimum of eight when the password is used as part of multi-factor authentication. Systems should accept at least 64 characters so password managers and passphrases work properly.
Length is a baseline, not proof of strength. A compromised-password blocklist is needed because a long password that is already known to attackers remains unsafe.
Routine password expiration
Forced changes on a fixed schedule tend to produce small, predictable edits. They also impose a cost on every user without evidence that every password has been exposed. NIST, the UK NCSC, and Microsoft advise against routine expiration. A password should instead be changed when there is evidence or a reasonable suspicion of compromise, after vulnerable storage is discovered, or when an account-recovery event requires it.
Organizations still need rapid detection and reset capability. Removing periodic rotation does not mean keeping a known-compromised password.
Composition rules
Mandatory uppercase, lowercase, number, and symbol rules encourage patterns such as a capital first letter and a digit or symbol at the end. Attack tools already model those substitutions. Services should allow spaces and broad character input, avoid arbitrary composition rules, and evaluate the full candidate against common and compromised values.
Blocking punctuation because it might be used in SQL injection or cross-site scripting is a warning sign. Application code must use parameterized database queries and safe output handling. Restricting a user's password is not a substitute for fixing injection vulnerabilities.
Password reuse and breached credentials
Reuse is one of the most consequential risks because a breach at one provider can unlock accounts at another. A policy should require a unique password for the service, support password managers, and screen candidates against known compromised values using a privacy-preserving method. Organizations should also monitor credential-stuffing patterns and unusual login behavior.
Password history can prevent exact reuse within one service, but very long history lists can encourage cosmetic changes. It cannot detect reuse at unrelated providers and should not be treated as the primary defense.
Secure password storage
Passwords should travel to the service only over a protected TLS connection and should never be logged. On the server, each password must be processed with a unique random salt and a slow password-hashing function designed for this purpose. OWASP generally recommends Argon2id; scrypt, bcrypt, or PBKDF2 may be appropriate under stated constraints. Work factors need periodic review as hardware improves.
A pepper stored outside the password database can add another layer, but it creates key-management and rotation responsibilities. It does not replace a salt or a strong password-hashing function. Fast general-purpose hashes such as MD5 and plain SHA-1/SHA-2 are not suitable for password storage by themselves.
What an effective policy includes
A risk-appropriate minimum length and support for long passwords.
Blocking of common, expected, and known-compromised passwords.
Password-manager, paste, and autofill support.
Unique, salted, slow password hashing with reviewed work factors.
Layered rate limiting and detection for guessing, spraying, and credential stuffing.
Phishing-resistant MFA or passkeys, especially for privileged and sensitive accounts.
Secure recovery, authenticator replacement, session revocation, and compromise-triggered resets.