Replay Attacks vs Deepfake Attacks: What Is the Difference in Identity Verification?

Replay attacks vs deepfake attacks: how they differ

A replay attack presents something that was genuinely captured before. In biometric verification that might be a video of the real customer recorded from a social media profile, a selfie stolen by malware, or a previously accepted upload request resent to the API. Nothing in the pixels is fake. The fraud lies in the timing and the context: the evidence belongs to a different moment or session.

A deepfake attack presents something that never happened. The face was swapped onto another person's head, reenacted from a still photo, generated from nothing, or edited at pixel level. A deepfake can be pre-rendered or produced live, and live tools can respond to whatever the verification flow asks for in the moment.

That single difference decides which controls work. Replay defences ask whether this evidence is fresh and bound to this session. Deepfake defences ask whether the evidence itself was manufactured. A flow that answers only one of those questions leaves the other attack open.

How replay attacks reach a verification flow

Replays arrive by two routes. A presentation replay holds a phone or monitor playing the recorded video up to the real camera. The camera films a screen, so presentation attack detection can look for moire patterns, bezels, glare and flat geometry. A digital replay skips the camera and resends the recording, or a whole captured request, through a virtual camera, a hooked app or the API, which is where replay overlaps with injection.

Recorded material is easier to obtain than many teams assume. Group-IB described in February 2024 an iOS trojan, GoldPickaxe, that prompted victims in Thailand to record face videos and photograph their ID cards, and that collected SMS messages. Group-IB said the attackers likely used AI face-swap services on the stolen material, and noted it had not documented the data being used in the wild. Stolen face video like this can be replayed as-is or used as raw material for a deepfake.

The defence against a pure replay is freshness. NIST SP 800-63B-4 explains that protocols using nonces or challenges resist replay because old messages will not contain the right nonce or timing data. In a selfie flow, that means a server-issued, single-use challenge bound to the capture, short validity windows, and rejecting any media hash or face template already seen in another session. The sibling guide on replay attacks in identity proofing covers these controls in depth.

How deepfake attacks get past freshness checks

Deepfakes get past freshness checks because they can be made fresh. A real-time face swap or reenactment tool renders a new frame for every moment of the session, so it can blink, turn its head or read out a random number on request. The nonce is valid, the timing is right, and the face is still not the person it claims to be.

Industry reporting shows the volume moving this way. iProov reported in February 2024 a 704% rise in face swap attacks and a 353% rise in emulator use between the first and second halves of 2023, with face swaps passed into virtual cameras. Gartner reported the same month that injection attacks increased 200% in 2023.

Some attacks combine both types. FinCEN's November 2024 deepfake alert notes that identity verification tools may flag third-party webcam plugins, which can let a customer display previously generated video instead of live video. That is a pre-rendered deepfake delivered like a replay, and it needs both freshness checks and media analysis.

Which controls stop replay attacks and which stop deepfakes?

Replay controls and deepfake controls sit at different layers, so a KYC stack needs both. The list below maps each control to the attack it addresses most directly.

• Server-issued, single-use challenges bound to the capture and checked for timing stop recorded media and resent requests, and do little against live deepfakes.
• Signed, short-lived session tokens and rejection of reused request payloads stop API-level replays.
• Duplicate search on media hashes and face templates across sessions catches the same recording or face used for several accounts.
• Presentation attack detection catches recordings played on a screen in front of the camera.
• Device attestation and virtual camera checks reduce both digital replays and injected deepfakes by questioning the capture path.
• Media analysis for face manipulation, generative-model artifacts and pixel-level edits catches deepfakes whether they arrive fresh or pre-rendered, and is required in some form by NIST SP 800-63A-4 for all submitted media.

Where NeuroVerify fits against both attack types

NeuroVerify covers the deepfake side of the problem and supports the replay side. One request runs six signals on a face image, video or audio clip: Visual Safety Screening, Live Presence Verification, Face Manipulation Detection, AI Generative Model Analysis, AI Pixel-Level Manipulation and AI Content Compliance. It returns one unified risk score with signal-level evidence, and your policy decides the outcome.

For pure replays of authentic, unedited media, manipulation signals have nothing to find, and NeuroVerify should not be treated as a replay control. The Live Presence Verification signal adds a presence check, while freshness, session binding and duplicate search remain your platform's job.

Speed matters because both checks run in the same synchronous step. Eligible image requests return in under 200 ms p95 under defined test conditions. The detection models build on ARCAS 1B, Neural Defend's deepfake detection foundation model, and Neural Defend ranked first of 36 systems on the public VendorBench-100 still-image benchmark with an MCC of 0.876 against 0.646 for the next vendor; that benchmark does not test replay, video or injection.

SDKs cover Android, iOS and Flutter on mobile and Python, TypeScript, Go and Java on the backend, plus a REST API, with cloud, private cloud, on-premises and air-gapped deployment options.

What to do after a suspected replay or deepfake

Classify the attempt before you respond, because the fix differs. If the media is genuine but stale, look at how the attacker obtained it and which session or token check failed. If the media is synthetic, look at the capture path it used and whether media analysis scored it, then tune thresholds or routing.

Preserve the raw media, session and challenge identifiers, device signals, scores and decision log. Search for the same face, file or device across other accounts, since both replays and deepfakes are often reused at scale. The wider attacker playbook is covered in how deepfakes exploit KYC verification systems.