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 and the 2024 update SP 800-63-4, 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. The 2024 update (SP 800-63-4) 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

NIST 800-63B sets length requirements based on who chose the password.

User-chosen passwords:

• 8 characters minimum (absolute floor).
• 15 characters strongly recommended.
• Allow up to at least 64 characters in length.
• Allow all printable ASCII characters, Unicode characters (U+0020 to U+10FFFF), and spaces.

Randomly generated passwords (passphrases produced by a system):

• 6 characters minimum if generated with full ASCII alphabet using a strong random source.
• For 8-bit (one byte) random passwords: 5 characters minimum.

The 15-character recommendation is new in the 2024 update. The earlier 2017 version recommended 8 as the minimum and 64 as the maximum. The shift to 15 is a direct response to GPU-accelerated cracking benchmarks: an 8-character random ASCII password can now be brute-forced offline in days, while a 15-character random ASCII password takes thousands of years on the same hardware.

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 section 3.1.1.2 of SP 800-63B: "Users respond in very predictable ways to the requirements imposed by composition rules. The result is passwords that contain only the minimum amount of additional complexity required to meet the rule." 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 requires verifiers to check user-chosen passwords against a list of values known to be compromised. 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 API. Offers a free, k-anonymity-based API that lets your authentication service check passwords against more than 1 billion known compromised hashes without ever transmitting the full password.
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 5.1.1.2 of SP 800-63B states "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."

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. The 2024 update 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 5.2.2 of SP 800-63B 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 5.1.1.2 explicitly tells verifiers to "permit claimants to use 'paste' functionality when entering a memorized secret." Blocking paste, blocking autofill, or breaking password manager extensions all violate the guideline.

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. The cost is recovered through reduced help-desk tickets for password resets within the first quarter of deployment, and a small business can cover its full team for less than $5 per user per month.

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?

Yes, 8 characters is the absolute floor for user-chosen passwords under the NIST password guidelines. The 2024 update strongly recommends 15 characters as the new minimum. Anything below 15 characters should be flagged for review during your next policy refresh.

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. The 2024 update of the NIST password guidelines 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?

NIST issues major updates to the NIST password guidelines roughly every five to seven years. SP 800-63 was published in 2017, and SP 800-63-4 was finalized in mid-2024. Expect minor revisions in between as new attack patterns emerge.

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 see help-desk reset volumes drop, account takeover incidents fall, and audit findings on authentication shrink to near zero. The work to update policy, identity provider configuration, and onboarding training is one quarter at most. The benefit compounds for years.