Notifications
Clear all
Topic starter
24/06/2026 8:43 pm
TL;DR: Composition-based password rules measure character variety, not real resistance to brute force or credential stuffing, and NIST 800-63B has treated them as an outdated proxy since 2017 according to Avatier. The security case now belongs to length, breach-corpus exclusion, and runtime policy enforcement, because calendar rotation and predictable transforms keep producing the same weak patterns.
NHIMG editorial — based on content published by Avatier: Password complexity debate in 2026
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams implement stronger password policy without relying on complexity rules?
A: Use runtime enforcement instead of composition-only checks.
Q: Why do complexity rules fail to improve password security in practice?
A: Because they measure visible character variety rather than attacker resistance.
Q: What breaks when password rotation is based on the calendar instead of risk events?
A: Calendar rotation creates unnecessary churn while missing the moments that actually change risk, such as leaked credentials, anomalous access, role changes, and offboarding.
Practitioner guidance
- Audit every credential creation path Map user self-service resets, helpdesk resets, API provisioning, password imports, and legacy application stores.
- Replace complexity checks with breach-corpus screening Reject credentials that appear in known leaked-password datasets and block common predictable transforms such as seasonal suffixes and symbol substitutions.
- Tie rotation to identity events Trigger password rotation on breach exposure, anomalous access, role changes that cross privilege boundaries, and offboarding.
What's in the full article
Avatier's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step credential firewall design across self-service reset, helpdesk reset, and API-driven provisioning paths
- The runtime checks used to block breached passwords, predictable transforms, and contextual guesses before storage
- The event-triggered rotation workflow tied to breach exposure, role changes, and offboarding
- The implementation sequence for integrating password policy with lifecycle management and legacy directories
👉 Read Avatier's analysis of password strength versus complexity in 2026 →
Password complexity rules: what should IAM teams change now?
Explore further
25/06/2026 5:29 am
Composition-based password policy is a compliance artifact, not a strength model. The industry kept a 1990s control because it was easy to audit, not because it mapped to attacker behaviour. That assumption failed once attackers started exploiting breach corpora, predictable transforms, and credential stuffing at scale. The implication is that password governance cannot be judged by policy wording alone; it must be measured by whether the policy blocks known attacker input patterns.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when password policy allows predictable or reused credentials?
A: IAM and security owners are accountable because the control design failed to stop known-bad inputs at creation time. If policy still permits weak but compliant-looking passwords, the issue is governance, not user behaviour. Organisations should align the policy with NIST SP 800-63B and lifecycle controls.
👉 Read our full editorial: Password complexity rules fail in 2026: strength needs runtime enforcement
