Identity proofing failures are driving insurance application fraud

At a glance

What this is: This is an analysis of how identity fraud exploits insurance onboarding flows, with the key finding that pre-authentication data exposure can turn customer convenience features into fraud-enabling control gaps.

Why it matters: It matters because insurers and any IAM programme handling consumer onboarding need to treat identity proofing as a first-step control, not a downstream check, or they risk enabling account opening fraud and regulatory exposure.

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.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Prove Identity's analysis of identity fraud in insurance onboarding

Context

Insurance application fraud is what happens when stolen or fabricated identity data is used to pass onboarding checks and create an account, policy, or claim relationship that should never have been trusted. In this article, the primary failure is sequencing: customer data is exposed before the organisation has established who is really at the other end of the interaction.

The article connects consumer identity fraud to insurance operations, but the governance lesson is broader. Any onboarding flow that reveals sensitive attributes before proofing the user creates a reusable fraud surface, especially where downstream systems trust the application data as if it were verified at the start.

For IAM, fraud prevention, and customer identity teams, the issue is not only stronger authentication. It is whether the identity programme enforces assurance before disclosure, especially when application flows, autofill logic, and verification dependencies are chained together.

Key questions

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. The key is sequencing: do not let unverified users see attributes that help them complete fraud elsewhere. Pair proofing with device, phone, and reputation signals so stolen consumer data alone cannot establish trust.

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. Once a fraudster can pass initial screens, they can open fictitious policies or reuse exposed attributes for other schemes. The risk is magnified when applications reveal more data before verification.

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. In practice, those signals can be spoofed or manipulated. Verification needs to be tied to a trusted device, stronger approval, or a controlled exception path.

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.

Technical breakdown

Application fraud and pre-authentication data exposure

Application fraud occurs when an attacker uses stolen or synthetic identity data to satisfy onboarding checks and obtain a trusted account or policy relationship. The article’s example shows a specific failure mode: auto-filled fields exposed additional sensitive data before the user was authenticated or verified, giving the fraudster material to continue the attack elsewhere. In identity terms, the system treated convenience as harmless, but that convenience became a data disclosure control failure. Once a form reveals authoritative identity attributes to an unverified party, the organisation has already reduced the attacker’s work and increased the chance of successful impersonation.

Practical implication: move identity proofing ahead of any data reveal that could strengthen a fraudulent application.

Why identity proofing has to come before onboarding completion

Identity proofing is the process of establishing that a real person is the one interacting with the system before the organisation grants trust. In this article, the insurer’s flow assumed that user input could be gathered safely before assurance was established. That assumption is wrong in high-fraud environments because the application itself becomes an attack channel. Proofing is not only about preventing account opening fraud, it also protects the confidentiality of data used to complete the onboarding step. If the system treats verification as a late-stage step, it allows fraudsters to harvest attributes that can be reused across benefits, lending, insurance, or tax fraud.

Practical implication: treat proofing as a gate to data disclosure, not only a gate to account creation.

Cryptographic authentication, possession, reputation, and ownership

The article describes cryptographic authentication and a three-part PRO check as a way to strengthen assurance. The technical point is that identity confidence comes from combining evidence, not from a single password or static data point. Possession verifies access to the device at the moment of interaction, reputation looks for suspicious phone-number behaviour such as SIM swaps or burnered numbers, and ownership links the device identity to the person. Together, these signals reduce the chance that a fraudster with stolen personal data can convincingly impersonate a legitimate consumer across the application flow.

Practical implication: combine device, phone, and identity signals to raise assurance before approving high-risk onboarding actions.

Threat narrative

Attacker objective: The attacker’s objective is to create trusted insurance relationships under false identities so the fraud can be monetised later through claims or downstream benefit abuse.

1. Entry occurs when fraudsters obtain consumer information from breaches or other schemes and use it to begin an insurance application that appears legitimate.
2. Escalation occurs when the onboarding flow auto-fills additional sensitive attributes before identity is verified, giving the attacker more data to reuse and more confidence to pass checks.
3. Impact occurs when fictitious identities are opened successfully and later used for fraudulent claims, reputational damage, and regulatory scrutiny.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• McKinsey AI platform breach — McKinsey AI platform hack exposed 46M chats and sensitive data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Proof-before-disclosure is the right named concept for insurance onboarding risk. The system should establish assurance before revealing authoritative identity attributes, because those attributes are often the very material attackers need to complete fraud elsewhere. This is especially important where autofill, third-party data enrichment, or assistive onboarding tools increase the amount of information shown before verification. Practitioners should review every onboarding step for data that should never be visible to an unverified user.

Consumer identity fraud and NHI governance are converging on the same control question: what is trusted, and when. Human onboarding flows and non-human credential flows both fail when trust is granted too early or too broadly. The difference is that insurers usually see the human surface first, while the operational lesson extends to machine access, API trust, and delegated identity workflows. Practitioners should align assurance boundaries across both consumer and machine identity programmes.

Identity theft scale makes onboarding controls a business resilience issue, not a narrow fraud issue. When identity theft is already occurring at national scale and application flows can leak data before verification, the operational cost shows up as claims fraud, regulatory pressure, and customer trust loss. The governance lesson is that identity assurance needs to be designed as a fraud containment layer. Practitioners should measure whether their onboarding design prevents data amplification as well as fake-account creation.

From our research:

• 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.
• For a broader breach pattern view, 52 NHI Breaches Analysis shows how identity failures compound when credentials, access scope, and offboarding are weak.

What this signals

Proof-before-disclosure is the practical governance shift this article points to. Insurance onboarding teams should stop treating verification as a single event and start treating it as a gate that protects every downstream attribute. The more data a flow reveals before assurance, the more useful it becomes to fraudsters and the harder it is to contain the harm.

The broader programme signal is that consumer IAM, fraud operations, and privacy controls need one shared control model. Identity assurance is no longer just about logging in or opening an account. It now has to prevent data amplification, suspicious reuse, and unauthorised onboarding at the same time.

Teams that already track identity risk should add a simple question to every flow review: would this step still be safe if the user were fraudulent? That question often surfaces the exact place where assurance, disclosure, and onboarding order have drifted apart.

For practitioners

• 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. That includes pre-fill logic, enrichment lookups, and surfaced account attributes.
• Inventory pre-authentication disclosures in onboarding flows Map every field, lookup, and autocomplete step that occurs before the user is verified. Prioritise flows that expose driver’s licence numbers, contact data, or other reusable identity attributes.
• 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.
• Re-evaluate fraud controls in shared identity journeys Review insurance onboarding, claims, and account recovery as one identity system rather than separate checkpoints. Fraud often succeeds when trust is established in one step and reused in the next.

Key takeaways

• Insurance application fraud succeeds when onboarding exposes data before identity is proven.
• The scale of identity theft makes weak proofing a business and regulatory problem, not only a fraud problem.
• The most effective fix is to verify first, then disclose, then complete the transaction.

Key terms

• Identity Proofing: Identity proofing is the process of establishing that a real person is who they claim to be before the organisation grants trust. In consumer onboarding, it determines whether later steps can safely expose data, open accounts, or approve transactions.
• APP Fraud: Authorised push payment fraud happens when a victim is manipulated into approving a payment to a criminal account. Because the payment is user-authorised in form, reimbursement and accountability rules often shift the burden onto banks, making identity assurance at the point of approval financially critical.
• Proof Before Disclosure: Proof before disclosure is a control pattern that requires identity assurance before the system reveals sensitive attributes to the user. It reduces the chance that an attacker can use onboarding data to strengthen fraud in the same or a different channel.
• Cryptographic Authentication: Authentication that relies on cryptographic proof rather than easily copied or guessed factors. In consumer identity, it binds the user or device to a verifiable trust signal, which improves assurance, reduces replay risk, and makes transaction decisions easier to audit.

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.

👉 The full Prove Identity post covers the fraud use case, onboarding controls, and the PRO check model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.