The camera is no longer evidence

Remote identity verification rests on one quiet assumption: that a camera observes reality. Injection attacks turn that assumption into a configuration setting on the attacker's machine. Once you understand the difference between holding a mask up to a lens and replacing the lens entirely, you cannot unsee the problem.

A fraud analyst at a mid-size neobank pulls up a verification session that was flagged three weeks after the fact, long after the account was opened and drained. She is expecting to find something sloppy. A photo of a photo. A screen reflection. The tell that every training deck promises will be there.

What she gets is a clean three second clip. A person turns their head to the left when asked, then to the right. They blink at a natural interval. The skin has pores. The lighting on the cheek shifts correctly as the head rotates, and the shadow under the jaw moves with it. When the challenge asked them to say four random digits, the mouth shapes match the audio. The document held up to the camera has the right microprinting and the right hologram behaviour under the glare the app induced.

Every check passed because every check was supposed to pass. The vendor scored it 0.03 on the spoof scale, where anything under 0.15 is a clean human. There is nothing to find, because there was never a camera. The frames were generated on a machine in a rented server rack and pushed into the app through a driver that told the operating system it was a webcam.

The analyst is looking for evidence of tampering in a video that was never a recording of anything. This is the part that takes a while to sit properly in your head, so it is worth saying plainly: the industry built identity verification on the belief that a camera is a sensor pointed at the world, and attackers have quietly reclassified it as an input field.

What is an injection attack in identity verification?

There are two families of attack against a face verification check, and almost all public discussion collapses them into one word, deepfake. They are not the same thing, they fail differently, and the defenses that work against one are close to useless against the other.

The presentation attack, which is what liveness was built for

A presentation attack puts something physical in front of a real, working camera. A printed photograph. A face on a phone screen. A silicone mask. A high resolution portrait on a tablet, tilted to catch the light.

This is the attack that liveness detection was designed to defeat, and against this attack it works reasonably well. The reason it works is that a real camera capturing a fake object leaves physical residue everywhere. A screen has a refresh rate, and it beats against the camera's shutter to produce moire patterns and banding. Paper is flat, so when the app asks the face to turn, the parallax is wrong: real faces occlude their own nose and ear as they rotate, and a photograph does not. Skin under changing illumination reflects with subsurface scattering that print and plastic do not reproduce. A screen emits light rather than reflecting it, and the colour temperature gives it away. Some systems flash a randomised colour sequence on the device screen and look for that exact sequence reflected in the eyes and on the skin.

All of these defenses have the same shape. They compare what the sensor recorded against what physics says a real face in a real room would produce. That is a sound approach, and the standards work behind it is genuinely good. ISO and IEC published a multi part standard on presentation attack detection, commonly cited as ISO/IEC 30107, which gives vendors a shared vocabulary and a testing methodology, and independent labs certify against it. Reputable vendors pass. The certification means something.

It means something about presentation attacks.

The injection attack, which never meets the camera at all

An injection attack skips the physical world. Nothing is held up to anything. The attacker generates video frames on a computer and inserts them into the pipeline at a point after the sensor, so the application receives what looks like camera output and has no way, from the frames alone, to know that no camera was involved.

Here is the analogy worth holding onto. Picture a bank with a security guard who watches a monitor showing the vault door. The guard is well trained. If you walk up to the monitor and hold a photograph of an empty corridor in front of the screen, the guard will notice, because your hand is in frame, the photo has a border, the lighting is wrong, and the image does not move when the camera pans. That is a presentation attack, and the guard catches it.

Now picture someone in the basement who does not go near the monitor. They find the cable running from the camera to the guard's screen, cut it, and splice in a laptop playing a loop of an empty corridor. The guard sees a perfect, uninterrupted, correctly lit, correctly moving feed of an empty corridor. There is no border, no hand, no reflection. The guard's training is irrelevant, not because the guard is bad at the job, but because the guard is being asked to judge the contents of a picture when the actual failure happened to the wire.

That is an injection attack. The verification vendor is the guard. The capture path is the cable.

Where exactly does the video get injected?

To take this seriously as an engineer rather than as a headline, you have to look at the path a frame travels before a vendor's model ever scores it. On a laptop, roughly:

physical sensor
  -> camera firmware
  -> OS driver (this is where a virtual camera registers itself)
  -> browser or native app media layer (getUserMedia, AVFoundation, Media Foundation)
  -> the vendor's capture SDK
  -> encode and upload
  -> the vendor's liveness and matching models
  -> a pass or fail decision returned to the bank

Every arrow in that chain is a place where frames can be substituted, and the further down the chain you go, the less physical residue there is to find.

Virtual camera drivers

The lowest effort method. Software that registers itself with the operating system as a webcam and serves frames from a file or a live render. This exists for entirely legitimate reasons, which is exactly why it is hard to ban: streamers, video producers, and conference software have used virtual cameras for years. The operating system does not distinguish between a virtual camera used to add a background blur and one used to play a rendered face, because at the driver interface they are the same thing.

Emulators and instrumented devices

An Android emulator running on a workstation presents a virtual camera by design, because there is no physical sensor. A rooted phone can have its camera stack hooked so that a specific app receives replaced frames while everything else on the device behaves normally. Frameworks for exactly this kind of hooking are widely available and were built for legitimate development and testing.

Modified or repackaged applications

The attacker decompiles the bank's app, replaces the capture routine, repackages, and runs it. Now the substitution happens inside the app's own process, below the SDK, and any check the SDK performs on the frames is checking frames the attacker chose.

Network layer substitution

If the client uploads video to the vendor and the transport can be intercepted with a controlled certificate on a device the attacker owns, the payload can be swapped in flight. Certificate pinning makes this harder, and it is the most defended of the four, but on a device the attacker fully controls, pinning is a speed bump rather than a wall.

Notice what all four have in common. They do not attempt to fool the model with a better fake face. They relocate the fake to a point where the model's inputs are attacker controlled, and then the model faithfully reports what it was given.

How big is the injection attack problem?

The honest answer is that nobody knows the true number, and the reason why is itself the most important fact in this section. Still, the visible numbers are large enough to settle the question of whether this is a niche concern.

Yoti, which operates identity and age verification at scale, published research covering 2025 that reported on the order of 3.2 million injection attacks against its liveness checks over the year, with a monthly peak above 500,000 in August. That peak matters because of its timing: the United Kingdom's Online Safety Act age assurance duties came into force in late July 2025, creating an enormous new population of age checks almost overnight, and the attack volume followed the opportunity within weeks.

Group-IB's Weaponized AI research, published in January 2026, documented 8,065 attempts to bypass the liveness checks of a single financial institution's digital lending flow between January and August 2025, using biometric injection with AI generated imagery. Hold that shape in mind. One institution. One product line. Eight months. Eight thousand attempts. Whatever the global figure is, it is not small, and it is not concentrated in one unlucky bank.

On the supply side, security vendors report that deepfake bypass kits are sold for very low amounts, in the region of tens of dollars, packaged for buyers with no machine learning skill. Treat the exact price as indicative rather than precise, because these listings move and the reporting is secondhand. The economic point survives the imprecision: the attacker's marginal cost per attempt is roughly the price of a sandwich, and the defender's cost per attempt is a model inference plus, increasingly, a manual review.

The caveat that has to be stated

Every number above comes from a vendor or a security research group with a commercial interest in the problem being large. That is not an accusation, it is a structural fact about where this data can come from, and any honest reader should hold it in mind. Vendor telemetry has selection bias in both directions: a vendor sees only attacks against its own customers, which understates the total, and a vendor that markets injection detection has an incentive to count generously, which overstates it.

There is a deeper measurement problem underneath. A vendor can publish how many attacks it caught. No vendor can publish how many it missed, because a missed injection attack is, by definition, recorded as a legitimate verification of a real person. The undetected rate is not merely unpublished. It is unmeasurable from inside the system that failed. Any claim about it, including a comforting one, is inference rather than data.

Why can't a better injection detector win this?

The industry's answer to injection attacks has been to build injection detectors: look for the signature of a virtual camera driver, check device integrity through platform APIs such as Play Integrity or App Attest, examine frame metadata for the fingerprints of a render pipeline rather than a sensor, and analyse timing jitter that a real camera would produce and a file would not.

These are real engineering, they raise attacker cost, and they should be deployed. They also cannot end the contest, for three structural reasons.

The feedback loop is asymmetric

The attacker gets a clean, immediate, unlimited signal: pass or fail. Every rejected attempt is a labeled training example telling them which artifact to remove. They iterate at will against a live oracle at negligible cost. The defender gets the opposite: the attacks they see are the ones they caught, and the ones that mattered most are invisible. One side is optimising against ground truth, the other is optimising against a censored sample.

Device attestation proves the binary, not the pixels

This is the subtle one and it deserves care, because device attestation is often presented as the answer. Play Integrity and App Attest can give strong evidence that an unmodified copy of your app is running on a device with an intact boot chain. That is genuinely valuable and it eliminates the crudest attacks.

What it does not do is attest the provenance of the pixels. Attestation says this software is authentic on this hardware. It does not say these particular frames came from that particular physical sensor rather than from somewhere else in the operating system. On a rooted device, an emulator, or a platform without strong attestation, the gap is wide open. Even on a locked down device, attestation and capture are separate claims, and the industry frequently treats one as if it implied the other.

The economics do not work at twenty dollars an attempt

Any defense whose cost per attempt exceeds the attacker's cost per attempt by orders of magnitude loses on volume, even when it has a better hit rate. If a bypass kit costs tens of dollars and a manual review costs a trained analyst several minutes, the attacker can simply buy more attempts than you can afford to review. Detection contests are won by whoever can iterate more cheaply, and that is not the bank.

That last row is the one to sit with. A device farm staffed by real people holding real phones, paid a small amount per verification, produces genuine camera footage of a genuine live human. There is no injection to find and no deepfake to score. Every defense in the table above returns a confident pass, correctly. This is why framing the problem as a deepfake problem is a category error: the underlying failure is not that the video is fake, it is that a video, real or fake, was never capable of proving the thing the system needed proved.

What is the Enrollment Binding Gap?

It is worth naming the failure precisely, because the name tells you where to put the control.

The moment under attack is not a login. It is the enrollment moment, the single event where a system decides that a particular human being is now associated with a particular account. Everything downstream inherits that decision: the transfers, the withdrawals, the payroll, the age gate, the employment. Verification is the hinge on which every later action swings.

The Enrollment Binding Gap is the distance between two claims that systems routinely treat as one. The first claim is that a live human presented a valid document and a matching face at some moment. The second claim is that this specific human controls this specific account and is the one acting in it now. Identity verification establishes the first. Systems behave as though it established the second.

It did not, and injection attacks are simply the cheapest current way to exploit the difference. If the only artifact produced by enrollment is a stored decision that says verified, then anyone who can produce one passing video, by any means, obtains a durable and reusable identity. The attacker's cost is a single successful injection. The payoff is every action the account can ever take.

What should the evidence be instead?

The shift is small to describe and large in consequence. Stop treating the video as the asset. Treat the key as the asset.

At the enrollment moment, alongside whatever document and face check you run, the human's own device generates a keypair in its secure element. The private key never leaves the hardware and is not extractable, not by the user, not by the app, not by you. What your systems keep is the public key and a record that it was bound during a verification event. No face template is stored anywhere. There is no biometric database to breach, because the only durable output is a one way key.

Then every consequential action afterwards, the withdrawal, the payee change, the payroll update, the high value transfer, requires a fresh signature from that key over the exact details of that action. Not another video. Not another selfie. A signature, bound to a payload, produced by hardware the human physically holds.

Here is what a signed action actually contains, using a withdrawal as the worked example:

{
  "action": "withdrawal.execute",
  "account_id": "acct_9f31c0",
  "amount": "48200.00",
  "currency": "USD",
  "destination": "GB29NWBK60161331926819",
  "destination_first_seen": "2026-09-09T11:04:22Z",
  "requested_at": "2026-09-09T11:06:03Z",
  "enrollment_id": "enr_7be2a1"
}

payload_hash = SHA-256(canonical_json(payload))
assertion    = WebAuthn.get({ challenge: payload_hash,
                              allowCredentials: [enrolled_credential_id],
                              userVerification: "required" })

The verifier recomputes the hash from the payload it is about to execute, checks that the assertion signs that hash, checks the credential identifier matches the one bound at enrollment, and stores the whole thing as a receipt. Because the receipt verifies against a published key, an auditor or a regulator can check it years later without calling anyone's API.

Now count what an attacker gains from one successful injection under this model. They get an enrolled key on a device they control, at one institution. They do not get a reusable identity, because the second institution requires its own binding. They do not get the ability to act later from anywhere else, because the key is in hardware they must keep possession of. They cannot escalate by presenting another video, because after enrollment nothing accepts a video as authorisation. The single bypass has been reduced from a master key to a single door.

That is the whole argument. Injection attacks do not become impossible. They become expensive per account rather than cheap per identity, and their blast radius collapses.

How does this compose with an existing IDV vendor?

Nothing above replaces document verification, and any vendor claiming otherwise should be treated with suspicion. Someone still has to check that the passport is real, that the face on it matches the person, and that the person is not on a sanctions list. That is a specialised discipline with real regulatory weight behind it, and Onfido, Jumio, Persona, Veriff, iProov and their peers do it properly.

The composition is straightforward, and the ordering matters:

1. The IDV vendor runs its document and liveness check.       (unchanged)
2. On a pass, your backend opens a binding window.            (new, seconds)
3. The user's device creates a passkey in its secure element. (new)
4. You store the public key plus the vendor's decision id.    (new)
5. Every later consequential action requires a signature.     (the point)

The vendor never sees the private key, because nobody sees the private key. Your systems never store a face template. The vendor's decision becomes what it was always suited to be, a one time gate, rather than what it has been asked to be, a permanent proof of identity that gets reused implicitly on every future action.

For the companion device pattern, where a person verifies on a phone while working on a desktop, the pairing itself should not be a scannable URL, because a URL can be relayed to a victim in real time by an attacker. Manav's Beam flow pairs using a rotating pattern rather than a link, which removes the class of attack where a phishing page shows you a code that belongs to the attacker's session.

Honest limits

This section is the important one, and it is where most vendor writing on this subject quietly stops.

Enrollment is still camera based, and Manav's on device face match is not immune to injection. If an attacker injects synthetic video at the binding moment, they can bind a key to an account. Nothing in this post makes the first check magic. The claim is narrower and, we think, more useful: the value of one successful bypass drops from a reusable identity to a single account on a single device, and the attacker must repeat the full cost at every institution and for every account.

You still need a real identity proofing event against an authoritative source. A key bound to a person who was never actually checked against a government document is a well protected fiction. Device binding solves continuity, not initial truth.

Device attestation has real limits. On rooted devices, emulators, and platforms with weak attestation, the integrity signals you would like to rely on are degraded or absent. Hardware attested device chains, where the device itself proves the provenance of its secure element to your backend, are on the roadmap and are not shipped. It would be dishonest to describe them as available today.

Device farms with real humans are unaffected by any of this. If someone pays a hundred real people to complete a hundred genuine verifications on a hundred real phones, every check passes truthfully and every key binds correctly. What changes is cost and scale: this is a per human, per device, per institution expense with physical logistics, rather than a script. That is a meaningful economic difference, and it is not a fix.

Coercion is out of scope. A signature proves that the enrolled human's device authorised this action. It cannot tell you whether someone was standing behind them.

Recovery is where this gets hard. The strength of a device bound key is that it lives in one place, and the cost of that strength is what happens when the device is lost. Recovery flows are where attackers move next, and they deserve their own careful treatment.

What to do this week

1. Ask your identity verification vendor, in writing, what fraction of their attack telemetry in the last twelve months was injection rather than presentation. The shape of the answer, and whether they have one, tells you a great deal.
2. Ask the follow up question that matters more: how would they know about an injection attack they did not catch? Listen for whether the answer is a method or a reassurance.
3. Write down every downstream action that currently inherits authority from a single passed verification. Account opening, first withdrawal, payee changes, credential resets, payout details. That list is your actual exposure.
4. Pick the two highest value actions on that list and require a fresh device signature for them, independent of any video check.
5. Turn on platform integrity checks (Play Integrity, App Attest) if you have not, and document honestly which of your user platforms they do not cover.
6. Check whether your verification session video is retained, for how long, and under which lawful basis. If it is not the durable evidence anymore, retaining it is liability without benefit.
7. Test your own capture path with a virtual camera on a workstation. Most teams have never tried, and the result of ten minutes of effort is usually clarifying.
8. Review your account recovery flow with the same eye. It is the path that undoes everything else.

If you want to see the shape of a device bound check without building anything, the walk up verification demo runs entirely in a browser with no signup, and the developer documentation covers the binding and signature calls.

Frequently asked questions

Can deepfakes bypass liveness detection? Yes. The effective method is not holding a fake face to a camera, which modern liveness handles well. It is injecting synthetic video into the capture path through a virtual camera, emulator, or modified app, so the vendor scores frames the attacker generated. Vendors recorded millions of such attempts during 2025, and the technique is sold in low cost kits.

What is the difference between a presentation attack and an injection attack? A presentation attack puts a physical artifact in front of a working camera, which leaves detectable physical residue like moire patterns and wrong parallax. An injection attack never uses a camera, inserting frames after the sensor. Presentation attack detection standards and certifications address the first category and were not designed for the second.

Does device attestation stop injection attacks? It helps and it does not close the gap. Play Integrity and App Attest give strong evidence that an unmodified app is running on an uncompromised device. They do not attest that specific frames came from the physical sensor rather than elsewhere in the operating system, and on rooted devices or emulators the signals degrade.

What is the Enrollment Binding Gap? It is the distance between proving a live human passed a check at one moment, and proving that this specific human controls this account and is acting in it now. Verification establishes the first. Most systems behave as though it established the second, which is why one successful bypass yields a durable, reusable identity.

Does binding a device key mean storing biometrics? No, and this is the point of the design. The face match happens on the device, and what persists is a public key plus a record that binding occurred during a verification event. No template leaves the hardware, so there is no biometric database to breach and nothing to hoard.

What happens if the user loses their phone? Recovery becomes the critical path, and it is where attackers concentrate once binding is in place. The honest answer is that recovery must re establish continuity rather than simply re running a document check, because re running the document check reopens the exact injection problem this design was meant to contain.

Can this stop a device farm of real people? No. If real humans complete real verifications on real phones, every check passes truthfully. What changes is the economics: it becomes a per person, per device, per institution cost with physical logistics attached, rather than a script that scales for the price of compute.

Sources

1. Federal Bureau of Investigation, Internet Crime Complaint Center, annual Internet Crime Report series, for downstream fraud loss categories. ic3.gov
2. Yoti, published research and reporting on liveness and injection attack volumes during 2025. yoti.com/blog
3. Group-IB, Weaponized AI research, January 2026, documenting biometric injection attempts against a financial institution's digital lending flow. group-ib.com research hub
4. National Institute of Standards and Technology, SP 800-63 Digital Identity Guidelines, on identity proofing and enrollment assurance. pages.nist.gov/800-63-4
5. ISO and IEC, ISO/IEC 30107 series on biometric presentation attack detection, for the vocabulary and testing methodology referenced above. iso.org
6. Google, Play Integrity API documentation, on what device and app integrity signals do and do not assert. developer.android.com
7. Apple, DeviceCheck and App Attest documentation. developer.apple.com
8. Ofcom, Online Safety Act age assurance guidance and implementation timeline. ofcom.org.uk
9. FIDO Alliance, face verification certification programme and WebAuthn specifications. fidoalliance.org

Stop asking whether the video is real. Ask whether the key that signed this action has been in that human's pocket since the day they enrolled.