NIST requires 15 characters, not 25. See what SP 800-63B-4 actually says, why Grover's algorithm changes less than claimed, and what to measure instead.
NIST’s 2025 digital identity standard requires 15 characters when a password is the only authenticator, not 25. Quantum computing weakens password hashing in theory through Grover’s algorithm, which offers a quadratic speedup, but the practical effect is far smaller than headline advice suggests and does not change the recommended length.
NIST finalized Special Publication 800-63B Revision 4 in mid-2025, replacing guidance that had shaped corporate password policy for roughly two decades. It is the reference standard for US federal authentication and is progressively mirrored by other national bodies, so it is the sensible baseline for any policy discussion.
| Requirement | What Revision 4 says |
|---|---|
| Minimum length, single factor | 15 characters when the password is the only authenticator |
| Minimum length, within MFA | 8 characters when the password is one factor among others |
| Maximum length | Verifiers must accept at least 64 characters |
| Composition rules | Prohibited. No mandatory uppercase, digit, or symbol requirements |
| Periodic rotation | Not required. Change only on evidence of compromise |
| Blocklist screening | Required against commonly used and known-compromised values |
| Character set | All printing ASCII, spaces, and Unicode accepted |
| Hints and security questions | Prohibited as recovery mechanisms |
| Passkeys | Synced passkeys recognized at AAL2, device-bound at AAL3 |
Two things in that table matter more than the numbers. NIST states plainly that passwords are not phishing-resistant, which positions them as a floor rather than a strategy. And the removal of composition rules and forced rotation reflects a finding NIST repeats across revisions: those requirements produce predictable user workarounds and weaker outcomes, not stronger ones. Practical guidance is collected in how to keep passwords safe from attackers.
Quantum computing threatens two different things by two different mechanisms, and conflating them is where most password-and-quantum advice goes wrong.
Shor’s algorithm breaks asymmetric cryptography. It renders RSA and elliptic curve schemes worthless rather than merely weaker, which is why post-quantum migration is urgent for key exchange, certificates, and signatures. Passwords are not asymmetric cryptography, so Shor’s algorithm does not apply to them at all.
Grover’s algorithm is the one that touches passwords, and it is a much gentler effect. It provides a quadratic speedup on unstructured search, reducing brute-force preimage search against an n-bit hash from roughly 2^n to 2^(n/2) operations. In NIST’s own description, this suggests an attacker with a quantum computer might attack a cipher with a key up to twice as long as a classical attacker could. Symmetric primitives and hash functions are consequently weakened but, as the cryptographic literature consistently concludes, not broken.
Discover how Threatcop protects your workforce from modern cyber threats.
Taking the quadratic speedup at face value produces alarming arithmetic and misleading conclusions. Three practical constraints sit between the theory and an actual cracked password.
Grover’s algorithm requires a long-running serial computation, which is difficult to implement on real hardware. A realistic attack has to run many smaller instances in parallel instead, and parallelizing Grover’s erodes the advantage substantially, because the speedup comes from sequential iteration rather than from breadth. Analyses using NIST’s own quantum circuit estimates reach the same conclusion.
It also requires a large fault-tolerant quantum computer, which does not exist. And password hashes in any competent system are salted and processed through a memory-hard key derivation function, which imposes a heavy per-guess cost that Grover’s does not remove. An attacker still has to steal the hash first, which is the step most attacks skip entirely.
The reasonable position is that quantum computing is a genuine and urgent problem for asymmetric cryptography and a marginal one for password length. NIST’s post-quantum work reflects exactly that split: the transition timelines target quantum-vulnerable asymmetric algorithms, while the symmetric answer is larger key sizes rather than a change to authentication policy.
The length debate optimizes the attack path that matters least. Password length is relevant to precisely two attacks: guessing against a live login screen, and cracking a stolen hash offline. Neither is how most credentials are lost.
Credentials are taken overwhelmingly through phishing pages that capture whatever the user types, through infostealer malware that reads them from the browser, and through reuse, where a password exposed in one breach opens an unrelated account. A 40-character password entered into a convincing fake login page is compromised exactly as fast as an 8-character one. Scale is visible in the leak of 16 billion credentials and in 26 million credentials lost to malware infection.
This is not a controversial claim, and it is worth noting that even advocates of much longer passwords generally concede it before recommending more characters anyway. Mechanics of the dominant path are set out in credential harvesting, and the consequences at scale in what CISOs can learn from a breach of 16 billion accounts.
Published tables showing how long a password survives a cracking rig share an assumption that is rarely stated: they measure a fast hash. The widely circulated figures describing rigs performing tens of trillions of guesses per second are measured against NTLM, a fast, unsalted hash function, and the numbers change by many orders of magnitude the moment the stored hash is anything a modern system should be using.
That difference dwarfs anything achievable through length. A password storage scheme built on bcrypt, scrypt, or Argon2 is deliberately slow and, in the case of the latter two, deliberately memory-hard, meaning each guess consumes memory that cannot be economized by adding parallel hardware. Where a GPU rig might attempt trillions of NTLM guesses per second, the same hardware against a properly tuned memory-hard function manages a rate lower by a factor large enough to make offline cracking uneconomic against passwords far shorter than any of the headline recommendations.
Salting compounds it. A unique salt per password means an attacker cannot precompute, cannot use rainbow tables, and cannot amortize work across a stolen database. Each account has to be attacked individually, which turns a single expensive campaign into one expensive campaign per user.
The practical conclusion is uncomfortable for length-based advice. If an organization stores passwords with a fast unsalted hash, no realistic length policy saves it, because the attacker’s economics are favourable at almost any length a workforce will tolerate. If it stores them with a salted memory-hard function, the length required to be safe is well inside what NIST already recommends. Either way, the storage decision determines the outcome and the character count adjusts it at the margin.
This is also why breach severity varies so much between organizations that had superficially similar password policies. The variable that separated them was almost never how many characters users were made to type. Exposure at scale is visible in how credentials are captured in plaintext, where the stored hash never enters the picture because the password is captured in plaintext.
AI appears in most current password advice as a reason to lengthen requirements, and the mechanism is usually left unexplained. Examined directly, its effect on cracking is real but narrow, and its effect elsewhere is far larger.
Machine learning improves candidate generation. Models trained on billions of leaked passwords learn the patterns humans actually produce, including the substitutions, keyboard walks, date suffixes, and phrase structures that composition rules encourage. Against human-created passwords, this meaningfully reduces the search space, because those passwords occupy a tiny, highly structured region of the possible space.
Against genuinely random passwords, it does nothing at all. There is no pattern to learn in output from a cryptographic random number generator, so a model provides no advantage over brute force. The uncomfortable implication is that AI-driven cracking is an argument for password managers rather than for longer human-chosen passwords, since the benefit accrues precisely where humans invent the string themselves.
The larger effect sits on a different attack path entirely. Generative models make phishing pages and pretexts cheaper, more fluent, and more targeted, and a credential typed into a convincing fake login page is compromised regardless of its length, randomness, or storage. That is the path where AI has genuinely shifted the balance, and it is not addressed by any password policy. Behaviour under those conditions is examined in the psychology attackers rely on.
Recommendations well above the standard usually arise from stacking worst cases. Take a fast unsalted hash, assume a nation-state cracking budget, apply the theoretical Grover speedup at face value, add a margin for AI-assisted guessing, and the arithmetic produces a large number. Each assumption is individually defensible; multiplied together they describe a threat model almost no organization faces.
The compounding is the flaw. A defender who has migrated to salted memory-hard storage has already removed the first assumption, which was doing most of the work. A defender facing a nation-state with that budget has problems that password length will not solve, a point the advocates of longer passwords generally concede. And the Grover adjustment does not survive contact with the serial-computation and fault-tolerance constraints that govern real quantum hardware.
There is also an opportunity cost that the arithmetic never includes. Policy attention is finite, and a quarter spent raising minimums and handling the resulting reset volume is a quarter not spent deploying phishing-resistant authentication, which removes the dominant loss path rather than making one uncommon path more expensive.
None of this makes long passwords harmful in themselves. A 25-character random string generated by a password manager costs the user nothing, because they never type it, and it sits comfortably inside the 64-character minimum that NIST SP 800-63B Revision 4 requires verifiers to accept. Manager deployment is the step that makes such lengths realistic, as password safety guidance sets out. The problem is a mandate, applied to human-chosen passwords across a workforce, justified by a threat model that does not match the organization.
Password policy has costs that appear in user behavior rather than on a balance sheet, and beyond a point those costs exceed the security gained.
Requirements that exceed what people can manage produce the workarounds every security team has seen: a base phrase with an incrementing digit, a password written down, the same long password reused across every system because inventing a second one is too much effort. Reuse is the specific failure that turns one breach into several, and long minimums without a password manager make reuse more likely rather than less.
The cost is also operational. Longer minimums increase reset volume, and reset processes are a recognized social engineering target, since help desk verification is frequently weaker than the authentication it restores. A policy change that adds characters and also adds help desk resets can move the organization backwards.
None of this argues for weak passwords. It argues for matching the requirement to the control, which is what NIST SP 800-63B Revision 4 does in its 2025 form: 15 characters where a password stands alone, 8 within MFA, a manager to make uniqueness practical, and effort redirected to the paths where credentials are actually lost. Help desk exposure of this kind is illustrated in the HMRC phishing case.
Revision 4’s most consequential move is not the length number. It is the formal recognition of passkeys, with synced passkeys accepted at AAL2 and device-bound passkeys at AAL3, alongside a clear preference for FIDO2, WebAuthn, and PKI-based authenticators.
The reason is structural rather than cryptographic. A passkey is bound to the origin it was created for, so a phishing page on a lookalike domain cannot elicit a usable credential no matter how convincing it is or how carefully the user was deceived. That removes the dominant loss path rather than making it more expensive, which is a categorically different kind of improvement from adding characters.
NIST also moves organizations away from SMS-based authentication, which is interceptable and subject to SIM-swap. Where passkeys are not yet deployable, an authenticator app or hardware key is the intermediate step, and the password minimum can be lower because the password is no longer standing alone.
Each item below restates a requirement or recommendation from NIST SP 800-63B Revision 4, finalized in 2025, in the order a policy rewrite should apply them.
Set 15 characters as the minimum for single-factor accounts, and 8 where genuine MFA is enforced
Accept at least 64 characters, along with spaces and Unicode, so passphrases and managers work
Remove composition rules entirely, since they generate predictable substitutions rather than entropy
Stop scheduled rotation, and reset on evidence of compromise instead
Screen every new password against a breach corpus at creation and at change
Remove password hints and security questions from all recovery flows
Deploy a password manager before raising minimums, because uniqueness is the property that matters most
Prioritize passkeys for high-value systems, and move off SMS as a second factor
Harden help desk verification, since reset processes are where a strong policy is most often defeated
Running these in order matters. Raising minimums before deploying a manager reliably produces reuse, which is the outcome the policy was meant to prevent. Account-level hardening steps are covered in preventing phishing on a Gmail account.
| Metric | Why it beats average password length |
|---|---|
| Share of accounts covered by phishing-resistant MFA | Directly tracks removal of the dominant loss path |
| Credentials found in breach corpora, by account type | Measures real exposure rather than theoretical strength |
| Reuse rate across internal systems | Identifies the failure that converts one breach into many |
| Rate of credential entry during phishing simulations | Shows behavior under realistic conditions |
| Time from credential compromise to detected reset | Bounds the damage window |
| Help desk reset volume and verification failures | Surfaces the process attackers actually target |
Average password length is an attractive metric because it is easy to extract from a directory, and it measures a property no successful attacker had to defeat. Each row below measures something an attacker either had to get past or benefited from, which is the test a security metric should pass. Selecting measures on that basis is covered in scoring exposure at the individual level, and the simulation mechanics behind the fourth row in what a controlled phishing simulation measures.
Threatcop’s TSAT measures the fourth of these directly, running credential-harvesting simulations across the channels a workforce actually uses and scoring exposure per employee rather than per department, so the population that enters credentials under pressure is named rather than estimated. The accompanying training then reaches those people specifically, which is a narrower and more useful intervention than a policy change applied to everyone.
If you are considering raising your password minimum, run a cheaper test first: find out what proportion of your accounts are covered by phishing-resistant authentication, and what proportion of your workforce enters credentials into a realistic simulated login page. Those two numbers will tell you more about your actual exposure than any length policy.
Measure the credential behaviour directly and spend the effort where the credentials are being lost, which is almost never at the point where an attacker is counting characters.
NIST SP 800-63B Revision 4, finalized in mid-2025, requires at least 15 characters where a password is the only authenticator and at least 8 characters where it is one factor within MFA. Systems must accept at least 64 characters. Recommendations of 25 characters or more exceed the current standard and deliver little against the attacks that actually compromise credentials.
Not in the way headlines suggest. Shor’s algorithm breaks asymmetric cryptography such as RSA and elliptic curve, which passwords do not use. Grover’s algorithm applies to hash preimage search but offers only a quadratic speedup, requires long serial computation that is hard to implement, and needs a large fault-tolerant quantum computer that does not yet exist. Salting and memory-hard hashing further blunt the effect.
No. Revision 4 removes mandatory periodic rotation. Passwords should be changed only where there is evidence of compromise. NIST’s position is that scheduled expiry drives predictable user behavior, such as incrementing a digit each cycle, which reduces security while increasing help desk load.
No. Revision 4 prohibits mandatory composition rules. Requiring an uppercase letter, a digit, and a symbol produces predictable substitution patterns that attackers already model, without meaningfully increasing entropy. Length, blocklist screening against compromised values, and phishing-resistant authenticators do the work those rules were intended to do.
Passkeys are credentials based on FIDO2 and WebAuthn that are cryptographically bound to the site they were created for, so they cannot be captured by a phishing page on a different domain. NIST Revision 4 recognizes synced passkeys at AAL2 and device-bound passkeys at AAL3. They are structurally stronger than any password because they remove phishing as a loss path rather than raising its cost.
Security Compliance Executive
Department: Compliance, Threatcop
Sanjana is a Security Compliance Executive working on best-of-the-industry-level compliances relevant from a cybersecurity perspective, their implementation, learning and outcomes in various business domains.
Information barriers fail at the wall crossing, not the firewall. See what the SEC expects, how crossings work, and...
Human risk management assumes risk enters through a person. AI agents have identity without training. See the lifecycle that...
Personal AI agents reach work devices without procurement or review. See what OpenClaw exposed, how to find agents already...
