Why a liveness result from the phone is not enough
A liveness result produced on the phone is a claim made by a device the attacker may control. Treat it as input, keep the recorded evidence, and re-check that evidence on the server before the result counts.
Charles Archibong, Co-founder
· 5 min read
Key takeaways
- Anything the phone reports, including a liveness pass, can be forged by someone who controls the device.
- Injection attacks skip the camera, so the app can run perfectly and still be fed synthetic video.
- Keep the recorded evidence and re-derive the verdict on the server; treat the client result as a claim.
- A server-side mismatch is best used as a risk signal routed to review, not an automatic ban.
Because the phone is not yours. A liveness result computed in the app and sent to your server as "passed" is a claim made by a device that, in the cases you care about, is controlled by the attacker. They can modify the app, run it in an emulator, or feed it video that never came from a camera. A server that accepts the claim has outsourced its most important check to the person it is checking.
The fix is a principle more than a feature: the phone collects evidence, and the server decides. Keep what was captured, re-derive the verdict from it on infrastructure you control, and treat the device's own verdict as one input among several.
What can an attacker change on the device?
On their own phone, almost everything that happens before data leaves it.
The result itself. If the app sends
liveness: true, a patched app or an intercepted request can send the same value without anyone standing in front of the camera.The camera feed. A virtual camera, an emulator or a hooked camera API can present a pre-recorded or generated video as if it were live. The app's liveness logic then runs correctly, on fake input.
The timing. A replay tool can resend a genuine session captured earlier.
The US National Institute of Standards and Technology describes the second case directly. Its identity proofing guideline, SP 800-63A-4 (opens in a new tab) (July 2025), defines injection attacks as inserting "modified or forged media between the capture point (e.g., a device) and the element conducting the comparison", and notes that they are increasingly paired with generative AI tools. It adds that live capture and presentation attack detection make this harder, but "are not sufficient to address all possible cases of these kinds of attacks".
Why doesn't a good on-device liveness check solve this?
Because a presentation attack and an injection attack are different problems.
A presentation attack puts something in front of a real camera: a photo, a screen, a mask. Good on-device liveness is built to catch those, and NIST expects it to be tested: SP 800-63A-4 requires presentation attack detection for remote biometric collection with an impostor attack presentation accept rate below 0.07, tested in conformance with ISO/IEC 30107-3:2023. NIST is a US standard, but it is a useful benchmark to ask a vendor about.
An injection attack never presents anything to a camera. The on-device check can be excellent and still pass, because it is analysing exactly the video it was given. The only places to catch that are the evidence itself and signals about how it was captured, examined somewhere the attacker cannot reach.
What should the server actually re-check?
Four practices, in order of how much they add.
1. Keep the recording, not only the frame
A single selfie frame proves little about liveness. Keep a short recording of the challenge. It gives the server something to re-analyse and gives a reviewer something to watch. In the Myaza Trust SDKs, the selfie is auto-captured once the challenges pass, and a short liveness video is recorded for server-side review, as described in the SDK documentation.
2. Re-derive the verdict from the recording
For a challenge whose answer is visible in the video, check the answer on the server. A screen-flash challenge is the clearest case: the colours the screen showed should appear, in order, as reflections on the face. Myaza Trust Identity Verification re-analyses the recorded video on the server to confirm the flash sequence appears on the face.
3. Record how the evidence was captured
Some injection tools leave traces: a camera device name that belongs to known virtual-camera software, a camera with implausible capabilities, signs of an emulator. None is proof on its own, but together they tell you how much to trust the pixels. In Myaza Trust, capture-integrity signals feed a decision field, verification.cameraSuspect, which is true when they flag possible injection, so a workflow can route those sessions to review. The decisioning documentation lists it alongside the other fields.
4. Where you can, make the challenge come from the server
The strongest pattern is a challenge the server issues and later checks. Passport chips are the reference example: in NFC chip verification, the server runs passive authentication on the chip data itself ("the client never decides authenticity"), and Active Authentication asks the chip to sign a one-time challenge, which a copy of a genuine chip cannot do. The same idea applies to any check: the less the client chooses, the less the client can fake.
What should happen when the server disagrees with the phone?
This is where many designs overreach. A server-side mismatch is strong evidence that something is wrong, but not always evidence of fraud. Light can wash out a reflection. A cheap front camera can blur a nod. A virtual-camera name can belong to a legitimate accessibility or streaming tool.
So treat a mismatch as a risk signal, not a verdict. In Myaza Trust, a flash-sequence mismatch is recorded as a risk signal rather than failing the verification by itself. Your workflow decides what it means for your product.
A reasonable routing, for illustration:
What the server found | Suggested handling |
|---|---|
Recording confirms the challenge, no capture-integrity flags | Proceed on the other checks |
Flash sequence could not be read (for example, too bright) | Proceed, or ask for a retake indoors on high-value flows |
Flash sequence contradicts what the phone reported | Send to review; decline on high-risk products |
| Send to review, and look at the device's other activity |
Both of the last two | Decline and investigate the device and any linked accounts |
Give reviewers the recording as well as the flag. Watching the clip is often the quickest way to tell a sunlit face from a replayed one.
Questions to ask of any liveness vendor
Whether or not you use Myaza Trust, these questions separate a phone-trusting design from a server-verifying one:
Is the liveness verdict computed on the device, on the server, or both? If both, which one decides?
What evidence is kept, and can a reviewer watch it?
How do you detect video that did not come from a real camera?
How has presentation attack detection been tested, and against which standard?
What happens when the server disagrees with the device: a hard failure, or a signal I can route?
The rule to take away
Trust in a verification flows from the least trustworthy place it passes through. If the decisive judgement happens on a phone you do not control, that phone sets your ceiling. Move the decision to the server, keep the evidence it was based on, and use the phone for what it is good at: guiding a real person through a capture quickly.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
