Your password policy may still demand a capital letter, a symbol and a change every 90 days. The US National Institute of Standards and Technology (NIST) has moved away from all three. Its current guidance, SP 800-63B-4, was finalised in 2025 and replaces the 2020 edition of SP 800-63B.
NIST writes these guidelines for US federal systems, but they are a useful reference for any organisation. Here is what they say and how to apply them.
The password rules in SP 800-63B-4
Section 3.1.1.2 sets the requirements for systems that check passwords. NIST uses SHALL for requirements and SHOULD for recommendations.
| Topic | What NIST says |
|---|---|
| Minimum length, password alone | SHALL be at least 15 characters |
| Minimum length, password as part of MFA | SHALL be at least 8 characters |
| Maximum length | SHOULD allow at least 64 characters |
| Characters | SHOULD accept all printing ASCII characters, spaces and Unicode |
| Composition rules | SHALL NOT impose them, for example "one upper case, one digit, one symbol" |
| Periodic changes | SHALL NOT require them |
| Known compromise | SHALL force a change when there is evidence the password is compromised |
| Blocklist | SHALL check new passwords against known common, expected or compromised values |
| Hints and security questions | SHALL NOT store hints or prompt for knowledge-based questions |
| Password managers | SHALL allow them and autofill; SHOULD allow paste |
| Failed attempts | SHALL rate-limit them |
| Truncation | SHALL check the entire password as entered |
Why the old rules are gone
Composition rules and forced rotation feel strict, but they push people towards predictable patterns. A user forced to change Autumn2026! may well choose Winter2026!, and an attacker who has the old password can guess the new one.
NIST relies on length and a blocklist instead. A long passphrase is easier to remember than a short random string. Rotation only helps once a password has leaked, so NIST ties changes to evidence of compromise rather than the calendar.
The blocklist replaces composition rules as the real filter. It rejects the passwords attackers try first: common choices, words tied to your organisation and passwords already seen in breaches.
Checking against breached passwords
The Have I Been Pwned "Pwned Passwords" service lets you check a password against breach data without sending the password. Your system hashes the password with SHA-1 and sends only the first five characters of the hash. The service returns every hash suffix that starts with those five characters, with a count, and you compare locally.
# SHA-1 of "password" is 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
curl -s -H "Add-Padding: true" https://api.pwnedpasswords.com/range/5BAA6This approach, called k-anonymity, means the service never learns which password you checked. A typical response holds several hundred suffixes, and the Add-Padding header hides the real response size from anyone watching the traffic. No API key is needed for the password range search.
Build this check into password set and change screens. In Active Directory environments, look at tools that apply a breached-password list to domain password changes.
Let people use password managers
NIST requires verifiers to allow password managers and autofill. That makes sense: a manager makes long, unique passwords practical, and it fills in only on the domain where the password was saved. Blocking paste on login forms works against this.
For staff, provide a company password manager rather than leaving people to choose their own. Protect the manager itself with a strong master passphrase and phishing-resistant MFA.
Not all MFA is equal
With a second factor, a stolen password alone is no longer enough, but some methods can still be phished. An attacker's fake login page can ask for a code and pass it on in real time. NIST defines phishing resistance as the protocol's ability to stop secrets being disclosed without depending on the user's vigilance.
| Method | Phishing-resistant? | NIST notes |
|---|---|---|
| SMS or voice code | No | A "restricted" authenticator; verifiers must offer alternatives and should watch for SIM swaps and number porting |
| Authenticator app code (TOTP) | No | Codes are typed by hand, so they can be relayed |
| Push approval or out-of-band app | No | Out-of-band methods are not phishing-resistant |
| Email code or link | Not allowed for out-of-band | Email SHALL NOT be used for out-of-band authentication |
| FIDO2 / WebAuthn security key or passkey | Yes | The response is bound to the verified site name |
At NIST's middle assurance level, AAL2, verifiers SHALL offer at least one phishing-resistant option. At the highest level, AAL3, the authenticator must provide phishing resistance and use a private key that cannot be exported.
Passkeys
A passkey is a FIDO credential built on WebAuthn. Your device creates a key pair for each site. The site stores only the public key, and the private key stays with you. You unlock it with the same method you use to unlock your device, such as a fingerprint, face or PIN. The FIDO Alliance notes that biometric data stays on the device and is never sent to the site.
Because each passkey is tied to one site, it simply does not work on a lookalike phishing domain. There is also no shared secret on the server to steal.
Passkeys come in two forms:
- Synced passkeys are copied across your devices through a provider's sync service. NIST calls these syncable authenticators and allows them at AAL2. Because the key can be exported, they SHALL NOT be used at AAL3.
- Device-bound passkeys stay on one device, such as a hardware security key. They suit administrators and other high-risk accounts.
Think about account recovery too. If someone can reset a passkey account with an email link or a call to the helpdesk, attackers can simply target that route instead. Make recovery at least as strong as the login it replaces.
A policy you can adopt
- Minimum 15 characters where a password is the only factor, and allow at least 64.
- No composition rules and no scheduled expiry.
- Check every new password against a breached and common password list.
- Force a change only on evidence of compromise.
- Provide a password manager, and allow paste and autofill.
- Require MFA everywhere it is available, and phishing-resistant MFA for administrators, email and remote access.
- Roll out passkeys where your systems support them, starting with high-risk accounts.
- Rate-limit failed logins, and make account recovery as strong as login.
Where to start
Check whether a password already appears in breach data with our Pwned Passwords checker, and test how long a passphrase needs to be with our password strength tool.
If you are reworking your identity policy or planning a passkey rollout, our consulting team can help you plan it.
