Account fraud detection: what IAM teams need to change now

TL;DR: Account fraud now hinges on legitimate credentials, hijacked sessions, and blended-in activity, with the article citing FBI complaints, phishing prevalence, and a 1.2 million-account banking database exposure as evidence that point-in-time checks are not enough, according to Imprivata. Detection has to move from login verification to continuous identity context, cross-system correlation, and response orchestration.

NHIMG editorial — based on content published by Imprivata: account fraud detection and the shift from login checks to continuous identity analysis

By the numbers:

• In early 2026, a single compromised account belonging to a French government official enabled access to a database with details for over 1.2 million banking accounts.
• In a November 2025 public service announcement, the FBI reported more than 5,100 complaints of account takeover fraud since January 2025, with losses exceeding $262 million.
• Recent research shows that between 80-90% of cyberattacks are phishing attacks, and 67% of data breaches start when someone unknowingly clicks a malicious link.

Questions worth separating out

Q: How should security teams detect account fraud beyond password checks?

A: Security teams should combine authentication data with behavioural and contextual signals such as device posture, location, timing, and action sequence.

Q: Why do valid sessions create such a large fraud risk?

A: Valid sessions are dangerous because they let attackers inherit an authenticated state without repeating the password or MFA challenge.

Q: What breaks when identity data is scattered across many tools?

A: Fraud patterns become much harder to recognise when logs sit in separate identity, endpoint, VPN, application, and SIEM systems.

Practitioner guidance

• Instrument post-authentication behaviour Track device posture, location, action sequence, and resource access after login so a valid credential does not end the detection process.
• Separate session controls from login controls Treat active sessions as a distinct control surface and revoke or rebind them when cookies, tokens, or behaviour diverge from the expected user pattern.
• Correlate identity telemetry across systems Join identity provider, application, endpoint, VPN, and SIEM data so repeated infrastructure, shared device traits, or coordinated attempts can be seen as one fraud pattern.

What's in the full article

Imprivata's full article covers the operational detail this post intentionally leaves for the source:

• The article breaks down the specific fraud patterns teams should map, including credential stuffing, phishing, session hijacking, and account takeover.
• It explains how ITDR changes the response model by connecting detection to session revocation, account suspension, and investigation workflows.
• It outlines the practical signals used for behavioural baselining, such as first-time device use, unusual access paths, and atypical action sequences.
• It ties the account fraud problem to business loss, regulatory exposure, and customer trust erosion in a way that supports internal reporting.

👉 Read Imprivata's analysis of account fraud detection and ITDR →

Account fraud detection: what IAM teams need to change now?

Explore further

View Full Forum →  |  NHI Foundation Course →