Retrospective note. The original 23 July 2009 date is retained. The current-guidance section discusses NIST's 2025 revision, not guidance available in 2009.
Ask a security team in 2009 what their password policy was and you would get a confident answer: minimum eight characters, upper and lower case, a number, a symbol, changed every 90 days, no reuse of the last twelve, lockout after three failures. Ask what evidence supported it and the room went quiet. The policy existed because auditors expected it, and auditors expected it because everyone had it. We now know, with more than a decade of behavioural data behind us, that several of those rules made organizations measurably less secure.
What the Rules Actually Produced
Forced rotation created predictable passwords. Required to change quarterly, people did not invent new secrets — they incremented old ones. Winter2024 became Spring2025. The rule intended to limit the lifetime of a compromised credential taught users to make their credentials guessable by design. Complexity requirements were defeated by pattern. NIST's own analysis makes the point with a well-chosen example: a user who would have chosen "password" is relatively likely to choose "Password1" when required to add an uppercase letter and a number, or "Password1!" when a symbol is also required. The rule is satisfied. The password is not meaningfully stronger, and attackers know the transformation. Frequent change drove passwords out of memory and onto paper. A password changed four times a year is one people write down or store insecurely — or reuse across systems, which is the failure mode that turns any third-party breach into a problem for you. Aggressive lockout became a denial-of-service tool. Three failures and lock meant an attacker could disable accounts deliberately, and legitimate users generated a help desk queue that trained support staff to reset credentials quickly, with weak verification. Social engineering follows the path of least resistance, and the help desk was it. Security questions were worse than useless. Mother's maiden name, first school, first pet: facts that are publicly discoverable, shared across every service that asks them, and permanently unchangeable once exposed.
What the Guidance Says Now
The reversal is formal and unambiguous. NIST SP 800-63B states that verifiers shall not require subscribers to change passwords periodically, and shall force a change where there is evidence the credential has been compromised. The guidance has recommended against mandatory periodic rotation since its 2017 revision, and the current version reaffirms it. Under NIST SP 800-63B-4, section 3.1.1, centrally verified single-factor passwords must have at least 15 characters. Passwords used only within multi-factor authentication may be shorter but must have at least eight. Verifiers should permit a maximum length of at least 64 characters. They must not impose character-class composition rules or periodic password changes, must force a change when compromise is evidenced, and must screen prospective passwords against common, expected or compromised values. Password hints accessible to unauthenticated claimants and security questions for choosing passwords are prohibited. The logic behind the change is simple. Length beats complexity because length resists guessing without requiring memorable substitutions. Breach screening beats composition rules because it blocks the passwords attackers actually try. And removing rotation removes the incentive to make passwords predictable.
Why Organizations Still Run the Old Policy
Three reasons, and none of them is a security argument. Auditors and standards lag. Some frameworks and client questionnaires still ask when passwords expire, and "never, in line with current NIST guidance" invites a conversation that a 90-day answer avoids. Systems enforce it by default, and changing the setting requires someone to own the decision. And the policy feels rigorous — frequent change looks like diligence, which makes removing it politically awkward even when the evidence is clear. The result is organizations running a control they know is counterproductive because explaining its removal is harder than keeping it.
| Habit to review | Control question |
|---|---|
| Calendar-based expiry | How are compromised credentials detected and changed? |
| Composition rules | How are length, breached values and supported inputs handled? |
| Recovery questions | How is recovery verified without public personal facts? |
| Hard lockout | How are guessing, rate limits and denial-of-service risks balanced? |
| Repeated shared secrets | Are unique secrets supported by approved tooling and phishing-resistant authentication? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Modernising Authentication Policy
- Remove scheduled expiry. Force a change when there is evidence of compromise. Document the reasoning and the NIST reference so the audit conversation is short.
- Screen against breached credentials. Check new and existing passwords against known-compromised lists at the point they are set. This blocks what attackers actually use, which composition rules do not.
- Increase length, drop composition rules. Encourage passphrases, support long inputs, and stop mandating character classes that produce predictable substitutions.
- Evaluate phishing-resistant authentication. NIST distinguishes cryptographic authenticators with phishing resistance from OTP methods. Choose and test the required assurance level, recovery process and device controls; this is not a guarantee against all credential or endpoint compromise.
- Delete security questions. Replace account recovery with identity verification that does not rely on publicly discoverable facts.
- Harden the help desk. Reset procedures need verification a caller cannot fake. The help desk is a favoured route precisely because password policy pushes volume through it.
- Balance guessing and denial-of-service risks. NIST requires rate limiting and, unless an authenticator-specific rule differs, a limit of no more than 100 consecutive failed attempts on an authenticator before disabling it. Lower limits may be chosen. Assess recovery and denial-of-service implications rather than treating lockout as universally unnecessary.
- Provide a password manager. If you want unique passwords per service, make unique passwords storable. Policy without tooling is an instruction to write them down.
The Broader Lesson
Password policy is the clearest case in security of a control that persisted because it was conventional rather than because it worked. It was measurable, auditable, and visibly rigorous — three properties that are easily mistaken for effective. The same pattern is visible elsewhere. Annual awareness training with click-rate targets. Access reviews rubber-stamped quarterly. Vendor questionnaires answered by people who have never seen the system. Each is measurable and auditable; none is demonstrably effective on its own. The useful question for any long-standing control is the one nobody asked about passwords for fifteen years: what behaviour does this actually produce in the people subject to it? Sometimes the honest answer is that the control is teaching exactly the habit you were trying to prevent.
Common Questions
Should passwords expire every 90 days?
No. NIST SP 800-63B states that verifiers shall not require periodic password changes, and shall force a change when there is evidence of compromise. Scheduled expiry encourages predictable incremental passwords.
Are complexity requirements still recommended?
No. Mandatory character-class rules produce predictable substitutions such as "Password1!" without meaningfully increasing strength. Length and breach screening are more effective.
What should replace security questions?
Identity verification that does not rely on publicly discoverable facts, supported by phishing-resistant multi-factor authentication and a hardened help-desk reset procedure.
What single change improves authentication most?
Phishing-resistant multi-factor authentication such as passkeys or hardware security keys. It limits the damage of credential theft regardless of password quality.
Authentication Policy Review — Outpace rewrites password and access policy against current evidence, adds breach screening and phishing-resistant MFA, and gives you the audit language to defend removing controls that were never working.