What should teams do when users keep choosing weak passwords?

Why This Matters for Security Teams

When users keep selecting weak passwords, the problem is usually not just user discipline. It often indicates that the policy is too permissive, the prompts are too vague, or the enforcement path is so frustrating that people find ways around it. NIST’s NIST Cybersecurity Framework 2.0 treats identity and access as a control function, which is the right lens here: repeated weak-password choices are evidence that the control design is failing to shape secure behaviour. In practice, teams should look at whether the password policy still relies on composition rules, whether reused passwords are slipping through, and whether helpdesk or application exceptions are undermining the intended standard. The question is not only whether the password is weak, but whether the surrounding process makes strong choices realistic. NHI Management Group’s Ultimate Guide to NHIs shows how often identity controls fail when governance is weak; the same pattern appears with human authentication when control design does not match real usage. In practice, many security teams encounter repeated weak-password reuse only after account compromise or mass lockout events have already exposed the flaw in the policy design rather than through intentional control testing.

How It Works in Practice

The first step is to tighten rejection logic so the system actually blocks weak passwords, not merely advises against them. That means checking against breached-password lists, rejecting common variants, and preventing simple transformations of known passwords. Current guidance suggests moving away from legacy composition rules, because adding symbols or mixed case does not reliably improve resistance if users can still choose predictable patterns. Good enforcement should be paired with better feedback. If a password is rejected, the system should explain why in clear language and, where possible, point the user toward an acceptable alternative pattern. Security teams should also verify that internal exceptions are not creating a bypass path. For example, if one legacy application still accepts short or common passwords, users will adapt to the weakest rule they encounter. A practical response usually includes:

• checking passwords against a breach corpus and denylist;
• removing unnecessary complexity rules that confuse users without improving security;
• supporting longer passphrases instead of arbitrary character-mix requirements;
• reviewing password reset flows, helpdesk overrides, and application-specific exceptions;
• tracking repeated rejection events as a signal of policy friction.

That last point matters because repeated failures often mean the policy is too hard to follow, not that users are indifferent. NIST guidance on modern digital identity practices aligns with this approach, and the Ultimate Guide to NHIs reinforces the broader lesson: controls fail when they are not operationally enforceable at scale. These controls tend to break down when multiple identity systems, legacy apps, and helpdesk-driven overrides create inconsistent password rules across the environment.

Common Variations and Edge Cases

Tighter password enforcement often increases user friction, requiring organisations to balance stronger rejection logic against login fatigue and support burden. That tradeoff is real, especially in environments with older applications, shared administrative workflows, or external user populations. One common edge case is where password policy is technically strong but operationally inconsistent. If SSO enforces one standard while downstream apps retain their own weaker rules, users will still gravitate toward the easiest path. Another is when repeated weak-password selection is actually a symptom of poor onboarding or password manager incompatibility. In those cases, the right fix may be to improve generation support rather than keep raising complexity. There is no universal standard for this yet, but current guidance suggests measuring how often users hit password rejection, how often helpdesk resets occur, and whether those patterns cluster around specific systems or teams. If they do, that usually points to a design issue, not a training issue. Security teams should also watch for accessibility concerns, because control changes that ignore legitimate user constraints can create workarounds that are even weaker than the original password problem. When that happens, the organisation has not reduced risk, it has merely shifted it into informal processes.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?