NIST password rules

NIST SP 800-63B-4 (July 2025) replaced the 2017 SP 800-63B as the US federal guideline for passwords, and it is widely used outside government as a reference. It tightened several 2017 recommendations into requirements. Composition rules and forced periodic changes moved from "should not" to "shall not", and the minimum length for a password used on its own rose to 15 characters. This page lists every password rule in sections 3.1.1.1 and 3.1.1.2, plus the rate-limiting rule in 3.2.2, with its exact strength word. The password policy checker is built on this table.

The rules, with strength and section

Wording is condensed. Read the text of section 3.1.1.2 before writing policy. SP 800-63B-4 also states that passwords are not phishing-resistant (3.1.1) and not replay-resistant (3.2.7).

Setting and storing a password, as a flow

Password storage, precisely

SP 800-63B-4 asks for a "suitable password hashing scheme": a function that takes a password, a salt and a cost factor and is deliberately expensive, so each guess costs an attacker who steals the hash file. Its normative points are rules 26 to 33 above. Three details are often misquoted:

• It does not name algorithms. It points to "an approved password hashing scheme published in the latest revision of SP 800-132 or updated NIST guidelines" (SHOULD). The 2017 edition named PBKDF2 and Balloon as examples, said a memory-hard function SHOULD be used, and suggested at least 10,000 PBKDF2 iterations. None of those three statements appears in SP 800-63B-4.
• The "pepper" is a SHOULD, but its handling is SHALL. The extra keyed iteration is recommended. If you use it, the key must come from an approved random bit generator and be stored separately from the hashes.
• Record the parameters. Storing the scheme and cost factor with each hash (SHOULD) is what lets you raise the cost later and rehash at the next sign-in.

Choosing a specific algorithm and parameters is outside what this page can state from SP 800-63B-4. Use current NIST guidance where it applies to you, and a widely reviewed password-hashing implementation.

Blocklists

SP 800-63B-4 gives three example sources: passwords from previous breach corpuses, dictionary words, and context-specific words such as the service name, the username and derivatives. Because the minimum length already rules out short passwords, the list only needs entries that meet the minimum (Appendix A). NIST also warns against overdoing it: "excessively large blocklists are of little incremental security benefit", because the blocklist targets online guessing, which rate limiting already bounds. Compare the whole password. Rejecting a password because it contains a dictionary word is a substring rule, and the text says the entire password is what gets compared.

Changes from the 2017 revision

OMB M-22-09 had already required US federal agencies to remove password policies requiring special characters and regular rotation within one year of January 2022.

Activation secrets (local PINs) are different

A PIN or password that unlocks an authenticator locally, and is never sent to the verifier, follows section 3.2.10:

• At least 4 characters (SHALL), and at least 6 is recommended (SHOULD). Entirely numeric PINs are allowed (MAY).
• A blocklist of common values such as 123456 (SHOULD).
• At most 10 consecutive failed attempts, then the authenticator is disabled (SHALL).
• For authenticators usable at AAL3, verification happens in a hardware-protected environment such as a secure element, TPM or TEE (SHALL).

A conforming policy, in plain words

Password policy (aligned to NIST SP 800-63B-4, sections 3.1.1 and 3.2.2)

Length:      minimum 15 characters (8 if the password is only ever used with a
             second factor); maximum at least 64. Each Unicode code point
             counts as one character.
Characters:  any printable ASCII, space and Unicode. No required character
             classes. No other composition rules.
Screening:   the full password is checked against a list of breached, common
             and service-specific passwords. Rejected passwords get a reason.
Change:      no scheduled expiry. Forced change on evidence of compromise.
Entry:       paste and password managers allowed; "show password" offered.
Not used:    password hints, security questions.
Attempts:    at most 100 consecutive failures, then the password is disabled
             and must be bound again (or the account recovered).
Storage:     salted (32+ bit salt) hash using an approved password hashing
             scheme at the highest practical cost, plus a keyed hash with a
             key held in an HSM. Scheme and cost stored with each hash.

Test your own policy against these rules with the password policy checker.

Common mistakes

• Keeping "one uppercase, one digit, one symbol" alongside a long minimum. Under SP 800-63B-4 that is a SHALL NOT.
• Applying the 8-character minimum to a password that can also be used alone, for example on a legacy protocol that skips MFA. Then it is single-factor and needs 15.
• Blocking paste "for security". Autofill must work (SHALL), and paste should (SHOULD).
• A blocklist check that matches substrings and rejects good passphrases.
• Expiring passwords every 90 days. Rotate on evidence of compromise instead, and detect compromise (breach-corpus checks at sign-in are a common practice).
• Fast, unsalted or single-iteration hashes, or a "pepper" stored in the same database as the hashes.

Sources

1. NIST SP 800-63B-4: Authentication and Authenticator Management, NIST. Public domain (U.S. government work).
2. NIST SP 800-63B (2017): Authentication and Lifecycle Management (superseded), NIST. Public domain (U.S. government work).
3. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, NIST. Public domain (U.S. government work).
4. OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, Office of Management and Budget. Public domain (U.S. government work).