A bank tells you your password must contain an uppercase letter, a number and a symbol, and that you will have to change it again in ninety days. Somewhere in the compliance file behind that screen there is very likely a reference to NIST.
NIST's current guidance forbids both of those rules, and it forbids them to the bank rather than recommending anything to you.
What the document says
The relevant publication is SP 800-63B, whose password requirements read as prohibitions on the service:
"Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."
"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
A third prohibition covers the questions that often sit beside the password field:
"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."
Who "SHALL NOT" is addressed to
This is the part that usually goes missing when the guidance is summarised. A verifier is the party checking the password — the bank, the employer, the service. A credential service provider issues and manages the credential.
⚠️ So these are not tips for choosing a password. They are things an organisation is instructed not to impose on you, which turns the whole document from personal security advice into a question you can ask about a service you are using.
The length requirement went the other way
The figure most often quoted from NIST is eight characters. The current text requires more than that where the password stands alone:
"…SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length."
Length replaced composition deliberately. Complexity rules push people toward predictable substitutions and toward writing the result down; length does not.
Check which revision you are citing
Guidance that cites "NIST 800-63B Rev. 3" is citing a withdrawn document — it was withdrawn on 1 August 2025, superseded by revision 4. The much older advice about composition and expiry traces back to a 2003 NIST appendix whose own author publicly disavowed it in 2017.
What this does not mean
It does not mean a service breaking these rules is insecure, or non-compliant with anything binding. SP 800-63B is normative for US federal agencies and their contractors; for a commercial bank in Singapore or Malaysia it is a reference, not a regulator's order.
⚠️ It also does not mean you should stop changing a password you have reason to worry about. The same clause that removes scheduled expiry keeps forced change on evidence of compromise, which is the case where changing it actually accomplishes something.
What to do with it
When a service imposes composition rules or ninety-day expiry and cites NIST, the citation is checkable and it is wrong. That is worth knowing if you are the one being asked to comply with an internal policy, and more worth knowing if you are the one writing it.
For your own passwords the practical reading is length over character classes, a unique password per service, and a change when something suggests a breach rather than when a calendar does.
Where this comes from
The quoted requirements are from NIST Special Publication 800-63B-4, July 2025, section 3.1.1.2 "Password Verifiers", read from NIST's published text. Cite the PDF rather than the HTML if you need section numbers, because the HTML numbers its headings in script.
⚠️ One limit. We have verified what the publication says. We have not surveyed which banks or employers cite it while breaking it, so the opening example is illustrative of a widely reported pattern rather than a finding about any named organisation.
This dates when NIST issues revision 5, and the thing to check first is whether the revision you are reading has been withdrawn — two of the documents most often cited in this area now have been.
View author profile → · Editorial policy
