NIST 800-63B Password Rules: A Practical 2026 Summary

NIST Special Publication 800-63B is part of the Digital Identity Guidelines issued by the National Institute of Standards and Technology, a U.S. federal agency. While NIST standards are mandatory for U.S. government agencies, they have become the de facto global benchmark for password security. Organizations from financial institutions to tech startups reference NIST 800-63B when designing their authentication systems.

The most recent revision fundamentally changed how the security community thinks about passwords. It rejected decades of conventional wisdom — mandatory complexity rules, periodic password changes, and security questions — in favor of evidence-based practices that actually improve security without degrading usability.

Understanding these guidelines is essential whether you are a developer building an authentication system, an IT administrator managing company policy, or an individual trying to make informed security decisions. This guide translates the technical document into actionable recommendations.

Drop mandatory complexity rules. NIST explicitly recommends against requiring uppercase letters, digits, or special characters. Research shows that forced complexity leads to predictable patterns: users capitalize the first letter, add "1!" at the end, or use common substitutions. These patterns are well-known to attackers and provide negligible security improvement. Instead, NIST focuses on password length as the primary strength indicator.

Stop requiring periodic password changes. Forcing users to change passwords every 60 or 90 days causes them to make minimal incremental changes (Password1 → Password2 → Password3) or to choose simpler passwords they can remember despite frequent changes. NIST now recommends changing passwords only when there is evidence of compromise — a breach notification, suspicious activity, or malware detection.

Screen against breached password lists. When a user creates or changes a password, check it against a list of known compromised passwords. The Have I Been Pwned Passwords API provides a free, privacy-preserving way to check over 900 million breached passwords using k-anonymity. If the password appears in a breach, reject it and explain why.

Allow long passwords. Systems should accept passwords up to at least 64 characters. This supports passphrases and password manager-generated credentials. Truncating passwords silently — as some legacy systems do — is a serious security flaw that NIST explicitly prohibits.

NIST sets an absolute minimum of 8 characters for user-chosen passwords and 6 characters for randomly generated PINs. However, security researchers widely recommend 12 characters as a practical minimum and 15+ as ideal. The reasoning is straightforward: modern GPU-accelerated cracking tools can exhaust all 8-character passwords from a 95-character set in hours to days, depending on the hashing algorithm.

For passwords that protect high-value assets (email master accounts, cryptocurrency wallets, server root access), 16+ characters or a 5+ word passphrase is strongly recommended. At this length, even if an attacker obtains the password hash, brute-force cracking becomes computationally infeasible with current technology.

Systems must not impose a maximum password length below 64 characters. Many users employ password managers that generate 20-40 character passwords, and passphrases with separators can easily reach 30+ characters. Arbitrary length limits actively harm security by preventing users from using their preferred generation methods.

NIST requires that new passwords be checked against a list of commonly used, expected, or compromised passwords. This list should include: passwords from previous breach corpuses (available through Have I Been Pwned or similar services); dictionary words; repetitive or sequential characters (aaaaaa, 123456, abcdef); context-specific words (the service name, username, email address).

When a password is rejected, the system should provide a clear explanation: "This password has appeared in a known data breach. Please choose a different password." Generic error messages like "Password does not meet requirements" leave users confused and frustrated.

The Have I Been Pwned Passwords API makes implementation straightforward. It uses k-anonymity: your application sends only the first 5 characters of the SHA-1 hash, receives all matching hash suffixes, and checks locally. The actual password never leaves the user's device, and the API operator cannot determine which password was checked.

NIST requires that passwords be stored using a memory-hard, one-way key derivation function. The recommended algorithms are Argon2id (the winner of the 2015 Password Hashing Competition), bcrypt with a work factor of at least 10, or PBKDF2-HMAC-SHA256 with at least 600,000 iterations (increased from the previous 10,000 recommendation).

Argon2id is the preferred choice for new implementations. It is resistant to both GPU-based attacks (due to memory hardness) and side-channel attacks. Recommended parameters: at least 19 MiB of memory, 2 iterations, and 1 degree of parallelism. These parameters should be tuned so that hashing takes approximately 0.5-1 second on your server hardware.

Never use plain cryptographic hash functions (MD5, SHA-1, SHA-256) for password storage. These are designed to be fast — exactly the opposite of what you want for password hashing. An attacker with a modern GPU can compute billions of SHA-256 hashes per second, but only a few thousand Argon2id hashes.

Always use a unique, random salt for each password (at least 128 bits). The salt must be stored alongside the hash. This prevents precomputed rainbow table attacks and ensures that identical passwords produce different hash values.

NIST strongly recommends multi-factor authentication for any system handling sensitive data. The three factors are: something you know (password), something you have (phone, hardware key), and something you are (biometric). MFA should combine at least two different factors.

NIST classifies authenticators into three assurance levels (AAL1, AAL2, AAL3). AAL1 requires single-factor authentication. AAL2 requires two different factors and is suitable for most business applications. AAL3 requires a hardware-based authenticator and is needed for the highest-security applications.

SMS-based one-time codes are classified as a "restricted" authenticator due to known vulnerabilities (SIM swapping, SS7 interception). While still better than no MFA, organizations should prefer TOTP apps (Google Authenticator, Authy) or FIDO2 hardware keys (YubiKey, Titan) for stronger assurance.

When MFA is implemented, NIST allows relaxing some password requirements (such as minimum length) because the second factor provides additional protection. However, weak passwords remain a risk even with MFA — phishing attacks can capture both the password and the OTP simultaneously.

For developers and IT administrators implementing NIST-compliant password policies, here is a practical checklist. Start by removing any existing complexity requirements (mandatory uppercase, digit, symbol). Set the minimum length to 12 characters and maximum to at least 64. Implement a breached password check using the Have I Been Pwned Passwords API.

Update your password storage to use Argon2id (preferred), bcrypt (minimum work factor 10), or PBKDF2-HMAC-SHA256 (minimum 600,000 iterations). If migrating from a weaker hash, rehash passwords transparently when users next log in. Ensure unique 128-bit random salts per password.

Remove periodic password change requirements. Instead, implement breach detection: monitor for credential leaks affecting your users and force password changes only when compromise is detected. Add rate limiting to login endpoints (lock accounts after 10-20 failed attempts within a short window).

Enable and encourage MFA, prioritizing FIDO2/WebAuthn hardware keys or TOTP apps. Offer clear enrollment instructions and recovery procedures. Store MFA backup codes securely and remind users to save them.