What should security teams do first when password complexity rules are still in place?

What to remove first from a password policy

Start with the rules that create predictable user behaviour without materially improving resistance to attack: composition requirements that force awkward patterns, and periodic password expiry that drives incremental changes. Those controls often make passwords easier to predict or reuse, while adding friction for users and service desks. Replace them with length, screening, and stronger authentication for higher-risk journeys.

When you remove complexity rules, the policy should become simpler, not weaker. Longer passwords and passphrases are harder to guess than short but “complex” strings, and compromised-password blocklists catch many real-world takeover attempts better than symbol-counting rules. For sensitive actions, step up to phishing-resistant authenticators rather than relying on password quality alone.

That shift also changes the operational model. Security teams need to treat recovery, password reset, and exception handling as part of the policy, because those flows can quietly reintroduce weak checks or bypass the new standards. If the reset path is easier to abuse than the sign-in path, the policy change will not deliver the intended gain.

How to replace complexity with stronger password control

The practical replacement is a policy built around resistance to guessing, reuse, and known-compromised secrets. A modern password control approach focuses on minimum length, checks against blocklists of breached passwords, and sensible rate limiting or lockout logic, rather than trying to engineer character mixtures that users defeat with predictable substitutions. NHIMG’s Password Security and Password Manager Guide covers that shift in more detail.

For administrators, this usually means separating ordinary authentication from high-risk or privileged journeys. Everyday sign-in can often be improved by removing forced rotation and composition rules, but access to admin functions, finance actions, or account recovery should be protected with a stronger authenticator and tighter step-up requirements. The goal is to make the password itself one layer in a broader access decision, not the only line of defence.

Longer passwords, password managers, and reusable-user-unfriendly policy defaults help because they reduce human workarounds. The common failure mode is keeping the old complexity policy while adding new checks on top, which preserves frustration without meaningfully reducing takeover risk. A clean policy reset is usually more effective than a layered patchwork of conflicting rules.

What to validate after the policy change

After the change, validate the full identity journey, not just the main login form. Reset, self-service recovery, help desk verification, MFA enrolment, and account unlock flows should all match the same security intent, or attackers will target the weakest path. If one route still allows weak passwords, short secrets, or insecure fallback, it becomes the policy’s real control point.

It is also worth checking that your password policy does not unintentionally weaken other controls. For example, very aggressive lockouts can create denial-of-service risk, while weak recovery questions can undermine stronger authentication at the front door. The right validation question is whether the revised policy makes compromise harder in practice, not whether it simply looks stricter on paper.

Risk and Threat Considerations

Complexity rules and forced rotation often fail by creating predictable user behaviour: incremental changes, reused patterns, and passwords that are easier to guess or phish. The risk is not just user annoyance, it is that the policy can make credential attacks more efficient while giving teams a false sense of control.

Failure mechanism: Users respond to awkward rules with predictable substitutions, recycled bases, or unsafe storage habits, while periodic expiry encourages the next password to be only marginally different from the last.

Impact: Attackers benefit from lower-entropy secrets, easier guessing, and more reuse across services, while defenders absorb more support load without a corresponding security gain.

Practitioner Guidance

What to prioritise: Remove the controls that create predictable behaviour first, then replace them with length-based rules, compromised-password screening, and step-up authentication for sensitive actions. That sequence matters because it reduces user friction while preserving security signal.

What to verify: Test the entire account lifecycle, especially recovery and reset, against the new policy. If those paths still permit short, reused, or weakly verified secrets, the front-end password rule is not the control that determines real risk.

Practitioner takeaway: The first job is not to make passwords “harder” in the abstract, but to remove rules that encourage bad password behaviour and ensure every alternate access path is at least as strong as sign-in.

Related resources from NHI Mgmt Group

• What should security teams do first when password resets are still used as a primary control?
• What should security teams do first when they still rely on password-only authentication for some resources?
• What should security teams do first when manual credential rotation is still in place for on-prem systems?
• What should security teams do first when passwords can still be compromised even with MFA in place?