NIST minimum password length, and the rest of the current password guidance: what to set in your app and what to stop doing

Set 15 characters as the floor if a password is the only thing protecting an account, and 8 if a second factor is always required: that is the NIST minimum password length in SP 800-63B Revision 4. Then drop three old rules the same document now forbids: forced symbols, scheduled expiry, and security questions.

NIST minimum password length: 15 characters alone, 8 with a second factor

The NIST minimum password length in SP 800-63B Revision 4 is 15 characters when the password is the only authenticator, and 8 characters when it is used only as part of multi-factor authentication. Verifiers should also permit at least 64 characters, should accept spaces and Unicode, and must check the whole password, never a truncated part.

Length is one row of the authentication checklist, the list of sign-in controls a small SaaS works through before launch. The rest of this page takes the password rows one at a time and ends with eight checks that prove the app enforces them.

Every row in the table below is read from section 3.1.1.2 of NIST SP 800-63B Revision 4. The “where to set it” column is my reading of where each number lives in a web app: the auth provider’s settings and your own form, which have to agree.

The reason length carries the weight is in the standard’s own Appendix A: “Password length is a primary factor in characterizing password strength”, and its summary adds that, past the rules it sets, other mitigations such as blocklists, secure hashed storage and rate limiting “are more effective at preventing modern brute-force attacks”.

The standard password length outside NIST lands in the same place. OWASP’s Authentication Cheat Sheet treats passwords shorter than 15 characters as weak when MFA is not enabled and shorter than 8 when it is, and says the maximum should be at least 64. Microsoft’s password length recommendations for Microsoft 365 sit one character below NIST’s 15: the service requires at least eight, and Microsoft recommends “a minimum of 14 characters.”

In a builder stack the number usually lives in the auth provider. Supabase’s password security settings page tells you to “Set a large minimum password length” and says “Anything less than 8 characters is not recommended.” Its default minimum is not stated in Supabase’s password security docs, so read the value in your own project’s Auth settings rather than assume it. A password length best practice that holds across providers: the form and the provider show the same minimum, and the server refuses anything under it.

NIST 800 53 password requirements, and which NIST document says what

NIST 800-53 password requirements sit in control IA-5(1), password-based authentication, in the SP 800-53 catalog; the detailed password rules, such as the 15-character floor and the blocklist, are in SP 800-63B. For a private company, neither document applies until a contract, a customer or a framework asks for it.

SP 800-63B is the Digital Identity Guidelines volume on authentication, and its abstract says it “focuses on the authentication of subjects who interact with government information systems”. NIST SP 800-53 Revision 5 is a catalog of controls, and its IA-5(1) states the password requirements at control level. NIST SP 800-171 Revision 3 covers controlled unclassified information held in nonfederal systems.

So the practical question for a SaaS company is whether a contract, a framework or a customer names one of these documents; that is my reading, and this page is not legal advice. When a security questionnaire row asks whether passwords follow NIST, I read it as pointing at the SP 800-63B rules in the do and stop table below, and the eight checks at the end of this page are the evidence to attach.

Why it matters for a small SaaS

Two starting points are worth checking for in any app. One is the auth provider’s settings, set the way its docs recommend: Supabase’s password page tells you to “Use the strongest option of requiring digits, lowercase and uppercase letters, and symbols.” The other is a rule set copied from an older company policy; my working rule is to look for one uppercase letter, one number, one symbol and a 90-day expiry. Which one your app has is something you check in the settings and the code, not something to guess.

Each old rule has a cost on both sides. The reasons below are Revision 4’s where it gives one, and Microsoft’s for expiry.

Across the third-party apps I audited, the Authentication pillar averages 52.8 out of 100, scored on the 14 of the 21 where it applied (pillars that did not apply were excluded, not zeroed). Those 21 are third-party apps from my June and July 2026 audits, a selected set of audited apps rather than a random sample, so the average is not a rate for AI-built apps in general.

Length alone does not stop credential stuffing, where an attacker tries passwords leaked from other sites. Attempt limits (brute force login protection) and a second factor on owner and admin accounts (the reason to implement two-factor authentication before launch) sit beside the password rules rather than behind them.

How it works: the current NIST password guidelines, rule by rule

The first section below gives the whole rule list; the next three take expiry, security questions and storage, because each of those has a decision attached.

The new NIST password guidelines as a do and stop list

The current NIST password guidelines require a minimum length, a blocklist check on every new password, guidance when a password is rejected, support for password managers and autofill, and limits on failed attempts. They rule out composition rules, scheduled expiry, stored hints and security-question prompts, and force a change only on evidence of compromise.

The level and section in each row are read from Revision 4. The last column is my working rule for what that means in a web app’s sign-up form and auth provider. Read as NIST password best practices, the table also shows how hard each one binds: the SHOULD rows are NIST recommendations, and the SHALL and SHALL NOT rows are requirements.

Two rows reverse what older policies treat as standard password requirements: the character-type rule and the expiry date. Since July 2025, the NIST password guidelines for 2025 and for 2026 have been the same text: Revision 4 was published that month and supersedes the SP 800-63B edition of March 2020.

If you need a NIST password policy for a handbook or a questionnaire answer, here is the table written as one paragraph. It is my own example of the NIST password standards turned into policy wording, not text NIST publishes.

Passwords are at least 15 characters, or at least 8 for accounts that always use a second factor. The app accepts up to at least 64 characters, including spaces and Unicode, and checks the whole password. Every new or changed password is compared with a list of common and breached passwords and refused with a reason. Password managers, autofill and paste work. There are no character-type rules, no scheduled expiry, no hints and no security questions. A password is changed when there is evidence it was compromised. Failed sign-in attempts are rate-limited, and passwords are stored only as salted hashes.

On Supabase, the blocklist row of the NIST password guidance comes down to one setting. Supabase Auth “uses the open-source HaveIBeenPwned.org Pwned Passwords API to reject passwords that have been leaked”, and “Leaked password protection is available on the Pro Plan and above.” Outside that setting, the Pwned Passwords range API is free, needs no subscription or API key, and is queried with only “the first 5 characters” of the password’s hash, so neither the password nor its full hash is sent. How to run that check and what to do with a hit belongs with brute force login protection.

Here is how the gap shows up. A founder’s app runs on Supabase Auth on a plan below Pro; the founder raises the minimum length and turns on the strongest required-characters option, the one Supabase’s password page recommends. Leaked password protection is available on the Pro Plan and above, so a new password that is long, uses every character type and already sits in a breach corpus is accepted at sign-up. Revision 4 makes the blocklist check a SHALL and composition rules a SHALL NOT; length and symbols do not screen a password against breach lists, and a paid-plan setting or a check the app runs itself does. The lesson I take from it: a password can pass every composition rule and still sit on a breach list, and the blocklist check is the rule that looks at the password itself.

NIST password expiration and the forced password reset: what changed, and what to do after a breach

NIST password expiration guidance comes in two halves: verifiers shall not require periodic changes, and shall force a change when there is evidence the password was compromised. For a small SaaS, my working rule is to reset everyone after a breach of the user table, one user when their password shows up exposed, and nobody on a calendar date.

Section 3.1.1.2 says it plainly: “Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically.” The next sentence adds the other half: “However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.” The NIST password change frequency is therefore never on a calendar and always on evidence. The NIST password expiration guidelines published in July 2025 contain no rotation period at all.

The table is my working rule for the four triggers a small SaaS meets.

The NIST password reset guidelines go one step further in section 4.3: “The CSP SHALL suspend, invalidate, or destroy compromised authenticators from the subscriber’s account promptly following compromise detection.” In practice a forced reset needs the old password to stop working at once, the reset to go through the normal single-use link, the user to be told why, and that user’s sessions to end as far as your provider allows. In my reading, the security of a forced password reset rests on that first step, which is why check 7 below tests it. An access token already issued can keep working until it expires; Supabase describes its access tokens as “short lived, usually between 5 minutes and 1 hour”. Closing that gap belongs to what is active session management, starting with which sessions your provider lets you end.

The reset flow itself follows the same authentication best practices for user flows as sign-up and login, and its link travels by email, under the same rules as how to send a verification email. Who may force a reset for another user is a permission question about roles, and it belongs with your other RBAC examples: one named role gets the action, nobody else.

When a customer’s contract or an older framework still demands 90-day expiry, my working rule is to do what the contract says and record in writing that the guideline differs. Microsoft’s own password expiration best practice points the same way as NIST: “Microsoft’s latest guidance discourages password expiration policies for cloud-only accounts. The recommended setting is for passwords to never expire.” Microsoft’s password policy recommendations is the page to cite in that record.

What is a security phrase, and why security questions are gone

A security phrase means one of three things: a phrase a site shows back to you so you know the site is real, a passphrase used as a long password, or a security-question answer. NIST’s current guidance favors the second through its length rule and tells sites not to prompt for the third.

Revision 4 is direct about the third meaning. Verifiers and CSPs “SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords”, and SHALL NOT let a subscriber store a hint “that is accessible to an unauthenticated claimant” (section 3.1.1.2).

One more use of the name turns up in help pages: the College Board’s CSS Profile says its Security Phrase “is what you must provide to the Customer Support agent”, so there it works as a phrase for support calls, not a site check.

Security phrase examples are safer as patterns than as strings to copy. For the anti-phishing kind, pick something only you would recognize that says nothing public about you. A passphrase works best as several unrelated words strung into something long, and Revision 4 says verifiers should accept the spaces between them. On the recovery side, a second factor or recovery codes take the place of the question, and the examples of security questions and why they fail are the reason to make that switch.

How to store a password securely on the server

Storing a password securely means never storing the password itself: the server keeps a salted hash from a slow password hashing function. OWASP’s Password Storage Cheat Sheet ranks Argon2id first and scrypt second, keeps bcrypt for legacy systems, and names PBKDF2 for when FIPS-140 compliance is required. An app on managed auth keeps no password column in its own tables.

Revision 4’s requirement is short: “Passwords SHALL be salted and hashed using a suitable password hashing scheme.” The cost factor “SHOULD be as high as practical without negatively impacting verifier performance” and “SHOULD be increased over time”. The settings below are copied from OWASP’s Password Storage Cheat Sheet, with the condition OWASP attaches to each.

bcrypt’s limit matters for the 64-character maximum. OWASP says bcrypt “has a maximum length input length of 72 bytes for most implementations” and that you should enforce a maximum of 72 bytes, or less where the implementation has smaller limits. Revision 4 counts each Unicode code point as one character, so on a bcrypt-backed stack the byte limit, not the character count, is the ceiling to test.

On managed auth the provider does the hashing, and your check is that your own tables hold no password column. On Supabase the hash sits in the encrypted_password column of auth.users; Supabase uses bcrypt and calls the column’s name “a misnomer (cryptographic hashing is not encryption)”. Whatever the stack, never log a password, never email one, and never encrypt passwords where a hash belongs; OWASP says passwords should be hashed “rather than encrypted or stored in plaintext.” Old hashes are upgraded at the next login: when the user enters their password, usually by signing in, OWASP says “that input should be re-hashed using the new algorithm.”

Moving users and their hashes off a builder is its own job, and the first question there is whether users keep their passwords when you leave Lovable Cloud. For the other meaning of how to store a password, where a person keeps their own: a password manager, not a note or a spreadsheet.

How to check your own app

A password policy is checked with 8 tests against the live sign-up and change-password forms: too short is refused by the server, 64 characters with spaces works, no symbol is demanded, a breached password is refused, paste works, no hint or question appears, nothing expires by age, and no readable password sits in the database.

Run them on a staging or test project you own, never on real users’ accounts. Each check is a pass or a fail, and each leaves a piece of evidence to keep.

1. 01 Too short is refused by the server. Send a sign-up request one character under your minimum straight to the auth provider's API or your own endpoint, not through the form. Pass: an error comes back (on Supabase, the weak_password code). Keep the error response
2. 02 Long passphrases work. Sign up with a 64-character passphrase that has spaces and one non-Latin character, then sign in with it. On a bcrypt-backed provider keep it inside the 72-byte limit, or record the provider's own maximum. Keep both responses
3. 03 No composition rule. Sign up with a lowercase-only password at your minimum length that is not on a breach list. Pass: it is accepted. Keep the response
4. 04 Breached passwords are refused. Take a password you have confirmed is in the Pwned Passwords data through the range API, make sure it meets your minimum, and try to sign up with it. Pass: refused, with a reason. On Supabase this needs leaked password protection, available on the Pro Plan and above; on a lower plan, record the check as not run and name the plan, or run it against your own server-side check
5. 05 Paste and password managers work. Paste into the password field and let a password manager fill it. Keep a screenshot
6. 06 No hint or security question. Walk through sign-up, change password and recovery. Pass: none of them asks for a hint or a question. Keep screenshots of all three
7. 07 Nothing expires by age. Search the provider settings and the code for anything that reads a password's age. Then set a new password for one test user from the server side and confirm the old one is refused at the next sign-in. Keep the settings screen, the search and the refusal
8. 08 No readable password is stored. Query your own tables for any password column, then read one row of the provider's hash. Pass: no password column of your own, and the provider's value is a hash. Keep the query result with the hash cut after its first few characters

For check 1, Supabase’s error docs advise against relying only on HTTP status codes, which “may change unexpectedly”, so match the weak_password code instead. For check 7 on Supabase, the admin updateUserById call sets the new password; Supabase says its changes “are applied directly without confirmation flows”, and it “should only be called on a server”. Record the date, the settings pages you read and the eight results in one file. The attempt-limit check is part of brute force login protection, not this list.

Deliverable 1.1 of the Production Hardening Sprint is verified this way: Exercise successful, rejected, expired, and reused-token paths for each supported flow.

Where the sprint fits

In the Production Hardening Sprint, deliverable 1.1 is where we review and fix signup, login, logout, password reset, email verification, and OAuth callbacks. Deliverable 1.6 is where we implement rate limits and brute-force protections on authentication and recovery endpoints. Deliverable 1.11 is where we enforce a second factor on every owner and admin account, in the application and on every provider dashboard behind it, with recovery codes stored in the owner’s vault. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables. Each deliverable, with how it is verified, is listed in the published sprint scope.

Common questions about NIST password rules

What are the five golden rules of password?

My working five are: make it long, use it on one site only, check it against breach lists, keep it in a password manager, and back it with a second factor. None of the documents on this page publishes a list of five, so treat these as mine, not NIST’s.

Which password should never be used?

Never use a password that is already on a breach list, a dictionary word, or the service’s name, your username or anything derived from them: those are the examples Revision 4 gives for the blocklist a verifier must check against. A password you already use elsewhere is out too: NIST says distinct passwords are important to avoid “password stuffing” attacks. A site can check the breach part with the Pwned Passwords range API, which receives only the first five characters of the password’s hash.

Is NIST 800-53 a standard?

It is a NIST Special Publication: a catalog of security and privacy controls, mandatory for federal information systems, and not a password rulebook. Other organizations, private companies included, are invited to consider them where they fit. In my reading, a private SaaS meets it as a requirement only when a contract or a customer adopts it.

What is the main difference between NIST 800-171 and 800-53 standards?

The main difference is who they are for: SP 800-53 is the full catalog of controls, mandatory for federal information systems, while SP 800-171 is a set of requirements for protecting controlled unclassified information held in nonfederal systems. NIST writes SP 800-171’s requirements “for use by federal agencies in contractual vehicles or other agreements” with nonfederal organizations, so a private company meets it through an agreement with a federal agency.

Is a 20 character password safe?

Yes, on length: a 20-character password clears Revision 4’s 15-character floor for a password used on its own, so its length is fine. Length only helps if the password is not reused and not already on a breach list, which is why the blocklist check matters as much as the number.

Can you give me an example of a passkey?

Yes: signing in to a website with the fingerprint, PIN or pattern that unlocks your phone, with no password typed, is a passkey at work. In the FIDO Alliance’s words, a passkey is an authentication credential “that can be stored on your phone or computer, or in a hardware security key” that lets you sign in “with the same process that they use to unlock their device (biometrics, PIN, or pattern).” The FIDO Alliance’s passkey page has the full definition; adding passkeys to an app goes with the second-factor work, not the password rules.