NIST Password Guidelines

Most business password policies in use today were written before 2017 — the year the National Institute of Standards and Technology (NIST) rewrote its digital identity guidelines and reversed decades of conventional password advice. If your policy still requires special characters, forced 90-day resets, and a mix of uppercase, lowercase, and numbers, it's not following NIST guidance. It's following the guidance NIST replaced.

This article explains what NIST SP 800-63B, the Digital Identity Guidelines document governing "memorized secrets" (its term for passwords), actually recommends, why the agency changed course, and how to apply the current guidance to a real business policy.

What NIST SP 800-63B covers

NIST SP 800-63B is one part of the broader SP 800-63 Digital Identity Guidelines series published by NIST's Computer Security Resource Center. Section 5.1.1 of the document addresses "Memorized Secrets" — the formal name for passwords and PINs — and sets requirements for two roles: the party issuing and verifying the credential, and the length/composition rules that credential should follow.

SP 800-63B is written for federal information systems, but it has become the de facto reference for private-sector password policy because it's the most rigorously reasoned, publicly available guidance on the subject. Auditors, cyber insurers, and compliance frameworks (including HIPAA and PCI DSS assessors, informally) frequently point to it as the current standard of care, even where it isn't a direct legal requirement.

The core recommendations

Length over complexity

The single biggest shift in NIST's guidance is the move away from composition rules — requirements like "must contain one uppercase letter, one number, and one symbol" — toward length as the primary driver of password strength. NIST SP 800-63B §5.1.1.2 requires verifiers to accept user-chosen passwords of at least 8 characters and to support a minimum of 64 characters, without mandating a specific mix of character types.

The reasoning is well established in the security research NIST cites: composition rules push users toward predictable patterns (Password1!, Summer2024!) that satisfy the rule without meaningfully increasing guessing resistance, while making passwords harder for people to remember. A longer passphrase without forced complexity is both easier to recall and harder to crack. See Understanding Password Entropy for the underlying math.

No more forced periodic rotation

NIST SP 800-63B §5.1.1.2 states that verifiers "SHOULD NOT" require users to change memorized secrets periodically, except when there is evidence of compromise. This reverses guidance NIST itself published in earlier revisions.

The reasoning: forced rotation measurably degrades security in practice. Studies of real rotation policies (cited in NIST's supporting research and widely replicated since) found that users asked to change a password on a fixed schedule overwhelmingly make small, predictable modifications to their existing password — incrementing a number, swapping a symbol — rather than choosing something genuinely new. Attackers who obtain an old password can often predict the pattern of the new one. Rotation without a specific reason to believe a credential is compromised creates the appearance of security without the substance of it.

Screen against known-breached passwords

NIST SP 800-63B §5.1.1.2 requires verifiers to check chosen passwords against a list of values known to be compromised in prior breaches, commonly used, or otherwise predictable (dictionary words, repetitive or sequential characters like aaaaaa or 1234abcd, and context-specific words such as the service name or the username). A password that appears on such a list must be rejected, with guidance to the user on why.

This is arguably the most operationally important — and most commonly skipped — requirement in the entire document, because it directly defends against credential-stuffing attacks, where attackers try passwords leaked from one breach against other services. Length and complexity don't help if the exact password is already sitting in a public breach corpus.

In NIST's own document language, this requirement is written as a "SHALL" — mandatory — rather than a "SHOULD" — recommended. That distinction matters for auditors: SP 800-63B deliberately separates hard requirements (SHALL) from best-practice recommendations (SHOULD), and breach screening is one of the few memorized-secret provisions written as mandatory. A practical, low-cost way to implement it is Have I Been Pwned's Pwned Passwords API, which uses k-anonymity (the client sends only a partial hash prefix, never the actual password) so the check can be performed without exposing the candidate password to a third party. NIST's guidance also expects verifiers to implement rate-limiting or throttling on authentication attempts (§5.2.2) as a complementary control — breach screening stops known-bad passwords at creation time, while throttling limits how fast an attacker can guess at sign-in time.

Support the full character set, including paste

Verifiers must accept all printable ASCII characters and should accept Unicode, including spaces, without imposing truncation. NIST also explicitly recommends allowing "paste" functionality into password fields, since blocking it discourages the use of password managers — the opposite of what a business password policy should be encouraging. See the Password Manager Guide for deployment guidance.

What this means for a business password policy

Translating SP 800-63B into an actual organizational policy involves a few concrete decisions:

1. Set a minimum length of at least 12 characters for user accounts, higher than NIST's federal 8-character floor. NIST's 8-character minimum is a floor for federal systems with additional compensating controls (like mandatory MFA); most businesses get meaningfully more protection, with no added user burden, by requiring a longer minimum instead of mandatory complexity.
2. Remove mandatory character-composition rules where your identity platform allows it. Microsoft Entra ID, Google Workspace, and most modern identity providers support length-based policies without forced symbol/number requirements.
3. Turn off calendar-based forced password resets unless a specific regulatory requirement mandates it (some frameworks still require periodic rotation regardless of NIST's current position — verify against your specific compliance obligations before removing this control; see HIPAA Password Guidance and PCI DSS Password Guidance).
4. Enable breached-password screening. Microsoft Entra Password Protection, Have I Been Pwned's API, and similar services make this practical to implement even for small organizations.
5. Pair length-based policy with mandatory multi-factor authentication. NIST's own framing is that these recommendations assume MFA is protecting the account — password strength alone is not treated as sufficient for anything beyond the lowest assurance level.
6. Deploy and enforce use of a password manager, since removing composition rules only pays off if users are actually choosing long, unique passwords rather than reusing a memorable short one everywhere.

Common mistakes when adopting NIST guidance

• Removing rotation without adding breach screening. These two changes are meant to work together — rotation was partly a (weak) hedge against undetected compromise. Removing it without adding breach monitoring or screening leaves that gap open.
• Treating "8 characters" as the actual target. NIST's 8-character floor is a minimum for federally assured systems with other controls in place, not a recommended target. Most business policies should set the practical minimum meaningfully higher.
• Leaving composition rules in place "just in case." Composition rules that survive a length-based policy update tend to reintroduce the exact predictable-pattern problem NIST's guidance was written to eliminate.
• Assuming NIST guidance is a compliance safe harbor. SP 800-63B informs the standard of care but doesn't override specific requirements in frameworks like PCI DSS, which as of certain versions still reference periodic rotation directly. Always check the specific framework in scope.

FAQ

Is NIST SP 800-63B legally required for private businesses? No. It's a federal guidance document. It has become the reference standard of care that auditors and cyber insurers commonly expect, but it isn't itself a law or regulation.

Does NIST guidance apply to service accounts and system passwords the same way? SP 800-63B is written primarily with human-memorized secrets in mind. System-generated or machine-to-machine credentials should generally be longer, fully random, and managed through a secrets manager rather than memorized — the length-over-complexity principle still applies, but the practical mechanism differs.

If we stop forcing password rotation, are we less secure? Not if breached-password screening and MFA are in place. The research NIST relied on found that forced rotation without those complementary controls produced weaker real-world security than a longer, unrotated password combined with screening and MFA.

Where can I read the source document? NIST publishes SP 800-63B directly at the NIST Computer Security Resource Center (csrc.nist.gov). This article summarizes and interprets Section 5.1.1's memorized-secret requirements for a business audience; always verify current wording directly against the published NIST document, since guidance is periodically revised.

Related reading

• Passphrase vs. Password
• Understanding Password Entropy
• Password Manager Guide
• Building a Password Policy Template
• Password Generator — generate NIST-aligned passwords and passphrases directly
• Password Policy Generator — produce a ready-to-adopt policy document aligned with this guidance
• Download: Password Security Checklist
• Download: Password Security Awareness Guide