Check Your Password Against the New NIST Rules

Check Your Password Against NIST SP 800-63-4

Check your own password above against the federal publication that most enterprise, government, and increasingly consumer services build their rules from: NIST Special Publication 800-63-4, whose current revision breaks sharply from decades of composition-rule orthodoxy. Verifiers SHALL require at least eight characters for passwords used inside multi-factor authentication, and SHALL require at least fifteen characters for passwords carrying authentication alone as a single factor. Composition mandates, forcing a mix of uppercase, lowercase, digits, and symbols, are explicitly prohibited, and periodic forced rotation is prohibited too, unless there is specific evidence of compromise. In their place, NIST requires screening new passwords against a blocklist of known breached and commonly used credentials, and this page walks through what changed, why the guidance shifted this direction, and how it applies to whatever you just checked above.

The length requirements, word for word

NIST SP 800-63-4 Section 3.1.1.2 states it plainly: 'Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length,' while passwords used only as part of multi-factor authentication may be shorter but SHALL still reach a minimum of eight characters.¹ On the other end, verifiers SHOULD permit a maximum length of at least 64 characters, removing the artificially low caps some older systems still enforce.²

What else the standard says about maximum length

NIST also recommends that verifiers SHOULD allow passwords as long as 64 characters or more, explicitly rejecting the artificially low caps older systems impose. The standard further says verifiers SHOULD accept all printing ASCII characters and the space character, and SHOULD accept Unicode characters as well, counting each Unicode code point as a single character when evaluating length.² The goal is practical flexibility rather than pedantry: if a password manager generates a thirty-character passphrase, the backend should not silently truncate it.

That fifteen-character figure is not arbitrary. At the full 95-character printable ASCII pool, fifteen characters yields roughly 98.5 bits of entropy, comfortably clearing what current GPU-based cracking can reach within any realistic timeframe against a properly hashed password.³ Because the eight-character multi-factor floor and the fifteen-character single-factor floor apply to different threat models, a system that already enforces a second factor is not obligated to also push every user toward the longer figure, though doing so still adds a meaningful safety margin.

Why composition rules got dropped

For years, policies forced you to include an uppercase letter, a digit, and a symbol, on the theory that mixed character classes meant unpredictable passwords. NIST now explicitly states that verifiers SHALL NOT impose such composition rules, because the actual effect was the opposite of intended: users respond to composition mandates in extremely predictable ways, capitalizing the first letter, appending '1!' at the end, substituting '@' for 'a'.⁴

Length beats complexity, by the numbers

The math backs this up directly. A sixteen-character password using only lowercase letters carries roughly 75.2 bits of entropy. An eight-character password forced through a full composition rule, drawing from the 95-character pool, carries only about 52.6 bits, some 23 bits less despite following every complexity rule imposed on it. Length alone, even with a smaller character pool, outperforms complexity squeezed into a short password almost every time.³

NIST documents this reasoning in Appendix A, Strength of Passwords, which explains how the predictable patterns users create under composition mandates fail to produce the randomness the policy intended.⁴ Teaching users to inject capital letters, digits, and symbols into a short base does not expand keyspace meaningfully if the resulting passwords still cluster around a handful of templates; a password manager-generated random string sidesteps the distraction entirely and lands at higher entropy with less user effort.

Blocklist screening: the new mandatory control

In place of composition rules, NIST requires an active check: 'When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.'⁵ This targets the actual attack pattern that matters most, credential stuffing and dictionary attacks using real breach data, rather than a proxy metric like character variety that never measured predictability directly.

Why periodic rotation also lost its mandate

Because blocklist screening happens at password creation, it catches exactly the passwords composition rules used to let through unchecked: anything already known to attackers, regardless of how many character classes it technically contains. Periodic rotation is dropped for the same reason forcing composition was dropped; NIST SHALL NOT require it absent specific evidence the password has already been compromised, since routine forced changes push users toward small, predictable variations of their previous password rather than genuinely new ones.¹

When to use this

Reach for this guide when you are setting or auditing a password policy for an application, an internal system, or your own accounts, and want to check a password's bits against the 15-character floor before deciding whether your current rules reflect current best practice. It is also useful context when a service's outdated composition requirements are forcing you into a weaker password than you would otherwise choose. Because the guidance shifted so sharply from decades of prior practice, it also helps to have on hand when explaining to a team or a client why a policy change away from composition rules is not a security regression.

Examples