What should organisations improve first: password rules or password enforcement?

Why This Matters for Security Teams

Password rules often look strong on paper while enforcement remains inconsistent in the systems that actually authenticate users. That gap matters because attackers do not need to defeat the written policy if they can exploit exceptions, legacy directories, shared accounts, recovery flows, or application-level bypasses. Current guidance from the NIST Cybersecurity Framework 2.0 puts emphasis on reducing preventable identity risk through operational controls, not just policy language. The same lesson shows up in NHI environments, where weak governance around secrets and service accounts turns “strong rules” into little more than documentation. NHI Management Group’s Ultimate Guide to NHIs reports that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which is a reminder that enforcement failures create the real exposure.

In practice, many security teams discover weak password enforcement only after an account takeover, helpdesk abuse, or a legacy application exception has already been exploited.

How It Works in Practice

Improving enforcement first means closing the places where policy can be bypassed, then tightening the policy itself. That usually starts with the authentication stack, not the password complexity text. Security teams should verify that password length, breach checks, retry limits, lockout thresholds, session controls, and recovery steps are enforced centrally and consistently across all identity providers and applications.

A practical sequence looks like this:

• Inventory every login path, including SSO, local accounts, service portals, and password reset flows.
• Find exceptions where a legacy app, admin console, or vendor integration ignores central policy.
• Enforce minimum length and banned-password checks at the identity layer, not only in the application UI.
• Harden recovery with stronger proofing and remove weak fallback methods where possible.
• Instrument logging so failed attempts, resets, and bypasses are visible in one place.

That approach aligns with lessons from NHI operations, where control gaps around rotation and offboarding often matter more than the written standard itself. The same is true in incidents like the ASP.NET machine keys RCE attack, where insecure handling and weak enforcement around secrets led to compromise despite the presence of a control framework. For broader control design, NIST Cybersecurity Framework 2.0 is useful because it treats identity protection as an operational discipline rather than a policy-only exercise.

These controls tend to break down when organisations run multiple identity stacks with separate reset and lockout logic because no single team owns end-to-end enforcement.

Common Variations and Edge Cases

Tighter password enforcement often increases operational overhead, requiring organisations to balance stronger protection against user friction, helpdesk load, and legacy compatibility. That tradeoff is real, especially when older applications cannot support modern policy checks or when business processes depend on shared access.

There is no universal standard for this yet, but current guidance suggests handling edge cases by risk tier. High-value systems should get the strongest enforcement first, including phishing-resistant authentication where feasible, while lower-risk internal tools may need transitional controls until they can be modernised. Recovery flows deserve special attention because weak reset procedures can undo otherwise strong password policy. Shared accounts, emergency access, and third-party admin paths should also be treated as exceptions requiring separate control design, not as reasons to weaken the baseline.

For NHI-heavy environments, the same principle applies to secrets and API credentials: rule changes mean little if enforcement is absent in CI/CD, code repositories, or vault configurations. That is why organisations should review both human and non-human enforcement points together, using the discipline reflected in NHI Management Group’s Ultimate Guide to NHIs and the control priorities in the NIST Cybersecurity Framework 2.0.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Should organisations prioritise simulation clarity or campaign volume first?
• Password Policy Enforcement
• How do organisations operationalise NHI ownership at scale?