NIST SP 800-63B Password Guidelines: The Complete Summary

What is NIST SP 800-63B?

NIST Special Publication 800-63B is the United States government's authoritative guidance document on digital authentication. Formally titled "Digital Identity Guidelines: Authentication and Lifecycle Management," it is published by the National Institute of Standards and Technology (NIST) and last substantively updated in 2020.

While SP 800-63B is technically a requirement only for US federal agencies and systems that interact with them, it has become the de facto global standard for password policy. When security auditors, compliance frameworks, and enterprise security teams want to justify a password policy, they cite NIST 800-63B.

The reason it matters: the 2017 update reversed decades of password advice that security professionals had accepted as settled. Understanding what changed — and why — is essential for anyone writing or implementing a password policy.

What changed from the old guidance

Before NIST 800-63B's 2017 update, the standard password policy advice was: require complexity (uppercase, lowercase, numbers, symbols), force rotation every 60–90 days, require security questions as a reset mechanism. These rules came from a 2003 NIST Special Publication written by a single author who later publicly stated he regretted writing them.

The research that accumulated over the following 14 years consistently showed these rules were counterproductive:

• Complexity rules cause predictable substitutions: Password1! satisfies all four requirements and is trivially guessable
• Mandatory rotation causes users to choose weaker passwords incrementally: Summer2023! becomes Summer2024!
• Security questions are either guessable (mother's maiden name) or memorable in ways that make them weak
• The cognitive burden of managing rotating complex passwords drives password reuse, which is far more dangerous than any of the problems the rules were trying to solve

The 2017 update replaced this paradigm entirely. The table below summarises the key reversals:

Length over complexity

The single most important principle in NIST 800-63B is that length is a more reliable predictor of password strength than character diversity. The mathematics support this conclusively.

Consider the search space for two passwords:

• 8-character password with all 4 character types: ~96 bits of theoretical maximum entropy, but the complexity rules constrain the actual distribution of characters in ways that significantly reduce real-world entropy. The average user choosing a "complex" password achieves around 30–40 bits of effective entropy.
• 16-character lowercase passphrase: With a pool of 26 characters, the theoretical entropy is 75 bits — and crucially, users are far more likely to choose unpredictably, because long passphrases don't have the same human-pattern traps that short complex passwords do.

The practical implications for policy:

• Set the minimum to 8 characters (the NIST minimum) — but recommend and encourage longer passwords
• Set the maximum to at least 64 characters — long passphrases must be supported
• Do not restrict which characters can be used — accept all Unicode, spaces, and special characters
• Do not require specific character types — make them optional but show the entropy score

No mandatory password rotation

NIST 800-63B Section 5.1.1.2 states clearly: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)." This represents one of the most significant reversals in the document.

The reasoning: research consistently found that forced rotation caused users to:

1. Choose weaker baseline passwords because they knew they'd need to change them soon
2. Apply predictable transformations: Spring2024! → Summer2024!
3. Write passwords down to manage the cognitive load
4. Reuse passwords across systems with slight variations

NIST's recommended approach: require password changes only when there is evidence that a credential has been compromised. "Evidence" includes:

• The credential appearing in a known breach database (check against HIBP)
• Suspicious login activity detected in audit logs
• User reports suspected compromise
• Phishing campaign known to have targeted the organisation

Banned password lists

Section 5.1.1.2 requires that newly chosen passwords be checked against a list of commonly used, expected, or compromised values. This is now standard practice and one of the most impactful controls you can implement.

NIST recommends blocking passwords that appear on:

• Known breached credential lists — Have I Been Pwned (HIBP) Passwords API contains over 900 million known-compromised passwords
• Dictionary words — single words or simple variations
• Repetitive or sequential characters: aaaa, 1234, abcd
• Context-specific words: the service name, username, organisation name

The HIBP k-anonymity API allows you to check passwords against the breach database without sending the password to any external server — only the first 5 characters of the SHA-1 hash are transmitted. This is the implementation PassGeni's breach checker uses.

MFA and authenticator guidance

NIST 800-63B defines three assurance levels (AAL1, AAL2, AAL3) and specifies which authenticator types meet each level. For most enterprise applications, AAL2 is the appropriate target.

SMS OTP being marked RESTRICTED is significant. NIST doesn't prohibit it, but organisations at AAL2 should migrate away from SMS toward authenticator apps or hardware tokens, particularly for high-privilege access.

No security questions

NIST 800-63B explicitly prohibits knowledge-based authentication (KBA) — security questions — as a standalone authentication mechanism. The document is unambiguous: "Verifiers SHALL NOT use KBA for authentication."

The reasons are well-documented:

• Answers to common security questions (mother's maiden name, first pet, high school) are often publicly available through social media
• Users choose predictable answers or lie in consistent ways (favourite colour: always "blue")
• KBA provides false confidence — it appears to add security while the actual entropy is often lower than a 4-digit PIN

If you are currently using security questions for account recovery, replace them with: email-based magic link recovery, SMS or authenticator OTP verification, or out-of-band identity verification for high-assurance systems.

Who must comply

NIST 800-63B is formally mandatory for US federal agencies and systems that interact with federal identity management. Beyond that, compliance is voluntary — but practically unavoidable:

• SOC 2: Auditors commonly use NIST 800-63B as the reference for evaluating password controls under CC6.1
• FedRAMP: Cloud service providers seeking FedRAMP authorisation must comply
• HIPAA: HHS guidance references NIST standards as the implementation benchmark
• CISA guidance: All critical infrastructure sectors are guided toward NIST standards
• Cyber insurance: Many underwriters now require NIST-aligned controls as a policy condition

How to implement NIST 800-63B

A practical implementation checklist for aligning your password policy with NIST 800-63B:

1. Set minimum password length to 8 characters — recommend 15+ characters in UX copy
2. Set maximum length to at least 64 characters — do not truncate passphrases
3. Accept all printable ASCII and Unicode characters including spaces
4. Remove mandatory complexity requirements — make character type badges visual but not enforced
5. Implement HIBP breach check at password creation and reset (k-anonymity API — no password transmitted)
6. Block obvious bad passwords: dictionary words, sequential characters, username, service name
7. Remove forced periodic rotation — change only on evidence of compromise
8. Remove security questions — replace with email or OTP account recovery
9. Implement account lockout after 10 failed attempts with exponential backoff
10. Require MFA for all high-value access (admin accounts, systems with sensitive data)
11. Document everything: policy, rationale, deviations, review schedule