NIST Password Guidelines: What SP 800-63B Really Requires

For two decades, password policies looked the same everywhere: eight characters, one uppercase letter, one digit, one symbol, and a forced change every 90 days. The U.S. National Institute of Standards and Technology (NIST) has spent years taking that model apart. Its Digital Identity Guidelines, SP 800-63B, now say most of those rules do more harm than good.

This guide translates the current revision (Revision 4, finalized in 2025) into plain English: what is required, what is only recommended, and how to roll it out without surprising your auditors.

The rules at a glance

• 15 characters minimum when the password is the only factor, 8 when it is used with MFA.
• Accept at least 64 characters, including spaces and Unicode, and never truncate.
• Screen every new password against breached, common and context-specific lists.
• Welcome password managers: allow autofill and paste.
• Limit failed attempts to 100 consecutive failures at most.
• No composition rules, such as "must contain a symbol".
• No scheduled expiry. Change passwords only when there is evidence of compromise.
• No hints and no security questions.

SHALL vs. SHOULD: how to read NIST

NIST writes "SHALL" for requirements, "SHOULD" for strong recommendations and "MAY" for options. If you are audited against SP 800-63B, as U.S. federal agencies and many of their suppliers are, the SHALL statements are mandatory. Everyone else can treat the document as the best free, evidence-based playbook available.

1. Length is the main requirement

Revision 4 raises the floor. A password that is the only authentication factor shall be at least 15 characters long. When the password is one part of multi-factor authentication, the minimum is 8. Systems should accept at least 64 characters and must check the whole password rather than silently cutting it short.

The reason is simple arithmetic. As our crack-time table shows, a random 8-character password using every printable character falls to a GPU cluster in under an hour, while 15 or more characters pushes the same attack past the age of the universe.

2. Composition rules are out

Verifiers shall not impose composition rules, such as requiring a mix of uppercase, digits and symbols. People respond to those rules predictably: a capital at the start, a digit and an exclamation mark at the end. Password1! satisfies most legacy policies and is one of the first guesses in any cracking tool.

Instead, systems should accept every printable ASCII character, spaces, and Unicode characters such as emoji or accented letters. More choice for the user means more unpredictability for the attacker.

3. No more 90-day password changes

NIST says verifiers shall not require periodic password changes. They shall force a change when there is evidence of compromise, for example a breach notification or a match against a leaked-password list.

Forced rotation feels safe but backfires. Users who must change passwords on a schedule make small, predictable edits: Spring2026! becomes Summer2026!. A well-known University of North Carolina study found that, given an old password, attackers could guess many users' next password in a handful of tries.

4. Blocklists are mandatory

Every new password shall be compared against a blocklist of values that are commonly used, expected or compromised. That list should include:

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

If a password is rejected, tell the user why, so they can choose a better one instead of adding a digit at the end. Our breach checker uses the same Pwned Passwords data that many identity providers rely on. In Active Directory, Microsoft Entra Password Protection fills this role.

5. Make password managers welcome

Verifiers shall allow password managers and autofill, and should allow paste into password fields. Blocking paste sounds like a security measure, but it pushes people toward short passwords they can type from memory, which is the opposite of what you want.

6. Drop hints and security questions

Systems shall not store password hints that anyone could read, and shall not ask users to set knowledge-based answers such as "the name of your first pet". Those answers are often public on social media, and they become a weaker second password that never expires.

7. Throttle guessing without punishing users

Verifiers shall limit consecutive failed attempts on a single account to no more than 100. That is a ceiling, not a target: many organizations choose 10. Combine it with progressive delays, bot detection and risk signals so legitimate users are rarely locked out while online guessing becomes pointless.

8. Store passwords like it matters

Passwords shall be stored salted and hashed with a suitable password hashing function, using a salt of at least 32 bits. In practice that means Argon2id, scrypt, bcrypt or PBKDF2 with a high work factor. NIST also recommends an additional secret "pepper" kept separately from the database, so a stolen database alone is not enough to start cracking.

How NIST compares with PCI DSS and CIS

If you are audited against several frameworks, you will notice they do not fully agree:

The most useful move is to enforce MFA. It lowers the NIST minimum to 8 characters and removes PCI DSS's 90-day rotation requirement, which leaves composition as the main conflict. The policy builder shows, rule by rule, which frameworks a configuration satisfies.

Roll it out in a week

1. Turn on MFA first, starting with email, VPN and administrator accounts.
2. Raise the minimum length to 15 for password-only accounts and accept 64 or more.
3. Deploy a blocklist: Entra Password Protection for Active Directory, pwquality dictionary checks on Linux, the Pwned Passwords API in your own applications.
4. Remove composition rules and scheduled expiry, and announce it. Users love this part.
5. Allow paste and password managers, and retire security questions.
6. Write it down: generate the policy document and scripts with the NIST preset.

FAQ

Does NIST still allow 8-character passwords?

Only when the password is used together with another authentication factor. On its own, a password must be at least 15 characters.

Is NIST SP 800-63B mandatory for my company?

It is mandatory for U.S. federal agencies and organizations contracted to follow it. For everyone else it is voluntary, but it is widely treated as best practice and auditors increasingly expect policies to be aligned with it.

Should we drop password expiry entirely?

Yes, unless another framework you are audited against still requires it, such as PCI DSS for password-only accounts. Always keep forced changes after a suspected compromise.

Where do passkeys fit in?

NIST added guidance for syncable authenticators such as passkeys in 2024. They are phishing-resistant and remove the password from the equation entirely, so roll them out wherever your systems support them. Read passkeys vs. passwords.