TL;DR: Password composition rules measure character variety, not actual resistance to cracking or credential stuffing, and they keep producing predictable patterns and helpdesk burden, according to Avatier. The real control is runtime strength enforcement with breach-corpus checks, length, and event-triggered rotation, not 90-day complexity theater.
At a glance
What this is: This is an analysis of why composition-based password complexity rules are outdated and why runtime password strength enforcement is the stronger IAM control.
Why it matters: It matters because password policy still affects human IAM, privileged access, and the credentials that anchor many NHI and service-account workflows.
👉 Read Avatier's analysis of password complexity versus strength in 2026
Context
Password complexity rules are a policy problem, not a security outcome. They ask users to satisfy character-pattern requirements that attackers already know how to predict and automate against, which is why modern guidance has moved toward length, uniqueness, and breach-corpus checks instead of composition theater.
For IAM programmes, the issue is broader than user inconvenience. Weak password policy choices affect human authentication, privileged access, and adjacent identity lifecycle controls, because the same policy logic often governs reset flows, helpdesk actions, and downstream account governance.
Key questions
Q: How should security teams implement password policy without relying on composition rules?
A: Use length, uniqueness, and breached-password screening as the primary acceptance tests, then enforce them at every password creation point. A policy that only checks for uppercase letters or symbols creates compliance theatre. The control has to work in self-service resets, helpdesk resets, automation, and legacy integrations for it to be meaningful.
Q: Why do composition-based password rules fail in practice?
A: They reward predictable user behaviour. People append numbers, capitalise the first letter, and reuse familiar patterns, which makes compliant passwords easy for attackers to guess. The rule looks strict on paper, but it often lowers real security by pushing users toward memorisable structures that are already overrepresented in breach corpora.
Q: When should organisations prioritise password length over composition complexity?
A: Always, if the goal is actual resistance to cracking. Length expands the search space far more effectively than adding a symbol or capital letter. Once a sensible minimum length is in place, organisations should prioritise breach-corpus exclusion and password uniqueness before they worry about character-class variety.
Q: What is the difference between password complexity and password strength?
A: Complexity is a visible formatting rule. Strength is the real difficulty of guessing or cracking the credential. A password can satisfy every complexity requirement and still be weak if it is short, reused, or derived from common patterns. Strength is measured by attack resistance, not by the presence of special characters.
Technical breakdown
Composition rules measure pattern, not strength
Composition-based rules count character classes, such as uppercase letters, symbols, and digits. That creates a compliant-looking password, but not necessarily a resistant one. Attackers do not test passwords by policy compliance. They use breach corpora, dictionary rules, and transformation logic that makes predictable substitutes such as capitalised first letters or numbers appended to the end. The result is a policy that rewards visible complexity while leaving real entropy low.
Practical implication: replace character-class checks as the primary gate with controls that evaluate actual resistance, including length and breached-password screening.
Credential firewall enforcement belongs at every creation point
A credential firewall is a runtime control that screens passwords before they enter the directory. It only works if every path into identity storage is covered, including self-service reset, helpdesk reset, API-driven provisioning, password import, and automation-driven creation. If one path bypasses the firewall, the policy is incomplete. This is why architecture matters more than the wording of the password rule itself.
Practical implication: audit every password creation path and enforce the same acceptance logic at each one.
Event-triggered rotation beats calendar rotation
Forced 90-day rotation is a calendar rule that ignores actual risk signals. Event-triggered rotation ties password changes to concrete conditions such as breached-password exposure, suspicious activity, role change, or offboarding. That reduces meaningless churn and targets the accounts that have actually entered a higher-risk state. The operational difference is that risk drives the change, not the date on the calendar.
Practical implication: redesign rotation policy around security events and lifecycle changes rather than fixed intervals.
NHI Mgmt Group analysis
Composition-based password policy is a compliance proxy, not a security control. The article is right to separate visible complexity from actual strength, because attackers optimise against predictable character substitutions and password corpora, not policy checklists. The deeper governance failure is that many enterprises still treat compliance-friendly password shape as evidence of resilience. Practitioners should stop equating audit pass conditions with attack resistance.
Credential firewalling is the real control plane for password governance. Password policy only matters if the same acceptance logic applies at every entry point into the identity store. Where reset, import, and automation paths bypass enforcement, the programme creates uneven trust boundaries that attackers and users both exploit. The implication is that policy design must be treated as an architecture problem, not a single setting.
Runtime password strength is where human IAM and lifecycle governance intersect. Passwords decay when they are rotated blindly, reused under pressure, or recreated through weak operational processes. That is why lifecycle events, breached-password checks, and access governance belong in the same control conversation. For IAM teams, the real question is whether credential governance is enforced continuously or only inspected after the fact.
Length and uniqueness matter more than composition, and that changes the security model. NIST-style guidance has already moved the field toward longer passwords and breach-corpus exclusion because those controls alter attacker economics. The industry problem is that many policies still optimise for symbolic compliance instead of reducing exposure. Practitioners should treat length and uniqueness as the baseline, not the bonus feature.
From our research:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
- The broader control pattern is also visible in The 52 NHI breaches Report, which shows how identity exposure turns into real incident paths across machine and service credentials.
What this signals
Credential governance is moving from policy wording to enforcement architecture. Teams that still rely on composition rules will increasingly find that audit evidence and attack resistance diverge. The next maturity step is not a more complicated password policy, but a control stack that validates strength at the moment of creation and ties it to identity lifecycle events.
The operational signal is that password policy can no longer be isolated from broader identity architecture. As organisations modernise access governance, the same discipline that applies to NHI lifecycle management and privilege control is now being applied to human credentials, especially where helpdesk resets and automation still bypass modern checks.
For practitioners
- Audit every credential creation path Map user self-service, helpdesk resets, API provisioning, import jobs, and legacy application writes to confirm that the same password acceptance logic applies everywhere.
- Enforce breached-password screening at runtime Reject credentials that appear in breach corpora before they are stored, and apply the check on every reset and provisioning path, not only at the user portal.
- Replace calendar rotation with event-driven rotation Rotate credentials when exposure, anomalous activity, role change, or offboarding changes the risk profile, and stop treating 90-day rotation as a security outcome.
- Align policy with identity lifecycle controls Connect password governance to joiner-mover-leaver events so that changes in employment status, role, or privilege boundary trigger the appropriate credential action.
Key takeaways
- Composition rules are a weak proxy for password security because they measure visible formatting, not attacker resistance.
- The security problem is structural: if any password creation path bypasses the firewall, the policy is incomplete.
- Enterprises should move to length, breached-password screening, and event-triggered rotation as the baseline control set.
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 SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | 5.1.1.2 | Password guidance here maps directly to modern verifier requirements. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and authentication controls depend on stronger credential policy. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers rotation and credential governance issues that recur in password policy debates. |
Apply runtime checks and lifecycle triggers to reduce credential exposure windows.
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.
- Password strength: Password strength is the real resistance of a credential to guessing, dictionary attacks, and brute-force attempts. It depends on length, uniqueness, unpredictability, and context, not on whether the password contains uppercase letters, symbols, or numbers.
Deepen your knowledge
NHI governance, agentic AI identity, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.
This post draws on content published by Avatier: password complexity in 2026 and the case for strength-based governance. Read the original.
Published by the NHIMG editorial team on 2025-12-03.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org