NIST password guidelines 2026: What SP 800-63B-4 requires

NIST SP 800-63B-4 requires passwords used as the only authentication factor to be at least 15 characters long. Many summaries describe that figure as a recommendation, but Sec. 3.1.1.2 states it as a requirement.

The NIST password guidelines in SP 800-63B-4 (final since July 2025) set 15 characters as the minimum for password-only login and 8 when the password is one factor in multi-factor authentication. They prohibit composition rules and periodic changes, and they require verifiers to block breached, common and context-specific passwords.

This guide sorts every password requirement into SHALL, SHOULD and MAY with section numbers, shows what changed from Rev 3, corrects six common misreadings and ends with a rollout checklist.

NIST password guidelines: what SP 800-63B-4 is and who it applies to

NIST SP 800-63B-4 is the authentication volume of NIST's Digital Identity Guidelines (SP 800-63-4). NIST published the final version in July 2025, and it supersedes SP 800-63B of March 2020. The standard is written for US government information systems, so for organizations in Europe and elsewhere it is voluntary guidance and a reference point for your own policy.

SP 800-63-4 has four volumes: the core document, identity proofing (63A), authentication (63B) and federation (63C). According to NIST's SP 800-63-4 page, the revision took almost four years, with two public drafts and nearly 6,000 public comments.

The scope sits in the abstract. The guideline "focuses on the authentication of subjects who interact with government information systems" and is "not intended to constrain the development or use of standards outside of this purpose." For US federal agencies and their credential service providers the requirements are normative.

NIST uses its own vocabulary, which differs from vendor language:

NIST password requirements: the SHALL, SHOULD and MAY map

NIST password requirements come in three strengths. SHALL and SHALL NOT mark mandatory conformance rules of the standard itself, SHOULD marks a recommendation that needs a reason to skip, and MAY marks a permitted option. In SP 800-63B-4, the length floors, the bans on composition rules and periodic changes, blocklist checks, rate limiting and salted hashing are all SHALL.

Use the SHALL-first password policy as the working method: implement every mandatory requirement before any recommended one. Tier 1 is the SHALL baseline, tier 2 is SHOULD hardening, and tier 3 is the MAY allowances you adopt only when they fit your users. The table below sorts every password requirement into those tiers, with the section where NIST states it.

Build the policy from the SHALL rows first. Each SHOULD row you skip needs a recorded reason, and the MAY rows are options you take or leave.

What changed from SP 800-63B Rev 3 to Rev 4

Rev 4 raises the single-factor password minimum to 15 characters (up from 8) and moves two Rev 3 recommendations, no composition rules and no periodic changes, from SHOULD NOT to SHALL NOT. NIST's FAQ says both were previously discouraged but allowed. Blocklist checks, hint and KBA bans, salted hashing and rate limiting were already mandatory in Rev 3.

NIST's implementation FAQ lists the new password requirements, and SP 800-63B Rev 3 (2020) confirms the earlier wording. The table compares both texts.

Rev 4 also adds requirements for syncable authenticators such as synced passkeys (Appendix B) and a definition of phishing-resistant authenticators (Sec. 3.2.5), both listed in NIST's change log (Appendix E). For a policy written to Rev 3, the length floor, composition rules and expiry settings are the first to change.

Six common misreadings of the NIST password rules

Six errors circulate in summaries of SP 800-63B-4: treating 15 characters as optional, quoting 8 as the general minimum, mixing up the 100 and 10 attempt limits, calling SMS banned, requiring paste instead of password managers, and calling blocklist screening new. Each row gives the actual requirement and the section that states it.

Length, characters and blocklists: what verifiers must check

Verifiers must require 15 characters for password-only login, count each Unicode code point as one character, reject composition rules and compare every new password in full against a blocklist of breached, common and context-specific values. When a password is rejected, the verifier must say why and offer guidance on choosing a strong one.

The length rule has two tiers. A password used as the only factor needs 15 characters. A password used only as part of multi-factor authentication may be shorter than 15 but needs at least 8 (Sec. 3.1.1.2). You can set one floor of 15 for every path, because NIST allows it and it keeps user guidance to a single number.

Beyond the floor, verifiers should accept at least 64 characters and must verify the whole password without truncation. Each Unicode code point counts as one character. When Unicode is accepted, NFC normalization should be applied before hashing, because NIST warns that some endpoints represent some characters differently, which can break authentication.

Character sets are open: verifiers should accept all printing ASCII characters, the space character and Unicode. They must not impose other composition rules, such as requiring mixtures of character types (Sec. 3.1.1.1 and 3.1.1.2). Appendix A gives the reason: users "respond in very predictable ways to the requirements imposed by composition rules", so password becomes Password1 and then Password1!. Our article on why composition rules fail in practice covers the behavior and the entropy math.

When a user sets or changes a password, the verifier must compare it against a blocklist of commonly used, expected or compromised values. The comparison covers the entire password, not substrings or words inside it. The list may draw on three sources:

• passwords from previous breach corpuses
• dictionary words
• context-specific words, such as the service name, the username and derivatives of them

If the password is on the list, the verifier must require a different one, give the reason for the rejection and offer guidance on choosing a strong password. The guidance matters most after a rejection, because it discourages trivial edits of a listed password.

Size has a limit. NIST states that "Excessively large blocklists are of little incremental security benefit because the blocklist is used to defend against online attacks, which are already limited by the throttling requirements." The target is a list large enough to stop passwords an attacker would guess before reaching the attempt limit (SHOULD).

Two prompts are banned when a password is chosen. Verifiers must not let a subscriber store a hint that an unauthenticated claimant can see, and must not prompt for knowledge-based authentication (KBA) or security questions.

Password changes, rate limiting and storage

Verifiers must not require periodic password changes, but must force a change on evidence of compromise. Consecutive failed attempts are capped at 100 per authenticator, and stored passwords must be salted and hashed with a salt of at least 32 bits. Sec. 3.1.1.2 and Sec. 3.2.2 hold these rules.

Changes. Calendar-based expiry is out, and NIST's FAQ says routine periodic changes were "previously discouraged but allowed" in Rev 3. A forced change is required when there is evidence that the authenticator has been compromised. NIST does not define that evidence, so your policy has to. A report from the subscriber and a match of an existing password against a breach corpus are two practical triggers, and both are policy choices rather than NIST-defined events.

Rate limiting. A verifier must limit consecutive failed attempts on a single authenticator to no more than 100 "by disabling that authenticator", and a disabled authenticator must be rebound to the account before it works again (Sec. 3.2.2, 4.1). The limit is an upper bound, and lower limits are allowed. To keep attackers from locking out legitimate users, a verifier may add a bot-detection challenge, a wait that grows from 30 seconds up to an hour, or risk-based signals. Compare your IdP's lockout behavior against the "disabling" wording. Activation secrets, such as a device PIN that never leaves the device, follow a different rule: at least 4 characters (6 recommended) and no more than 10 consecutive failed attempts (Sec. 3.2.10).

Storage. Passwords must be salted and hashed with a suitable password hashing scheme, and the salt must be at least 32 bits and chosen to minimize collisions between accounts. Verifiers should use an approved scheme from the latest SP 800-132 or updated NIST guidance, set the cost factor as high as practical and raise it over time. They should also add a keyed hash with a secret key stored separately from the hashes, ideally in a hardware security module or trusted execution environment. NIST no longer lists specific algorithms because storage requirements change quickly.

Where passwords fit in AAL1, AAL2 and AAL3

Password-only authentication is permitted only at AAL1, which is why the 15-character rule applies there. At AAL2 a password must be paired with a physical authenticator, and verifiers must offer a phishing-resistant option. AAL3 requires a cryptographic authenticator with a non-exportable private key, with a password allowed only as an additional factor.

The values come from Sec. 2.1 to 2.3 of NIST's standard. Three notes follow.

1. The 15-character floor attaches to single-factor use. NIST's FAQ describes the increase as applying to passwords "being used as a single authentication factor at AAL1".
2. Passwords are not phishing-resistant (Sec. 3.1.1). At AAL2, verifiers must offer at least one phishing-resistant option (Sec. 2.2.2). Phishing resistance requires cryptographic authentication, and authenticators that involve manual entry of an output, such as OTP and out-of-band codes, do not qualify (Sec. 3.2.5). Our guide to how passkeys work covers the cryptographic side.
3. Syncable authenticators such as synced passkeys can support AAL2 when the Appendix B requirements are met. They must not be used at AAL3: syncing means the private key is exportable, and AAL3 requires a non-exportable key (Sec. 2.3.2).

SMS and voice codes sit in a separate category. Out-of-band authentication over the telephone network is a restricted authenticator. The organization must assess and accept the risk, offer at least one unrestricted alternative, give subscribers meaningful notice and keep a migration plan (Sec. 3.1.3.3, 3.2.9).

How to apply the NIST password guidelines: a SHALL-first rollout

A SHALL-first rollout configures every mandatory requirement before any recommended one. Inventory each system that verifies a password, set the 15-character floor, remove composition and expiry rules, turn on blocklist screening, confirm rate limiting, audit in-house code, offer phishing-resistant authentication and record exceptions in a register.

1. Inventory every place a password is verified: directory, IdP, VPN, customer-facing applications and internal applications. NIST obligations attach to the verifier, so each system that checks a password needs its own row.
2. Set the length floor. Use 15 characters for every password-only path, and decide your floor for MFA paths: NIST allows 8 there, and one rule of 15 for both keeps policy and user guidance simple.
3. Remove composition rules from the directory password policy, the IdP policy and the application code.
4. Remove calendar-based expiry. Keep the forced change on evidence of compromise, and write down what triggers it.
5. Turn on blocklist screening for set and change events, including context-specific words such as the service name and username. The rejection message must give the reason and offer guidance. If your directory cannot screen natively, the requirement still sits with the verifier, so check what your IdP can do.
6. Check rate limiting: at most 100 consecutive failures per authenticator. Apply a lower limit and progressive delays where the business can accept them, and compare your lockout behavior with NIST's "disabling that authenticator" wording.
7. Audit in-house applications. They should accept 64 or more characters, Unicode and spaces, allow paste and autofill, never truncate, and store passwords salted and hashed with a current scheme. Drop special-character filters meant to stop SQL injection: Appendix A notes that an unhashed password is never sent intact to a database, so those filters are unnecessary.
8. Offer phishing-resistant authentication for privileged and remote access. Passwords are not phishing-resistant, and AAL2 verifiers must offer at least one phishing-resistant option.
9. Record exceptions. A contract or framework may still require something different, such as periodic rotation. Log each exception with the requirement, the reason, an owner and a review date.

Where a password manager fits in an SP 800-63B-4 policy

SP 800-63B-4 requires verifiers to allow password managers and autofill, and NIST notes that managers raise the likelihood of stronger passwords, especially with generators. A password manager covers credentials your identity provider does not verify. It does not change how your directory or IdP verifies passwords, which stays a separate configuration task.

Two groups of credentials sit outside your verifier configuration: accounts on SaaS and vendor systems that you do not verify yourself, and shared or privileged credentials that no directory password policy covers. Both need long, random, unique passwords.

Passwork supports this use with four capabilities:

• A built-in password generator in the web interface, browser extension, and mobile and desktop apps. It applies organization-defined rules and helps users create a unique password for each service.
• A security dashboard that reports password strength (based on length and character diversity), age (it flags passwords unchanged for 180 days or more) and compromise risk, such as passwords still accessible to users whose access was revoked. Administrators can filter by vault, folder, user and threat category.
• An administrator-configurable lockout policy for local authentication, with maximum failed attempts, a time window and a lockout duration. It governs the vault's own sign-in and is separate from the attempt limit your verifier enforces under Sec. 3.2.2.
• Sign-in with passkeys (WebAuthn), TOTP, SAML SSO or LDAP/AD, plus an Activity Log of user, admin and system actions that can be exported to SIEM systems.

The age flag is a review signal, not an expiry rule. Sec. 3.1.1.2 prohibits requiring periodic changes of the passwords your own verifier checks, and the platform does not change that.

Conclusion

The NIST password guidelines in SP 800-63B-4 add up to a short policy: one length floor, no composition rules, no expiry calendar, blocklist screening, rate limiting and salted hashing. Run the SHALL-first password policy before you spend effort on the SHOULD rows.

Start with three changes. Set 15 characters on every password-only path and drop composition and expiry rules. Add blocklist screening wherever passwords are set. Offer phishing-resistant authentication to privileged users. Credentials for systems outside your IdP's password policy still need long, unique values, and a password manager is where they belong.

Frequently asked questions

Northflank breach: What to rotate after the incident

Northflank told customers to assume every environment variable was decrypted. Railway warned some may have been, and Huntress tracked stolen M365 tokens replayed at 79 organizations. What each disclosed, and what to rotate.

PassworkPasswork Team

NIS2 access management: What five experts would fix first

From policy to practice: who had access to what, with whose approval, for how long, and can you prove it? Five cybersecurity leaders on the access controls that are hardest to operationalize, and the evidence organizations need to demonstrate that they work.

PassworkPasswork Team

Password manager compliance standards: What changed in 2026

NIST says never rotate. PCI DSS can still say every 90 days. This guide maps nine frameworks and passkeys to vault controls and shows how to resolve the conflict by scope.

PassworkAlex Muntyan