Notifications
Clear all
Topic starter
12/07/2026 12:26 pm
TL;DR: Fraudsters are using stolen consumer data to pass insurance application flows and open fictitious policies, with one example showing how auto-filled form fields can be scraped and reused for downstream fraud, according to Prove Identity. The control failure is not just verification strength but the order of operations: proof the person before exposing sensitive data.
NHIMG editorial — based on content published by Prove Identity: What Goes Wrong for Insurers Who Don't Get Identity Right
By the numbers:
- Someone becomes a victim of identity theft every 14 seconds in the US.
- In 2020 alone, victims filed 2.2 million reports with the FTC.
- Up to 33% of all Americans have been victims of identity theft.
Questions worth separating out
Q: How should insurers prevent application fraud in digital onboarding flows?
A: Insurers should require identity proofing before any sensitive data is disclosed or auto-filled to the applicant.
Q: Why do stolen consumer records create such a large fraud risk for insurers?
A: Because stolen records contain enough detail to satisfy many basic onboarding checks, especially when systems rely on static data entry alone.
Q: What do security teams get wrong about identity verification for support requests?
A: They often rely on static personal data, a return call, or a quick manager check as if that were enough to defeat social engineering.
Practitioner guidance
- Move identity proofing to the first trust gate Require assurance before any workflow reveals data that could help a fraudster complete or reuse an application.
- Inventory pre-authentication disclosures in onboarding flows Map every field, lookup, and autocomplete step that occurs before the user is verified.
- Add cryptographic and device-based signals to verification Use possession, reputation, and ownership signals together so a stolen data set alone cannot satisfy the entire assurance requirement for high-risk transactions.
What's in the full article
Prove Identity's full article covers the operational detail this post intentionally leaves for the source:
- The specific Prove Pre-Fill workflow and how verified consumer data is used during onboarding.
- The three-part PRO check in more detail, including possession, reputation, and ownership.
- How cryptographic authentication is positioned for seamless MFA in consumer journeys.
- The NAIC anti-fraud working group context and why insurance governance is changing.
👉 Read Prove Identity's analysis of identity fraud in insurance onboarding →
Insurance application fraud: what identity teams need to fix now?
Explore further
12/07/2026 12:38 pm
Identity proofing is the control that determines whether the rest of the onboarding workflow is safe to execute. The article shows that if a customer is not verified before sensitive data is exposed, the organisation has already lost the first trust decision. That is a governance problem, not just a UX defect. Practitioners should treat pre-authentication disclosure as an identity control boundary.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why trust boundaries need explicit ownership and lifecycle review.
A question worth separating out:
Q: Who is accountable when onboarding design enables identity fraud?
A: Accountability sits with the teams that own identity assurance, customer onboarding, fraud controls, and privacy review. If the flow exposes data before verification, the control failure is architectural, not just operational. Frameworks such as fraud governance and access assurance should be applied to the full journey, not one step.
👉 Read our full editorial: Identity proofing failures are driving insurance application fraud
