NIST Password Guidelines

What NIST SP 800-63B applies to

SP 800-63B defines technical requirements and recommendations for digital identity authentication. It is written for credential service providers and verifiers, not as a universal consumer password recipe. A service may have stricter requirements based on law, risk or compatibility.

Minimum and maximum password length

A password used as a single authentication factor must be at least 15 characters. When used as part of multi-factor authentication, it may be at least eight. Verifiers should permit a maximum length of at least 64 characters and process the full accepted value.

Users can choose longer generated values when the service permits them.

No mandatory composition rules

Verifiers should not require mixtures of upper case, lower case, numbers and symbols as a general rule. Such policies often create predictable patterns. Services should still accept a broad range of characters, and generated passwords may use mixed groups voluntarily or to meet another service policy.

Block common and compromised values

When a user creates or changes a password, the verifier should compare the complete value against a blocklist of commonly used, expected or compromised passwords. Context-specific words such as the service name and username may also belong on the list.

A rejection should explain the reason and ask for another value rather than impose arbitrary transformations.

Do not force periodic password changes

Verifiers should not require regular changes unless there is evidence the authenticator has been compromised. Forced rotation encourages minor variations and insecure recording. Change defaults, temporary values, disclosed credentials and passwords affected by an incident.

Allow paste and password managers

Verifiers should allow password managers and autofill, and should permit paste into password fields. Blocking paste encourages weaker manually typed credentials and interferes with accessible workflows.

Rate limiting and secure verifier storage

Online attempts need rate limiting. Stored passwords must be salted and hashed with a suitable password hashing scheme and cost. The exact storage guidance is for service operators, while users can only assess the evidence a provider publishes.

OWASP recommends modern password-hashing choices and parameters that should be reviewed over time.

Unicode, spaces and normalization

NIST permits spaces and Unicode and describes normalization expectations. Real services vary, and keyboard or device differences can make some characters difficult to reproduce. A generated ASCII password is often a practical compatibility choice even when Unicode is accepted.

Practical user checklist based on the guidance

• Use a long unique value, preferably generated.
• Store it in a password manager and paste or autofill it.
• Do not rely on composition tricks.
• Change it after compromise rather than on an arbitrary calendar.
• Enable MFA or a passkey.
• Follow the actual service rules where they differ.

Common claims NIST does not support

NIST does not require users to change passwords every 30, 60 or 90 days without compromise evidence. It does not require a mandatory mixture of character classes. It does not say a password manager should be blocked, and it does not recommend preventing paste.

Policies attributed to NIST should identify the publication and revision, because older summaries remain widely copied after the underlying guidance changes.

What service operators should implement together

Length acceptance alone is incomplete. The verifier also needs a blocklist, protected transport, rate limiting, secure salted password hashing, safe recovery, session security and event monitoring. MFA requirements depend on the assurance level and authenticator combination.

Usability is a security control: allow managers and autofill, provide clear rejection messages and avoid rules that push users toward predictable workarounds.

Password blocklists in practice

A useful blocklist contains common passwords, values exposed in breaches and context-specific terms likely to be guessed. The comparison is made when a password is created or changed. It should not disclose whether another user chose the same value, and it should not store plaintext passwords for routine checking.

Blocklists are not a reason to require endless special-character mutations. Give a clear rejection message and allow the user or manager to generate an unrelated value.

Authentication assurance and MFA context

The allowed password minimum differs when the password is the sole factor versus part of multi-factor authentication. This does not make an eight-character password a good general target. It reflects the combined authenticator requirements within an assurance model.

Implementers should read the complete normative text, definitions and authenticator requirements rather than copying an isolated number into a consumer policy.

Accessibility and usability requirements

Allow paste, autofill and password managers. Provide show-password controls with appropriate privacy behavior and clear validation errors. Permit long input and avoid silently truncating values. These choices help users create and enter strong credentials instead of weakening them for the interface.