How to Prevent Replay Attacks in Identity Proofing

What is a replay attack in identity proofing?

A replay attack in identity proofing presents previously captured evidence as if it were being captured now. The evidence may be genuine: a real selfie of the victim scraped from social media, a liveness video recorded during an earlier session, or an API request that once returned success. What makes it an attack is that the system accepts old evidence for a new decision.

Replay overlaps with two other attack families. When the old recording is played on a screen in front of the camera, it is also a presentation attack. When it is fed through a virtual camera or straight into the API, it is also an injection attack. The distinguishing question for replay is freshness: was this evidence created in this session, for this challenge? The comparison of replay attacks and deepfake attacks explains how replay differs from synthesis.

Five routes attackers use to replay identity evidence

Replay works wherever the system cannot tell old evidence from new. The routes below differ in where the old media enters, so each needs its own control.

How to prevent replay attacks: freshness, binding and duplicate checks

Prevention rests on proving that each capture belongs to one session and one moment. The controls below work together; dropping any one leaves a route open.

Freshness checks must be enforced on the server. A challenge generated and verified only in the app can be replayed by anyone who controls the app or calls the API directly.

• Issue a random, single-use challenge from the server at the start of each capture, such as a head movement, a phrase or a colour sequence, and verify the response in the captured media.
• Bind the challenge, session identifier and device to the uploaded media with a signed token, and reject any token used twice.
• Set short validity windows: a capture that arrives minutes after its challenge expired should be retaken, not accepted.
• Record server-side timestamps for challenge issue and media receipt, and ignore client-supplied capture times.
• Require live capture inside the app or web flow and disable gallery uploads for identity steps.
• Hash every accepted selfie, video and document image, and search new submissions for exact and near-duplicate matches and for the same face under different identities.

What NIST SP 800-63A-4 expects on freshness and replay

NIST SP 800-63A-4, published in July 2025, does not have a single replay section, but several requirements target the same weakness. Automated document validation must use live capture of documents, which helps confirm the image captured during the session is not a manipulated digital copy. Confirmation codes must be invalidated once used, and a code sent to a validated phone number may stay valid for 10 minutes. Continuation codes used to resume an interrupted proofing session must also be invalidated on use.

The guidance's digital injection section adds controls that raise confidence media came from a genuine sensor and requires authenticated protected channels for data exchange during remote proofing. Remote attended sessions must include random human-in-the-loop cues, which a pre-recorded video cannot answer. Taken together, these requirements describe the same principle as the controls above: evidence counts only for the session that created it. Testing schemes are moving the same way: CEN/TS 18099:2024 sets out how to test biometric data injection attack detection, the route most replayed streams use, and the FIDO Alliance Face Verification certification covers injection attacks alongside liveness.

Where media analysis helps with replay, and where it cannot

Media analysis helps when the replayed content is synthetic or edited. A previously generated deepfake video played through a webcam plugin, as FinCEN describes, carries generation and face manipulation traces that a model can find whatever route it took. Screen replays also leave visual clues, such as moire patterns and reflections, that presentation attack detection uses.

Media analysis cannot tell that an unedited, genuine recording of the real person is old. If an attacker replays a real liveness video captured last month, every pixel is authentic. That case is caught only by challenge binding, freshness windows and duplicate search. Treat this as the dividing line when assigning controls: synthetic replay is a media problem, genuine replay is a session problem.

When a replay is confirmed, preserve the session identifiers, challenge data, raw media, device details and timestamps before changing anything. Then search for other sessions that reused the same file, face or device, because replay is cheap to repeat and rarely tried only once. Accounts approved through the same route during the exposure window should be re-verified with a fresh, bound capture, and the finding should feed back into the duplicate-search index so the same media is rejected on sight next time.

How NeuroVerify fits with replay controls

NeuroVerify analyses each face image, video or audio clip your flow captures and returns one unified risk score with signal-level evidence. Live Presence Verification addresses screen and printed replays, while Face Manipulation Detection, AI Generative Model Analysis and AI Pixel-Level Manipulation flag replayed deepfakes and edited captures. Eligible image requests complete in under 200 ms p95 under defined test conditions, so the check runs inside the same short freshness window as the challenge.

NeuroVerify does not issue challenges, manage session tokens or search your archive for duplicates; those belong to your proofing platform. Its results should be combined with them in your policy. The detection models build on ARCAS 1B, Neural Defend's own model, and Neural Defend ranked first of 36 systems on the public VendorBench-100 still-image benchmark with an MCC of 0.876. That benchmark does not test replay or injection, and one of its authors also co-authored the ARCAS paper.