Detecting deepfakes in identity verification
A convincing synthetic face is generated with public tools. How it is used against an identity verification, how a presentation differs from an injection, and which control makes the difference.
What a deepfake does to a verification
A deepfake is a face or a voice generated with machine learning to stand in for someone who is not there. What it is in detail, why the content is not the same as the vector it arrives through, and where it shows up in an identity journey are all in the glossary term: deepfake.
This page is about the other half: how that content is used to get past an identity verification, where it enters, who pays for it, and which controls stop it.
Presentation and injection are two different attacks
Treating the deepfake as a single phenomenon leaves a gap open, because the two vectors are stopped by different controls.
- Presentation attack — the attacker shows something to the device's real camera: a printed photo, a screen playing a video, a mask, a projected deepfake face. The camera works normally and captures what is in front of it.
- Injection attack — the attacker shows nothing to the camera. They replace the video stream before it reaches the application, with a virtual camera, an emulator or by manipulating the device itself. The image never went through a lens.
A system that detects presentation doesn't detect injection by default. The first is a problem of what is in front of the camera. The second is a problem of whether there is a camera.
How the attack runs, step by step
The sequence is short and each step has a control that corresponds to it.
- Get an image of the holder. A public profile photo, a leaked selfie, a video frame. No access to anything is needed.
- Generate the face. A model produces a face that moves and responds, from that image.
- Choose the vector. Present it to the device's camera, or inject it by replacing the video stream before it reaches the application.
- Pass the biometric comparison. It is the easiest step: if the face resembles the one on the document, the comparison approves.
- Pass or bypass the presence check. If the system runs liveness detection, the attacker needs their synthetic face to pass it. If the system doesn't, this step doesn't exist.
Step 5 is the only one that decides the outcome. The previous four are within reach of anyone with a free afternoon.
Who it affects and what it costs
The vector doesn't attack the impersonated person. It attacks the organization's verification process, and the cost falls on the organization's side.
- Financial services — account opening with an impersonated identity, later used to receive funds from other fraud. The cost isn't just the account: it is the report, the investigation and the position before the regulator.
- Betting and gaming platforms — age and identity verification evaded, which is a regulatory problem before an economic one.
- Background screening — a false identity in a hiring or accreditation process.
- Government — access to procedures and benefits in someone else's name.
In every case the operational damage is the same: the organization holds a record that claims to have verified someone who was never there, and it can't tell it apart from the genuinely verified ones.
Comparing faces isn't enough
The biometric comparison answers a single question: whether the captured face matches the one on the document. It is a question of resemblance.
The question the fraud exploits is a different one: whether that face belongs to a real person present at that moment. A well-made deepfake passes the first and fails the second, as long as someone is asking the second question.
That is the gap. An onboarding that validates the document and compares faces, without verifying presence, accepts a synthetic face with the same criterion it uses to accept the holder.
What controls stop a deepfake
No single control solves the problem, and several of the ones that matter aren't supplied by VU. Naming them all is the only way the list is useful.
- Passive liveness detection — analyzes presence signals in the capture without asking the user for anything. It is the main control against presentation.
- Active liveness detection — challenges the user with random instructions and validates the response in real time. It adds unpredictability, at the cost of friction.
- Injection detection — identifies virtual cameras, emulators and video stream manipulation. It is a control distinct from the previous one, not a variant.
- Device and application integrity — detection of rooting, emulation and tampering with the runtime environment. It is usually solved with mobile security tools, not with the identity provider.
- Capture hardware attestation — verification that the image comes from the device's physical camera. It depends on what the operating system and the manufacturer expose; a provider can integrate those interfaces, it can't replace them.
- Behavioral and session risk signals — usage patterns, device reputation and interaction speed. They add context that biometrics alone doesn't have.
Device integrity and hardware attestation aren't solved by a verification provider on its own: they depend on the guarantees the operating system exposes. A team that builds its defense against deepfakes only with what its biometrics provider sells is covering one part of the problem.
What the ISO/IEC 30107-3 standard measures
The ISO/IEC 30107-3 standard is the international standard that defines how to evaluate presentation attack detection in biometric systems.
The method is what gives it value. An accredited laboratory builds a set of attack instruments, presents them against the system under controlled conditions and measures how many are accepted. The result is a reproducible number produced by a third party.
The standard doesn't define levels. The levels are defined by iBeta's testing program, which applies that methodology and grades by the attack potential: Level 1 uses low-cost, easy-to-build instruments, Level 2 adds more sophisticated and costly instruments, and the lab added a Level 3 for highly prepared instruments. Confusing one with the other is common and worth avoiding: the standard is the method, the level is the demand of the test.
VU is certified by iBeta at Level 2 of that program.
The standard doesn't evaluate injection attacks. Its scope is presentation attacks, the ones that happen in front of the capture device. No certification under this standard says anything about injection, and that is worth keeping in mind when comparing providers.
One piece of data a security team should ask any provider for, VU included: the date of the certification and which version of the product was certified. A result from two years ago was obtained against attacks from two years ago.
Where impersonating with artificial intelligence already carries a heavier penalty
Colombia increased the penalty for the crime of personal impersonation (falsedad personal) when it is committed with artificial intelligence. Ley 2502 de 2025 amended Article 296 of the Penal Code and added the aggravating factor: if the conduct is carried out with artificial intelligence, the fine is increased by up to one third, provided the act doesn't constitute another crime. The same law defines what a deepfake is and orders the formulation of a public prevention policy. The amendment to Article 296 has been in force since July 2026, one year after its enactment. It is worth placing it within the country's compliance framework.
The change matters beyond Colombia because it moves the argument onto different ground. It stops being a discussion about probable risk and becomes an obligation with a defined legal consequence, which is ground where a compliance team can act.
How VU approaches it
VU applies certified liveness detection within the same flow that reads the document and compares the face, without adding a separate step for the user.
The iBeta certification at Level 2, against the ISO/IEC 30107-3 methodology, is the evidence that this control was measured by a third party and not just declared. It covers presentation, not injection.
The capability that applies that control within the flow is Verify.
Frequently asked questions
It is audio or video content generated or altered with machine learning models to depict a person saying or doing something that didn't happen. In the context of identity verification, it is a synthetic face that imitates the holder of a document with enough quality to pass a biometric comparison. What turned it into an operational problem isn't the technique, but that generating one no longer requires specialized equipment or knowledge.
With presence controls, not with face comparison. Liveness detection analyzes signals that indicate whether there is a real person in front of the camera, and injection detection verifies that the image actually comes from the device's camera and not from a substituted stream. They are two different controls and both are needed: one covers what is shown to the camera and the other covers whether the camera is being used. The way to compare implementations across providers is the result of an independent evaluation under ISO/IEC 30107-3.
It is the international standard that defines how to evaluate a biometric system's ability to detect presentation attacks. It establishes the method and the metrics: an accredited laboratory builds attack instruments, presents them against the system under controlled conditions and measures the acceptance rate. The levels often cited alongside the standard aren't part of the standard: they are the grades of iBeta's testing program, which applies this methodology and distinguishes them by the attack potential. Today there are three, and it is worth looking at the level together with the date of the test, because the ladder changes. One point the standard leaves out: it doesn't evaluate injection attacks, only presentation.
