Notifications
Clear all
Topic starter
24/06/2026 10:43 pm
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
25/06/2026 7:30 am
Account fraud detection has outgrown authentication-centric IAM. Once attackers use valid credentials or live sessions, the problem is no longer whether a user can log in, but whether the resulting behaviour fits the identity's normal operating pattern. That shifts the control boundary from initial authentication to continuous identity evaluation across systems. Teams that still treat login success as proof of legitimacy are measuring the wrong event, and that is now a programme-level blind spot.
A few things that frame the scale:
- 23.5% of security professionals are unsure about the biggest threat to their non-human identities, indicating a significant awareness gap, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
A question worth separating out:
Q: Who is accountable when account takeover fraud causes downstream losses?
A: Accountability sits with the teams that own authentication, session management, fraud detection, and incident response together. If an organisation treats account takeover as only a user problem or only a security problem, it will miss the handoff points where abuse becomes loss. Frameworks such as NIST CSF 2.0 and Zero Trust help define shared responsibility.
👉 Read our full editorial: Account fraud detection is failing where identity becomes the attack path
