What NIST SP 800-63B-4 actually requires

The requirements, in the document's own words

SP 800-63B-4 uses SHALL and SHALL NOT in their formal sense: requirements from which no deviation is permitted. That is the source of most of the misquotation, because a great deal of secondary writing reports these as recommendations.

The length requirement is the one most often softened. The text 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. 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."

The eight-character figure, which is what most articles quote, only applies inside a multi-factor flow. For a password standing alone, fifteen is the floor and it is mandatory.

The composition prohibition is equally unambiguous, and appears twice. "Other composition requirements for passwords SHALL NOT be imposed", and separately, "Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."

• SHALL: 15 characters minimum for single-factor, 8 minimum inside MFA.
• SHALL NOT: impose composition rules such as requiring a mixture of character types.
• SHALL NOT: require periodic password changes. A change SHALL be forced on evidence of compromise.
• SHALL NOT: permit a stored password hint accessible to an unauthenticated claimant.
• SHALL NOT: prompt for knowledge-based authentication or security questions when choosing a password.
• SHALL: screen the prospective password in full against a blocklist of common, expected or compromised values.
• SHALL: verify the entire submitted password, not a subset, and not truncated.
• SHOULD: permit a maximum length of at least 64 characters.
• SHOULD: accept all printing ASCII characters and the space character.
• SHOULD: accept Unicode, counting each code point as one character, with NFC normalisation applied before hashing.

Why composition rules are prohibited rather than merely discouraged

Appendix A gives the reasoning, and it is empirical rather than theoretical. Composition rules were introduced to raise the effective strength of user-chosen passwords. Analyses of breached password corpora show the benefit is far smaller than assumed, because users respond to the rules in highly predictable ways.

The document gives the canonical example: a user who would have chosen "password" is relatively likely to choose "Password1" when required to include an uppercase letter and a digit, and "Password1!" if a symbol is also demanded. The rule has added three characters and close to no unpredictability, while making the password materially harder to remember and type.

The point that gets lost is what NIST recommends instead. Appendix A identifies machine-generated random passwords as a more effective mitigation than composition rules. The problem composition rules were reaching for is real; the fix is to remove the human from the character selection, not to constrain the human's selection.

There is a nuance here that is worth stating because it is the obvious counter-argument. NIST also moved away from entropy scoring, on the grounds that estimating the entropy of a human-chosen password is unreliable. That critique is correct and it does not apply to a uniformly generated string, where length times the base-two logarithm of the alphabet size is not an estimate but an exact figure.

No rotation, no hints, no security questions

The rotation prohibition is stated with an explicit exception: "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."

The reasoning is the same as for composition rules. Forced rotation produces predictable transformations, so an attacker who has one password of a user often has the next. The security benefit was always speculative, and it is now explicitly traded away in favour of compromise-driven change.

Hints are prohibited where they are readable without authentication, which is where hints are useful and therefore where they are implemented. Knowledge-based authentication and security questions are prohibited outright as part of password selection: the answers are typically low-entropy, frequently public, and shared across every service that asks.

Screening against breached lists

The screening requirement is the one thing NIST adds in place of everything it removed. When a password is being set or changed, the verifier compares it against a blocklist of known common, expected or compromised passwords, including values obtained from previous breach corpora, dictionary words, repetitive or sequential characters, and context-specific words such as the service name.

Two details are load bearing. The entire password is compared, not substrings or contained words, so this is a set membership test rather than a content filter. And the list does not need to be enormous: the document notes that excessively large blocklists offer little incremental benefit, because the blocklist defends against online guessing, which is already bounded by rate limiting.

The verifier must also tell the user why a password was rejected, and offer guidance, precisely because the failure mode otherwise is a trivial modification of the rejected value.

The PCI DSS conflict, which is real

PCI DSS v4.0.1 requirement 8.3.6 requires passwords of at least twelve characters containing both numeric and alphabetic characters, with eight permitted only where a system cannot support twelve. It has been a full requirement since 31 March 2025. It also requires 90-day rotation unless the access is protected by multi-factor authentication or dynamic risk analysis.

That is a composition rule and a rotation requirement, which are the two things NIST prohibits by name. Both documents are current. Both apply to organisations in the cardholder data environment. There is no reading under which an organisation satisfies both by following one of them.

The conflict is narrower than it first appears, though, because PCI applies to a defined scope: system components in or connected to the cardholder data environment. Consumer-facing authentication for the rest of your product is generally outside it. The first move is therefore scoping, not policy design.

Within the PCI scope, the resolution is to generate rather than to constrain. Issue machine-generated passwords of fifteen characters or more, which clears the NIST length SHALL and the PCI twelve-character minimum in one step, and enforce the character-class requirement inside the generator rather than as a validation rule imposed on a human. NIST prohibits imposing composition requirements on the subscriber; it does not prohibit a generator from producing a string that happens to contain a digit.

That distinction is not a lawyer's trick, it is the whole point of Appendix A. The harm composition rules cause is the predictable human response to them. A generator has no predictable human response.

What to accept on the verifier side

The acceptance requirements are the least implemented part of the document, and the cheapest to fix. Permit at least 64 characters. Accept every printing ASCII character and the space. Accept Unicode, counting each code point as one character for length purposes, and apply NFC normalisation before hashing so the same password typed on two keyboards produces the same bytes.

Verify the password in full. Do not truncate it, and do not verify a subset of it, which some legacy systems still do by asking for the third, fifth and ninth characters. Truncation in particular is invisible: a user with a 40-character password on a system that silently truncates at 20 has half the password they think they have.

These rules exist to make password managers work. A generated 40-character password with symbols is useless if the field rejects it, and a rejected paste is what pushes a user back to something they can type.

Questions