Security 7 min read

One in five biometric fraud attempts is now a deepfake

Detection accuracy that looks excellent in a laboratory collapses in production. The answer is not a better classifier, because that is an arms race you are structurally losing.

A smartphone on a tripod replaying a face to a laptop webcam, illustrating a deepfake injection attack that never passes through a real camera

The numbers from this year are worth sitting with for a moment. Deepfakes now account for roughly one in five biometric fraud attempts globally. Deepfaked selfie submissions rose about 58 per cent in a year. Injection attacks, where the fake never passes in front of a camera at all, rose around 40 per cent.

And the detection figure that should worry people most is the flattering one. Leading detectors report accuracy in the mid-nineties under laboratory conditions. In production, real deployments have seen that fall to somewhere near half. Not because the vendors lied, but because a benchmark and an adversary are different things, and only one of them updates.

The instinct in most companies is to go shopping for a better detector. I think that instinct is the mistake, and I want to explain why in engineering terms rather than in the language of a threat report.

The device half of this is not new ground for me. GB2551794A, filed in 2016, paired a machine-readable code on a device with a biometric taken on a phone, so that neither the device nor the person alone was sufficient to authorise anything. The lesson that carried forward is that a single channel is never enough, however good it is.

The camera stopped being the entrance

Face verification inherited its threat model from physical security. The assumption baked into the phrase "presentation attack" is that an attacker presents something to a sensor: a printed photograph, a screen, a mask. Every classic defence follows from that assumption. Look for the flatness of paper, the refresh of a display, the absence of blood flow in the skin, the way a real face responds to a change in light.

Injection attacks discard the premise. Rather than fooling the camera, the attacker replaces it. A virtual camera driver, a hooked framework, a modified client, an emulator, a manipulated stream between the device and your server. What arrives at your endpoint is a perfectly clean video of a person who does not exist, and it is clean precisely because it never travelled through an optical path. There is no screen to detect, no moiré, no reflection off a phone case. Your model is being asked to find artefacts of a physical attack in an attack that was never physical.

This is why lab accuracy and production accuracy diverge so violently. The lab measures how well the classifier separates real faces from fakes. Production measures something else entirely: whether the whole path from the sensor to your decision can be trusted. A model can be excellent and still be irrelevant if the pipeline feeding it is under someone else's control.

An arms race you are structurally losing

Set aside injection for a second and take detection on its own terms. It is still a losing position, for a reason that has nothing to do with how good your team is.

Generative models improve continuously and globally. Your detector is a snapshot, trained on the artefacts of the generation that existed when the training set was assembled, and it degrades from the day it ships. Retraining is a project. Generation is a background process running across the entire world, for free, without your roadmap.

Worse, the feedback loop is asymmetric. An attacker learns from every rejection, at no cost, as many times as they like. You learn only from the attacks you caught, which by definition excludes the ones that worked. Your data is a biased sample of your own successes. Theirs is complete.

You can still be very good at this. What you cannot be is durably ahead, and a security control that has to stay durably ahead of a fast-moving generative field is not a foundation you should build a bank on.

The question is wrong

All of the above stems from asking a single question at the door: is this face real?

The better question is different in kind. Is the expected human present, on the expected device, in the expected context, at the moment this action is being taken? That reframing does most of the work, because it stops treating verification as an image classification problem and starts treating it as a decision made from several independent signals, none of which is sufficient on its own.

Independence is the operative word, and it is what most stacks get wrong. Three signals that all derive from the same video stream are not three signals. If an attacker controls the stream, they control all of them at once, and your defence in depth is one compromise deep. Signals earn their place by failing independently: something about the biometric, something about the device and its integrity, something about the context the request arrives in, something about the pattern of behaviour over time. An attacker who defeats one should still be sitting in front of a refusal.

The second correction is temporal. Verification at the door tells you about the door. A session can be handed over, hijacked or resumed by a different person entirely, and the check that mattered happened twenty minutes ago against someone who is no longer there. Trust should be scored across a session and re-established at the moments that carry consequence, which are almost never at login. They are at the approval, the release, the payment, the change of bank details.

The failures are never where you look

I want to be concrete, because it is easy to write about deepfakes in the abstract and miss where systems actually break.

We had an app rejected by Google Play this year. The reviewer could not get in, and the obvious conclusion, the one everyone reached first, was that the face verification had failed for them. It had not. The face check was never involved. Google reviews Android apps on emulators, and the emulator had consumed a one-time grant that our server only ever issues to the first device on a new account. The reviewer was locked out by a piece of enrolment logic that had nothing to do with biometrics, and every minute spent looking at the matcher was a minute spent in the wrong file. The fix was on the server, in the grant, and it took a fraction of the time the diagnosis did.

That is the general shape of it. Teams pour effort into the matcher and the liveness model because that is the part that feels like security, while the exploitable seams sit in enrolment, in recovery, in device binding, in the fallback route that exists because someone's camera is broken, in the support process that lets a convincing caller re-register a phone. Attackers are not sentimental. They will not fight your best model when your account recovery flow is a phone call.

The uncomfortable follow-on is that recovery paths are, in practice, the weakest identity check in most companies, and they are usually owned by a customer experience team rather than a security one, precisely because they were designed to be forgiving.

What I would build instead

Assume the stream can be forged. Design so that the forgery is not sufficient.

Bind the human to a device and treat the device as a first-class part of the claim, with its integrity checked rather than assumed. Attest where you can, so you have some basis for believing the image came from a real sensor rather than a driver. Weigh independent context: where, when, on what network, at what velocity, against what this person normally does. Make the decision at the moment of the action rather than inheriting it from an earlier one. Score continuously, step up when the stakes rise, and let the response be graduated instead of binary, because a system that can only allow or block will be tuned to allow.

Then record all of it. Every confirmed action signed and written to a trail, including the refusals, because the refusals are where you learn what is being attempted. Most organisations discover they are under attack from the fraud loss, which is the most expensive possible detector.

And carry the cost honestly. Every additional check is a tax on genuine users, so the goal is not to check harder, it is to check at the right moments and stay invisible the rest of the time. A control that is too heavy gets relaxed, and a relaxed control is worse than an honest absence of one, because it produces the paperwork of security without the substance.

Detection still has a place in that design. It just stops being the thing the building stands on. If your architecture collapses the day someone renders a better face, the problem was never the face.

Common questions

What is an injection attack in biometric verification?

An injection attack replaces the camera rather than fooling it. A virtual camera driver, a hooked framework, a modified client or an emulator feeds a synthetic video stream straight into the application, so the fake never passes through an optical path. Classic liveness defences look for artefacts of a physical attack and there are none to find.

Why does deepfake detection accuracy drop in production?

Laboratory accuracy measures how well a classifier separates known real faces from known fakes. Production measures whether the entire path from sensor to decision can be trusted. Generative models also improve continuously while a detector is a snapshot that degrades from the day it ships, and attackers learn from every rejection at no cost.

What should replace liveness detection?

Not a replacement, a demotion. Ask whether the expected human is present, on the expected device, in the expected context, at the moment of the action, using signals that fail independently. Three signals derived from the same video stream are one signal. Re-establish trust at the moments that carry consequence rather than only at login.