Password complexity rules create risk because they reward formatting instead of real resistance to attack. Users respond by choosing predictable patterns, reusing variants, or appending numbers and symbols in obvious ways. The result is a policy that looks strict but still allows credentials attackers already know how to guess or crack.
Why This Matters for Security Teams
Password complexity rules look like a control, but they often optimise for compliance theater instead of attacker resistance. NIST’s current guidance has moved away from forced complexity because predictable composition rules push people toward reusable patterns, not stronger secrets, and the same dynamic appears across enterprise estates where humans and tools both end up handling credentials badly. In parallel, NHI risk is already widespread: the Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage.
For security teams, the real issue is that complexity rules can increase helpdesk resets, encourage weak user behaviour, and still leave passwords guessable through spraying or pattern-based cracking. They also distract from controls that matter more, such as MFA, rate limiting, detection, and removing passwords where possible. Enterprise identity programs should treat passwords as a legacy fallback, not a resilience strategy. As a baseline reference, the NIST Cybersecurity Framework 2.0 puts stronger emphasis on governance, access control, and resilience than on composition rules alone. In practice, many security teams encounter credential abuse only after a password policy has already been “passed” by users who learned how to game it.
How It Works in Practice
Complexity rules create risk because they measure surface form, not entropy in the ways attackers actually exploit. If a policy demands uppercase, lowercase, a number, and a symbol, many users respond with the same human-friendly pattern: capitalise the first letter, swap one character for a symbol, and append a year or exclamation mark. That makes credentials easier to predict, not harder.
In enterprise environments, the operational impact is bigger than the password itself:
- Users reuse a base word across accounts and rotate variants instead of adopting unique secrets.
- Helpdesk teams spend more time on resets, which raises cost and expands social engineering exposure.
- Attackers can use credential stuffing, password spraying, and cracking against predictable structures.
- Developers and admins often store “temporary” passwords in tickets, spreadsheets, or chat tools.
Current guidance suggests moving away from composition rules and toward controls that reduce guessability and reuse: long passphrases, breached-password screening, MFA, and passwordless authentication where feasible. The Top 10 NHI Issues page is also relevant because the same design mistake appears in machine accounts: static, reusable credentials create risk when they are shared, long-lived, or hard to rotate. For service accounts and automation, best practice is evolving toward short-lived secrets, workload identity, and automated revocation rather than “stronger” passwords that still need to be remembered or stored. These controls tend to break down in legacy applications that cannot support MFA, passwordless flows, or short TTLs because the authentication path is too rigid to modernise safely.
Common Variations and Edge Cases
Tighter password rules often increase operational overhead, requiring organisations to balance apparent stringency against usability and incident response burden. That tradeoff matters most in regulated environments, shared admin estates, and older systems where the password is still the primary control. In those cases, the goal should not be to write more complex rules, but to reduce the number of places a password can be guessed, reused, or stolen.
There is no universal standard for this yet, but the direction across current guidance is clear: length, uniqueness, breach screening, and phishing-resistant MFA outperform character-mix mandates. For non-human identities, the risk is even sharper because secrets are often embedded in code, CI/CD, or vaults, and complexity does nothing to solve exposure. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how commonly secrets remain exposed and over-privileged, while NIST Cybersecurity Framework 2.0 reinforces that resilience depends on access governance and recovery, not just password format. In practice, the best teams use complexity rules only as a temporary compatibility measure, then phase them out where stronger authentication is available.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control should not rely on weak password composition. |
| NIST SP 800-63 | Digital identity guidance discourages outdated complexity-heavy password policies. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static secrets and poor rotation practices create the same risk as weak passwords. |
Replace composition rules with stronger access controls, MFA, and verified authentication paths.
