What breaks when organisations rely only on password policies to stop ATO?

Why This Matters for Security Teams

Password policy is a control for choosing and changing passwords, not a defence against account takeover. Attackers do not need to guess weak passwords if they can reuse credentials from phishing, buy valid logins, or steal session tokens from malware. That is why account takeover persists even in organisations with long minimum lengths, complexity rules, and forced rotation. The control simply does not observe risk signals at login or transaction time.

NHI Management Group has repeatedly shown how identity risk becomes systemic when credentials are dispersed across systems, with the Ultimate Guide to NHIs highlighting that 79% of organisations have experienced secrets leaks and 97% of NHIs carry excessive privileges. Those conditions matter because the same weaknesses that affect service accounts also affect human accounts when organisations rely on static rules instead of runtime verification. The NIST Cybersecurity Framework 2.0 treats identity assurance as part of a broader risk program, not a password-only exercise.

In practice, many security teams discover account takeover only after fraudulent sessions, payroll diversion, or inbox abuse has already begun, rather than through intentional identity risk detection.

How It Works in Practice

Stopping ATO requires layered controls that evaluate the login, the device, and the transaction in context. Password policy still has a place, but it should sit underneath stronger controls such as phishing-resistant MFA, breached-password screening, anomaly detection, and step-up verification when behaviour changes. If a user signs in from a known device and then attempts an unusual money movement, the system should re-evaluate trust before allowing the action.

Operationally, teams should treat passwords as one signal among many:

• Use breached-password and credential-intelligence checks to block known compromised secrets.
• Enforce phishing-resistant MFA for high-value applications and privileged users.
• Bind sessions to device posture, location, and risk score where feasible.
• Apply transaction-level verification for payment, payroll, admin, and support actions.
• Monitor impossible travel, new device enrolment, token replay, and anomalous API use.

This approach aligns with the identity guidance in the Top 10 NHI Issues, because static credentials create a lasting attack surface whether the identity is human or machine. For human users, the most useful model is still risk-based access under NIST Cybersecurity Framework 2.0: detect, decide, and respond at the point of use, not just at password creation or reset.

These controls tend to break down in legacy applications that only support password-only authentication or cannot consume modern risk signals without custom integration.

Common Variations and Edge Cases

Tighter authentication often increases user friction, so organisations need to balance takeover resistance against business continuity, help desk volume, and application compatibility. That tradeoff is real, but current guidance suggests the risk of ATO is usually higher than the inconvenience of additional verification for sensitive actions.

There is no universal standard for this yet, but most mature programs distinguish between low-risk sign-in and high-risk transaction control. A user may be allowed to authenticate with one factor for a low-value workflow, while wire transfers, inbox forwarding, API key resets, and privilege elevation require stronger assurance. This is where password policy fails most obviously: it treats all authentications as if they carry the same risk.

Teams should also account for password manager misuse, session theft, and MFA fatigue attacks. In those cases, the attacker may never need to crack the password at all. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because auditors increasingly expect evidence of compensating controls, not just password rules, when identity compromise has enterprise impact.

In mixed environments with legacy SSO, service desks, and shared accounts, password policy remains necessary but cannot be the primary ATO defence.

Related resources from NHI Mgmt Group

• What breaks when organisations stop at AI inventory and do not enforce policy?
• What breaks when organisations rely on SSPM without identity governance?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• What breaks when organisations rely only on password complexity rules?