Deepfake-Resistant Identity Verification Guide

Remote identity verification that relies on a selfie and a photo of a document can now be defeated by generated faces and forged media fed straight into the capture pipeline, without anything ever being held in front of a camera. Liveness checks built to catch printed photos and masks do not, on their own, stop a synthetic video stream injected through a virtual camera, an emulator or a tampered app. This guide explains the two families of attack (presentation attacks and injection attacks), what NIST SP 800-63A-4, ISO/IEC 30107-3, CEN/TS 18099 and ETSI TS 119 461 expect, how to design and test a layered verification flow, and how to measure whether it is working. It is written for fraud, identity and security teams that run or buy onboarding, account recovery and step-up verification, and for assessors who need to judge a provider's claims. It is defensive throughout: attack techniques are described at the level needed to choose controls, not to reproduce them.

Key takeaways

Two different attacks need two different defences. Presentation attack detection (PAD) judges what is in front of the sensor; injection attack detection (IAD) judges whether the data really came from a genuine sensor. A deepfake can be delivered either way.
NIST now names injection explicitly. SP 800-63A-4 requires PAD for remote biometric capture with an impostor attack presentation accept rate (IAPAR) below 0.07, tested to ISO/IEC 30107-3:2023, and calls for controls against virtual cameras, emulators and manipulated media.
Trust the channel, not just the image. Device and app integrity, authenticated protected channels between capture and server, and reading the cryptographically signed chip in an ePassport or ID card remove whole classes of forgery that image analysis can only guess at.
Independent testing is becoming mandatory in Europe. ETSI TS 119 461 V2.1.1 requires identity proofing providers to have biometric IAD and PAD tested by an accredited laboratory every second year, with the first testing due before the end of 2026.
Measure attacks, not just conversion. Track IAPAR and bona fide rejection from test reports, injection detections in production, manual review overturn rates and confirmed fraud found after onboarding, and feed every confirmed case back into rules and supplier assurance.

Presentation attacks and injection attacks

A remote verification flow has a capture point (the camera on the user's phone or laptop), an app or browser that packages the capture, a channel to the verification service, and the analysis engines (document authenticity, face comparison, liveness). Attacks target different points in that chain, and the standards draw the line in the same place.

Presentation attacks: an artefact is shown to the real sensor. ENISA's remote identity proofing work groups these as photo attacks, video replay on a screen, 3D masks and deepfake video displayed to the camera. ISO/IEC 30107-3 covers only attacks that take place at the capture device during presentation, and its Annex A classifies known attack types.
Injection attacks: the genuine sensor is bypassed and media is inserted into the data stream, for example through a virtual camera driver, an emulated device, a hooked or repackaged app, a manipulated browser, or interception of the upload. CEN/TS 18099:2024 defines these attacks and the "injection attack instruments" used, and explicitly places presentation attack testing out of scope.
Synthetic and forged media: the payload in either route can be a face swap, a fully generated face, a re-enacted video or a forged document image. NIST SP 800-63A-4 notes that generative AI tools are being used with injection attacks to defeat document checks, biometric checks and visual comparison, and that a biometric comparison on a captured sample does not by itself prevent this.
Human-channel attacks: a live video interview with an agent can be attacked with real-time face or voice manipulation. The FBI's December 2024 public service announcement describes criminals holding real-time video chats while posing as executives, and using AI-generated audio to access bank accounts. See the Deepfake and AI Impersonation Guide.

Attack class	Where it enters	Primary defence	Testing reference
Printed photo, screen replay	In front of the sensor	PAD (passive or active), capture quality thresholds	ISO/IEC 30107-3
3D mask or prosthetic	In front of the sensor	PAD with depth or texture analysis	ISO/IEC 30107-3
Deepfake video shown on a screen	In front of the sensor	PAD, screen and moire artefact detection, challenge response	ISO/IEC 30107-3
Virtual camera or emulator feed	Between sensor and app	IAD: device and camera integrity, emulator detection	CEN/TS 18099
Hooked or repackaged app, tampered browser	Inside the client	App attestation, runtime integrity, signed capture	CEN/TS 18099, mobile app security testing
Upload interception or API replay	Between client and server	Authenticated protected channel, nonces, session binding	Application security testing
Forged or altered document image	Document capture	Live capture, document liveness, chip reading, issuer database checks	Document authenticity certification
Real-time deepfake in an attended video session	Human review channel	Agent training, random prompts, out-of-band checks	Operational testing, red team

What the standards require

NIST SP 800-63A-4

The identity proofing volume of SP 800-63-4, which supersedes SP 800-63A, sets the most specific public baseline:

Assurance levels: IAL1 limits highly scalable attacks; IAL2 adds stronger evidence and verification to resist scaled and targeted attacks, basic evidence falsification and social engineering; IAL3 requires an on-site attended session with a trained proofing agent and collection of at least one biometric.
Proofing types: remote unattended (fully automated), remote attended (a secure video session with an agent or trusted referee), on-site unattended (a CSP-controlled kiosk) and on-site attended. In both remote types the provider does not control the location or the device, which is exactly where injection happens.
PAD: mandatory for remote biometric capture, with IAPAR below 0.07, and PAD testing conformant to ISO/IEC 30107-3:2023.
Document capture: live capture of documents during validation, plus passive or active document liveness checks, so that a pre-made image file cannot simply be uploaded.
Injection and manipulation: controls including detection of virtual cameras and emulators, analysis of submitted media for manipulation, and authenticated protected channels; for remote attended sessions, agent training to spot manipulated media and random human-in-the-loop prompts.
Biometric performance: for 1:1 verification a false match rate of 1:10,000 or better and a false non-match rate of 1:100 or better; for 1:N deduplication a false positive identification rate of 1:1,000 or better; no demographic group more than 25% worse than the overall population at a fixed threshold; testing to ISO/IEC 19795-1:2021 and ISO/IEC 19795-10:2024.
Fraud management: a fraud management programme with detection, investigation, reporting and resolution, a death records check for all proofing, and suggested signals such as SIM swap detection, device fingerprinting and transaction analytics. Knowledge-based verification shall not be used to verify identity.

European standards

ISO/IEC 30107-3:2023: the second edition of the PAD testing and reporting standard (replacing the 2017 edition). It defines how to evaluate and report PAD performance, including the attack and bona fide classification error rates (APCER and BPCER), but does not standardise PAD mechanisms or system-level security.
CEN/TS 18099:2024: "Biometric data injection attack detection", valid from 16 December 2024. It defines injection attacks and instruments against enrolment and verification, and gives guidance on detection systems, risk mitigation and test plans for evaluating IAD, including bona fide testing so that genuine users are not rejected. It is a Technical Specification rather than a full European Norm, so check the current status with your national standards body before quoting it in a contract.
ETSI TS 119 461 V2.1.1 (2025-02): the policy and security requirements for identity proofing used by trust services under eIDAS. It defines a baseline level of identity proofing (substantial confidence, considering attackers with moderate attack potential) and an extended level (high confidence, considering high attack potential). Clause 4.5 treats presentation attacks, injection attacks and deepfakes as threats; it cites CEN/TS 18099 and ISO/IEC 30107-3 as normative references and requires accredited independent testing of IAD and PAD every second year. Fully automated remote proofing with an identity document requires a digital identity document (such as the chip in an eMRTD) plus face biometrics for binding.
ENISA: its remote identity proofing reports (attacks and countermeasures, and good practices published March 2024) stress that there is no single ideal countermeasure and that the mix depends on the business, user base and required level of assurance.

For how these levels feed onboarding and KYC decisions, see the Identity Proofing and KYC Guide.

Designing a layered verification flow

No single engine is enough. A resilient flow combines evidence strength, capture integrity, liveness and context, so that an attacker has to defeat several independent checks at once.

Prefer cryptographic evidence where you can get it: read the chip of an ePassport or national ID card over NFC and verify the issuer signature (ICAO Doc 9303 passive authentication). A signed chip photo and data group cannot be generated by an image model, which shifts the question from "is this image real" to "is this person the holder", a much smaller problem. NIST rates cryptographically protected evidence with a verifiable issuer signature as the strongest (Superior) evidence class.
Capture inside a trusted client: use a native SDK or an attested web capture component rather than accepting file uploads. Require live capture, block gallery uploads, and use platform attestation (for example Android Play Integrity or Apple App Attest) to show the request came from your genuine, unmodified app on a genuine device.
Detect injection at the client and server: check for virtual camera drivers, emulators, rooted or jailbroken devices, hooking frameworks and debugger attachment; bind each capture to a server-issued nonce and session so that recorded or replayed streams fail; sign the capture payload in the client and verify it server side.
Run PAD and media forensics: passive PAD (single frame or short sequence analysis) has the least friction; active PAD (randomised head turns, expressions, colour or light challenges) adds assurance at a usability cost. Add media forensics for synthesis artefacts, inconsistent lighting and compression traces, but treat deepfake detectors as one signal, since they degrade as generators improve.
Compare and deduplicate: 1:1 comparison of the live face with the document or chip photo, and 1:N checks against previously enrolled faces to catch one face behind many identities, a common synthetic identity pattern. See the Synthetic Identity Fraud Guide.
Add context signals: device reputation and velocity, IP and geolocation consistency with the document, SIM swap and number porting checks, email and phone age, and whether the same device has attempted multiple identities.
Route uncertainty to trained people: send borderline or conflicting results to reviewers or a trusted referee process, with clear evidence on screen and the authority to require a different channel, such as chip reading, a branch visit or a recorded attended session.

Choosing assurance for each journey

Not every journey needs the same depth. Over-engineering low-risk sign-ups loses customers; under-engineering account recovery hands accounts to attackers.

Journey	Typical target	Recommended pattern	Trade-off
Low-risk account creation	IAL1 or no proofing	Device and velocity signals, phone or email checks	Low friction, weak against synthetic identities
Regulated onboarding (banking, payments, crypto)	IAL2 or eIDAS substantial	Chip read where available, live document capture, PAD plus IAD, 1:N deduplication	Higher drop-off on older devices without NFC
Account recovery and authenticator reset	Same level as original proofing or higher	Re-verification against the enrolled face and original evidence, plus device and history checks	Slower recovery; this is where takeover attempts concentrate
High-value transaction step-up	Risk-based	Phishing-resistant authenticator first; biometric re-verification only as a supplement	Biometric step-up alone can be replayed if channel integrity is weak
Workforce onboarding and remote hiring	IAL2	Chip read, attended video with random prompts, check against HR records	Needs HR and IT coordination; see the Hiring Fraud and Candidate Identity Verification Guide
Privileged or high-assurance credentials	IAL3	On-site attended or supervised kiosk	Cost and logistics, justified for administrators and signing keys

Small organisations: buy rather than build, and put effort into contract terms: require ISO/IEC 30107-3 PAD reports and CEN/TS 18099 style IAD test evidence from an independent laboratory, disclosure of the attack species tested, and notification when engines change. The Identity Verification Buyer's Guide covers evaluation questions.
Large organisations: run more than one signal source, keep the decision logic in your own risk engine so you can switch or combine providers, and run your own adversarial testing programme against each release.
Passive versus active liveness: choose passive by default for consumer flows and step up to active challenges or chip reading when risk signals fire; active challenges alone do not stop injection, because a real-time generator can follow prompts.

Implementation and testing

Map the journeys: list every place identity is proven or re-proven (onboarding, recovery, authenticator reset, payee changes, help desk), the assurance level each needs and the fallback paths. Fallbacks are often the weakest link.
Threat model each capture path: native app, mobile web, desktop web and agent video each have different injection surfaces. Desktop browsers with virtual camera software are usually the hardest to secure, so consider routing high-risk desktop users to mobile capture.
Collect evidence from suppliers: obtain current independent PAD and IAD test reports, the IAPAR and BPCER achieved, demographic performance, and the date of the last test. Treat self-declared results as marketing until tested.
Run in shadow mode first: turn on new IAD or deepfake detection in log-only mode for two to four weeks, measure false positives against confirmed genuine users, then tune thresholds before enforcing.
Pilot by segment: enforce for the highest-risk segment first (new devices, high-value products, recovery requests), keep a manual review queue sized for the expected referrals, and watch drop-off by device type.
Red team regularly: commission authorised testing that includes presentation, injection and attended-session scenarios, using an accredited laboratory or a specialist tester under a written scope. Repeat after every major SDK or model update.
Plan rollback: keep decision thresholds and engine choices configurable, version the rules, and have a documented fallback (for example forcing chip read or manual review) if a detector fails open or causes a spike in false rejections.

Detection, review and measurement

Verification decisions need the same telemetry discipline as authentication. Log, for every attempt: device and app integrity verdicts, camera source metadata, PAD and IAD scores, media forensics flags, face comparison scores, document checks, chip read result, reviewer decision and final outcome. Keep enough to reconstruct a case, and apply biometric data minimisation and retention rules (see the Illinois BIPA and Biometric Privacy Guide).

FinCEN alert FIN-2024-Alert004 (November 2024) gives useful red flags for reviewers and rules, among them a third-party webcam plugin during a live check, a request to switch channel after repeated "technical glitches", a refusal to use MFA, a photo that matches galleries of generated faces, documents inconsistent with each other or with apparent age, and device or geography that does not fit the documents. US financial institutions reporting such cases are asked to use the key term FIN-2024-DEEPFAKEFRAUD in suspicious activity reports.

Metric	What it shows	Source
IAPAR and APCER by attack species	How often attacks are wrongly accepted	Independent test reports, internal red team
BPCER and false rejection by device and demographic group	Cost to genuine users, and fairness	Test reports, production outcomes
Injection detections per 10,000 attempts	Attack pressure and detector health (a sudden drop can mean evasion)	Production logs
Manual review overturn rate	Whether automated decisions and reviewers agree	Case management
Confirmed fraud found after onboarding (per 10,000 accounts)	Attacks that got through, the true outcome measure	Fraud investigations, chargebacks, SARs
Time from new attack pattern to rule or model update	Speed of the feedback loop	Change records

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	PR.AA-02	Identities are proofed and bound to credentials based on context
NIST SP 800-53 Rev. 5	IA-12, IA-12(2), IA-12(3), IA-12(4), IA-12(5)	Identity proofing, evidence, validation and verification, in-person verification, address confirmation
NIST SP 800-53 Rev. 5	SI-10, SI-4	Input validation on capture payloads; monitoring of proofing systems
NIST SP 800-63A-4	IAL1 to IAL3	PAD, injection controls, biometric performance, fraud programme
MITRE ATLAS	AML.T0088 Generate Deepfakes	Adversary creation of synthetic media
MITRE ATLAS	AML.T0015 Evade AI Model	Inputs crafted to evade AI-based detectors such as PAD and deepfake classifiers
ETSI TS 119 461	Clause 4.5, baseline and extended LoIP	PA, injection and deepfake threats; independent IAD and PAD testing
ISO/IEC 30107-3, CEN/TS 18099	Testing standards	Evidence to demand from suppliers

Where identity fits

Verification is only the first link in an identity lifecycle. A proofed identity that is then bound to a phishable password and SMS code gives attackers an easier route than beating liveness. Bind verified identities to phishing-resistant authenticators at enrolment (see the Passwordless and Passkeys Guide), and make recovery require re-verification to the same standard. The client SDKs, API keys and service accounts that connect your capture app to the verification provider are themselves non-human identities: scope them narrowly, rotate them and monitor their use, since a stolen provider API key can let an attacker submit captures directly.

Common failure patterns

Liveness treated as a cure-all: passing a PAD test does not prove resistance to injection. Organisations that only ask for an ISO/IEC 30107-3 report miss the attack class that generative AI has made cheap.
File upload fallback left open: the main flow uses live capture, but a "having trouble?" path accepts uploaded images, which turns every control into optional.
Trusting live video by default: treating a video call as proof of identity. The Arup deepfake fraud showed how convincing a real-time fake on a multi-person call can be; attended sessions need random prompts, trained agents and out-of-band confirmation.
Weaker recovery than onboarding: strong proofing at sign-up, then account recovery through a help desk or a chatbot that accepts personal details. See the Account Recovery and Help Desk Security Guide.
No feedback loop: fraud found months later is never traced back to the verification attempt, so thresholds and rules never improve.
Unmanaged supplier change: a provider updates its models or SDK, and nobody re-tests or checks demographic performance before the new version reaches production.

Practitioner checklist

Inventory every journey where identity is proven or re-proven, with its target IAL or eIDAS level and every fallback path.
Require live capture through a native SDK or attested web component, and close file upload routes for high-risk journeys.
Read and verify document chips over NFC wherever the document and device support it.
Deploy injection attack detection (virtual camera, emulator, hooking, app attestation, nonce-bound captures) alongside PAD.
Obtain current independent ISO/IEC 30107-3 PAD and CEN/TS 18099 aligned IAD test reports, with IAPAR, BPCER and demographic results.
Test new detectors in shadow mode, then enforce by risk segment with a sized manual review queue and a documented rollback.
Train reviewers and attended-session agents on deepfake indicators and FinCEN red flags, and use random prompts in video sessions.
Make account recovery re-verify to at least the onboarding standard, and bind verified users to phishing-resistant authenticators.
Track the six metrics above monthly and link post-onboarding fraud back to the verification record.

Deepfake-Resistant Identity Verification Guide: Liveness, Injection Attacks and Assurance