TL;DR: Only 7% of organizations say they are more than moderately prepared to detect or prevent AI-powered fraud, according to Trusona and the ACFE and SAS Anti-Fraud Technology Benchmarking Report, even as AI use in anti-fraud analysis rises and deepfake-enabled impersonation tactics accelerate. The readiness gap is fundamentally an identity verification problem, not an analytics problem.
NHIMG editorial — based on content published by Trusona: AI-powered fraud readiness and identity impersonation risk
By the numbers:
- Only 7% of organizations say they are more than moderately prepared to detect or prevent AI-powered fraud.
- A quarter of organizations, 25%, now use AI or machine learning in anti-fraud data analysis.
- Another 28% of organizations plan to adopt AI or machine learning in anti-fraud programs within two years.
Questions worth separating out
Q: What breaks when organizations rely on knowledge-based verification for AI-powered fraud?
A: Knowledge-based verification breaks because the answers are often guessable, breached, or publicly available, especially when attackers use AI to sound convincing in real time.
Q: Why do AI-driven fraud tactics create new pressure on traditional identity verification?
A: AI lowers the cost of fraud by making synthetic identities, deepfakes, and automated account takeover faster and more convincing.
Q: How do security teams know if impersonation detection is actually working?
A: It is working if high-risk requests are consistently challenged, blocked, or escalated when the claimant cannot satisfy stronger proofing controls.
Practitioner guidance
- Replace knowledge-based verification Retire identity questions that depend on public or breached data, and require stronger proofing for password resets, MFA recovery, and high-risk support requests.
- Add layered impersonation checks Combine government-issued ID verification, SIM swap detection, and session integrity checks for help desk and call-center interactions that can lead to account takeover.
- Tighten privileged support workflows Require step-up approval, call-backs to verified numbers, and ticket-linked audit trails before any support action that changes authentication or recovery state.
What's in the full report
Trusona's full article covers the operational detail this post intentionally leaves for the source:
- The ACFE and SAS benchmarking context behind the 7% readiness figure and the adoption trends that frame it.
- The specific identity impersonation scenarios in help desks, service desks, and call centres that practitioners can map to their own workflows.
- The verification capabilities behind Trusona's approach, including government ID checks, SIM swap detection, and anti-replay protections.
- The practical distinctions between analytics-led fraud tooling and real-time identity proofing at the moment of request.
👉 Read Trusona’s analysis of AI-powered fraud readiness and identity impersonation risk →
AI-powered fraud readiness: where identity verification is failing now?
Explore further
AI-powered fraud has become an identity verification problem before it becomes an analytics problem. The report’s 7% readiness figure shows that most organisations still depend on post-event detection while attacks are succeeding at the moment of impersonation. That is a governance failure in the verification layer, not just a tooling gap. Practitioners should treat real-time identity proofing as part of the control stack, not an optional fraud add-on.
A question worth separating out:
Q: Who is accountable when a help desk scam leads to account takeover?
A: Accountability is shared across identity, support, and application owners. The help desk owns the verification process, IAM owns the policy for resets and MFA changes, and application owners own whether direct login paths and recovery flows are too permissive. If any one of those layers is weak, a scam can turn into an enterprise-wide access event.
👉 Read our full editorial: AI-powered fraud readiness lags because identity impersonation wins