Set a minimum length of at least 14 characters, with 16 or more preferred, and require randomness over predictable patterns. Complexity helps, but length is the stronger driver of resistance to brute-force attacks. Teams should also allow passphrases where policy permits, avoid personal information, and pair password rules with rate limiting and multifactor authentication to reduce the impact of compromise.
Password length and complexity in practice
Password policy should start with length, because longer passwords resist online and offline guessing far better than short but complicated ones. For most user accounts, a minimum of 14 characters is a sensible floor, with 16 or more preferred where usability allows. Complexity rules can still help, but they should not be the main control, and they should not force predictable substitutions such as “P@ssw0rd”.
The better standard is to allow strong passphrases and random character strings, while blocking weak patterns that look complex but are easy to predict. That means avoiding dictionary words with simple tweaks, repeated characters, keyboard walks, and personal information. If a policy makes users choose between memorability and compliance, length usually wins because it gives them room to create something both usable and hard to crack.
Organisations should also be careful not to equate “complexity” with security. An 8-character password with symbols may still fall quickly to guessing, while a long passphrase can be resilient even with limited character variety. The practical standard is to optimise for entropy, not for visual variety alone.
Why length beats complexity for attack resistance
Password length expands the search space much more reliably than adding a single required uppercase letter or symbol. That matters because attackers rarely rely on one technique only, they combine brute force, password spraying, credential stuffing, and pattern-based guessing. A policy that focuses on complexity but allows short passwords can still leave accounts exposed to high-probability guesses and recycled credentials.
Usability also matters. When complexity rules become too prescriptive, users tend to create predictable forms that satisfy the checker without improving real resistance. Length-based standards reduce that incentive, and they are easier to explain, remember, and enforce consistently across the account population.
For organisations that need a reference point on how weak or reused secrets become operationally dangerous, NHIMG’s Internet Archive breach is a useful reminder that exposed authentication material can turn into broader account exposure quickly. It is also worth reviewing the OWASP Cheat Sheet Series for implementation detail on password handling and authentication hygiene.
Operational controls that make password policy actually work
Password length and complexity standards are only one layer. They need rate limiting, lockout or throttling controls, and multifactor authentication so that a guessed or reused password does not immediately become account compromise. Organisations should also reject known breached passwords, enforce sensible minimum age rules only where needed, and make password reset flows resistant to abuse.
Policy should be applied in context. High-impact user accounts, administrative access, and externally exposed logins deserve stricter verification and stronger monitoring than low-risk internal accounts. If a business still depends heavily on password-only access, the organisation should treat the password policy as a compensating control, not as a complete defence.
For standards mapping, NIST Cybersecurity Framework 2.0 supports the broader governance and protective controls around account authentication, while PCI DSS v4.0 provides a stronger compliance-driven benchmark where user authentication is in scope. In environments that need more detail on authentication controls and secret handling, NIST SP 800-53 Rev 5 Security and Privacy Controls is the most direct control catalogue reference.
Risk and Threat Considerations
Poor password standards increase exposure to guessing, spraying, reuse, and credential stuffing. The main risk is not just that one password is cracked, but that the same weak rule produces many weak accounts, which makes large-scale compromise far more efficient for attackers.
Failure mechanism: Short or predictable passwords shrink the search space, while overreliance on complexity rules encourages users to create patterns that are easy to infer or reuse across services.
Impact: Attackers can gain unauthorized access, pivot into additional systems, and bypass business controls that assume a password is a meaningful proof of legitimacy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | User password standards directly shape authentication strength and account access control. |
| Recommendation — Set password policy as part of identity and access controls, and pair it with MFA and throttling. | ||
| CIS Controls v8 | 6 — Access Control Management | Password length, complexity and account protections are prescriptive access-control safeguards. |
| Recommendation — Enforce strong account authentication rules and review them alongside access removal and restriction practices. | ||
| NIST SP 800-63 | AAL — Authentication Assurance Level | Password standards affect how much assurance an authenticator can provide for user access. |
| Recommendation — Match password requirements to the assurance needed for the account's risk level. | ||
| PCI DSS v4.0 | 8 — Identify Users and Authenticate Access to System Components | PCI DSS requires stronger authentication and account controls for user access to in-scope systems. |
| Recommendation — Apply strong authentication requirements and enforce account controls consistently across in-scope users. | ||
Practitioner Guidance
What to prioritise: Set the minimum length first, then tune complexity rules only where they add clear value. If a control makes users choose short-but-complicated passwords instead of long memorable ones, the policy is working against the real threat.
What to verify: Check whether your enforcement actually blocks predictable patterns, breached passwords, and weak resets, not just whether it counts characters and symbols. A policy that looks strict on paper can still be weak in practice if the user can satisfy it with a guessable template.
Decision rule: If the account can access sensitive data, production systems, or administrative functions, require stronger authentication support around the password, especially multifactor authentication and throttling. Password quality matters most where a single compromise creates outsized blast radius.
Practitioner takeaway: The best password policy is usually the simplest one that drives long, random, non-personal secrets and is backed by controls that limit the damage if the password is guessed or reused.
Related resources from NHI Mgmt Group
- How should organisations implement NIST password guidance without creating weaker user behaviour?
- When do service accounts become a higher risk than ordinary user accounts?
- When should organisations prioritise password length over composition complexity?
- Why do non-human identities create more audit risk than human accounts?