NIST Password Guidelines

The short version

Passwords used on their own must be at least 15 characters long. Services should accept long passwords and almost any character. They must not force you to mix uppercase, numbers and symbols, and they must not make you change your password on a schedule. Instead, they must check new passwords against a list of common and leaked ones, limit failed login attempts and store passwords safely ^[1].

Below, each rule is explained with the reason behind it, for both policy writers and everyday users.

What is NIST SP 800-63B?

NIST, the US National Institute of Standards and Technology, publishes the Digital Identity Guidelines, a set of documents numbered SP 800-63. Part B, SP 800-63B, covers authentication: how a system checks that you are who you say you are, with passwords, one-time codes, security keys and other authenticators (anything you use to prove your identity) ^[1].

The current version is Revision 4. NIST's overview page says the final version of SP 800-63 Revision 4 was released in July 2025 ^[2]; the online SP 800-63B document is dated 26 August 2025 ^[1]. It replaces the earlier SP 800-63B from 2017 (Revision 3) ^[1][3].

Who has to follow it

The document describes its own scope as the authentication of people "who interact with government information systems" ^[1]. In practice, that means US federal agencies and the service providers that authenticate users for them. The abstract also says the guidelines are not intended to constrain standards outside this purpose ^[1].

A private company or hobby website is not bound by SP 800-63B because of the document itself, but many use it as a reference. The OWASP Authentication Cheat Sheet, a widely used guide for web developers, cites it for its length, blocklist and rotation advice ^[5]. Treat it as a well-argued baseline, not a law for everyone.

SHALL, SHOULD and MAY

SHALL and SHALL NOT are requirements. SHOULD and SHOULD NOT are strong recommendations: you need a good reason to do otherwise. MAY means something is allowed. This guide keeps NIST's exact words, because the difference matters in a policy.

What changed in Revision 4

Revision 3 required subscriber-chosen passwords to be at least 8 characters ^[3]. Revision 4 requires 15 characters when the password is the only factor, and keeps 8 as the minimum when the password is part of multi-factor authentication ^[1]. NIST's change log lists this increase for section 3.1.1.2 ^[1].

Two rules also became stricter. In Revision 3, verifiers "SHOULD NOT" impose composition rules and "SHOULD NOT" require periodic password changes ^[3]. In Revision 4, both are "SHALL NOT" ^[1]. Password managers moved the same way: Revision 3 said verifiers SHOULD permit paste to help password managers ^[3], while Revision 4 says verifiers SHALL allow password managers and autofill ^[1]. Revision 4 also renames "memorized secrets" to simply "passwords" ^[1].

The NIST password rules, one by one

Rules below are from section 3.1.1.2 unless another section is named ^[1]. A verifier is the system that checks your password, usually the website or app.

Length: 15 characters, or 8 with MFA

Verifiers SHALL require passwords used as a single factor to be at least 15 characters long. If the password is only used together with another factor, such as a code from an authenticator app, it MAY be shorter, but it SHALL be at least 8 characters ^[1].

Why: NIST's informative Appendix A calls length "a primary factor" in password strength ^[1]. Every extra character multiplies the number of possible passwords an attacker must try. With a second factor, a guessed password alone is not enough to log in, so a lower minimum is acceptable. Our password generator starts at 16 random characters and goes up to 64, and you can see how one service's rules compare with the NIST baseline on our password requirements page.

Long passwords and any characters

Verifiers SHOULD permit a maximum length of at least 64 characters. They SHOULD accept all printing ASCII characters and the space, and they SHOULD accept Unicode characters, such as letters with accents or other scripts. Each Unicode code point (one encoded character) SHALL count as one character when checking length ^[1].

If Unicode is accepted, the verifier SHOULD apply NFC normalisation before hashing. Normalisation turns different encodings of the same visible character into one standard form. Example: "é" can be stored as one code point or as "e" plus an accent mark; NFC makes both the same, so your password still works from a different device ^[1].

Why: long limits and spaces make passphrases, several random words in a row, practical. Appendix A notes that a hashed password's size does not depend on its length, so there is no reason to forbid long passwords ^[1]. See What Is a Passphrase? or create one with the passphrase generator.

No composition rules

Verifiers SHALL NOT impose composition rules, for example requiring a mix of character types ^[1]. A composition rule is a rule like "at least one uppercase letter, one number and one symbol".

Why: Appendix A explains that people respond to these rules in predictable ways. Someone who wanted "password" will likely type "Password1", or "Password1!" if a symbol is required ^[1]. Attackers know these habits and try them early. NIST also notes that analyses of breached password databases show the benefit of such rules is smaller than expected, while the cost to usability and memory is high ^[1].

A blocklist of common and compromised passwords

When someone sets or changes a password, the verifier SHALL compare it against a blocklist of "commonly used, expected, or compromised passwords". The whole password SHALL be compared, not words or substrings inside it ^[1]. Examples NIST gives for the list: passwords from previous breaches, dictionary words, and context-specific words such as the service name or the username ^[1].

If a password is on the list, the service SHALL ask for a different one and SHALL explain why it was rejected. Verifiers SHALL also offer guidance to help users choose a strong password ^[1].

Why: attackers try the most likely passwords first, so blocking them removes easy wins. NIST says excessively large lists add little security, because their job is to stop common guesses in online attacks, which rate limiting already slows down ^[1]. You can see this idea at work in our password strength checker, which flags common passwords and patterns in your browser.

No hints and no security questions

Verifiers SHALL NOT let users store a password hint that people who are not logged in can see. They SHALL NOT prompt users to use knowledge-based authentication or security questions, such as "What was the name of your first pet?", when choosing passwords ^[1].

Why: hints and personal answers are often easy to guess or find online.

Password managers, autofill and paste

Verifiers SHALL allow password managers and autofill. They SHOULD permit paste, so password managers still work when autofill is not available ^[1]. NIST adds that password managers have been shown to make stronger passwords more likely, particularly when they include a generator ^[1].

Verifiers SHOULD also offer an option to show the password while it is typed, instead of dots, so users can check for mistakes ^[1]. Our guide Are Password Managers Safe? looks at the trade-offs.

Check the whole password

Verifiers SHALL ask for the full password, not a subset of characters, and SHALL verify the entire password, for example without truncating it ^[1]. Truncation means silently cutting a password after a certain length, so that only the first part matters.

Verifiers MAY allow for small typing mistakes, such as removing leading and trailing spaces or ignoring the case of the first letter, but only if the password still meets the minimum length and is not made much weaker ^[1].

Limit failed login attempts

Verifiers SHALL implement rate limiting, a limit on how many failed logins are possible ^[1]. Section 3.2.2 sets the upper bound: no more than 100 consecutive failed attempts on one account, after which that authenticator is disabled. Agencies MAY set lower limits ^[1].

To avoid locking out real users, NIST lists optional techniques: a bot-detection challenge, waiting periods that grow as failures add up (for example 30 seconds up to an hour), and risk-based checks such as IP address or location ^[1]. After a successful login, previous failed attempts SHOULD be disregarded ^[1].

Why: an attacker limited to a few guesses cannot work through a large list.

Store passwords salted and hashed

Verifiers SHALL store passwords in a form that resists offline attacks: salted and hashed with a suitable password hashing scheme. The salt SHALL be at least 32 bits, and both salt and hash SHALL be stored. The cost factor, which controls how slow each hash is, SHOULD be as high as practical and SHOULD be increased over time. Verifiers SHOULD also add a keyed hashing or encryption step with a secret key stored separately from the hashes ^[1].

Why: if the password database is stolen, attackers can guess offline without any rate limit. Slow, salted hashing makes each guess more expensive. The details are in How Passwords Should Be Stored.

Should passwords be changed regularly? (password rotation)

No. Password rotation, also called password expiration, means forcing users to change their password on a schedule, for example every 90 days. SP 800-63B Revision 4 says verifiers SHALL NOT require periodic password changes. The same rule says verifiers SHALL force a change if there is evidence that the password has been compromised ^[1].

Why does rotation not help? NIST's FAQ, written for Revision 3, explains the reasoning. People who know their password will expire soon tend to choose weaker ones. When forced to change, many make a small, predictable edit to the old password, such as increasing a number at the end. Attackers can apply the same edits, so rotation gives a false sense of security ^[4].

What should trigger a change instead? Evidence of compromise. The FAQ gives examples: a breach of the service's password database or observed fraudulent activity ^[4]. If a password appears in a known breach, or someone notices logins they did not make, change it then. Our guide What Is a Data Breach? explains how leaked passwords end up being used against other accounts.

OWASP gives developers the same advice: avoid periodic password changes, rotate credentials when a leak occurs, and encourage strong passwords and MFA instead ^[5]. Section 8 of SP 800-63B puts it simply: do not require changes unless the user asks for one or there is evidence of compromise ^[1].

Password policy best practices: a checklist

A password policy is the set of rules an organisation or app uses for creating, checking and storing passwords. The checklist below maps a good policy to the NIST wording, so you know which points are requirements and which are recommendations ^[1].

Every row is a yes/no question to ask about your system:

OWASP adds two practical points: use generic error messages on login and recovery pages, so attackers cannot learn which accounts exist, and consider a strength meter for user feedback ^[5].

What NIST's rules mean for you as a user

NIST writes for people who build login systems, but the logic carries over. This section is our interpretation, not a NIST requirement.

Length beats tricks. A long passphrase of random words, or a random password of 15 or more characters, does more than swapping letters for symbols. Make every password unique, so a leak on one site does not open your other accounts; SP 800-63B's usability section points out that distinct passwords protect against attacks that reuse stolen credentials ^[1].

A password manager makes this practical. Turn on multi-factor authentication where you can; NIST lowers the minimum length only because a second factor adds protection. What Is Two-Factor Authentication? compares the options.

You do not need to change good passwords on a schedule; change them after a breach notice, suspicious activity or known reuse.

Common myths about NIST password guidelines

"NIST says passwords must contain symbols." It does the opposite. Revision 4 says verifiers SHALL NOT impose composition rules ^[1].

"NIST says change passwords every 90 days." Revision 4 forbids required periodic changes and requires a change only when there is evidence of compromise ^[1].

"Eight characters is the NIST minimum." That is only true for passwords used as part of multi-factor authentication. On their own, passwords need at least 15 characters ^[1].

"Blocking paste makes logins safer." Revision 4 requires verifiers to allow password managers and autofill and recommends allowing paste ^[1].