Synthetic identity fraud: what it is and how to catch it early

Why this matters to you

Your 2-minute quick win

Open the written procedure your team uses for remote onboarding and add one line today: any case that shows a face mismatch, odd movement, or unusual document-to-selfie inconsistency must be paused and sent to a second human check. Success looks simple. The rule is written in the team playbook, staff can point to it, and people know that a fast pass is no longer the default when a remote identity proofing session feels wrong.

Synthetic identity fraud is hard to catch because it does not look like classic identity theft. The criminal may use some real details and some fake ones. That blended profile can pass checks that were built to compare one person against one document.

ENISA describes remote identity proofing as a crucial element in creating trust for digital services. Its report focuses on the collection and validation of evidence provided by the applicant to complete identity verification. That matters here because synthetic identity fraud often appears during exactly that evidence collection stage.

The same ENISA report highlights face presentation attacks that aim to fool facial recognition systems. It names four major attack types: photo attack, video of user replay attack, 3D mask attack, and deepfake attack. A synthetic identity operation can use any of these to support a false profile during onboarding or account recovery.

This is also an AI issue. ENISA’s AI cybersecurity report stresses that AI threats should be understood across a lifecycle, from requirements analysis to deployment. If your identity workflow uses AI at any point, the trust problem is not only the applicant. It is also the security of the AI ecosystem, its assets, and the data protection around it.

For mid-market and enterprise teams, the risk grows with scale. More remote customers, more contractors, more digital account changes, and more self-service verification all create more chances for a stitched identity to look normal.

Why synthetic identities slip through

Many controls were designed for stolen identities, not invented ones. They ask, in effect, whether this person matches this document. They do not always ask whether the whole identity story makes sense over time.

Fraudsters exploit that gap. If one real data point helps them open the door, they can add false details that are hard to disprove in a single session. A clean image, a plausible name, and a successful liveness step may create false confidence.

Remote checks also compress decision time. Staff may have only minutes to review a session. That makes it easier to miss a replayed video, a static photo held in front of a camera, or a deepfake that looks good enough on a small preview.

What you are protecting

You are protecting the trust your organisation places in a claimed identity. That trust decides who gets an account, who can reset one, who can receive payments, who can sign up as a supplier, and who can access internal systems.

At a practical level, you are protecting the evidence gathered during remote identity proofing. ENISA frames this as collection and validation of evidence from the applicant. If either part is weak, a false identity can be accepted as genuine.

You are also protecting your facial recognition step from presentation attacks. ENISA explicitly lists photo attack, video of user replay attack, 3D mask attack, and deepfake attack. Each one can make a non-genuine applicant appear present during a remote session.

Your organisation is also protecting the wider AI and identity ecosystem around that process. ENISA’s AI report says that identifying assets is a fundamental step in pinpointing what needs protection and what could go wrong. In this context, assets include identity data, captured images, verification models, workflow rules, staff decisions, and the audit trail that shows why an identity was accepted.

For enterprise teams, this is not only about onboarding customers. The same weakness can affect partner portals, expense fraud checks, contractor vetting, privileged access requests, and internal help desk resets.

What a fraudster wants from a synthetic identity

A synthetic identity gives a criminal room to operate. Because the identity is partly invented, normal victim reports may come late or never. That delay gives more time to build account history, request more access, or move money and goods.

The fraudster also wants durability. A fully stolen identity may trigger a complaint quickly. A synthetic one may survive longer because there is no single real person checking every detail.

That is why early detection matters. Once a synthetic identity gains a foothold, later checks may trust the history that the fraudster created.

What it costs you if you skip this

The first cost is bad access. You may give an account, service, or entitlement to someone who should never have received it. Once that happens, every later control starts from a false assumption.

The second cost is bad data. If a synthetic identity enters your systems, downstream teams may treat it as a normal customer, employee, or supplier record. That can distort investigations, billing, support history, and audit evidence.

The third cost is weak incident response. ENISA’s AI report stresses the need to identify assets and classify threats across lifecycle stages. If you do not know which part of your remote identity proofing stack was trusted, you will struggle to find whether the failure came from evidence capture, facial matching, workflow logic, or human approval.

You also face avoidable operational strain. A fraud case discovered late usually triggers manual clean-up across support, security, legal, finance, and operations. A short pause at onboarding is cheaper than a long cross-team recovery later.

There is a trust cost as well. Remote identity proofing exists to create trust for digital services, as ENISA notes. If staff stop trusting the output of the process, they either wave risky cases through or block too many legitimate users. Both outcomes are expensive.

The hidden cost of fast approvals

Fast approval feels efficient, but speed can hide weak controls. A team that rewards only low handling time teaches reviewers to ignore subtle signs of a replay, a mask, or an AI-generated face.

That creates a dangerous loop. The cleaner the fraud session looks, the more the process trusts automation alone. Synthetic identity fraud thrives in that gap between technical confidence and human doubt.

Step by step

1. Open your remote onboarding or account recovery procedure and add a named escalation step called 'second human check for presentation attack signs'. Done correctly, staff can see that exact step in the document or workflow and know when to use it.

2. In the same procedure, create a short checklist that names ENISA’s four face presentation attack types: photo attack, video of user replay attack, 3D mask attack, and deepfake attack. Done correctly, the checklist appears on the reviewer screen or in the case file, not only in a training deck.

3. Map where your organisation uses remote identity proofing. Include onboarding, password reset, account recovery, supplier set-up, contractor intake, and high-risk profile changes. Done correctly, you have one visible list of business processes, owners, and the evidence each process collects.

4. List the assets involved in each flow, following ENISA’s asset-first approach for AI systems. Write down the identity data, captured images, facial recognition component, workflow rules, approval logs, and stored audit trail. Done correctly, each flow has an asset list that a non-specialist can read and use.

5. For each flow, note which evidence is collected from the applicant and how it is validated. Done correctly, the case record shows both parts clearly: what was submitted and what checks were applied before approval.

6. Add a visible pause point before final approval for any case with image quality issues, unusual movement, partial face coverage, or mismatch between the person on screen and the claimed identity story. Done correctly, the reviewer sees a clear option to pause, not only approve or reject.

7. Require a second reviewer for high-risk cases, such as first-time large transactions, privileged access requests, or changes to key account details made soon after onboarding. Done correctly, the case cannot be completed until the second approval is present in the audit trail.

8. Keep the evidence trail together. Store the submitted images, the decision notes, and the final approval record in the same case file or linked system record. Done correctly, an investigator can open one place and see what was presented, what was flagged, and who accepted it.

9. Train reviewers using plain examples of the four ENISA attack types. Show what a static photo attempt might look like, what a replayed video might look like, why a 3D mask can flatten natural cues, and why a deepfake may appear convincing at first glance. Done correctly, reviewers can name the attack type they suspect instead of writing vague notes such as 'looked odd'.

10. Check your identity workflow against the AI lifecycle idea from ENISA. Ask where requirements, data handling, deployment, and ongoing operation could introduce trust problems. Done correctly, you can point to the stage where each control sits rather than treating the whole system as one black box.

11. Run a simple retrospective on recently approved cases that later needed correction. Look for patterns in evidence collection and validation, not just individual reviewer error. Done correctly, the output is a short list of control changes, such as more escalation, clearer attack labels, or stronger separation between auto-pass and human pass.

12. Update staff guidance for customer-facing teams. Give them one exact sentence to use: 'I need to pause this identity check for an additional verification review.' Done correctly, staff can say it without improvising, and the pause sounds procedural rather than accusatory.

What done correctly looks like

A good process does not rely on one perfect algorithm or one perfect reviewer. It creates several chances to slow down a suspicious case. It also records why that case was slowed down.

The key sign of success is not zero friction. It is targeted friction. Ordinary applicants still move through the process, while doubtful cases leave a clear trail for follow-up.

Illustrative example

Marie leads identity operations for a European software company with remote customer onboarding. Her team accepts new business accounts through a digital form, a document upload, and a selfie video. The process was built for speed, and most cases had been approved after one reviewer glance.

After reading ENISA’s guidance on remote identity proofing attacks, Marie changed the playbook. She added a checklist that named photo attack, video of user replay attack, 3D mask attack, and deepfake attack. She also added a pause option called 'second human check for presentation attack signs'.

A week later, a new applicant submitted a clean-looking profile for a high-value business account. The company details looked ordinary. The identity document image looked sharp. The selfie video also looked polished, with steady lighting and a centered face.

The first reviewer almost approved it. Then he noticed that the face movement looked a little too smooth for a live call. He opened the checklist and selected possible 'video of user replay attack' because the session felt more like a played clip than a spontaneous recording. He used the new pause option instead of forcing a yes or no.

The second reviewer checked the same case file. Because the evidence, notes, and approval trail were stored together, she could see the original concern immediately. She compared the submitted material again and agreed that the movement cues did not fit a natural live interaction. The team held the account instead of activating it.

Marie then logged the case as a control test for the onboarding process. She did not claim certainty about the attacker’s exact method. She recorded only what the team could support: the case showed signs consistent with a replay-style presentation attack during remote identity proofing, so approval was withheld pending stronger verification.

The outcome was useful beyond that single case. The team saw that the new checklist gave the first reviewer a concrete language for doubt. The pause step prevented a rushed approval. The shared case file made the second review quick instead of messy.

The near-miss

Now replay the same case without Marie’s change. The reviewer sees a sharp document image and a polished selfie video. There is no attack checklist on screen, and the workflow offers only approve or reject.

Because the case looks cleaner than most, he clicks approve. The account opens, and later requests from that profile inherit the trust created on day one. Support staff treat the customer as already verified because the audit trail shows a completed identity check.

When odd behaviour appears later, investigators have less to work with. The original session contains little reasoning beyond 'approved'. The key moment to catch the issue was the first remote proofing step, and that moment passed because the process had no structured way to pause doubt.

How to check it worked

Start with your documents and screens. Open the reviewer procedure, the case workflow, and the case record. Confirm that the named escalation step, the four attack labels, and the pause option are present where staff actually work.

Next, inspect a sample of recent identity cases. Look for evidence that staff used the checklist and wrote specific notes such as possible photo attack or possible deepfake, not only general comments such as suspicious. A process works better when people can describe what they saw in the language the control expects.

Then check the audit trail. Make sure high-risk cases show the second approval when your rules require it. If the second check exists only in chat or email, the control is weak because investigators will not see it in the core record.

Also test whether your asset list stays useful. Pick one remote proofing flow and ask a colleague outside the security team to explain the assets involved from the written list alone. If they cannot, the list is too abstract to help during an incident.

Finally, ask whether your workflow helps people slow down without embarrassment. Staff should be able to pause a case using standard language. If they feel they must justify every pause from scratch, many doubtful cases will still slip through.

Test yourself

Question: Which four face presentation attack types does ENISA name in its remote identity proofing report?
Answer: Photo attack, video of user replay attack, 3D mask attack, and deepfake attack.

Question: What is the most important early process change in this guide?
Answer: Add a visible pause and second human check for signs of presentation attacks during remote identity proofing.

Question: Why should you list assets in an identity workflow?
Answer: Because an asset list helps you see what needs protection and where a failure happened when a case goes wrong.

Common mistakes

Treating every identity problem as simple impersonation

Synthetic identity fraud is different from a straightforward stolen-ID case. If your process looks only for a perfect match between one person and one document, it may miss a profile built from mixed real and invented details.

Relying on facial recognition alone

ENISA’s report exists because facial recognition can be targeted by presentation attacks. A sharp selfie or a successful automated step should not end the investigation if the wider identity story feels wrong.

Giving reviewers no language for doubt

When staff can only write suspicious or unusual, organisations learn little from near-misses. Named attack categories create better notes and better follow-up.

Making pause decisions socially costly

If staff think a paused case will be seen as poor performance, they will approve doubtful cases to keep queues moving. The workflow should make careful delay normal for a narrow set of risky signals.

Keeping evidence in separate places

A weak evidence trail slows every later check. Images in one system, notes in another, and approvals in email create confusion at the exact time you need clarity.

Ignoring the AI lifecycle around the process

ENISA stresses a lifecycle view for AI systems. If you only look at the final face match result, you may miss problems introduced earlier in requirements, data handling, deployment, or operations.

Level up

Take one remote identity proofing journey and turn it into a tabletop exercise for your team this month. Use ENISA’s four named presentation attacks as the script: run the same onboarding case four times, once as a photo attack, once as a video of user replay attack, once as a 3D mask attack, and once as a deepfake attack. The goal is simple. Confirm that staff know when to pause, what label to apply, and where the second approval appears in the audit trail.