A liveness check is built to confirm that a living person is in front of the camera right now. A deepfake injection attack never puts anything in front of the camera: it feeds a synthetic video stream straight into the software, so the check inspects a flawless face that was never there. This article explains where the two attack types enter, what running the check on your own infrastructure changes, and which parts of the problem no liveness engine solves alone.
THE DISTINCTION
Presentation Attacks And Injection Attacks Enter At Different Points
A presentation attack holds a fake in front of a real camera, and an injection attack replaces the camera’s output with fabricated data. The first is a physical object the sensor can see. The second is a digital stream that skips the sensor entirely.
Presentation attacks are the older problem: a printed photograph, a face replayed on a tablet, a silicone mask. The camera captures the fake honestly, and the detector looks for what gives it away, such as paper texture, screen moiré, flat depth or the edge of a mask. ISO/IEC 30107-3 is the test standard for this kind of presentation attack detection.
An injection attack happens further down the chain. The attacker installs a virtual camera driver, runs an emulator, or hooks the app’s video pipeline, then plays a face swap or a fully synthetic face into it. The verification software receives clean frames with no moiré and no paper edges, because no physical fake was ever filmed. In October 2024 the European Committee for Standardization approved CEN/TS 18099, the first technical specification written specifically for biometric data injection attack detection, because the presentation attack standards do not cover this route (Persona’s summary of CEN/TS 18099).
THE THREAT
Why Injection Is Now The Main Route Against Liveness Checks
Injection attacks are growing fastest because they are cheap to run and they defeat checks built only to inspect the image. iProov’s Threat Intelligence Report 2025 measured a 2,665% rise in native virtual camera attacks and a 300% rise in face swap attacks over the previous year (iProov).
Gartner predicted that by 2026, 30% of enterprises would no longer consider identity verification and authentication solutions reliable in isolation because of deepfake attacks on face biometrics (FutureCIO). The key words there are “in isolation”. A liveness model that receives one well-made synthetic frame has very little to work with. Stopping injection depends on who controls the path between the lens and the model, which makes it an architecture question as much as a model question.
ARCHITECTURE
What On-Premise Processing Changes About Injection
Running the liveness engine inside your own network shortens the path an attacker can tamper with and removes the public endpoint they would otherwise aim at. Three changes matter.
You Can Own The Capture Device
At a door, a turnstile or a staffed onboarding desk, the camera is your hardware on your network. Nobody can install a virtual camera app on it, and the video travels a cable you control to a server you control. Injection kits typically need a phone or laptop the attacker controls, and a fixed site camera denies them that foothold.
The Endpoint Has No Public Address
ARSA’s Face Recognition and Liveness SDK runs as one container and needs no network for inference, so the liveness API can sit on an internal VLAN with no internet route. An attacker cannot post a synthetic video to an endpoint they cannot reach. The licensed product makes no outbound call and sends no telemetry, so no copy of the face data goes to a third party who could lose it.
A Randomised Challenge Defeats Pre-Recorded Video
Active liveness issues a randomised head movement sequence and checks both the order of the movements and the anti-spoof result across the video. A deepfake rendered in advance cannot know which order it will be asked for. When liveness fails in the combined call, recognition is skipped entirely, so a spoofed submission is never matched to an identity.
LIMITS
What Liveness Alone Does Not Stop
A liveness engine judges the frames it receives, and it cannot prove where those frames came from. That limit applies to ARSA’s SDK as much as to any other, and a buyer should plan for it.
ARSA documents passive anti-spoofing against printed photos, screen replay and masks, and randomised active liveness over video. It does not publish a separate deepfake classifier or a CEN/TS 18099 evaluation, so you should not assume either. A real-time face swap driven by a live attacker can follow a randomised head sequence, because the attacker performs the movements and the software redraws the face over them. The randomised challenge removes pre-recorded attacks. It makes live ones more expensive without removing them.
That makes the capture path the decisive control. Where you own the camera, physical and network design mostly close the injection route. Where customers onboard from their own phones, the phone is untrusted and the defence moves into the app. The app should attest the device’s integrity, refuse to run under an emulator or with a virtual camera driver present, and tie each capture to a single challenge issued by the server. Those controls live in your mobile app and backend. Our fintech implementation and troubleshooting guide covers implementing liveness in an onboarding flow.
SPECIFICATION
The Controls In The SDK And The Ones You Add
The SDK supplies the liveness checks and the isolation, and hardening the deployment is the buyer’s job. The table separates the two, using figures from ARSA’s published system requirements.
| Item | What The SDK Provides | What You Configure |
|---|---|---|
| Passive anti-spoof | Single image, a few hundred milliseconds, POST /face_liveness |
Where in the flow to call it |
| Active liveness | Randomised challenge over video, several seconds, POST /face_liveness_active/request |
Client timeout of 30 seconds minimum |
| Liveness plus identity | submit_and_recognize, recognition skipped on liveness failure |
Your decision threshold policy |
| Video input | MP4 with H.264 recommended, single face in frame | The capture device and its integrity |
| Network | None required for inference, offline licence activation | Isolated VLAN, no internet route |
| Transport | Plain HTTP on port 8080 | TLS at a reverse proxy |
| Abuse limits | Not built in | Rate limiting and restricted CORS at the proxy |
| Audit | Request log with endpoint, status, latency, masked key, client IP; bodies never stored | Log review and alerting |
| Tenancy | Each API key is an isolated face database namespace | Key rotation plan, with re-enrolment |
The request log does more against injection than it might seem. An attacker tuning a face swap leaves a trail: a burst of failed active liveness attempts from one client IP or one key. The log records that pattern without storing any biometric payload.
COMPLIANCE
Keeping Biometric Data Inside Your Own Boundary
Processing liveness on your own servers keeps the face images and templates under your control, which makes it simpler to meet the security duties privacy law places on you. Under UK GDPR, biometric data used to uniquely identify a person is special category data. The ICO says explicit consent is likely to be the right condition and advises offering a genuine alternative such as a PIN (ICO).
Singapore’s PDPA requires reasonable security arrangements for personal data in your possession, and the UAE’s Federal Decree-Law No. 45 of 2021 treats biometric data as sensitive personal data. Under each of these laws, a liveness engine with no outbound connection means fewer processors to list, fewer transfers to justify, and one less place for a breach to start. If you would prefer not to run the server, ARSA offers a managed deployment. Each instance is single-tenant, in a region you choose among the EU, the US and Asia-Pacific, and ARSA does not access enrolled data.
ARSA sells the SDK outside Indonesia. List prices are in USD, invoicing is available in USD or EUR, and where visa conditions prevent ARSA engineers travelling, a qualified local partner installs under ARSA supervision.
FAQ
Questions Buyers Ask About Deepfakes And Liveness
What Is The Difference Between Deepfake Detection And A Liveness Check?
A liveness check asks whether a live person is present, and deepfake detection asks whether the face itself was synthesised. They overlap, since a good liveness check rejects many deepfakes. Neither one tells you whether the video came from a real camera, and the only answer to that third question is controlling the capture path.
Why Do Liveness Checks Fail Against Deepfakes?
They mostly fail when the deepfake is injected, because the check then receives clean synthetic frames with none of the artefacts a printed photo or screen replay would show. A model trained only on physical spoofs finds nothing in such an image to catch. Randomised challenges and a trusted capture device close most of that gap.
Is Active Or Passive Liveness Better Against Deepfakes?
Active liveness is stronger against pre-recorded deepfakes, because nobody can predict the randomised movement order in advance. Passive liveness takes a few hundred milliseconds and asks nothing of the user, which suits low-risk steps. Every ARSA SDK licence includes both, and many flows run passive first and active for higher-risk actions. Our guide to active liveness challenge-response explains how the challenge works.
Is There A Deepfake Liveness Detection Add-On?
ARSA sells no separate add-on, because passive and active liveness are part of every licence, including the $1,490 per year Developer licence. ARSA does not publish a standalone deepfake classifier. If your threat model needs one, ask ARSA directly what it can test against your own attack samples.
Does On-Premise Processing Stop Injection Attacks On Its Own?
It stops them where you also own the camera, and it narrows the attack surface everywhere else. On-premise processing removes the public endpoint and keeps the video on your network. When customers verify on their own phones, you still need device integrity checks in the app, because the phone is where the frames get injected.
Can We Test It Before Buying?
Yes. The free 14-day demo is the full product, limited to 100 enrolled identities and 50 API calls an hour. It needs an internet connection only to validate its key, and your face images are processed on your own machine throughout. Our comparison of cloud and on-premise face SDK pricing helps you size a licence after the trial.
NEXT STEP
Run The Liveness Checks On Your Own Attack Samples
The quickest way to judge any liveness engine against injection is to run it against your own capture setup and your own spoof attempts. The Face Recognition and Liveness SDK runs as one Docker container with passive and active liveness, 1:1 and 1:N matching, and its own dashboard. Start the free 14-day demo and test it on your network before you commit.