Why does account takeover keep rising even when organisations invest in authentication controls?

Why authentication controls do not stop takeover by themselves

Authentication answers a narrow question, namely whether the caller can prove possession of a factor or secret at sign-in. account takeover rises when attackers no longer need to defeat that gate cleanly, because they can buy, steal, replay, or phish what the gate trusts, then move through the account after the login event has already succeeded.

The practical weakness is that many organisations still measure success at the point of authentication, not across the full session and transaction lifecycle. Controls that only harden enrolment or login can leave stolen cookies, token replay, consent abuse, or session hijacking untouched, so the account remains usable even when the password or MFA prompt was never directly “broken”.

Attackers also benefit from the fact that identity proof is not the same as intent validation. A valid login does not prove the device, location, behaviour, or transaction context is benign, which is why Microsoft Midnight Blizzard breach and Uber Breach both show that strong-looking authentication can still be followed by meaningful abuse when the attacker can drive the session or exhaust human approval paths.

Why stolen data and automation make takeover easier at scale

Account takeover is increasingly a data problem as much as an authentication problem. Breaches, credential dumps, and exposed personal data give attackers the raw material to answer recovery questions, craft believable phishing, bypass weak identity proofing, and impersonate users or support staff with enough context to survive basic checks.

Automation multiplies that advantage. Generative AI helps attackers produce more convincing lures, deeper social-engineering variants, and faster impersonation attempts, which reduces the cost of trial and error. The result is not just more login attacks, but more attempts to reuse the same identity signal across recovery, help desk, and session-authorised actions.

This is why session visibility matters alongside login strength. If an organisation can only see failed password checks or MFA prompts, it may miss the later stage where a valid session is abused, a refresh token is replayed, or an attacker pivots into payment, profile, or support workflows. GitLocker GitHub extortion campaign is a useful reminder that stolen credentials often become a platform for broader misuse once the initial boundary is crossed.

One stat that captures the scale of the problem: Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That figure matters here because it shows how often attackers prefer the easier authentication path, the one that is already trusted and difficult to distinguish from legitimate session activity.

What organisations should measure if they want takeover to fall

The right response is to widen measurement from authentication success to authenticated behaviour. Teams should ask whether the account can be re-used safely after sign-in, whether session lifetime is too generous, whether recovery and support channels can be abused, and whether anomalous actions can be detected before funds, data, or permissions are changed.

• Track impossible travel, device drift, token reuse, and new-session creation after risky login events.
• Review whether password reset, MFA reset, and help desk flows are easier to exploit than the login page itself.
• Correlate authentication with high-risk actions, not just with access granted.
• Test whether stolen cookies, refresh tokens, or social-engineering paths can bypass the controls you count as “strong MFA”.

For governance and control design, session oversight should be treated as a first-class control surface rather than a monitoring add-on. That means limiting token lifetime where possible, tying sensitive actions to re-authentication or step-up checks, and making sure alerts are generated on suspicious post-login behaviour, not only on failed login attempts.

Practitioner takeaway: If your control story ends at sign-in, you are measuring the wrong boundary. The accounts that get taken over are usually the ones whose sessions, recovery paths, and post-auth actions remain too easy to reuse after the initial authentication step has passed.

Related resources from NHI Mgmt Group

• Why do stronger authentication controls reduce account takeover risk?
• Why do static authentication controls fail against modern account takeover?
• Why do organisations still face account takeover risk even after deploying FIDO-based passkeys?
• When does multi-factor authentication still leave organisations exposed to account takeover?