NIST passphrase requirements: Spaces, length, blocklists

NIST passphrase requirements are the password requirements of NIST SP 800-63B-4, because the standard has no separate rules for phrases. A passphrase used as the only authentication factor needs at least 15 characters. Whether passphrases actually work depends on the verifier, NIST's term for the system that checks a password at sign-in: your directory, IdP, VPN or an application's own login code. The verifier has to accept spaces, check the full length without truncation, handle Unicode and compare the whole phrase against a blocklist.

SP 800-63B-4 has been final since July 2025 and is the revision in force in 2026. This guide covers only the rules that affect multi-word secrets, shows where two widely deployed directories part ways with the standard and ends with the passphrase-ready verifier test, eight checks you can run against any system that checks passwords. For every other password rule, see our SP 800-63B-4 requirement map.

Key takeaways

NIST defines a passphrase as a kind of password, so the same verifier rules apply to both (Sec. 3.1.1).
A passphrase needs at least 15 characters as the only factor and at least 8 when it is one factor in multi-factor authentication (Sec. 3.1.1.2).
Accepting spaces, Unicode and 64 or more characters is recommended, while verifying the entire passphrase without truncation is mandatory.
The blocklist compares the whole phrase, not the words inside it, and only needs entries at least as long as your minimum.
Active Directory and Microsoft Entra ID both ship defaults that conflict with SP 800-63B-4, so test the verifier rather than trusting the policy screen.

Does NIST have separate passphrase requirements?

No. SP 800-63B-4, Sec. 3.1.1 defines a password as a secret "sometimes referred to as a passphrase or, if numeric, a personal identification number". Every verifier rule in Sec. 3.1.1.2 therefore applies to passphrases unchanged. Appendix A confirms that its own use of "password" includes passphrases and PINs.

Appendix A also names phrases as a tool. NIST writes that multi-word passphrases are often an effective way to create a longer password. That is advice on how users reach the length floor, and it adds no requirement of its own.

NIST passphrase requirements at a glance

SP 800-63B-4, Sec. 3.1.1.2 holds every rule that decides whether a passphrase survives enrollment and login. The length floors, code-point counting, full-length verification, whole-password blocklist screening and the ban on composition rules are mandatory. Accepting spaces, Unicode and at least 64 characters is only recommended, so a verifier can conform and still reject phrases.

That last point is the gap this article is about. The table lists each rule with its level in NIST SP 800-63B-4, Sec. 3.1.1.2, and what it means for a multi-word secret.

Rule	Level	What it means for a passphrase
Minimum 15 characters as the only factor; 8 inside MFA	SHALL	A four-word phrase usually clears 15 without effort
Request the full password and verify all of it	SHALL	No silent truncation of long phrases
Compare the entire password against a blocklist	SHALL	Famous phrases are rejected; dictionary words inside a phrase are not
Give the reason for rejection and guidance	SHALL	The user learns why a phrase failed
No other composition rules	SHALL NOT	No forced digit or capital letter in a phrase
Allow password managers and autofill; permit paste	SHALL / SHOULD	Long secrets can be filled in instead of typed
Accept Unicode; count each code point as one character	SHOULD / SHALL	Non-English phrases work, and length is measured consistently
Maximum length of at least 64 characters	SHOULD	Long phrases need room; a 20- or 32-character cap breaks them
Accept printing ASCII and the space character	SHOULD	Spaces are the separator most phrases rely on
Apply NFC normalization before hashing	SHOULD	The same accented phrase verifies on every device
Offer an option to show the password while typing	SHOULD	Typos in long phrases become visible
Trim leading/trailing whitespace, tolerate case of first letter	MAY, with conditions	Allowed only if the result still meets the minimum length

Spaces: what the verifier has to do

SP 800-63B-4 says verifiers should accept the space character, and Appendix A gives the reason: users should be able to include spaces so they can use phrases. Spaces are the one character most passphrases depend on. They are also the character login forms most often strip, trim or reject without telling the user.

The standard gives three rules for whitespace:

Accept the space. Sec. 3.1.1.2 lists the space character alongside printing ASCII as characters verifiers should accept.
Trim only within limits. Verifiers may remove leading and trailing whitespace, but only if the result still meets the minimum length and complexity is not significantly reduced. A 15-character entry that becomes 14 after trimming has to fail the length check.
Treat repeated spaces as noise. Appendix A notes that repeated spaces add little strength and that removing them may help if the first verification attempt fails.

The failure NIST doesn't describe is inconsistency. If enrollment keeps a double space and login collapses it, or the reverse, the user can never match their own phrase. Pick one behavior, apply it at both enrollment and login, and write it down.

Do	Don't
Accept spaces anywhere in the phrase	Reject or silently strip internal spaces
Trim leading/trailing spaces only after checking the minimum length	Trim first and let a 14-character result through
Apply the same whitespace handling at enrollment and login	Normalize at login but store the raw value
Retry once with repeated spaces collapsed, if you choose to	Block spaces or quotes "for SQL injection"

The last row deserves one sentence. Appendix A states that character filters meant to stop SQL injection are unnecessary, because an unhashed password is never sent intact to a database.

Length: 15 characters, 64 and no truncation

A passphrase used as the only authentication factor must be at least 15 characters, and one used only inside multi-factor authentication at least 8 (Sec. 3.1.1.2). Verifiers should allow at least 64 characters and must verify the entire submitted password. Truncation is the length failure that does the most damage to passphrases, because users never see it.

Floors

NIST allows the 8-character floor on MFA paths, but one floor of 15 for every path keeps policy and user guidance to a single number. That is a policy choice, and a reasonable one.

Maximum

Appendix A says there is no reason to prohibit long passphrases, since a hash has the same size whatever the input length. It accepts that some upper limit is reasonable to keep hashing cost in check. At least 64 characters is the SHOULD, so a form field capped at 20 or 32 characters falls short of it.

Truncation

A verifier that stores or compares only the first N characters turns a 40-character phrase into a 20-character secret, with no error anywhere. Sec. 3.1.1.2 requires the verifier to request the password in full and verify all of it. To check for truncation on a test account:

Set a 40-character passphrase.
Sign in with only its first 20 characters.
If the sign-in succeeds, the system truncates, and the effective secret is half what the user thinks it is.

Unicode

If you accept Unicode, each code point counts as one character when you measure length (SHALL). The letter "é" can be stored as one code point or as "e" plus a combining accent, so the same phrase typed on two devices can produce two different byte strings. NFC normalization before hashing (SHOULD) removes that mismatch. NIST also says users should be warned that some endpoints represent certain characters differently.

Where directories diverge from SP 800-63B-4

Two widely deployed directories ship password policies that collide with SP 800-63B-4 on length or composition. Active Directory caps the classic minimum-length setting at 14 characters unless a separate policy is enabled. Microsoft Entra ID fixes the minimum for cloud-only accounts at 8 and requires three of four character categories.

The table reflects Microsoft's documentation as published in 2026: the minimum password length enforcement article and the Entra ID combined password policy.

Directory and setting	Documented behavior	SP 800-63B-4 rule affected
AD: MinimumPasswordLength	0–14 unless RelaxMinimumPasswordLengthLimits is enabled, then up to 128; enforcement above 14 needs every DC on Windows Server, version 2004 or later	15-character floor for single-factor use
AD: minimum above 14 without the relax setting	The domain enforces 14 and logs Event ID 16979	Same: a policy that reads 15 enforces 14
Entra ID cloud-only: length	Minimum 8, maximum 256, not configurable	15-character floor for single-factor use
Entra ID cloud-only: complexity	Three of four categories: uppercase, lowercase, numbers, symbols	Composition rules SHALL NOT be imposed
Entra ID cloud-only: character set	Unicode not allowed (with exceptions for some External ID tenants)	Unicode SHOULD be accepted

Active Directory

Microsoft's own sequence is audit first. Set MinimumPasswordLengthAudit to your target, then watch Event ID 16978 for three to six months to find software that still sets shorter passwords. Once those are fixed, enable RelaxMinimumPasswordLengthLimits and raise MinimumPasswordLength on all DCs. Fine-grained password policies cover accounts that can't move yet.

Entra ID

For accounts synchronized from on-premises AD, the on-premises policy governs length and complexity, so the AD path above is your lever. Cloud-only accounts offer no length setting. Only the banned password list and smart lockout are configurable.

The blank space appears in Microsoft's list of allowed symbols. Whether an all-lowercase phrase with spaces clears the three-of-four check is not spelled out in the documentation, so test it in your tenant before you tell users that any 15-character phrase will work.

The broader point holds for every system on your list: the obligations in Sec. 3.1.1.2 sit with whoever verifies the password. That means your directory, your IdP, your VPN and every application that runs its own login form each need their own check.

Blocklists for passphrases

When a passphrase is set or changed, SP 800-63B-4 requires the verifier to compare the entire password against a blocklist of commonly used, expected or compromised values. The comparison covers the whole string, not substrings or words inside it. A phrase built from dictionary words passes unless the full phrase is on the list.

Appendix A adds a detail that changes how you build the list for passphrases: the blocklist only needs entries that meet your minimum length. At a 15-character floor, most of a classic breach corpus is made of short passwords that can never match a valid entry. Those entries cost lookup time and buy nothing.

What belongs on a phrase-length blocklist:

well-known quotations, song and film lines, book openings and proverbs that run past your minimum
example passphrases printed in security guides, comics and training slides, which users copy word for word
context-specific values that Sec. 3.1.1.2 names directly: the service name, the username and derivatives of them, plus your company and product names
long passwords from breach corpuses that meet your floor

Size has a ceiling. NIST states that excessively large blocklists bring little extra security, because the list defends against online guessing that rate limiting already caps at 100 consecutive failures (Sec. 3.2.2). Appendix A adds that an oversized list frustrates users trying to pick something memorable. The target is a list big enough to stop phrases an attacker would try before reaching the attempt limit.

When a phrase is rejected, the verifier must say why and offer guidance on choosing a strong one. That guidance does most of its work right after a rejection, when the user's instinct is to append "1" to the phrase that just failed.

Six misreadings of NIST passphrase requirements

Most errors about NIST and passphrases come from summaries that blur SHALL and SHOULD or carry over numbers from Rev 3. The six below appear in ranking articles and in policy templates. Each row gives what SP 800-63B-4 actually states and the section to point to when someone pushes back.

Misreading	What SP 800-63B-4 says	Section
"NIST requires passphrases"	It recommends multi-word phrases as an effective way to reach length; it does not require them	Appendix A
"Verifiers must accept spaces"	Accepting the space character is a SHOULD	3.1.1.2
"A phrase made of dictionary words fails the blocklist"	Only the entire password is compared, not the words inside it	3.1.1.2
"Trimming spaces violates NIST"	Trimming leading and trailing whitespace is a MAY, if the minimum length still holds	3.1.1.2
"NIST sets a minimum number of words"	Length is counted in characters, one per Unicode code point	3.1.1.2
"The 15-character rule covers device PINs"	Local unlock secrets are activation secrets with a 4-character minimum	3.2.10

A seventh claim shows up in older articles that still rank: that NIST wants passphrases to mix character types. Sec. 3.1.1.2 says the opposite. Verifiers shall not impose composition rules.

The passphrase-ready verifier test

The passphrase-ready verifier test is eight checks that show whether a system accepts, stores and verifies passphrases the way SP 800-63B-4 expects. Run it against each verifier separately: directory, IdP, VPN, and every customer-facing or internal application with its own login. A policy screen that says 15 proves nothing until the test passes.

#	Test	Pass condition	Rule
1	Set a 15-character, all-lowercase phrase with spaces	Accepted	No composition rules; spaces SHOULD be accepted
2	Set a 64-character phrase	Accepted and verifies at login	Maximum of at least 64 SHOULD be permitted
3	Sign in with the first half of a 40-character phrase	Rejected	Entire password SHALL be verified
4	Sign in with a double space where the phrase has one	Matches your documented behavior	Appendix A, repeated spaces
5	Add a trailing space to a 15-character phrase at enrollment	Trimmed result still at or above the minimum, or rejected	Trimming MAY, with conditions
6	Set an accented phrase on one device, sign in from another	Verifies	NFC normalization SHOULD be applied
7	Set a phrase from your blocklist	Rejected with a reason and guidance	Whole-password blocklist SHALL
8	Fill the phrase from a password manager and by paste	Both work	Managers and autofill SHALL; paste SHOULD

Log every failure as an exception with the system, the failed test, an owner and a review date. Some failures are vendor limits you can't fix this quarter, and the register shows an auditor that you know where they are.

Where a password manager fits

SP 800-63B-4 requires verifiers to allow password managers and autofill, and NIST notes that managers with built-in generators make stronger passwords more likely. A password manager covers the credentials no directory policy reaches: vendor portals, SaaS admin accounts and shared logins. It leaves untouched how your directory or IdP verifies passwords.

Most of those credentials are never typed by a person, so they don't need to be phrases at all. A long random value from a generator is the better fit. Passphrases belong where a human types from memory: the directory sign-in, a device unlock and the master password of the vault itself.

Passwork supports that split:

A built-in password generator in the web interface, browser extension and mobile and desktop apps applies organization-defined rules to new credentials.
The free passphrase generator produces word-based phrases for the secrets people need to remember.
Administrators can set requirements for master passwords. The master password derives the user's encryption keys on the device and never reaches the server, which puts it closer to NIST's local verification than to a central login, so its length policy is your decision to make.
The security dashboard reports strength (based on length and character diversity), flags passwords unchanged for 180 days or more and shows credentials still accessible to users whose access was revoked. The age flag is a review signal.

Conclusion

Meeting NIST passphrase requirements takes less policy than most teams expect and more testing. The standard asks for one length floor, open character sets and a whole-phrase blocklist. The work is in finding the verifier that truncates, the form that strips spaces and the directory setting that quietly enforces 14.

Start with three moves. Run the passphrase-ready verifier test on every system that checks passwords. Fix length caps and truncation before you announce a 15-character policy. Rebuild the blocklist around phrases at least as long as your minimum.

Frequently Asked Questions

Does NIST have separate passphrase requirements?

No. SP 800-63B-4, Sec. 3.1.1 defines a password as a secret sometimes referred to as a passphrase, so every verifier rule in Sec. 3.1.1.2 applies to phrases unchanged. Appendix A adds that multi-word passphrases are often an effective way to create a longer password, which is advice rather than a requirement.

What is the minimum passphrase length under NIST?

A passphrase needs at least 15 characters when it is the only authentication factor and at least 8 when it is one factor in multi-factor authentication (Sec. 3.1.1.2). NIST counts each Unicode code point as one character and sets no word count. Verifiers should also accept at least 64 characters.

Do systems have to accept spaces in passphrases?

NIST says verifiers should accept the space character, which makes it a recommendation, not a mandatory rule (Sec. 3.1.1.2). Appendix A explains the intent: users should be able to include spaces so they can use phrases. A verifier that rejects spaces can still conform on paper while breaking most passphrases in practice.

Can a verifier trim spaces from a passphrase?

Yes, within limits. Sec. 3.1.1.2 allows removing leading and trailing whitespace only if the result still meets the minimum length and complexity is not significantly reduced. Appendix A adds that collapsing repeated spaces may help after a failed first attempt. Apply the same handling at enrollment and at login.

Will a passphrase made of dictionary words fail the NIST blocklist check?

Not for containing them. Sec. 3.1.1.2 requires comparing the entire password against the blocklist, not substrings or words inside it. A phrase is rejected only when the full phrase is on the list, for example a famous quotation, a published example passphrase or the service name combined with the username.

Does the 15-character rule apply to device PINs?

No. A secret used locally to unlock a device or a multi-factor authenticator is an activation secret under Sec. 3.2.10. It needs at least 4 characters, with 6 recommended, and no more than 10 consecutive failed attempts. The 15-character floor applies to passwords sent to a central verifier.