Why do liveness checks fail against replay and deepfake fraud?

Why replay and deepfake attacks defeat simple liveness checks

Liveness checks often fail because they prove “a person is present” only indirectly. If the control is looking for motion, blinking, head turns, or a challenge response, an attacker can satisfy those cues with a recorded clip, a synthetic face, a relayed camera feed, or an injected video stream. The more the check relies on one visible signal, the easier it is to spoof.

That weakness is why liveness is best treated as one signal in a broader fraud decision, not as a standalone trust decision. A robust design looks for signs that the capture is live, local, and hard to replay, while also checking whether the device, channel, and session look consistent with normal use.

What replay, injection, and deepfake fraud exploit

Replay attacks reuse a previously captured face, voice, or screen image and feed it back into the verification flow. Deepfake fraud goes further by generating a convincing synthetic face or voice that can be adapted to the challenge in real time. Injection attacks bypass the camera path entirely and feed fabricated media into the application, which can make a weak liveness check believe the capture is genuine.

These attacks work because many liveness systems are judged only on appearance, not provenance. If the control does not strongly distinguish a live camera feed from an emulated or substituted one, a high-quality spoof can satisfy the expected behaviour without proving that the person on the other end is real.

• Replay fraud abuses trust in previously captured media.
• Deepfake fraud abuses trust in synthetic but convincing media.
• Injection fraud abuses trust in the capture pipeline itself.

Why stronger liveness design still has gaps

Passive signals can be fooled by better media quality, better synthesis, or better relaying. Active challenge response raises the bar, but it still assumes the attacker cannot observe the prompt, coordinate a response quickly enough, or proxy the interaction through another channel. If the system never validates the device path, a fraudulent feed may look live even when the capture is not local.

The strongest designs combine several checks, for example passive texture and motion cues, challenge response, device attestation, and risk scoring. Even then, no single liveness method is perfect against all replay, deepfake, and injection scenarios, so the control should be calibrated to the fraud impact and the rest of the onboarding or authentication flow.

Risk and Threat Considerations

When liveness becomes the primary gate to onboarding, account recovery, or step-up verification, a successful spoof can convert a remote attacker into a trusted user. That creates identity fraud risk, account takeover risk, and in some workflows, payment or privilege abuse if the verification result is used to unlock higher-trust actions.

Failure mechanism: The attacker defeats the presentation test by replaying, synthesising, or injecting media that matches the expected cues closely enough to pass, while the system fails to verify capture provenance or device trust.

Impact: The organisation may accept a false identity, approve a fraudulent recovery or enrollment event, or create a durable compromise path that is harder to unwind after the fact.

Practitioner Guidance

What to verify: Treat liveness as incomplete unless you can also verify where the capture came from, whether the device was trustworthy, and whether the interaction showed signs of relaying or injection. A pass that is not tied to a known device or trusted session is a weak signal for high-risk workflows.

Decision rule: If the action would enable onboarding, reset access, change payout details, or unlock sensitive account functions, require layered checks rather than a standalone liveness result. If the downstream action is low risk, a lighter signal may be acceptable, but the control should still log enough evidence to investigate fraud attempts.

Practitioner takeaway: The real control objective is not “detect a face,” it is “prove a trustworthy capture path with enough confidence for the decision being made.”

Related resources from NHI Mgmt Group

• Guide: Deepfakes, Social Engineering and AI Impersonation Guide
• Why do gesture-based liveness checks fail against modern fraud?
• Why do single biometric checks fail against deepfake and injection attacks?
• Why do traditional call center checks fail against modern fraud?
• Why do credential checks fail against fake account creation and fraud rings?