privileged.id

Tool · NIST SP 800-63B-4

Password policy checker

Describe your password policy and see, rule by rule, where it meets or breaks NIST SP 800-63B-4 (July 2025), with the exact requirement strength and section for each.

Runs in your browser. Nothing you enter is sent or stored.Reviewed

Load:
Length and limits
How is the password used?
Characters
Lifecycle
Choosing and entering
Verifier side

    How long is this password, by NIST's count?

    SP 800-63B-4 counts each Unicode code point as one character, and recommends normalizing to NFC first. Many systems count something else: JavaScript's .length counts UTF-16 units, databases often count bytes. Type here to compare (it stays on this page).

    The rules, in full

    Every rule the checker applies, from NIST SP 800-63B-4, Authentication and Authenticator Management (July 2025), section 3.1.1 unless noted. The text is paraphrased; the requirement word is exactly the publication's. These apply to passwords that are verified centrally and used as an authentication factor, not to the local PIN that unlocks a security key or phone (an “activation secret”, §3.2.10).

    RequirementRuleSection
    SHALLMinimum length of 15 characters when the password is the only factor; at least 8 when it is only ever used as part of multi-factor authentication.3.1.1.2 (1)
    SHOULDPermit passwords of at least 64 characters.3.1.1.2 (2)
    SHOULDAccept all printing ASCII characters and the space character.3.1.1.2 (3)
    SHOULDAccept Unicode characters.3.1.1.2 (4)
    SHALLCount each Unicode code point as one character when checking length.3.1.1.2 (4)
    SHOULDIf Unicode is accepted, apply NFC normalization before hashing.3.1.1.2
    SHALL NOTImpose composition rules, such as requiring a mix of character types.3.1.1.1, 3.1.1.2 (5)
    SHALL NOTRequire passwords to be changed periodically.3.1.1.2 (6)
    SHALLForce a change when there is evidence the password has been compromised.3.1.1.2 (6)
    SHALL NOTLet users store a hint that an unauthenticated person can see.3.1.1.2 (7)
    SHALL NOTPrompt users to set knowledge-based questions (“name of your first pet”) when choosing a password.3.1.1.2 (8)
    SHALLAsk for the whole password (not selected characters) and verify all of it, without truncation.3.1.1.2 (9)
    SHALLCompare new passwords, whole, against a blocklist of commonly used, expected or compromised values (breach corpuses, dictionary words, context words such as the service name and username).3.1.1.2
    SHALLWhen a password is on the blocklist, require a different one and tell the user why it was rejected.3.1.1.2
    SHALLOffer guidance to help users choose a strong password.3.1.1.2
    SHALLRate-limit failed attempts: no more than 100 consecutive failures on one account before the authenticator is disabled.3.1.1.2, 3.2.2
    SHALLAllow password managers and autofill.3.1.1.2
    SHOULDPermit pasting into the password field.3.1.1.2
    SHOULDOffer an option to display the password while it is typed.3.1.1.2
    SHALLRequest passwords only over an authenticated protected channel with approved encryption (TLS).3.1.1.2
    SHALLStore passwords salted and hashed with a password hashing scheme that takes a cost factor; the salt is at least 32 bits.3.1.1.2
    SHOULDAdd a keyed hash or encryption step with a secret key stored apart from the hashes, ideally in a hardware-protected area.3.1.1.2

    What changed from the 2017 edition

    The 2017 SP 800-63B already told verifiers not to impose composition rules or periodic changes, but as SHOULD NOT. Revision 4 makes both SHALL NOT. It also raises the minimum for a password used on its own from 8 to 15 characters, while keeping 8 as the floor for a password that is only ever one factor of multi-factor authentication, and it makes allowing password managers and autofill a SHALL. Policies written to the 2017 text, or to older “complexity and 90-day expiry” habits, now fail mandatory requirements.

    Reading the results

    • Low lockout thresholds are allowed. 100 consecutive failures is an upper bound; agencies MAY set lower limits. But a limit of 3 or 5 makes it easy for anyone to lock a user out on purpose. §3.2.2 suggests alternatives such as bot challenges and growing delays between attempts.
    • “Blocklist” means the whole password. The comparison is against entire values, not substrings, and the list need not be enormous: it exists to stop guesses an attacker would try before hitting the attempt limit.
    • Passwords are never phishing-resistant. Meeting every rule here makes passwords harder to guess, not harder to steal. See phishing-resistant MFA.

    Sources

    1. NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management (July 2025), NIST. Public domain (U.S. government work).
    2. NIST SP 800-63B (June 2017, superseded), NIST. Public domain (U.S. government work).
    3. Unicode Standard Annex #15: Unicode Normalization Forms, Unicode Consortium. Cited for facts; not reproduced.

    Read next

    Authentication NIST password rules SP 800-63B-4 turned several 2017 recommendations into requirements. Each rule with its exact strength word and section, how to store passwords, and what changed. Authentication MFA strength compared All MFA beats passwords alone, but not equally. A side-by-side of what each form resists, using CISA's ranking and NIST SP 800-63B-4's requirements. Authentication Assurance levels: IAL, AAL, FAL Three separate dials for proofing, authentication and federation. What each level requires in the 2025 revision, and which levels fit privileged users.