Your Password Policy Is Probably Out of Date

Ninety-day password expiration isn't a security control, a best practice, or a compliance requirement. As of August 2025 it's something the federal standard explicitly tells organizations to stop doing - and most password policies still require it.

NIST SP 800-63B is the federal digital identity standard for authentication. It's what auditors reach for, what frameworks cite, and what most corporate password policies were originally derived from. Revision 4 became final on August 26, 2025, and the previous revision was formally withdrawn a month earlier. If your policy was written before then, it was written against a document that no longer exists.

What does the current standard actually say?

Two requirements, both stated as SHALL NOT - the standard's strongest prohibition:

1. "Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."
2. "Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically."

Read those again, because they invert the two rules almost every password policy is built on. No required symbols. No required mix of uppercase, numbers, and punctuation. No 90-day rotation. The standard does still require a change when there's evidence the password has been compromised - which is a different thing entirely, and the thing rotation was always a poor substitute for.

Why did forced rotation stop being good advice?

Because of what people actually do when you force it. Rotation assumes a password gets weaker with time. It doesn't - it gets weaker when it's exposed, and exposure isn't on a schedule. What rotation reliably produces is predictable modification: Summer2025! becomes Summer2026!, and the eighth password in a sequence is guessable from the first.

It also produces reuse and writing things down, both of which cost more than the stale password ever did. And it does nothing about the actual failure mode, which is credential theft - a stolen password is used within hours, not in month three of a 90-day window.

Complexity rules fail the same way. Requiring a symbol doesn't add meaningful entropy; it adds one exclamation point at the end. Length does the work that complexity was supposed to do, and a long passphrase a person can actually remember beats a short scramble they have to store in a browser.

Doesn't my compliance framework still require complexity?

Sometimes, and this is the honest complication. Frameworks update on their own schedule, and a few - including NIST CSF, PCI DSS, HIPAA, CMMC, and FTC Safeguards - still carry rules NIST has abandoned. PCI DSS is the most common conflict - its password requirements are stricter and more specific than the current NIST guidance, and if it applies to you, it applies regardless of what NIST says.

The resolution isn't to pick a side. It's to know which frameworks bind you and write one policy that satisfies the strictest of them. That's a smaller job than it sounds, because the strict requirements are usually a superset, not a contradiction.

What should a small business do instead?

1. Set a long minimum length and stop there. Length is the control that survives contact with real attackers.
2. Screen new passwords against known-breached lists. This is the single highest-value change on this list, and every major identity platform can do it. It stops the actual attack - credential stuffing with passwords already published - instead of guarding against a theoretical one.
3. Drop scheduled expiration. Change on evidence of compromise, not on a calendar.
4. Drop composition rules. Allow spaces and every printable character, and permit long passphrases.
5. Turn on MFA everywhere, especially email, remote access, and administrator accounts. This matters more than every password rule combined.
6. Give people a password manager. A rule people can't follow isn't a control, and 60 unique long passwords require software.
7. Get passwords out of browsers. A single malicious click can hand over every credential a browser has saved.

What this means for a business your size

If you run 10 to 200 people, the practical read is that you can make your security better and your users' lives easier at the same time - which almost never happens, and is worth using while it's true. Turning off forced rotation is a settings change. So is raising the minimum length. Both go in the same maintenance window.

The one that takes real work is breach-list screening and MFA coverage, and that's where the effort belongs. If you've been spending policy attention on symbol requirements, you've been guarding a door that was never the way in.

Two cautions. First, if you're subject to PCI DSS, HIPAA, CMMC, or a cyber insurance policy with specific authentication terms, check those before you change anything - the standard is the floor, and your obligations may sit above it. Second, write down what you changed and when. "We follow NIST 800-63B-4" is an answer to an auditor's question. "We turned expiration off at some point" is not.

FAQ

Does NIST still require password expiration?

No. NIST SP 800-63B-4, final since August 2025, states that verifiers and credential service providers SHALL NOT require subscribers to change passwords periodically. A change is required when there is evidence the password has been compromised.

Does NIST still require special characters and mixed case?

No. The current standard states that verifiers and credential service providers SHALL NOT impose composition rules such as requiring mixtures of different character types. Length is the requirement that remains.

Is a long passphrase better than a short complex password?

Generally yes. Length contributes far more to resisting an attack than character variety does, and a passphrase is more likely to be remembered than stored somewhere insecure. Screening against known-breached password lists matters more than either.

If NIST changed, do I have to change my policy?

Not automatically. NIST 800-63B binds federal agencies and their contractors directly; for everyone else it's the reference standard that other frameworks and auditors point to. If a framework that applies to you still requires rotation or complexity, that requirement governs. Check which frameworks apply before changing anything.