NIST's 2025 Password Rules: No Complexity, No Expiry, and a 15-Character Catch

If you set or enforce password policy for anything, a company directory, a customer login, a side project with 40 users, the rules you were most likely taught are now explicitly forbidden by the standard those policies usually cite. Not discouraged. Forbidden, in the standard's own "SHALL NOT" language.

This matters if you are only a password owner too, because it tells you which parts of a strength score reflect real difficulty and which are decoration. Below is what the text actually says, quoted directly, with the one requirement almost every summary of it gets wrong.

What the standard actually says

The document is NIST Special Publication 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, published July 2025. It supersedes the 2020 edition, and the full text is free to read online. The password requirements sit in section 3.1.1.2, addressed to verifiers, meaning whoever is checking the password on the other end.

The parts that overturn common practice, quoted:

• "Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types)."
• "Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
• Verifiers must "compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords."
• "Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters."
• "Verifiers SHALL request the password to be provided in full (not a subset of it) and SHALL verify the entire submitted password (e.g., not truncate it)."
• "Verifiers SHALL allow the use of password managers and autofill functionality."
• "Verifiers and CSPs SHALL NOT permit the subscriber to store a hint…accessible to an unauthenticated claimant."
• "Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication…when choosing passwords." That is the end of "what was your first pet's name" as a password-setting prompt.

Read as a set, these move the burden off the user and onto the system. The user picks something long. The system does the screening, the throttling, and the not-getting-in-the-way.

The 15-character rule has a condition most summaries drop

You have probably seen the headline "NIST now requires 15-character passwords." That is half of a sentence. The full requirement reads:

"Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length," and they "MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters."

So the floor depends on what else is guarding the account. If the password is the only thing between an attacker and the login, 15 characters. If it is one factor among several, 8 is the minimum the standard will accept. Plenty of write-ups report the 15 flat, which sends teams into a migration they may not owe anyone, or makes an 8-character policy look non-compliant when it is sitting behind mandatory MFA.

Worth noting what the 15 is not: it is not a claim that 15 characters is where a password becomes uncrackable. It is the point below which a lone password stops being an acceptable sole defence.

Why complexity rules got banned rather than just dropped

The reasoning lives in Appendix A, Strength of Passwords, and it is unusually blunt for a standards document. "Composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. However, research has shown that users respond in very predictable ways to the requirements imposed by composition rules."

Then NIST gives the example itself: "a user who might have chosen 'password' as their password would be relatively likely to choose 'Password1' if required to include an uppercase letter and a number or 'Password1!' if a symbol is also required."

That is the whole problem in one line. A rule that demands an uppercase letter, a digit and a symbol does not produce 95 possible characters per position. It produces a capital first letter, a 1 near the end, and an exclamation mark after it. The appendix's counterweight is stated just as plainly: "Password length is a primary factor in characterizing password strength."

Why expiry went with it

The forced 90-day change has been under attack from the evidence for a decade. In 2016 Lorrie Cranor, then chief technologist at the FTC, wrote that "unless there is reason to believe a password has been compromised or shared, requiring regular password changes may actually do more harm than good in some cases."

Her post describes UNC Chapel Hill research on accounts under a mandatory 3-month change policy, which found the replacement passwords were largely predictable from the old ones. In her summary of it: "for 17% of the accounts they studied, knowing a user's previous password allowed them to guess their next password in fewer than 5 guesses," and an offline attack could guess current passwords for "41% of accounts within 3 seconds per account."

The UK's National Cyber Security Centre reached the same conclusion in its own password guidance, which states flatly that "regular password changing harms rather than improves security" and advises organisations to "only ask users to change their passwords on indication or suspicion of compromise." The same guidance says the NCSC "do not recommend the use of complexity requirements when implementing user generated passwords," and asks for a deny list instead.

Two national bodies, arriving separately at the same two answers, is about as close to settled as this field gets.

What this does to the number a strength calculator gives you

Here is the part that matters for anyone who has ever pasted a candidate password into a meter, ours included. Appendix A opens by conceding the limits of the method: "the effective strength of user-chosen passwords has often been characterized using the information theory concept of entropy. While entropy can be readily calculated for data with deterministic distribution functions, estimating entropy for user-chosen passwords is challenging."

Take NIST's own example and run it through the standard formula, length multiplied by log2 of the character pool, which is what our Password Entropy Calculator uses. "Password1!" is 10 characters drawing on lowercase, uppercase, digits and symbols, so the pool is 95 and the score is 65.7 bits.

At the bcrypt guessing rate the tool assumes, 10,000 attempts per second, 65.7 bits works out to roughly 95 million years. For a password NIST names, in print, as the thing users predictably type when you demand a capital and a symbol. A real cracking rig finds it in the opening seconds, because it is a dictionary word plus the two most common decorations.

None of that makes the entropy figure useless. It makes it a ceiling rather than a forecast. The formula answers "how much work would this cost if every character had been chosen at random," and that answer is exact and worth knowing. It only equals real-world difficulty when the premise holds.

That is why the figure is trustworthy for output from a password manager's generator and generous for anything a human composed. Our calculator flags dictionary words, keyboard walks and leet substitutions alongside the bits for exactly that reason, but no static analysis catches every pattern a cracking wordlist already contains.

The practical read: treat a high entropy score as a necessary condition, never a sufficient one. Randomly generated and long clears both bars at once.

What to set instead

If you own a policy, the standard gives you the whole configuration:

• Minimum 15 characters where the password stands alone, 8 where real MFA sits behind it.
• Accept at least 64 characters, and every printing ASCII character plus the space.
• Drop every composition rule you have.
• Drop scheduled expiry, and keep a forced reset for evidence of compromise.
• Screen new passwords against a breach and common-password blocklist. This is the requirement that replaces the two you just deleted, and skipping it leaves you weaker than where you started.
• Rate-limit failed attempts, allow password managers and paste, and stop truncating.

If you are just picking passwords for yourself, the same evidence points somewhere simpler. Length beats character variety, a unique password per account beats a memorable pattern reused everywhere, and a password you never chose yourself beats one you did.

You can also check a password against known breach corpora without handing it over: Have I Been Pwned's Pwned Passwords uses a k-anonymity scheme where "your password is hashed locally and only the first 5 characters of the SHA-1 hash are sent to the API," so the full comparison happens on your machine. That is the same instinct behind our own tool, which does its scoring in your browser and sends nothing anywhere.

One caveat on the standard itself. Its binding force runs to US federal systems: the document tells you so directly in places, as when it says "federal agencies SHALL require their staff, contractors, and partners to use phishing-resistant authentication to access federal information systems." If you are not in that chain, 800-63B-4 is guidance rather than law.

It is guidance a great many audit frameworks and vendor security questionnaires quietly copy from, though. Which is why an auditor may still be asking you for the 90-day rotation the source document now prohibits.