They often treat complexity as a proxy for security. A password can be long and varied while still being exposed in public breach data or predictable enough to crack quickly. Effective policy must block known bad passwords, not just enforce character rules.
Why This Matters for Security Teams
Password complexity rules still fail when teams confuse formatting with resistance. A password can satisfy every length and character requirement yet remain weak if it appears in breach corpora, follows a pattern, or is reused across systems. That is why current guidance increasingly favors screening against known-compromised and commonly abused secrets instead of relying on composition alone, as reflected in the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs.
For security teams, the practical risk is not just account takeover. Weak password policy also drives lockouts, support overhead, user workarounds, and a false sense of control that delays stronger controls such as phishing-resistant MFA, secrets rotation, and breached-password blocking. The issue is especially acute where human and non-human identities share the same authentication stack, because a rule tuned for user convenience can still leave service accounts, admin consoles, and legacy apps exposed. In practice, many security teams encounter password compromise only after attackers have already reused a valid credential rather than through intentional policy testing.
How It Works in Practice
Modern password policy should be treated as a layered control, not a standalone defense. The first layer is minimum entropy, but that is only a baseline. The more effective layer is rejection of known-bad passwords at creation and reset time, including passwords found in breach datasets, obvious variants, and organisation-specific terms. The goal is to stop selection of secrets that are easy to guess, easy to spray, or already exposed.
Security teams should also reduce the number of places where passwords matter at all. The NIST identity guidance has long emphasized that compensating controls, such as phishing-resistant authentication and rate-limiting, matter more than forcing users into elaborate character recipes. For NHI programs, the equivalent move is to avoid static shared secrets where possible and prefer workload identity, short-lived tokens, and automated rotation. NHIMG’s research shows why this matters: only 5.7% of organisations have full visibility into their service accounts, and 79% have experienced secrets leaks, with 77% causing tangible damage. That is a policy failure, not just a user-training issue.
- Block breached passwords at set and reset time, not just during initial enrollment.
- Use length-first rules, then add screening against known-compromised passwords.
- Require MFA or phishing-resistant authentication to reduce reliance on password strength alone.
- Apply separate policy for NHIs, where static secrets should be rotated, scoped, and inventoried.
- Monitor for reuse, exposure, and privilege escalation rather than assuming compliance equals safety.
Where this guidance breaks down is in legacy environments that cannot support password screening, modern MFA, or central policy enforcement because authentication is embedded in appliances, old SaaS integrations, or hard-coded application flows.
Common Variations and Edge Cases
Tighter password rules often increase user friction, helpdesk volume, and the temptation to write secrets down, so organisations have to balance usability against real attack resistance. That tradeoff is why best practice is evolving toward minimum length, breached-password checks, and stronger authenticators instead of ever more complex composition rules.
There is no universal standard for this yet across every platform, but the direction is clear. Some systems only support composition rules, some can check against banned-password lists, and some can integrate with identity providers that enforce modern policy centrally. For NHI environments, the edge case is even more important: passwords should often not be the primary control at all. Secret sprawl, over-privileged accounts, and delayed rotation are usually bigger problems than whether a password contains a symbol. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which means a single compromised credential can become a broad access event if the policy model is too shallow.
Security teams get this wrong when they optimise for policy checkboxes instead of exposure reduction. The stronger posture is to treat password complexity as a hygiene measure, not a security boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access control should reduce exposure, not rely on complex passwords alone. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Password weakness is often really secret lifecycle weakness for NHIs. |
| NIST AI RMF | AI systems still depend on identities and secrets that must be governed safely. |
Apply risk-based governance to reduce credential exposure and automate stronger authentication controls.
