Notifications
Clear all
Topic starter
14/08/2026 6:32 pm
TL;DR: Account takeover can look contained to security teams while fraud losses emerge later, because the damaging activity often happens after login and outside the SOC view, according to Sift. The real governance problem is that security metrics, fraud metrics, and customer outcomes are still measured as separate events instead of one attack path.
NHIMG editorial — based on content published by Sift: Part 2 on how the CISO and the fraud leader see the same account takeover compromise
By the numbers:
- 65% of breached accounts had MFA enabled at, enabled at the time of compromise.
- $135 on average, e decision costs $135 on average, and up to $496 in Digital Commerce.
- Only 37% of ATO victims found out because the company or platform told them.
Questions worth separating out
Q: What breaks when account takeover controls focus only on login security?
A: Controls break after authentication, when a fraudster inherits an already trusted account and starts changing device, IP, contact details, and transaction patterns.
Q: Why do MFA controls still fail against account takeover?
A: MFA reduces password-only compromise, but it does not stop attackers who steal session tokens, hijack browsers, or obtain access through adversary-in-the-middle phishing.
Q: How do you know if account takeover controls are actually working?
A: Look for reduced successful takeovers, lower fraud losses, and preserved good-user throughput at the same time.
Practitioner guidance
- Build a post-login investigation path Correlate authentication success, recovery detail changes, device shifts, and transaction anomalies in one case workflow so the original compromise is not lost when the SOC closes the login incident.
- Share identity telemetry across fraud and SOC teams Make session lineage, device reputation, and account recovery events visible to both teams so customer losses are not treated as disconnected incidents.
- Measure loss progression after access Track time from login success to recovery change, first risky transaction, and chargeback initiation to expose the hidden interval where abuse is most likely to escalate.
What's in the full article
Sift's full article covers the operational detail this post intentionally leaves for the source:
- The step-by-step comparison between the SOC view and the fraud desk view across one account takeover chain.
- The specific metrics and survey findings Sift uses to show where visibility breaks down after login success.
- The practitioner questions the series uses to test cross-functional accountability between security and fraud teams.
- The source article's framing for how customer account takeover should be operationalised across the lifecycle.
👉 Read Sift's analysis of account takeover across security and fraud teams →
Account takeover after login succeeds: what teams are missing?
Explore further
14/08/2026 6:38 pm
Account takeover is a lifecycle failure, not a single security event. The article shows that the login success point is where security teams often stop looking, while fraud teams only see the outcome later. That split creates a governance vacuum in the middle of the account journey, where recovery changes, trusted devices, and payment abuse become invisible unless identity telemetry is shared across functions. Practitioners should treat this as an operating model problem, not a tooling problem.
A question worth separating out:
Q: Who is accountable when phishing leads to customer fraud and account takeover?
A: Accountability is shared across identity, fraud, and application owners because the attack crosses authentication, session handling, and transaction risk. The security programme should define who owns lookalike domain detection, who owns session abuse detection, and who decides when to step up or block access after suspicious login behaviour is detected.
👉 Read our full editorial: Account takeover leaves a security gap after login succeeds
