The Password Rules the Standard Now Forbids

By NorwegianSpark Editorial · Published Jul 26, 2026 · 9 min read — written with AI assistance and reviewed by the NorwegianSpark SA editorial team.

Somewhere in your working life there is a system that will, at an interval of ninety days, refuse to let you in until you invent a new password containing one capital letter, one number and one symbol. You will change Autumn2025! to Autumn2026!. Everyone knows this is what happens. Everyone does it anyway.

The interesting part is not that the practice is unpopular. It is that the current United States federal standard does not merely discourage it. It says SHALL NOT — the strongest prohibition the document has.

Below is the exact text, with section numbers, from NIST Special Publication 800-63B-4, published on 31 July 2025, which supersedes the 2020 edition. It is freely readable online; nothing here is behind a paywall or an interpretation.

"SHALL NOT require subscribers to change passwords periodically"

Section 3.1.1.2, on password verifiers, is unambiguous:

"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."

Two instructions in one sentence, and the second is the part usually lost. The standard does not say passwords should never be changed. It says the trigger must be evidence of compromise, not the calendar. Rotation on a schedule is prohibited; rotation on a breach is mandatory.

The reasoning is well established and stated plainly by the UK's National Cyber Security Centre under the heading "Don't enforce regular password expiry": "Regular password changing harms rather than improves security... Forcing password expiry carries no real benefits because: the user is likely to choose new passwords that are only minor variations of the old; stolen passwords are generally exploited immediately..."

That is Autumn2025! becoming Autumn2026!, described by a national cyber authority. And the second half matters more: a credential stolen on Tuesday is used on Tuesday. A ninety-day cycle does not intercept that; it simply degrades the quality of every password in the organisation in exchange for nothing.

Microsoft reached the same conclusion when it removed password expiry from its Windows security baselines in April 2019, in language rarely found in vendor documentation: "Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don't believe it's worthwhile for our baseline to enforce any specific value."

"SHALL NOT impose other composition rules"

The second rule is the character-mixture requirement, and the prohibition is equally direct. Section 3.1.1.2:

"Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."

Section 3.1.1.1 restates it: "Other composition requirements for passwords SHALL NOT be imposed."

So the box that rejects your passphrase until you add an exclamation mark is not a security control the standard tolerates. It is a security control the standard forbids. The mechanism of harm is the same as with expiry: constraints that are predictable to a human are predictable to an attacker. Requiring a capital letter reliably produces a capital letter in position one. Requiring a symbol reliably produces ! at the end.

What the standard requires instead

Removing two rules is only half the document. The current edition replaces them with requirements that are, in several places, considerably more demanding than what they replaced.

Length went up, sharply. Section 3.1.1.2: "Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length. Verifiers and CSPs 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 in length. Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters."

Fifteen characters as a floor for anything protected by a password alone. The change log confirms this is an increase over the previous edition, which set eight. If you have ever been told that an eight-character password with mixed characters is "strong", that guidance is now two editions old.

Checking against known-compromised passwords is mandatory. Section 3.1.1.2: "When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords... If the chosen password is found on the blocklist, the CSP SHALL require the subscriber to select a different secret and SHALL provide the reason for rejection."

Note the second SHALL. Rejecting silently is not compliant; the service must say why.

Security questions are prohibited outright. "Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., 'What was the name of your first pet?') or security questions when choosing passwords." Password hints accessible to an unauthenticated visitor are likewise SHALL NOT.

Password managers must be permitted. "Verifiers SHALL allow the use of password managers and autofill functionality. Verifiers SHOULD permit claimants to use the 'paste' function when entering a password to facilitate password manager use when password autofill APIs are unavailable." Blocking paste in a password field is a violation of the standard, not a hardening measure.

Everything you can type should be allowed. Printable ASCII and the space character SHOULD be accepted; Unicode SHOULD be accepted; and "Each Unicode code point SHALL be counted as a single character when evaluating password length" — so an emoji counts as one character, not four.

One more detail, small but telling: the current edition renamed memorized secrets back to passwords throughout. The standard stopped using jargon in the same revision it stopped requiring theatre.

Where the bad rules came from

The orthodoxy has a single, traceable origin, which is unusual and rather useful.

NIST Special Publication 800-63 version 1.0 — authors William E. Burr, Donna Dodson and W. Timothy Polk — contained Appendix A, "Estimating Password Entropy and Strength". That appendix is the ancestor of the mixed-character-plus-regular-change advice that spread through corporate IT policy for the following fifteen years.

In August 2017 the Wall Street Journal ran a piece by Robert McMillan headlined "The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d!", subheaded: "Bill Burr's 2003 report recommended using numbers, obscure characters and capital letters and updating regularly—he regrets the error."

A dating note, because it is worth being precise: the press consistently refers to a 2003 report, and NIST's own bibliographic record gives the formal publication date of SP 800-63 v1.0 as June 2004, withdrawn that September. Burr appears to have done the work in 2003 and the document to have been published in 2004. We flag the discrepancy rather than pick whichever suits the sentence.

Almost nobody complies

If the standard has said this since 2017 and says it more forcefully now, how much has changed?

The best non-vendor measurement is a peer-reviewed study by Kevin Lee, Sten Sjöberg and Arvind Narayanan of Princeton, presented at USENIX SOUPS in August 2022, which examined the password policies of 120 of the most popular English-language websites. Its findings:

• Only 13% of the sites followed all relevant best practices.
• 54 of 120 sites — 45% — still imposed character-class composition rules.
• 75% did not prevent users from choosing the most common passwords at all.

That last figure is the damning one when set beside the first two. Nearly half of these sites enforced a rule the standard prohibits, while three-quarters omitted the check the standard mandates. The effort went into the ceremony and not into the control that actually works.

The honest caveats

Two, because a piece arguing from a standard should be candid about the edges of it.

We could not find a credible source defending calendar-based rotation. We looked specifically for one, including for the common carve-out around shared and service accounts. The closest relevant material is the NCSC's own treatment of shared credentials, and even that is event-triggered — if someone loses access rights, change the password — not time-triggered. If a well-argued case for scheduled rotation exists, it belongs here; we did not find it.

Compliance regimes are their own question, and we have not verified the current PCI DSS position. PCI DSS v4.0 revised its password requirement, but the Security Standards Council's document library would not yield the primary text to us, so we are not quoting a requirement number. If you operate under PCI DSS, read requirement 8.3.9 in the current standard directly rather than trusting any summary, this one included. An organisation may also be contractually bound by an auditor or a customer to rules NIST prohibits — that is a governance problem rather than a security one, but it is a real constraint.

What to do with this

For an individual, the standard resolves into something short: use long, unique passwords, do not change them on a schedule, stop inventing character-class variations, and check whether the ones you have are already in a breach corpus. Fifteen characters is the current floor for anything not sitting behind a second factor — and a passphrase of ordinary words reaches that far more comfortably than a mangled eight-character string ever did.

Doing it by hand is not realistic at the number of accounts most people now hold, which is the practical case for a password manager, and for reading how the current tools compare in our best password managers guide. Our sister privacy site covers the same ground from the network side at vpntex.com's password manager comparison.

The blocklist requirement has a consumer equivalent worth acting on: find out whether your credentials are already circulating, using the steps in how to check if your data is on the dark web, and if they are, follow what to do after a data breach. Since the standard's only mandatory trigger for changing a password is evidence of compromise, knowing whether you have been compromised is the whole game.

Finally, note what the standard is quietly steering towards. It permits shorter passwords when they are one factor among several, which is a nudge towards two-factor authentication, and the direction of travel beyond that is passkeys — where there is no shared secret to rotate, compose or leak. Broader context sits in protecting your privacy online, and since credential theft still overwhelmingly arrives by email, in how to spot and avoid phishing.

General guidance only, current as at July 2026. NIST SP 800-63B-4 is a US federal standard; your organisation, sector regulator or contractual obligations may impose different requirements, and standards are revised. Quotations above are from the edition published 31 July 2025 — check the current text before relying on it.