Notifications
Clear all
Topic starter
11/07/2026 8:34 pm
TL;DR: NIST SP 800-63B Rev. 4 shifts password policy toward a 15-character minimum when passwords are the only authenticator, removes mandatory composition rules, requires blocklist screening, and rejects routine expiration, according to Enzoic. The practical effect is that security teams must trade complexity theatre for length, breach checks, and compromise-driven response.
NHIMG editorial — based on content published by Enzoic: NIST 800-63B Rev 4: What’s New in Password Security
By the numbers:
- When a password is the only authenticator, systems must enforce a minimum length of 15 characters.
Questions worth separating out
Q: How should security teams update password policy for NIST 800-63B Rev. 4?
A: Security teams should prioritise password length, reject weak or breached choices, and remove arbitrary composition rules that users routinely evade.
Q: Why do composition rules often make passwords weaker in practice?
A: Composition rules often make passwords weaker because users respond by creating predictable patterns, such as capitalising the first letter, adding a symbol, or appending a number.
Q: What breaks when password blocklist screening is missing?
A: Without blocklist screening, users can choose passwords that attackers already know, expect, or can guess from public context.
Practitioner guidance
- Raise password minimums across all user-facing systems Set a 15-character minimum wherever passwords are the only authenticator, and verify that legacy applications do not enforce shorter limits behind the scenes.
- Remove composition rules that users work around Eliminate mandatory uppercase, number, and symbol rules unless a system has a documented and measurable reason for keeping them, then standardise the policy across directories and applications.
- Deploy dynamic blocklist checks at creation and reset Screen new and changed passwords against common, breached, sequential, and organisation-specific terms using an always-current blocklist tied to identity workflows.
What's in the full article
Enzoic's full post covers the implementation detail this analysis intentionally leaves at the policy level:
- How to configure password length and character-set rules in legacy directories without breaking applications
- How to operationalise blocklist screening in reset and self-service password flows
- How to map compromise-driven expiration into helpdesk and incident response workflows
- How to interpret the revised guidance against older internal password standards
👉 Read Enzoic's analysis of NIST 800-63B Rev. 4 password changes →
NIST 800-63B Rev 4 password changes: what do teams need to update?
Explore further
11/07/2026 9:03 pm
Length-first password policy is a corrective, not a complete answer. NIST’s move away from composition rules fixes a common human failure mode, but it does not solve the broader identity problem of exposed credentials, reuse, or weak recovery paths. For IAM teams, the control shift is useful because it reduces predictable password behaviour, yet it still assumes the credential remains secret after issuance. Practitioners should treat this as a policy reset, not an end state.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when passwords are only changed after compromise?
A: Accountability sits with the identity team, application owners, and incident responders together, because compromise-driven expiration depends on detection, policy enforcement, and remediation working as one process. NIST SP 800-63 Digital Identity Guidelines supports that model by tying change requirements to real risk rather than calendar habits.
👉 Read our full editorial: NIST 800-63B Rev 4 resets password policy priorities
