What should our password policy actually say?

Why the old rules were wrong

The password rules most companies still run were sensible-sounding guesses from an era with less data. The character-soup requirement and the 90-day reset were not malicious; they were a theory of how attackers worked that turned out to be backwards. Once researchers and national authorities studied real human behaviour and real breach data, both rules were withdrawn.

Forced complexity produced weak, predictable passwords

The idea behind composition rules was that demanding an uppercase letter, a lowercase letter, a number, and a symbol would force a larger, harder-to-guess space of passwords. In practice it forced people into a small set of predictable shapes. A rule that says "include a capital, a number, and a symbol" reliably produces Password1!, Summer2026!, and Company123$, because that is the path of least resistance for a human who has to remember the thing.

Attackers know these shapes. Password-cracking tools apply exactly these transformation patterns first: capitalise the first letter, append a year, swap an "a" for an "@", add a "!" on the end. So the rule that was meant to widen the search space narrowed it to the patterns the rules predict. NIST's Rev. 4 guidance states plainly that verifiers "SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords," and explains the reasoning in its appendix on password strength. The NCSC is blunter: complexity requirements "provide no defence against common attack types" and should not be used.

Forced 90-day resets made people choose worse passwords

Periodic expiry assumed that changing a password regularly limited the damage from a quietly stolen one. The behaviour it actually produced undercut that. When people are made to change a password every 90 days, they do not invent a fresh, strong, unrelated password each time. They make the smallest change the system will accept: Spring2026 becomes Summer2026, then Autumn2026; Welcome1 becomes Welcome2. The new password is a trivial increment of the old one, which an attacker who has the old one can guess in seconds.

Forced rotation also pushes people to write passwords down in unsafe places and to reuse the same root across systems, because remembering a rotating set is genuinely hard. NIST now requires the opposite default: do not force routine changes, and force a change only on evidence of compromise. The NCSC's guidance agrees that regular expiry "does more harm than good," and recommends changing a password only when you know or suspect it has been compromised. The change is not a loosening of security. It removes a rule that was teaching users to pick weaker secrets.

What the modern standard says

The current guidance from NIST and the NCSC converges on a small, coherent set of rules. The shift is from rules that police the shape of a password toward rules that block known-bad passwords and let people use long ones. Below is what the standards require, with the technical work that sits behind each line.

Length over complexity

Length is the property that most reliably resists guessing and cracking, because each additional character multiplies the work an attacker has to do. NIST SP 800-63B Rev. 4 sets the floor: a password used as a single factor must be at least 15 characters, and a password used only as part of multi-factor authentication may be shorter but must be at least 8 characters. The maximum should be at least 64 characters, so long passphrases fit. NIST also says verifiers should accept all printable ASCII and the space character, and should accept Unicode, so people are not blocked from using spaces or non-English characters.

Crucially, on top of the length floor NIST forbids piling on composition rules. You set a minimum length, you allow a generous maximum, and you stop there on the structure question. The strength comes from length and unpredictability, not from a mandatory symbol.

No periodic resets without cause

The policy should not expire passwords on a calendar. NIST: verifiers "SHALL NOT require subscribers to change passwords periodically," but "SHALL force a change if there is evidence that the authenticator has been compromised." That is the whole rule. You change a password when there is a reason: a confirmed or suspected compromise, exposure in a breach, a shared credential that needs rotating, or a departing employee. You do not change it because three months have passed.

This is the change leaders find most counterintuitive, because routine expiry feels like diligence. It is worth saying clearly in the policy itself, with a one-line reason, so that an auditor or a security-conscious board member does not read the absence of a 90-day rule as an oversight.

Screen against breached and common passwords

Removing complexity rules does not mean accepting any password. The replacement control is screening. NIST requires that when a user chooses a password, the system compares it against a blocklist of commonly used, expected, or compromised values, and if it appears on that list, the user is required to choose a different one. This is what stops someone setting a 15-character password that happens to be Password12345678 or a phrase already sitting in every breach corpus.

In practice this means wiring in a breached-password check at the point of creation and change. The widely used free option is Have I Been Pwned's Pwned Passwords service, which lets a system check a password against billions of previously breached hashes without ever sending the password itself, using a k-anonymity model where only a short prefix of the hash is transmitted. Commercial equivalents exist and integrate the same way. Microsoft Entra ID and many identity platforms ship a banned-password capability that does similar work. The point is that the system, not the user, carries the burden of knowing which passwords are already burned.

Allow passphrases and password managers

The standards actively want people using long passphrases and password managers, and the policy should remove every obstacle to both. NIST states verifiers "SHALL allow the use of password managers and autofill functionality," and should permit the paste function in the password field so a manager can fill it. A policy or login form that blocks pasting is working against the standard and against the user, because it pushes people toward short passwords they can type from memory.

The NCSC promotes the "three random words" approach for passwords a person has to remember, such as the master password for a manager or the device login: stringing together several unrelated words produces something long, memorable, and hard to crack. For everything else, a password manager generates and stores a long random password per site, so the human never has to remember or reuse one. The combination is the modern default: a small number of strong memorised secrets, and a manager holding a unique strong password for every account.

Pair it all with MFA

A strong, unique, unbreached password is necessary and not sufficient. It protects against guessing and against credential-stuffing with reused passwords. It does not protect against a convincing phishing page that captures the password as the user types it, or a keylogger. That is the job of MFA: a second factor that an attacker with only the password still does not have.

The two controls cover different failure modes, which is why current guidance treats them together. A good password keeps a guessed or cracked credential out; MFA keeps a phished or stolen one out. NIST's higher authentication assurance levels require multi-factor authentication for exactly this reason. A password policy that does not also mandate MFA on accounts that matter is solving half the problem.

A short policy a mid-market company can adopt

Here is a policy short enough to actually use, phrased so a non-technical reader understands each line. Adapt the specifics to your identity provider, but keep the shape.

1. Length. Passwords must be at least 15 characters when used on their own. Where the account is protected by MFA, a minimum of 8 characters is acceptable. The system accepts passwords up to at least 64 characters, including spaces and passphrases.

2. No mandatory complexity. We do not require a specific mix of uppercase, lowercase, numbers, or symbols. Length and unpredictability are what we ask for. People are encouraged to use a passphrase of several random words or a password-manager-generated password.

3. No scheduled expiry. Passwords do not expire on a schedule. We require a change only when there is evidence or reasonable suspicion of compromise, including appearance in a known breach, a shared credential being rotated, or an account-takeover concern.

4. Screening at creation. Every new or changed password is checked against a list of common, expected, and known-breached passwords. If it appears, the user is asked to choose another. We do this with an automated service so the password itself is never exposed in the check.

5. Password managers are supported and encouraged. Pasting into password fields is allowed. We provide or recommend a password manager so staff keep a unique password per account without memorising them.

6. MFA is required. Every account that can reach company data or systems uses multi-factor authentication, with phishing-resistant factors (passkeys or hardware security keys) on administrator and privileged accounts.

7. Rate limiting and lockout. Login systems limit repeated failed attempts so that guessing at scale is not viable, in line with the verifier's controls.

That is a complete policy. It is shorter than most of the ones it replaces, and every line traces to current NIST or NCSC guidance.

Sources

• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management (Rev. 4, 2024) — https://pages.nist.gov/800-63-4/sp800-63b.html (15-character single-factor minimum, 8-character minimum within MFA, maximum at least 64; "SHALL NOT impose other composition rules"; "SHALL NOT require subscribers to change passwords periodically" and "SHALL force a change if there is evidence" of compromise; blocklist screening of common, expected, and compromised values; "SHALL allow the use of password managers," paste permitted; rate limiting)
• UK NCSC, Password policy: updating your approach — https://www.ncsc.gov.uk/collection/passwords/updating-your-approach (complexity rules provide no defence and should be dropped; routine expiry does more harm than good and should be replaced by change-on-compromise; deny-lists for weak passwords)
• UK NCSC, Three random words or #thinkrandom — https://www.ncsc.gov.uk/blog-post/three-random-words-or-thinkrandom-0 (passphrase approach: combining several random words for length and memorability)
• Have I Been Pwned, Pwned Passwords — https://haveibeenpwned.com/Passwords (free breached-password screening via k-anonymity, so the password is never sent in full; usable at password creation and change)