NIST password guidelines

Key Takeaway: NIST SP 800-63B Revision 4 (finalized mid-2025) replaced legacy password rules with a 15-character recommendation, mandatory blocklist screening, and no forced rotation. The update also formally recognizes synced passkeys at AAL2 and device-bound passkeys at AAL3. Teams still enforcing 90-day rotations or 8-4 composition rules are now out of step with current NIST guidance.

NIST finalized SP 800-63B Revision 4 in mid-2025, ending the prescriptive checklist era of digital identity and moving to a risk-based model. For GRC, infosec, and audit teams, that means rewriting policy language around rotation, composition, blocklist screening, and phishing-resistant MFA. Read on for what changed, how it maps to PCI DSS 4.0.1 and SOC 2, and how this guidance sits inside the broader NIST CSF 2.0 baseline most adjacent frameworks point to.

Why password security still matters

Credential abuse remains the dominant initial-access vector. The 2025 Verizon Data Breach Investigations Report found that 88% of basic web application attacks involved stolen credentials, and infostealer telemetry showed 30% of compromised systems were enterprise-licensed devices. Once attackers have a valid password, they can escalate privileges, move laterally, and reach sensitive personal, financial, and customer data.

Aligning to NIST password guidance gives audit and compliance teams a defensible baseline that maps cleanly to PCI DSS, SOC 2, ISO/IEC 27002:2022, and CISA's Cybersecurity Performance Goals. It is also the standard auditors increasingly cite by name in evidence requests.

NIST password guideline standards

The NIST password guidelines live in NIST SP 800-63B, part of the Digital Identity Guidelines suite. Originally published in 2017 under the Federal Information Security Modernization Act of 2014, revised in 2020, and most recently finalized as Revision 4 in mid-2025, the guidelines now cover both how to construct memorized secrets and how verifiers should evaluate them. Below are the core verifier-side practices practitioners should enforce.

1. Enable 'show password'

Hiding characters during entry increases mistyping and unnecessary password resets, each of which is its own exposure window. Most modern applications now include a visibility toggle or eye icon that lets users verify input before submission. Pair it with biometric or PIN-gated reveal in browser-integrated password managers so the convenience does not weaken the control.

2. Use a password manager for stronger credentials

NIST encourages organizations to deploy a password manager so employees and stakeholders can generate and store long, unique passwords without reuse. Browser-integrated managers can autofill credentials across cloud services, web applications, and local apps, and modern implementations require biometric or PIN re-authentication before revealing a stored secret — an additional layer on top of application MFA.

User behavior is the reason this matters. Many users reuse passwords across systems, which creates exposure to credential stuffing — attackers replaying credentials from one breach against unrelated accounts. Pairing a password manager with focused training measurably reduces reuse and supports the long, unique passphrases NIST now recommends.

3. Store secrets securely through salting and hashing

NIST requires verifiers to remove the user-supplied password from memory immediately after processing using a zero-knowledge password protocol or zeroization, and to store only a salted, hashed representation. A hash is a function that maps a string of arbitrary length to a fixed-length output — so a stored password becomes a fixed-length string of bytes rather than recoverable plaintext. Salting prepends or appends unique random data to each password before hashing, defeating precomputed rainbow-table attacks. Generate a unique salt for every stored credential.

Use a modern, slow, memory-hard key derivation function: Argon2id (preferred), bcrypt, or PBKDF2. MD5 and SHA-1 are not acceptable. SHA-256 is also not appropriate as a standalone password hash — it is FIPS-approved and cryptographically secure, but it is fast by design, which lets attackers run billions of guesses per second against stolen hashes. SHA-256 is acceptable only as a primitive inside an approved KDF (for example, PBKDF2-HMAC-SHA-256).

4. Lock after multiple attempts

NIST requires verifiers to rate-limit authentication attempts. The Digital Identity Guidelines cap consecutive failed attempts at 100, but most organizations enforce a far lower threshold combined with progressive delays between attempts. CAPTCHAs and IP allowlists are also acceptable compensating controls against credential-stuffing bots.

5. Use multi-factor authentication — and prioritize phishing-resistant factors

Multi-factor authentication (MFA) requires two or more factors: something you know (a password), something you have (a hardware key or TOTP authenticator), or something you are (biometrics). Smartphone authenticator apps typically require the device to be unlocked via biometrics or PIN before revealing the one-time code, adding a layer on top of the application's MFA. Hardware security keys such as YubiKeys also satisfy something you have.

Not all MFA is equal. NIST SP 800-63B Rev 4 and CISA authentication standards both rank hardware-based, cryptographic authenticators — FIDO2/WebAuthn security keys and PKI smart cards such as PIV — as the strongest, phishing-resistant tier. SMS, voice OTP, and push-notification MFA are better than passwords alone but remain vulnerable to SIM-swap, interception, and push-bombing, and should be deprecated for privileged and externally facing systems. PwC's 2025 Global Digital Trust Insights found only 47% of organizations apply MFA consistently across externally facing ICFR systems — a useful baseline when scoping remediation.

Third parties, auditors, and cyber insurers no longer accept "we have MFA" as a sufficient control statement. Document which authenticator tier protects which system, and tie the tier to data sensitivity.

Frequency of password changes

Contrary to legacy policy, NIST does not recommend periodic password expiration. Users forced to rotate every 60 or 90 days predictably reuse a prior password with a minor variation appended — a pattern attackers exploit, and a pattern that becomes more dangerous once any version of the original has been breached.

NIST SP 800-63B Rev 4 says rotate only on suspected compromise. Adjacent frameworks have aligned: PCI DSS 4.0.1 (June 2024) accepts the no-mandatory-rotation model when dynamic analysis of account access is in place, ISO 27001's companion controls in ISO/IEC 27002:2022 (control 5.17) contain no arbitrary rotation mandate, and SOC 2's Trust Services Criteria evaluate the effectiveness of access controls rather than prescribing a rotation cadence. Document the risk-based rationale, enforce length plus blocklist screening plus phishing-resistant MFA, and give auditors evidence of the compensating continuous controls.

What's new in NIST SP 800-63B Revision 4

NIST SP 800-63 was first released in 2017 and has gone through several iterations, summarized in the 2025 NIST update. Revision 4 was finalized in mid-2025 and is the governing document through at least 2026. The headline shifts: length over complexity, mandatory blocklist screening for known-compromised credentials, no periodic rotation, formal recognition of syncable authenticators (synced passkeys) at AAL2 and device-bound passkeys at AAL3, and updated threat coverage for injection attacks and forged media. Aligning policy to Rev 4 improves security posture without sacrificing user experience.

1. Reduce the importance of password complexity

NIST guidance prioritizes length over composition. Forcing uppercase, lowercase, digit, and special character requirements — often called the "8-4 rule" — drives predictable user behaviors like "Password1!" that are easier, not harder, to crack. Rev 4 reinforces that verifiers SHALL NOT impose composition rules on memorized secrets.

The current floor is a minimum of eight characters, but NIST's own consumer-facing guidance now recommends a 15-character minimum. The longer the password, the more computationally expensive it is to brute-force — NIST notes that at 100 billion guesses per second, a 15-character password takes significantly longer to crack than a shorter one. Practical floor: 15 characters for human-generated memorized secrets, 64-character maximum, with passphrase generation handled by a password manager wherever possible.

Passphrases. NIST treats multi-word passphrases as a preferred form of memorized secret because length drives entropy more efficiently than character complexity, and phrases are easier to recall without writing them down. Allow up to 64 characters, accept all printing ASCII and Unicode characters (including spaces), do not impose composition rules, and screen the resulting phrase against breached-password blocklists.

2. Monitor new passwords automatically

Some passwords are compromised before they are even created. Rev 4 expects verifiers to compare prospective memorized secrets against lists of known-compromised, commonly used, and context-specific values (for example, the company name or username) at registration and on change. Sequential strings like "123456" and dictionary words like "password" are only the most obvious entries on commonly compromised password lists.

Operationally, integrate a breached-password feed such as Have I Been Pwned's Pwned Passwords API (k-anonymity model), Enzoic, or Specops, and screen both at password creation and asynchronously against the existing user base. Track blocklist hit rate as a KPI and feed rejections into security awareness metrics.

3. Threats to authentication

Passwords are the front line of authentication, and breached credentials remain among the most common attack vectors — Verizon's 2025 DBIR puts stolen credentials behind 88% of basic web application attacks. Understanding the threats to authentication NIST identifies helps GRC teams scope which controls apply to which systems and assurance levels.

4. Eliminate password hints

NIST SP 800-63B prohibits password hints and knowledge-based authentication questions, both of which give attackers a meaningful clue toward the underlying secret.

NIST password recommendations

These items are best practices rather than hard requirements, but they materially reduce user error and friction:

• Set the maximum password length at 64 characters.
• Do not require special characters.
• Allow copy-and-paste in password fields so password managers work correctly.
• Accept all printing ASCII and Unicode characters, including spaces.
• Deploy a secure, organization-wide password manager.

NIST guidelines for compromised passwords

Change passwords as soon as compromise is suspected, and screen new passwords against compromised-credential lists at creation. Compare prospective passwords against breached and frequently used password lists, and reject matches before they become user accounts. Your IT or security team can use the same tools attackers use — dictionary lists, credential dumps, context-specific terms (company or product name), and hash tables — to filter compromised credentials out of your environment before someone else weaponizes them. A mature cyber risk management program will operationalize this screening as a continuous control rather than a point-in-time check.

Audit-ready evidence for NIST 800-63B Rev 4 alignment

Rev 4's risk-based model does not map cleanly to legacy checklist evidence requests, so prepare artifacts that translate directly to control language auditors recognize:

1. Updated password and authenticator policy explicitly referencing SP 800-63B Rev 4 and removing periodic rotation.
2. Verifier configuration evidence showing minimum length, 64-character maximum, and the absence of composition rules.
3. Hashing standard documentation confirming Argon2id, bcrypt, or PBKDF2 with unique per-secret salts.
4. Blocklist integration evidence with hit-rate metrics from creation-time and asynchronous screening.
5. MFA coverage reports broken down by authenticator strength tier (phishing-resistant vs. OTP vs. SMS).

Tie each artifact to the corresponding SP 800-53 Rev 5 IA-5 (Authenticator Management) control statement so auditors working from a control catalog have a clean mapping.

NIST password takeaways

NIST password guidelines are revised regularly, and SP 800-63B Rev 4 is the current authority through at least 2026. Make sure staff and stakeholders understand the length-over-complexity model, have password manager and MFA tooling in place, and can produce breached-password screening and authenticator-tier evidence on demand.

Frequently asked questions

What are the NIST password guidelines for 2026?

The governing document is NIST SP 800-63B Revision 4, finalized in mid-2025, and there is no announced successor in active comment. Headline requirements: an eight-character verifier floor with NIST recommending at least 15 characters, a 64-character maximum, no composition rules, no mandatory periodic rotation, mandatory blocklist screening, and a clear preference for phishing-resistant MFA (FIDO2/WebAuthn, PKI). Treat Rev 4 as the baseline through 2026.

What changed in NIST SP 800-63B Revision 4?

Rev 4 formalized a risk-based authentication model that replaces the prescriptive checklist of Rev 3. Key shifts: explicit elimination of mandatory periodic rotation (rotate only on suspected compromise), emphasis on length over composition, mandatory screening against compromised-password blocklists, and formal recognition of syncable authenticators such as synced passkeys at AAL2. Practitioners should update policy documents to reference Rev 4, remove residual 60/90-day rotation language, and add controls for breached-password screening.

What is the difference between NIST 800-63B and NIST 800-53 password requirements?

SP 800-63B is NIST's Digital Identity Guidelines covering authenticator design, password (memorized secret) construction, and verifier behavior. SP 800-53 is the broader security and privacy control catalog used for FISMA and FedRAMP, with control family IA-5 (Authenticator Management) covering authentication. SP 800-53's IA-5 controls reference 800-63 for implementation detail, so cite 800-53 IA-5 as the control authority and 800-63B as the technical specification.

Is SHA-256 acceptable for password storage?

No. SHA-256 is cryptographically secure but is designed to be fast, which lets attackers run billions of guesses per second against stolen hashes. NIST and OWASP both direct organizations to use slow, memory-hard key derivation functions: Argon2id (preferred), bcrypt, or PBKDF2 with a high iteration count. SHA-256 is acceptable only as a primitive inside an approved KDF (for example, PBKDF2-HMAC-SHA-256), not as a standalone password hash.

What is the "8-4 rule," and does NIST still endorse it?

The 8-4 rule requires an eight-character minimum plus at least one lowercase, uppercase, digit, and special character. NIST has explicitly moved away from this composition model. Rev 4 states verifiers SHALL NOT impose composition rules on memorized secrets, because complexity mandates drive predictable behaviors (e.g., "Password1!") that are easier to crack. Replace 8-4 rules with a minimum length floor (NIST recommends at least 15 characters), a 64-character maximum, and breached-password screening.

How do we operationalize breached-password screening?

Rev 4 expects verifiers to compare prospective memorized secrets against lists of known-compromised, commonly used, and context-specific values at registration and on change. Integrate a breached-password feed — Have I Been Pwned's Pwned Passwords API (k-anonymity model), Enzoic, or Specops are common choices — and run screening both at password creation and asynchronously against the existing user base. Track blocklist hit rate as a KPI.

How should we handle synced passkeys under NIST guidance?

SP 800-63B Rev 4 formally recognizes syncable authenticators (synced passkeys) and permits them at Authenticator Assurance Level 2 (AAL2), provided the syncing fabric enforces appropriate cryptographic protections and account recovery controls. Device-bound passkeys (such as FIDO2 security keys) remain the model for AAL3 and the strongest phishing-resistant option. Document which AAL each authenticator type satisfies and tie it to the sensitivity of the data it protects.

About the authors

Vice Vicente started their career at EY and has spent the past 10 years in the IT compliance, risk management, and cybersecurity space. Vice has served, audited, or consulted for over 120 clients, implementing security and compliance programs and technologies, performing engagements around SOX 404, SOC 1, SOC 2, PCI DSS, and HIPAA, and guiding companies through security and compliance readiness. Connect with Vice on LinkedIn.