NIST Password Guidelines 2026: 15 Characters, No Resets

NIST Password Guidelines 2026: The Complete Compliance Reference

The NIST password guidelines have changed dramatically over the past decade, and most organizations are still enforcing the rules NIST itself abandoned in 2017. The current NIST password guidelines, codified in NIST Special Publication 800-63B, now in its fourth revision (SP 800-63B-4, finalized 31 July 2025), throw out forced periodic resets, complex composition rules, and password hints. In their place, NIST recommends longer passphrases, screening against compromised password lists, and risk-based step-up authentication.

This guide breaks down what the NIST password guidelines actually say in 2026, why every old rule was retired, and the exact changes you should push to your identity provider, HR onboarding flow, and security awareness program.

What Are the NIST Password Guidelines?

The NIST password guidelines are the password and authenticator requirements published by the National Institute of Standards and Technology in Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management. While the guidelines are mandatory only for federal agencies, they have become the de facto baseline for every regulated industry.

NIST first published SP 800-63B in 2017 with a major overhaul of password rules. Revision 4 (SP 800-63B-4), finalized on 31 July 2025 and formally superseding the 2020 edition, refined those rules further, expanded passkey and phishing-resistant authentication guidance, and aligned the document with FIDO2 and WebAuthn standards. The current NIST password guidelines apply to any system that authenticates users to a federal information system, and they are referenced inside FedRAMP, CMMC, and many state-level data protection laws.

For SaaS startups, SMBs, and private-sector organizations of any size, the NIST password guidelines matter for three reasons:

• Cyber insurance. Most policies now require alignment with NIST 800-63B as a precondition for coverage. Many startups discover the requirement only at first renewal.
• Vendor due diligence. Enterprise customers and mid-market buyers regularly ask whether your authentication policies follow NIST, and SMBs that sell upmarket need a clean answer.
• Litigation defense. After a breach, plaintiffs and regulators ask whether you followed a recognized standard. NIST 800-63B is the standard most courts recognize, regardless of company size.

Quick Summary: What Changed in NIST Password Guidelines

The headline shift is from complexity to length. The full set of changes that distinguish current NIST password guidelines from the rules most organizations still enforce:

If your organization still enforces forced 90-day resets and uppercase-lowercase-symbol-number rules, you are operating on guidance NIST publicly retired more than nine years ago.

Current NIST Password Length Requirements

SP 800-63B-4 sets length requirements based on how the password is used, not on who chose it. Section 3.1.1.2 states it directly:

"Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length. Verifiers and CSPs MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length."

Passwords used on their own (single-factor):

• 15 characters minimum. This is a SHALL, not a recommendation. If a password is the only thing standing between an attacker and the account, 15 is the floor.
• Allow up to at least 64 characters in length.
• Allow all printable ASCII characters, Unicode characters, and spaces.

Passwords used as one factor inside MFA:

• 8 characters minimum. This is the only place the widely-quoted "8 characters" figure applies. Citing it as a general floor is the single most common misreading of this standard.

Randomly generated passwords (produced by a system):

Revision 4 removed the shorter length floor that the 2017 edition granted to machine-generated secrets. Section 3.1.1.1 now says only that "Passwords SHALL either be chosen by the subscriber or assigned randomly by the CSP" — the 15-character and 8-character rules above apply either way. The one genuinely shorter floor left in the standard is for activation secrets, the local PIN that unlocks an authenticator on a device, which "SHALL require the secrets to be at least four characters in length and SHOULD require the secrets to be at least six characters in length." Activation secrets are not passwords and the two should not be conflated in a policy document.

The 15-character requirement is new in Revision 4 and is mandatory, not advisory; the original 2017 edition set 8 characters as the minimum and specified no higher figure. Longer passwords are harder to brute-force than shorter ones because each additional character multiplies the search space, which is why length, not composition complexity, is now the primary defense NIST recommends.

Composition Rules NIST Now Forbids

The NIST password guidelines explicitly tell organizations to remove the following requirements that were standard for decades:

• Mandatory uppercase letters.
• Mandatory lowercase letters.
• Mandatory numbers.
• Mandatory special characters.
• Mandatory mix of two or more character classes.
• Forbidden character lists (other than those covered by the breach screening below).

The reasoning is captured in Appendix A ("Complexity") of SP 800-63B-4: "Composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. However, research has shown that users respond in very predictable ways to the requirements imposed by composition rules. For example, a user who might have chosen 'password' as their password would be relatively likely to choose 'Password1' if required to include an uppercase letter and a number." Translated, when you require a number, users append "1". When you require a symbol, they add "!". The end-state password is barely stronger than the original choice and far harder to remember.

NIST does require one substantive composition check: the password must not appear on a list of compromised passwords. We cover that next.

Compromised Password Screening (Mandatory)

Section 3.1.1.2 of SP 800-63B-4 requires verifiers to compare each prospective password against "a blocklist that contains known commonly used, expected, or compromised passwords," and states that "the entire password SHALL be subject to comparison, not substrings or words that might be contained therein." The check must occur:

• When a new password is created.
• When an existing password is changed.

The list should include, at minimum:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Repetitive or sequential characters (aaaaaa, 1234abcd).
• Context-specific words (the service name, username, organization name, or derivatives).

Two practical implementations are available:

1. Have I Been Pwned's Pwned Passwords API. Offers a free, k-anonymity-based API that lets your authentication service check passwords against a continuously updated corpus of compromised password hashes without ever transmitting the full password. Check the site for the current corpus size, it grows with every new breach ingested.
2. Commercial breach intelligence feeds. Vendors like SpyCloud and Enzoic offer paid feeds with deeper context, real-time updates, and account takeover monitoring.

If a user-supplied password matches the compromised list, the verifier must reject it and explain why ("This password has appeared in a known data breach"). Do not just reject silently, the explanation educates the user.

NIST Password Reset Requirements

The NIST password guidelines on resets are blunt: do not force periodic resets without cause. Section 3.1.1.2 of SP 800-63B-4 states: "Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically." Revision 4 hardened this from the 2017 edition's SHOULD NOT into a SHALL NOT, so forced rotation is now a direct violation rather than a discouraged practice.

Forced resets are required only when one of the following occurs:

• Evidence of compromise of the specific account.
• A breach of the authenticator database.
• A confirmed phishing event affecting the user.

This rule is the single most counterintuitive change in modern NIST password guidelines, and it is the one that produces the most pushback in legacy security teams. The data is clear: forcing a reset every 90 days produces predictable patterns (Q1Password!, Q2Password!) that attackers recognize. A long, unique password rotated only on confirmed compromise is more secure than a moderately long password rotated on a calendar.

If your organization is required by an older policy or contract to enforce 90-day resets, the cleanest path is to negotiate a policy update referencing SP 800-63B and to compensate with continuous compromised credential monitoring.

Multi-Factor Authentication Under NIST 800-63B

The NIST password guidelines treat passwords as one factor among several. Revision 4 strengthens the multi-factor authentication requirements at every assurance level.

Authenticator Assurance Level 1 (AAL1). Single-factor allowed. Password alone is sufficient.

Authenticator Assurance Level 2 (AAL2). Two-factor required. Acceptable combinations include:

• Memorized secret + OTP from authenticator app.
• Memorized secret + push notification from registered device.
• Cryptographic key (FIDO2 security key, smart card).

SMS one-time codes are still permitted at AAL2 but explicitly described as "restricted." NIST recommends migrating away from SMS for any account containing personally identifiable information.

Authenticator Assurance Level 3 (AAL3). Hardware-based phishing-resistant MFA. SMS and OTP are not allowed. Acceptable combinations include:

• FIDO2 security key + memorized secret.
• Smart card with PIN.
• Passkey on bound device.

The 2024 NIST update places significant emphasis on phishing-resistant authenticators. FIDO2, WebAuthn, and platform passkeys (Apple, Google, Microsoft) all qualify. SMS, push approval without number matching, and OTP do not.

Account Lockout and Rate Limiting

NIST password guidelines require rate limiting and lockout to prevent brute-force attacks. Section 3.2.2 of SP 800-63B-4 (Rate Limiting and Throttling) requires verifiers to:

• Limit consecutive failed authentication attempts to no more than 100 attempts on a single account.
• Implement a delay (such as exponential back-off) after each failed attempt.
• Notify the user of failed attempts and lockout via an out-of-band channel when possible.

Many implementations choose 5 to 10 failed attempts before lockout, but NIST itself sets the upper bound at 100 to balance security against denial-of-service risk.

For an external citation on rate limiting best practices, see the OWASP Authentication Cheat Sheet, which complements NIST guidance with web-specific implementation patterns.

What NIST Says About Password Managers

NIST password guidelines encourage password managers and require systems to support them. Section 3.1.1.2 of SP 800-63B-4 is explicit: "Verifiers SHALL allow the use of password managers and autofill functionality," and verifiers "SHOULD permit claimants to use the 'paste' function when entering a password to facilitate password manager use when password autofill APIs are unavailable." Revision 4 raised password-manager and autofill support from advice to a SHALL, so breaking them is now a direct violation; blocking paste specifically remains a SHOULD-level failure.

NIST also recommends that organizations:

• Provide a password manager to employees as part of standard equipment.
• Train employees on the use of the password manager during onboarding.
• Treat the password manager itself as a high-value asset and apply elevated protections (FIDO2 master authenticator, hardware key, dedicated logging).

For startups, SMBs, and larger organizations following NIST guidelines, deploying 1Password, Bitwarden, or Dashlane to every employee is now considered baseline. Business-tier pricing for these tools is published on each vendor's own site and changes over time, so check current rates there rather than treating any figure quoted secondhand as current. The mechanism is straightforward: the manager remembers the passphrase, so the employee no longer needs a reset when they forget it, which is the most common driver of authentication help-desk volume.

Implementation Checklist for the NIST Password Guidelines

Use this checklist to bring your authentication policy into alignment with the current NIST password guidelines:

How NIST Password Guidelines Map to Other Frameworks

NIST 800-63B is referenced by name or substantively aligned with most major compliance frameworks. The mappings below help compliance teams reuse one set of password controls across multiple programs.

• SOC 2. The Common Criteria CC6.1 and CC6.6 cover logical access controls. NIST 800-63B is the most commonly cited supporting standard for SOC 2 password requirements. See our SOC 2 trust service criteria guide for context.
• ISO 27001. Annex A.5.17 (Authentication information) and A.8.5 (Secure authentication) align with NIST 800-63B requirements for password length, screening, and MFA.
• HIPAA. 45 CFR 164.308(a)(5)(ii)(D) requires "procedures for creating, changing, and safeguarding passwords." HHS guidance recommends NIST 800-63B as the implementation reference.
• PCI DSS 4.0. Requirement 8.3 covers strong cryptography for stored authentication credentials and 8.5 covers MFA. PCI DSS 4.0 effectively requires NIST-style password length and MFA on all administrative accounts.
• CMMC 2.0. Level 2 maps directly to NIST 800-171, which references NIST 800-63B for authentication.

For organizations pursuing multiple frameworks, building the password policy to NIST 800-63B is the most efficient path because it satisfies the strictest requirements of every other standard.

Frequently Asked Questions

Are the NIST password guidelines mandatory for private companies?

Not directly, but the NIST password guidelines are the de facto baseline. Most cyber insurance policies, vendor due diligence questionnaires, and downstream regulations (HIPAA, PCI DSS, SOC 2) reference NIST 800-63B explicitly or substantively. Private companies that do not follow NIST password guidelines struggle to defend their authentication policy at audit and at renewal. Our ISO 27001 Statement of Applicability guide shows how authentication controls flow into a formal compliance posture.

Do the NIST password guidelines still allow 8-character passwords?

Only inside multi-factor authentication. Under SP 800-63B-4 the 8-character floor applies solely to a password used as one factor alongside another; a password used on its own SHALL be at least 15 characters. If your identity provider enforces 8 characters for single-factor logins, that is a gap against the current standard, not a lenient-but-compliant setting.

Should we still require special characters in passwords?

No. Section 3.1.1.2 of SP 800-63B specifically tells verifiers to remove composition rules. Length and breach screening are more effective than special character requirements under modern NIST password guidelines.

What about password expiration for service accounts?

NIST password guidelines recommend rotating service account credentials only when there is evidence of compromise. For most organizations, this means moving service accounts to managed identities (AWS IAM roles, Azure managed identities, GCP service account impersonation) and eliminating long-lived static secrets entirely.

Is SMS-based MFA still allowed under NIST 800-63B?

SMS is permitted at AAL2 but explicitly described as "restricted." It is not allowed at AAL3. SP 800-63B-4 encourages migration away from SMS in favor of authenticator apps and FIDO2 keys for all sensitive accounts.

How often do the NIST password guidelines update?

SP 800-63 was published in 2017 and SP 800-63B-4 was finalized on 31 July 2025, after drafts in 2022 and 2024. Two releases is not enough to promise a fixed cadence, so rather than planning around a predicted revision date, watch the CSRC publication page for SP 800-63 and re-check your policy whenever a new revision reaches final.

Final Word on the NIST Password Guidelines

The NIST password guidelines represent the largest reset of password thinking in 25 years. They prioritize length, breach screening, and phishing-resistant MFA over the complexity-and-rotation rules that dominated security policy from the 1990s through the early 2010s. Organizations that align with the current NIST password guidelines typically see fewer help-desk password-reset tickets, fewer credential-based account takeovers, and cleaner audit findings on authentication, because the policy stops fighting the way people actually behave. Updating policy, identity provider configuration, and onboarding training is a scoped project, not a multi-year overhaul, and the benefit compounds for as long as the policy stays enforced.

Primary Sources

This article references the following authoritative sources:

• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, final 31 July 2025 (the primary source for every section number and quoted requirement in this article). Full text: pages.nist.gov/800-63-4/sp800-63b.html. This revision supersedes SP 800-63B (2020).
• NIST Cybersecurity Framework, NIST Cybersecurity Framework 2.0
• NIST SP 800-53, NIST SP 800-53 Rev 5
• NIST SP 800-207, NIST SP 800-207 Zero Trust Architecture

Last reviewed: 2026-09-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.