If you run a login system, a NIST 800-63B compliance checker tells you which of your sign-in rules meet the current authentication requirements and which ones quietly work against your users. This guide walks through every test such a checker runs, from minimum length to blocklist screening, so you can read a result and know exactly what to change.
What a NIST 800-63B Compliance Checker Tests
NIST publishes its sign-in rules for government systems, and the NIST authors say plainly that private groups may adopt them, yet private companies in healthcare, banking and software borrow them as a baseline for their own security. NIST wrote the document for experts, and a NIST-aware checker turns it into a short list of pass or fail questions about your memorized secret rules, the way your servers store them, and the way your login form behaves when somebody guesses wrong. The questions fall into five groups.
- Length: how short a memorized secret you accept and how long an entry you permit.
- Screening: whether new passwords are compared against a blocklist of weak and breached values.
- Composition and expiry: whether you still force symbols, mixed case or scheduled changes.
- Attack resistance: whether your verification step limits failed authentication attempts.
- Storage: whether each secret is salted and hashed with an approved algorithm.
Each group maps to a specific clause in the guidelines, and the sections below explain the clause, the reasoning behind it and the way a checker scores it. Because the requirements changed between revisions, the next section starts with what is current.
Which revision applies to your checker result
The older Rev. 3 text was superseded on August 1, 2025, when NIST withdrew it and published Rev. 4 of the same volume. A checker still built on the old text will flag an eight-character minimum as acceptable, while the newer text sets a higher bar for passwords that stand alone. The current text, SP 800-63B, is the one to measure against, so always confirm which revision your tool targets before you treat a pass as proof, because a result against withdrawn guidance gives you false comfort about your risk.
NIST Password Compliance and the Digital Identity Guidelines
The password rules sit inside a family of digital identity guidelines that cover three volumes: identity proofing, authentication and lifecycle management, and federation. The authentication volume is the one a checker cares about, because it defines how a person proves control of a credential after the account exists. In the document's own vocabulary a password is one kind of memorized secret, alongside a PIN or a passphrase, and it is the most common authenticator on the web. Use the free password validation regex builder to assemble exactly what you need in a few clicks.
The vocabulary a checker report uses
Reports borrow wording straight from the standards text, so a short glossary saves time when you read one. A verifier is the part of your service that checks the secret. A credential service provider issues and manages the account. An authenticator is whatever the user holds or remembers to log in. Words in capitals carry weight: SHALL marks a mandatory rule, while SHOULD marks a strong recommendation that you may skip only with a reason you can defend.
Why this matters outside government
The guidelines bind federal agencies directly, yet they reach much further. Programs such as FedRAMP point to them, and contracts with a public-sector customer often require them. Many auditors in finance and healthcare, where digital identity proof is routine, also treat the NIST document as the reference answer for what good looks like in cybersecurity for sign-in screens, which is why a pass here carries weight in a vendor review.
Memorized Secret Length Requirements
Length is the first test and the one that changed most. A long memorized secret is harder to guess than a short one that is merely complicated, and the standard now reflects that. The numbers below are the facts a checker compares against.
Password length: minimum and maximum
Each memorized secret you accept is judged first on how long it is, so a checker's first finding is nearly always about password length, whether the entry is a primary secret or a fallback.
Under Rev. 4, a password used as the only authenticator must be at least 15 characters long. When a password is one factor inside multi-factor authentication, the floor drops to at least 8 characters, because a second factor carries part of the load. On the other end, your verifier must let people enter a secret of at least 64 characters, and you should accept longer where you can. A checker marks any maximum below 64 as a fail, because a low cap blocks passphrases and breaks the habits of people who use a password manager.
Truncation and character handling
A hidden failure sits behind many login forms: the server silently cuts a long entry short before it hashes it, a flaw known as truncation. The standard forbids this. The text requires that you hash the full value of the memorized secret, so a checker usually tests it by submitting an entry that is longer than your visible cap and seeing whether a login with only the first characters succeeds. Your form should also accept every printing ASCII character, the space, and the wider range of Unicode characters.
Unicode and normalization
People type in many languages, so a system that rejects non-ASCII input shuts them out of strong secrets. The guidelines ask you to accept Unicode in every memorized secrets field and to normalize it before hashing, so the same visible string always produces the same hash on every device. Count each Unicode code point as one character toward the length rules, which keeps a short phrase in a non-Latin script from failing a minimum it should pass. Test with a few accented letters, a space and an emoji, because inconsistent Unicode handling is a frequent cause of lockouts after a platform change.
Allow paste and a show-password option
The standard tells you to let people paste into the field, which makes password managers usable, and to offer an option that shows the entered value while they type. Blocking it pushes people toward shorter, memorable choices and weakens the whole scheme. A checker looks for the clipboard handler and for the reveal control as two separate items. Each is a small privacy and usability win, since users no longer retype secrets where onlookers can see.
NIST Password Requirements: Rev. 3 Versus Rev. 4
The table lists the main password requirements side by side, so you can see what moved between revisions and what stayed the same.
| Check | Rev. 3 (withdrawn) | Rev. 4 (current) |
|---|---|---|
| Shortest accepted value, sole authenticator | 8 characters | 15 characters |
| Shortest accepted value, inside multi-factor | 8 characters | 8 characters |
| Maximum length accepted | 64 characters or more | 64 characters or more |
| Composition rules | Should not be imposed | Should not be imposed |
| Periodic password change | No forced expiry without evidence of compromise | No forced expiry without evidence of compromise |
| Screening against known-bad values | Required | Required |
| Hint or secret-question prompt | Prohibited | Prohibited |
| Failed attempt limit | Limit consecutive failures | No more than 100 consecutive failures |
| Salt for stored secret | At least 32 bits | At least 32 bits |
The one headline change is the new 15-character floor for a single-factor password. Everything else among the NIST requirements carries forward, which means a checker built on the older text still catches most problems and only misses the length change.
Blocklist Screening and Compromised Passwords
The second test asks whether you compare every new secret against a blocklist. The idea is simple: the most dangerous values are the ones attackers already try first, so the verifier refuses them at the moment the user picks one. Some vendors call this password screening, and the rule is mandatory, not optional.
What belongs on the list
The standard names four sources you should include. Start with passwords that appeared in earlier breaches, since compromised passwords are the first values a stuffing attack replays. Add common passwords and dictionary words, repetitive or sequential characters such as "aaaa1234" or "abcdef", and context-specific values such as the service name, the username and the account holder's own details. Vendors that build this feature talk about checking against cybercriminal dictionaries, which describes the same breach-driven approach.
How a checker scores screening
A checker submits a handful of known-weak entries to your signup or reset form and records whether each one is rejected. It looks for a clear message that explains the refusal and asks for a new value, rather than a vague error. A screening list that is never updated slowly loses value, so a good report also asks when your blocklist last changed, and treats an old list as a partial pass.
Why Composition Rules and Forced Resets Fail
Many sign-in forms still demand an uppercase letter, a digit and a symbol. NIST advises against these composition rules, and a checker marks them as a warning, not a pass, because they push people toward predictable patterns instead of strength.
Password complexity versus real strength
Whether the secret is randomly-chosen by a generator or picked by a person makes a huge difference. Humans satisfy password complexity rules in the same few ways: capitalize the first letter, add a digit at the end, swap an "a" for an "@". Attackers know every one of those habits and build them into their guessing tools. A long phrase of ordinary words with whitespace between them (the standard also welcomes other space characters) beats a short mix of special characters, uppercase and lowercase letters in both strength and ease of recall. Entropy tells the story in numbers, and higher entropy means more guesses for the attacker. Treat entropy as an estimate rather than an exact grade.
For a secret chosen at random, the number of bits of entropy is
$$H = L \times \log_2 N$$
where \(L\) is the length and \(N\) is the size of the pool each position draws from. Four words drawn at random from a 7,776-word list give \(4 \times \log_2 7776 \approx 51.7\) bits, and six words give about 77.6 bits. A 16-character string drawn at random from all 94 printable ASCII characters gives \(16 \times \log_2 94 \approx 104.9\) bits. A human-picked eight-character password with a capital, a digit and a symbol scores far lower than its length suggests, since the choices are not random.
Periodic password changes and expiration
The guidelines also say you should not force scheduled password change events. People respond to a ninety-day deadline by adding a number to the old value, and an attacker who learns one version can predict the next. Require a new secret only when you find evidence that the old one leaked. A checker flags any expiry timer on the account as a failed item, and it treats a reset triggered by a breach alert as correct behavior.
Hints and knowledge-based questions
Prompts such as "your first pet's name" count as knowledge-based authentication, and the standard prohibits them. The answers are often public or easy to research, which turns security questions into a side door around a strong secret. Remove stored hints as well, because a guessing attack on a hint is cheaper than one on the secret and any attack that skips the secret defeats your verification step, because a hint displayed on the login page tells every visitor something about the account.
Rate Limiting and Failed Authentication Attempts
Strong secrets still need protection against an online guessing attack, so the verifier must limit how many wrong entries it accepts. This is the job of rate limiting, and the checker tests it by sending repeated bad logins against a test account.
Throttling and lockout limits
The guidelines cap failed authentication attempts at no more than 100 consecutive failures on a single account before the verifier takes action. Many teams meet that with throttling, which adds a growing delay after each miss, rather than a hard lockout that an attacker could use to block a real user. A second approach is to require a second factor once the counter climbs. A checker records the point at which your system first slows a client down and the point at which it stops accepting failed attempts altogether.
Brute force and credential stuffing
A brute force run tries many guesses against one account, while stuffing replays breached pairs across many accounts, and the two need different defenses. Per-account limits answer the first. Screening and monitoring of unusual sources answer the second. When you read your report, treat a pass on one as no proof about the other.
Storing Memorized Secrets: Salt, Hash and Key Derivation
A checker that only probes the login form misses the storage layer, so a thorough one also asks how your database holds each memorized secrets entry. The requirement is that a stolen database must not hand attackers a usable list.
Salting and approved hashing
Every secret gets its own random salt of at least 32 bits, which prevents an attacker from cracking two identical passwords in one pass. The verifier then runs the salted value through an approved hash built on a key derivation function such as PBKDF2, with a cost setting high enough to slow a guess to a crawl. The stored hashed value never reverses back to the original, and the salt can be stored beside it. Plain storage, unsalted hash values and fast general-purpose digests all fail this item. A checker may ask for a hash parameter report, show the hashed format your system writes, and compare the hashed record length against a known scheme, since a leaked hash in an unknown format hints at a weak design and a hashed value without a salt is easy to crack.
Keeping a stolen database useless
A checker verifies that nothing is stored in plain text, that every record carries a salt and an approved hash, and that the secret is stored securely and travels over TLS, since sound cryptography and encryption protect what the hash cannot. Ask how a restored backup is handled, because old copies often hold weaker records than the live table.
Memorized Secrets, PINs and Other Authenticator Types
A password is one of several authenticator families the guidelines recognize, and a checker sometimes covers more than one. Here is a short tour of the others, so you can see where a password fits among them. Teams that audit for NIST usually start with memorized secrets, since most users still log in with one of the memorized secrets types below.
Passphrases, PINs and look-up secrets
- Passphrases are longer than passwords and may contain spaces, which makes them the easiest long memorized secrets to remember.
- A PIN is a short numeric value, so it needs extra protection such as strict rate limiting and a device-bound check.
- A PIN that unlocks a device-held key is safer than a PIN sent to a server, and a PIN should never double as a password.
- One passphrase typed from memory can replace several short passwords, provided each service gets its own.
- Look-up secrets are printed or displayed recovery codes, each usable once, and they suit backup access.
- Single-use look-up secrets should expire, and your recovery page should explain that look-up secrets work only once, so users store the printed look-up secrets somewhere safe, since lost look-up secrets cannot be recovered. Single-use values should expire after use and the unused ones should be invalidated if a user asks for a fresh set.
One-time passwords and multi-factor authentication
A one-time password from an app or token proves possession of a device, and pairing it with a password creates multi-factor authentication. This pairing is what lets the password floor drop to eight characters. Offer multi-factor authentication to every user, and require it for administrators. The same multi-factor authentication prompt can protect a recovery flow, which attackers often target first.
Password managers in your design
Treat password managers as a feature to support rather than a nuisance to block. Keep the field a standard input, allow long values and clipboard input, and avoid scripts that fight autofill. A manager lets each user hold a unique random value for every service, which beats any rule you write for the human memory.
Threats Against Memorized Secrets and How the Rules Respond
Every rule in the guidelines answers a specific attack, and a checker is easiest to understand once you know the threats behind it. The document groups the threats to memorized secrets into guessing, theft, replay and social tricks, then ties each attack to a control. Your own risk assessment decides how much weight each one deserves, because the security of a payroll portal and a newsletter signup are not the same problem.
- An online guessing attack tries likely values through your login form, so rate limiting and screening against common passwords answer it.
- An offline attack works on a stolen database, so salting, a slow key derivation function and sound cryptography make every guess expensive.
- A phishing attack tricks the user into typing the secret on a fake page, which only a phishing-resistant authenticator stops.
- Credential stuffing reuses leaked credentials and stolen credentials from other sites, which is why checking new passwords against breached values matters.
- Session theft steals a live token, which shorter reauthentication limits contain.
An attack that fails at the login form often moves to the recovery flow, so run the checker against recovery too. Pair the hash with sound access control over who can read the table, and write down who owns each fix in your password policy and your incident policy, so every verification step you add answers one of these threats, and none of the listed threats is left without an owner.
Authenticator Assurance Levels AAL1 to AAL3
The guidelines grade login strength in three tiers: AAL1, AAL2 and AAL3, and a checker usually asks which tier your service claims. Each authenticator assurance level sets how much proof is required, so a higher level needs stronger controls. Picking the right tier is a risk decision, not a technical preference.
| Level | What it requires | Reauthentication limit |
|---|---|---|
| AAL1 | Single-factor or multi-factor, with any permitted authenticator | Reauthentication at least every 30 days |
| AAL2 | Two distinct factors, plus a phishing-resistant option offered to users | Reauthentication every 24 hours, and after 1 hour idle |
| AAL3 | Two factors, a phishing-resistant authenticator and a non-exportable key | Reauthentication every 12 hours, and after 15 minutes idle |
What each AAL level means for passwords
At AAL1, the lowest tier, a strong password alone can be enough, though the guidelines recommend you offer a second factor. At AAL2 a password must be joined by a second factor, so the shorter eight-character floor applies to the password half. At AAL3 the password becomes secondary, because the core of the login is a hardware-bound cryptographic key. If your service holds payment or health data, expect your auditor to push you toward AAL2 or AAL3, since AAL2 is the usual target and AAL3 is reserved for the highest-risk systems. Moving from AAL2 to AAL3 means hardware, and AAL3 also means non-exportable keys, while AAL2 accepts software authenticators and AAL1 accepts almost anything. The jump from AAL1 to AAL2 is where most teams spend their budget, and reaching AAL3 is rare outside government, and expect the AAL2 reauthentication rule to shape your session design.
Phishing resistance and verifier impersonation
Phishing resistance means the login cannot be replayed on a fake site. A phishing-resistant authenticator binds the proof to the real domain, so a lookalike page gets nothing usable. The guidelines call this verifier impersonation resistance, and they require it at AAL3. Passkeys and security keys are the practical route to phishing resistance, and strong phishing resistance is the single biggest upgrade over a password alone, so phishing resistance deserves its own line in your report, and a phishing-resistant option has to be on offer at AAL2. A password alone offers no verifier impersonation protection, so a plain password login never earns a phishing-resistant mark.
Reauthentication, sessions and step-up
Once a user signs in, the session lives on a token, and reauthentication decides how long that token stays valid. Shorter limits at higher levels keep a stolen session from lasting. NIST expects verification at each reauthentication, so a checker reads your session settings and compares each reauthentication limit against the level you claim. When a user wants to do something sensitive inside a lower-level session, step-up authentication asks for a stronger proof at that moment. Treat each prompt as a verification checkpoint and plan reauthentication prompts so that they do not annoy people, since usability decides whether a rule survives in practice.
Password Compliance Checklist You Can Run Today
You can run a first-pass review without special tools. Take sample entries from your own test accounts, submit each to your signup form, and compare the outcome with the table. These samples are invented for illustration.
| Sample entry | Characters | Result as sole authenticator | Reason |
|---|---|---|---|
| Harbor!2026 | 11 | Fail | Below the 15-character floor |
| Pa$$w0rd1234567 | 15 | Fail | Matches a common-password list pattern |
| blue-lantern-quiet-orchard | 26 | Pass | Long, not on a blocklist, spaces and hyphens accepted |
| Harbor!2026 | 11 | Pass | Meets the 8-character floor when paired with a second factor |
- Confirm the minimum is 15 characters for a sole password and 8 when a second factor is present.
- Confirm a 64-character entry is accepted without silent trimming.
- Confirm clipboard input works and a show-password control exists.
- Confirm a known breached value is rejected with a clear message.
- Confirm no composition rules, no hints and no scheduled expiry remain.
- Confirm that wrong guesses trigger throttling before the 100-failure limit.
- Confirm that stored values are salted and hashed with an approved algorithm.
Every item above is one of the NIST requirements in plain words. NIST describes the length and screening requirements as the most important, while NIST treats the storage requirements as a baseline. Work through the list in order, record a pass or fail for each line, and fix failures from the top because length and screening do the most for your users.
Strength meters and user feedback
A strength meter can help, as long as it measures real guessability and does not just count character classes. The guidelines welcome meters that explain why an entry is weak. A good meter supports password strength choices in the moment, and it should never block a long phrase that a naive rule would call weak.
Account recovery
Recovery is where good login design collapses. If account recovery falls back to an email link or an easy question, an attacker simply skips your strong secret. Notify the user whenever a recovery starts, tie recovery to the same assurance level as the login, and use look-up secrets or a second factor in place of questions. Check account recovery last, because it hides the weakest link in many systems.
Who Must Follow the Digital Identity Guidelines
A checker result matters most to teams in these groups. The mandate covers federal agencies (meaning every civilian federal agency) and the contractors who run systems for them. In practice the wider reach comes from contracts, audits and customer questionnaires. A short list of who is affected helps you decide how strictly to treat each result.
- Federal agencies and their cloud vendors, through FedRAMP and similar programs.
- Health and finance companies that borrow the rules as a baseline for identity and access management.
- Software vendors who sell to the public sector and answer security reviews.
- Any team that wants a defensible answer when a customer asks about sign-in practice.
Federation and the identity provider
Many organizations sign users in through a central service rather than a local table. In a federation, an identity provider (the IdP) authenticates the person and passes a signed assertion to your application. A checker can only test the password rules you control, so when the IdP holds the secret, ask its vendor for its own result and record which IdP is responsible for each assurance level. Under federation, your own rules still matter for any local fallback account, and the chain is only as strong as its weakest IdP or federation link.
Privacy and usability trade-offs
The guidelines treat privacy as a concern in its own right, so collect only the attributes your login needs and keep authentication logs short. Strict rules that annoy people lead to workarounds, and workarounds raise your risk: a person forced to rotate a long secret every month will reuse it or write it down, which lowers real security. Weigh each failed line in your report against the standards your customers expect before you change a rule.
Reading Your Memorized Secret Results and Next Steps
A result is only useful when it leads to a decision about verification, requirements and risk. Compare each failed line against your risk assessment, then list the identity, authentication and security requirements it touches. Record the passwords rules you changed and the verification steps you added, so your next review compares like with like.
After you run the checks, sort the findings by effort and impact. Raise the floor, add screening against known-bad values and remove expiry first, because those three changes lift the most users with the least friction. Then add throttling, then storage upgrades, then multi-factor options. Keep a dated record of every pass, with the standards reference, the risk rating and the verification evidence beside it, so that your next audit starts from evidence instead of memory.
A clean report is a snapshot, not a certificate. The standards evolve, breach lists grow and your own code changes, so schedule the review again at least once a year and after any major change to your login flow. When the next revision arrives, repeat the table comparison above, check the new text of SP 800-63B for changed numbers, and update your checklist before your customers ask.
Frequently Asked Questions
- Is this an official NIST certification tool?
- No -- there's no such thing as official NIST 'certification' for password policies. This tool is a self-assessment checklist against the practices NIST SP 800-63B's Digital Identity Guidelines actually recommend, meant to highlight where a policy diverges from current best practice, not to issue any formal compliance determination.
- Why does NIST recommend against forced password rotation?
- Research consistently shows that mandatory periodic rotation drives predictable behavior -- users make small, guessable variations on their existing password (Summer2024! becomes Summer2024!!) rather than choosing something genuinely new, which makes accounts easier to compromise, not harder. NIST now recommends rotation only when there's evidence of actual compromise.
- Why does NIST recommend against mandatory composition rules?
- Forcing 'one uppercase, one digit, one symbol' rules tends to produce predictable patterns (capital letter first, digit and symbol at the end) that attackers already model into their cracking tools, while frustrating users into weaker coping strategies. NIST's current guidance prioritizes length and breach-list screening over composition mandates.
- What's the single highest-impact change most policies should make?
- Screening new passwords against a list of known-breached and common passwords, combined with a reasonable minimum length -- this blocks the passwords attackers try first far more effectively than composition rules do, without adding user friction.
- Where can I read the actual NIST guidance?
- NIST Special Publication 800-63B, part of the Digital Identity Guidelines series, is published freely by NIST and covers authenticator and verifier requirements in full detail -- this checklist summarizes the password-specific practices most relevant to a typical login system.