If your password policy still says “at least eight characters, one capital, one number, one symbol, changed every 90 days”, it is out of date. NIST’s current guidance says the opposite on almost every point, and it now says so with the word SHALL.
This article explains what NIST SP 800-63B Revision 4 actually requires, gives you a sample policy table you can adapt, and shows you how to explain the change to an auditor who still expects 90-day rotation.
Is SP 800-63B Revision 4 final?
Yes. NIST published SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, as a final publication in July 2025. It is part of the SP 800-63-4 suite and supersedes the previous SP 800-63B (originally released in 2017 and last updated in March 2020).
Two points of context matter:
- Who it binds. SP 800-63B is written for US federal agencies and the services they use. For everyone else, including European businesses, it is not law. It is, however, the most widely cited technical reference for password and authentication policy, and auditors, insurers and frameworks frequently point to it.
- What “SHALL” means. In NIST language, SHALL is a requirement, SHOULD is a recommendation and MAY is optional. Key rules, such as no composition rules and no periodic changes, were SHOULD NOT in the previous version and are SHALL NOT in Revision 4.
The core password rules in SP 800-63B-4
The password requirements sit in section 3.1.1.2, “Password Verifiers”. Here are the ones that matter most for an organisational policy.
1. Minimum length: 15 characters, or 8 with MFA
Passwords used as a single-factor authentication mechanism SHALL be at least 15 characters. Passwords used only as part of multi-factor authentication MAY be shorter, but SHALL be at least eight characters.
Length beats complexity. A passphrase such as four unrelated words is easier to remember and harder to guess than a short string full of symbols.
2. Maximum length: allow at least 64 characters
Verifiers SHOULD permit a maximum length of at least 64 characters, so that passphrases and password-manager output fit. They SHALL verify the entire password and not truncate it.
3. No composition rules
Verifiers SHALL NOT impose composition rules, such as requiring a mix of upper case, lower case, numbers and symbols. NIST’s reasoning is that these rules push people towards predictable patterns (“Password1!”) without adding real strength. Verifiers SHOULD accept all printing ASCII characters, the space character and Unicode.
4. No forced periodic changes
Verifiers SHALL NOT require users to change passwords periodically. They SHALL force a change if there is evidence that the password has been compromised. This is the rule that most often surprises auditors, and we cover it in detail below.
5. Check against a blocklist
New passwords SHALL be compared against a blocklist of commonly used, expected or compromised values. The entire password is compared, not substrings. If a password is rejected, the user SHALL be told why and asked to choose another.
In practice, a blocklist should include breached-password corpuses, dictionary words, repetitive or sequential strings (“aaaaaa”, “12345678”), and context-specific words such as your company name, product names and the service name.
6. No hints or security questions
Verifiers SHALL NOT allow password hints accessible to an unauthenticated person, and SHALL NOT prompt users to use knowledge-based authentication or security questions (“What was your first pet’s name?”) when choosing passwords.
7. Allow password managers and paste
Verifiers SHALL allow password managers and autofill, and SHOULD allow users to paste passwords. Blocking paste mainly blocks password managers, which pushes people towards shorter, reused passwords.
8. Rate-limit failed attempts
Verifiers SHALL implement rate limiting on failed authentication attempts. SP 800-63B-4 sets an upper bound of no more than 100 consecutive failed attempts on a single account before the authenticator is disabled; you can and usually should set a lower threshold combined with progressive delays.
Beyond passwords: MFA, phishing resistance and passkeys
The bigger message of Revision 4 is that passwords alone are not enough for anything important. The guidelines define three Authentication Assurance Levels (AAL1–AAL3).
- AAL2 requires two factors. Revision 4 adds that verifiers SHALL offer at least one phishing-resistant authentication option at AAL2. US federal agencies SHALL require phishing-resistant authentication for their own staff, contractors and partners.
- AAL3 requires a phishing-resistant cryptographic authenticator with a non-exportable private key, such as a hardware security key or a device-bound credential.
Phishing resistance means the login cannot be relayed through a fake website. NIST cites WebAuthn and FIDO2 as examples of protocols that achieve this by binding the authentication to the real site’s name. One-time codes sent by SMS or voice are not phishing-resistant, and NIST classifies the use of the public telephone network for out-of-band authentication as restricted: if you offer it, you must offer alternatives and manage the additional risk.
Where passkeys fit
The document does not use the consumer term “passkey”. It uses syncable authenticators: WebAuthn credentials whose private keys are synchronised across a user’s devices through a cloud service. Appendix B of SP 800-63B-4 allows syncable authenticators up to AAL2, provided the keys are stored encrypted in the sync service and access to that service is itself protected by AAL2-equivalent MFA. They cannot be used at AAL3, because syncing requires an exportable key.
For most businesses, that makes passkeys a practical upgrade for everyday staff and customer logins, with hardware security keys reserved for administrators and other high-risk roles. For background, see our explainers on two-factor authentication and how phishing works.
Sample password and authentication policy
Use this table as a starting point. Adjust thresholds to your risk assessment and any sector rules that apply to you.
| Policy area | Requirement | Basis |
|---|---|---|
| Minimum length (password only) | 15 characters | SP 800-63B-4, 3.1.1.2 |
| Minimum length (password + MFA) | 8 characters minimum; 12+ recommended internally | SP 800-63B-4, 3.1.1.2; PCI DSS 8.3.6 where in scope |
| Maximum length | At least 64 characters; no truncation | SP 800-63B-4, 3.1.1.2 |
| Character set | All printable ASCII, spaces and Unicode accepted | SP 800-63B-4, 3.1.1.2 |
| Composition rules | None | SP 800-63B-4, 3.1.1.2 |
| Expiry | No scheduled expiry; mandatory change on evidence of compromise | SP 800-63B-4, 3.1.1.2 |
| Blocklist | Breached, common, sequential and company-specific values rejected, with reason shown | SP 800-63B-4, 3.1.1.2 |
| Hints and security questions | Not permitted | SP 800-63B-4, 3.1.1.2 |
| Password managers | Approved manager provided to all staff; paste and autofill allowed | SP 800-63B-4, 3.1.1.2 |
| Failed attempts | Rate limiting with progressive delays; lockout well below 100 attempts | SP 800-63B-4, 3.2.2 |
| MFA – all staff | Required for email, VPN, cloud apps and remote access; passkeys preferred | SP 800-63B-4, AAL2 |
| MFA – admins and high-risk roles | Phishing-resistant hardware-bound authenticator | SP 800-63B-4, AAL3 |
| SMS codes | Fallback only, with an alternative available | SP 800-63B-4, 3.1.3.3 (restricted) |
| Monitoring | Continuous checks of credentials against breach data; risk-based sign-in alerts | Compensating control for no-expiry |
How to explain the change to auditors still asking for 90-day rotation
Some auditors, customers and internal checklists still ask for forced 90-day changes. You do not need to argue; you need to show your reasoning and your evidence.
Start with the source
Quote the requirement directly: SP 800-63B-4 says verifiers SHALL NOT require periodic password changes and SHALL force a change on evidence of compromise. The UK’s National Cyber Security Centre has advised against forced regular expiry since at least 2016. Frame your policy as alignment with current authoritative guidance, not as relaxing security.
Explain the risk logic
Forced rotation has a known side effect: people make small, predictable changes (“Spring2026!” becomes “Summer2026!”), write passwords down or reuse them across services. An attacker with an old password can often guess the new one. Rotation also does nothing against the attack that matters most today, which is real-time phishing of a current password and MFA code.
Show the compensating controls
Auditors want to see that removing rotation did not leave a gap. Have this evidence ready:
- MFA coverage report for all users and all internet-facing systems.
- Configuration showing the blocklist and the minimum length in your identity provider.
- Breached-credential monitoring and the procedure that forces a reset when a match is found.
- Rate-limiting and lockout settings.
- Your incident procedure for suspected account compromise.
- Risk assessment and management approval of the policy change.
Know where rotation is still written into a standard
Be precise about the exceptions, because a good auditor will be:
- PCI DSS v4.0.1 requirement 8.3.9 says that if passwords are the only authentication factor for user access, they must either be changed at least every 90 days or the security posture of accounts must be analysed dynamically. With MFA in place, or with dynamic analysis, the 90-day rule does not bite. Note that PCI DSS 8.3.6 still asks for a minimum length (12 characters, or 8 if the system cannot support 12) and both numeric and alphabetic characters, so keep that for in-scope systems.
- ISO/IEC 27001:2022 Annex A control 5.17 requires a managed process for authentication information. It does not prescribe a rotation interval, so a NIST-aligned policy with documented reasoning fits well.
- Contracts and sector rules sometimes copy old wording. Check them, and where needed ask the counterparty to accept the NIST-aligned approach in writing.
If you map controls to the NIST Cybersecurity Framework, authentication sits under the Protect function; see our NIST CSF 2.0 guide.
This is general guidance, not legal advice.
Rollout checklist
- Get management approval for the new policy, with a short risk rationale.
- Deploy an approved password manager to all staff before you raise length requirements.
- Configure length, blocklist and rate limiting in your identity provider and key applications.
- Switch off scheduled expiry only once MFA and breached-credential monitoring are live.
- Roll out passkeys for staff, and phishing-resistant keys for administrators.
- Train staff on passphrases, password managers and MFA prompts. Reinforce it with phishing simulations.
- Update documentation and the audit evidence pack.
AceFortis runs practical training on modern password and authentication policy for IT teams, compliance officers and management — get in touch to plan a session.
FAQ
Does NIST still allow eight-character passwords?
Only where the password is used as part of multi-factor authentication. If a password is the only factor, SP 800-63B-4 requires at least 15 characters.
Should we stop expiring passwords completely?
Stop scheduled expiry, but keep forced changes when there is evidence of compromise, such as a match in breach data or suspicious sign-in activity. Put MFA and monitoring in place first.
Are passkeys acceptable under NIST guidance?
Yes, up to AAL2. NIST calls them syncable authenticators and sets conditions, including encrypted key storage and MFA protection of the sync account. For AAL3, use device-bound authenticators such as hardware security keys.
Is SMS-based MFA still allowed?
It is allowed but restricted. It is not phishing-resistant, and you must offer alternatives. Treat it as a fallback, not your main second factor.
