TL;DR: Password complexity rules measure character variety, not real password strength, and they keep pushing users toward predictable patterns, helpdesk churn, and false compliance, according to Avatier. The stronger model is runtime enforcement with breach-corpus checks, long passphrases, and event-triggered rotation, because the old composition rule assumes attackers still behave like they did in 1995.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Avatier's blog post: Password complexity rules fail as an identity control, and runtime strength enforcement is the more effective model.
Why it matters: It matters because IAM teams still rely on policies that create compliance theatre instead of reducing credential risk, and that gap affects human identity governance, lifecycle enforcement, and the controls surrounding NHI credential issuance.
Context
Password complexity rules are policies that require mixes of uppercase letters, lowercase letters, numbers, and symbols. In practice, they measure compliance with a format, not whether a password is hard to guess or present in known breach corpora.
For IAM teams, the governance problem is that composition rules often produce predictable human behaviour, including reused patterns, helpdesk resets, and calendar-based rotation theatre. That makes them a weak control for identity programmes that need measurable resistance to credential attacks.
Avatier frames this as a 2026 operational refresh rather than a theoretical debate, which is the right lens. The question is not whether password rules are tidy, but whether they actually reduce risk across the identity lifecycle.
Key questions
Q: What breaks when password complexity rules are the main control?
A: They create the appearance of security while allowing predictable passwords, breached credentials, and trivial pattern changes to pass. That means the policy can satisfy an audit and still fail against credential stuffing or brute-force attacks. The break is not technical syntax. It is the mismatch between compliance formatting and real attacker behaviour.
Q: Why do forced password rotations often make security worse?
A: Forced rotations often push users toward predictable year-based changes, reused patterns, and weaker memorisation habits. That increases helpdesk load and can reduce real resistance to attack. Rotation is more defensible when it is triggered by a breach, anomaly, privilege change, or offboarding event rather than by the calendar.
Q: How can security teams tell whether password management is actually improving?
A: Look for fewer avoidable resets, stronger SSO coverage, and better compliance among the riskiest user groups. If helpdesk demand stays high and audit coverage remains low, the programme is still absorbing identity friction rather than reducing it. Improvement shows up in lower recovery volume and better control consistency.
Q: Which authentication flows should organisations prioritise for passwordless migration first?
A: Organisations should prioritise the highest-risk flows first, especially privileged access, cloud administration, remote access, and systems that face frequent phishing attempts. These are the places where password compromise has the greatest impact. A phased migration reduces operational friction while delivering the biggest reduction in takeover risk early in the programme.
Technical breakdown
Why composition rules miss actual password strength
Composition rules ask whether a password contains required character classes. Strength, by contrast, is about entropy, uniqueness, and resistance to patterns that attackers already test at scale. A credential like P@ssw0rd!123 can satisfy every composition rule and still fail immediately against breach corpora and cracking wordlists. A long passphrase can violate composition rules yet remain far harder to brute force or guess. The technical flaw is that composition logic optimises for visible variety, while attackers optimise for predictability, leaked-password reuse, and structural transforms that users habitually repeat.
Practical implication: stop treating character mix as a proxy for security and evaluate passwords against actual attack patterns instead.
Why runtime credential checks outperform static policy gates
A static password policy only evaluates input at a single point. A runtime credential firewall evaluates candidate passwords at every creation path, including self-service reset, admin reset, API-driven provisioning, and legacy application flows. That matters because a control is only as strong as its weakest ingress point. Runtime enforcement can reject breached passwords, predictable rotations, and context-specific guesses before a credential is written to the directory. It also allows the same policy logic to apply across channels rather than splitting enforcement between the IdP, helpdesk, and downstream stores.
Practical implication: align password checks to every credential creation path, not just the user-facing reset screen.
Why calendar rotation creates more risk than it removes
Calendar-based rotation assumes changing credentials on a fixed schedule reduces exposure. In reality, forced rotation often encourages minimal edits such as Spring2026! to Spring2027!, which preserves the underlying pattern while creating more helpdesk demand and more user friction. Event-triggered rotation is different: it responds to breach exposure, anomalous activity, role changes, or offboarding. That makes the control responsive to actual risk signals instead of an arbitrary date. The architecture shifts the control from ritualised compliance to risk-based enforcement.
Practical implication: replace blanket rotation schedules with event-triggered rules tied to compromise, privilege change, and lifecycle events.
Threat narrative
Attacker objective: The attacker wants valid user or service access by exploiting predictable password behaviour rather than breaking the cryptography.
- Entry occurs when an attacker tests breached or predictable passwords against identity providers and user-facing credential flows.
- Escalation follows when composition-compliant but guessable passwords are reused across services or rotated with trivial pattern changes.
- Impact appears as account takeover, credential stuffing success, and helpdesk overload that obscures real compromise signals.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Composition rules are a compliance mechanism, not a strength mechanism. They tell an auditor that a password contains the right mix of characters, but they do not tell an attacker anything new. In practice, the control creates the appearance of discipline while leaving users free to generate predictable patterns that cracking tools already know how to test. The practitioner conclusion is simple: governance built on composition is not governance built on resistance.
The real control plane is runtime enforcement. Password strength only becomes operational when the policy is checked against breach corpora, predictable transforms, and context-specific guesses at every issuance point. That is why password governance belongs in the lifecycle and provisioning architecture, not as a one-time rule at the point of entry. Practitioners should treat credential validation as a live control surface, not a static form constraint.
Predictable rotation is a form of identity debt. When enterprises force calendar resets, they often manufacture the very patterns attackers later exploit, especially when users make small edits to satisfy a deadline. The organisation then inherits churn, weak deltas, and false confidence in policy compliance. The practitioner conclusion is to reclassify forced rotation as a control that can degrade identity assurance when detached from real risk signals.
Credential firewall: this article’s core concept is that password policy must act like an enforcement layer across all credential creation paths, not a rule on one form. That matters because the same password can be blocked at one ingress point and accepted at another, which creates governance inconsistency and audit blind spots. For practitioners, the decisive question is coverage, not policy wording.
The breach-corpus check is the highest-value password control enterprises still underuse. A password found in leaked credential feeds is already functionally compromised, regardless of whether it meets format rules. That makes breach-corpus filtering a more direct risk reducer than complexity scoring or arbitrary rotation cadence. The practitioner conclusion is to prioritise exclusion of known-bad credentials before focusing on cosmetic password policies.
From our research library:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Read next: Guide to NHI Rotation Challenges
What this signals
Credential governance now matters more than composition policy. Teams that still rely on character-mix rules are spending effort on the wrong layer of the problem. The better control is one that blocks weak or breached credentials wherever they are created, not one that merely formats them.
Rotation policies need a lifecycle trigger, not a calendar trigger. The practical shift for identity programmes is to connect password change events to breach signals, role changes, and offboarding. That keeps the control tied to actual risk instead of a fixed administrative rhythm.
For practitioners
- Implement runtime breach-corpus checks Reject candidate passwords that appear in public or commercial breach corpora at every creation point, including self-service reset, helpdesk reset, and API-driven provisioning.
- Audit every credential creation path Map user self-service, admin reset, HR-driven onboarding, application-local stores, and automated provisioning to confirm the same password policy is enforced everywhere.
- Replace calendar rotation with event-triggered rotation Trigger password changes on breach exposure, anomalous activity, privilege changes, and offboarding instead of rotating all accounts on a fixed schedule.
- Block predictable password transforms Reject common substitutions, seasonal variants, company-name patterns, and username-based guesses so users cannot satisfy policy with trivial edits.
- Segment the remaining password surface Move the user groups that can support passwordless authentication out of the password governance problem so the firewall protects a smaller, higher-risk surface.
Key takeaways
- Password complexity rules are a weak proxy for password security because they reward format compliance, not attacker resistance.
- The evidence in this article points to predictable user behaviour, breach-corpus reuse, and helpdesk churn as the real outcomes of composition-based policy.
- The control gap is at issuance time: enterprises need runtime strength enforcement, event-triggered rotation, and coverage across every credential creation path.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Fixed rotation and persistent passwords keep credentials alive longer than the threat model allows. |
| NHI-04 — Insecure Authentication | Weak composition policy accepts credentials that attackers can easily guess or reuse from breaches. | |
| Recommendation — Reduce standing password exposure by tying credential changes to risk signals instead of calendar dates. Enforce breached-password screening and reject predictable credential patterns at issuance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | This article centres on password issuance, change, and lifecycle controls covered by authenticator management. |
| Recommendation — Apply IA-5 to govern password creation, change, and verification across every identity path. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Password policy is part of access assurance and entitlement control within the identity stack. |
| Recommendation — Use PR.AA-05 to align credential policy with actual access assurance rather than form-based compliance. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article discusses lifecycle handling of credentials and account changes across the enterprise. |
| Recommendation — Use CIS-5 to keep account changes, resets, and deprovisioning tied to governed identity processes. | ||
Key terms
- Credential firewall: A credential firewall is a runtime policy control that screens passwords before they are accepted into an identity store. It rejects weak, breached, or predictable credentials at the point of creation, which makes the control effective only when every provisioning and reset path is covered.
- Breach-corpus screening: Breach-corpus screening checks a candidate password against known leaked credential datasets before it is stored. It prevents users from choosing passwords that are already in attacker wordlists, which is far more useful than relying on visible character complexity alone.
- Event-triggered rotation: Event-triggered rotation changes credentials when a risk event occurs, such as exposure, suspicious activity, role change, or offboarding. It replaces fixed calendar rotation with a policy tied to actual security signals, which is a better fit for modern identity governance.
- Composition Rule: A composition rule is a password policy that requires certain character types, such as uppercase letters, numbers, or symbols. It is easy to audit but weak as a security measure because it measures format, not actual resistance to guessing or reuse.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org