NIST Password Guidelines (SP 800-63B-4) in Plain English

By an independent developer · Updated October 11, 2026 · 10 min read

NIST Special Publication 800-63B is the US government’s standard for how systems should authenticate people. It is written for federal agencies, but it has become the reference point for password policy almost everywhere: auditors, security frameworks, and many companies cite it directly. Its fourth revision, SP 800-63B-4, was finalized in 2025 and turned several long-standing recommendations into firm requirements. This guide translates the password rules into plain English and explains the reasoning behind each one.

NIST uses precise wording: SHALL means required, SHOULD means recommended. We keep that distinction below. NIST also calls the system that checks passwords the “verifier” — in practice, your login service.

The rules at a glance

Length: 15 characters for passwords used alone

Length is the one property that reliably increases the work an attacker must do, so it is the one NIST mandates. The lower 8-character minimum only applies when the password is one part of MFA, because a second factor stops an attacker who guesses or cracks it. The 64-character maximum recommendation exists so passphrases and password-manager output are never rejected for being too long. Hashing makes long passwords cost the same to store as short ones, so there is no storage reason to cap them low.

No composition rules

Rules like “at least one uppercase letter, one digit, and one symbol” look rigorous but produce predictable results. Faced with them, most people capitalize the first letter and put a digit and an exclamation mark at the end: Password1!, Summer2026!. Cracking tools apply exactly these transformations first (see how password cracking works). The rules add frustration without adding meaningful entropy, so NIST now prohibits them and relies on length and a blocklist instead.

No forced periodic changes

Mandatory changes every 60 or 90 days were once standard. In practice users respond with small, predictable edits — Winter2026! becomes Spring2026! — which an attacker who has the old password can guess immediately. NIST now forbids scheduled expiry and requires a change only when there is evidence of compromise, such as the password appearing in a breach or suspicious sign-ins on the account.

The blocklist does the real work

Instead of rules about character types, the verifier must reject passwords that attackers will try first. NIST lists what the blocklist should cover:

• Passwords from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters, such as aaaaaa or 1234abcd.
• Context-specific words, such as the name of the service, the username, and derivatives of them.

When a password is rejected, the user should be told why, so they can choose something different instead of making a minor edit. A common implementation is the k-anonymity range API from Have I Been Pwned, which lets a service check a password against hundreds of millions of breached passwords by sending only the first five characters of its SHA-1 hash.

Make password managers work

Verifiers must allow password managers and autofill, and should allow pasting. Blocking paste on a password field pushes people toward short passwords they can type. Accepting spaces and Unicode supports passphrases and non-English speakers. NIST also recommends offering guidance, such as a strength meter, to help users choose well.

Throttle guesses, store safely

Shorter passwords are only acceptable because online guessing is rate-limited. NIST requires limiting consecutive failed attempts per account to no more than 100, using techniques such as increasing delays, CAPTCHAs, or risk-based checks rather than permanent lockouts that attackers can abuse to lock real users out. Stored passwords must be salted and hashed with a password hashing scheme designed to be costly to attack, such as Argon2id, scrypt, bcrypt, or PBKDF2.

A NIST-aligned policy you can copy

• Minimum 15 characters (or 8 if MFA is always required); maximum at least 64.
• Any characters allowed, including spaces and Unicode.
• No requirement to include particular character types.
• Checked against a list of breached and common passwords, plus the service and user name.
• Changed only when there is evidence of compromise.
• Paste and password managers allowed; no hints or security questions.
• Failed sign-ins throttled; passwords stored with Argon2id, scrypt, bcrypt, or PBKDF2.

Our password policy generator starts from these defaults and flags any setting that departs from SP 800-63B-4, so you can see the trade-off before you publish a policy.

Common objections

“Our compliance framework still requires complexity and rotation.”

Some older frameworks and internal policies have not caught up. Many auditors now accept NIST SP 800-63B as justification for dropping composition and rotation rules, especially when paired with a breach blocklist and MFA. Document the decision and cite the standard.

“Won’t users just choose weak long passwords?”

That is what the blocklist is for. passwordpassword meets a length rule but appears in every breach list. Length plus a good blocklist rejects the weak choices that composition rules let through.

Key takeaways

• Require length (15 characters single-factor), not character types.
• Stop forcing scheduled changes; force them on evidence of compromise.
• Reject breached and common passwords, allow password managers, throttle guesses, and hash with a slow algorithm.

Sources

• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (2025)
• Have I Been Pwned — Pwned Passwords range API (k-anonymity)
• OWASP Authentication Cheat Sheet