Deepfake Detection Buyer’s Guide: Choosing Tools That Hold Up Under Real Attacks

Deepfake detection tools are sold on headline accuracy figures, yet the attacks that cost organisations money arrive through live video calls, cloned voices on help desk lines and injected camera feeds in onboarding flows, where lab accuracy rarely holds. The category covers products that analyse images, video and audio, live or recorded, for signs of synthetic or manipulated media, and the related controls that detect injected media at the capture point. This guide is for security, fraud, identity verification and procurement teams deciding whether to buy, which use cases to cover, and how to test claims. It is vendor-neutral and does not name or rank products. For the threat itself, see the Deepfake and AI Impersonation Guide.

Key takeaways

• Detection is a layer, not the control: in the Arup deepfake fraud, HK$200 million left in 15 transfers after a video call; out-of-band verification and payment approval rules would have stopped it whether or not a detector fired.
• Use case decides the product: identity proofing, contact centre voice, executive video calls and media verification are different markets with different integration points and metrics.
• Ask for false negative rates by attack type: NIST SP 800-63A-4 requires identity providers to test media manipulation detection against attack artefacts and document the attack types tested and false negative rates; ask every vendor for the same.
• Injection beats analysis: forged media inserted between the camera and the checker can bypass content analysis, so virtual camera, emulator and device integrity checks matter as much as the model.
• Plan for decay: generation tools improve constantly, so contracts need model update commitments and you need a way to re-test regularly.

What the category does

Image and video manipulation detection has a public evaluation history: NIST's Open Media Forensics Challenge measures detection and localisation of manipulation, including GAN-generated content, building on the earlier Media Forensic Challenge evaluations. Treat such benchmarks as a starting point, because your channels, codecs and attack mix differ.

When you need it

• Strong case: remote onboarding or account recovery with face or voice biometrics, high-value payment approvals on calls, or a help desk that resets credentials over the phone.
• Weak case: where process controls are missing. If a single phone call can reset an administrator's MFA or release a payment, fix the process first; see the Account Recovery and Help Desk Security Guide.
• Regulated identity: if you rely on an identity verification provider, the requirement may sit with them. Ask whether their presentation attack detection is tested to ISO/IEC 30107-3:2023, as NIST SP 800-63A-4 requires for biometric PAD testing.
• Small organisations: start with callback rules, payment dual control and staff training, which the FBI also recommends; buy detection only for the highest-risk channel.
• Large organisations: expect separate tools per channel and plan a common alert route into fraud and security operations.

Define requirements

• Channels and volumes: which flows (onboarding, recovery, calls, meetings, uploads), how many sessions per day, and peak load.
• Real-time or batch: live calls need decisions in seconds; claims and investigations can wait for deeper analysis.
• Decision model: score only, step-up trigger, or block; who acts on an alert and in what time.
• Attack coverage: face swap, fully synthetic video, lip-sync, voice cloning, replayed recordings, injected camera feeds, document forgery.
• Device and capture integrity: NIST SP 800-63A-4 requires remote proofing services to detect virtual cameras, emulators and jailbroken devices, and recommends device attestation and passive forgery detection; include these in scope.
• Fairness: performance across demographic groups, languages and accents; NIST recommends periodic independent testing of biometric algorithms, including across demographic groups.
• Privacy: biometric and call data handling, retention, residency, lawful basis and whether data trains vendor models.

Must-have capabilities

Evaluation criteria

Questions to ask vendors

1. Which attack types have you tested against, and what are the false negative and false positive rates for each?
2. Who tested the product independently, against which standard, and when?
3. How does accuracy change on compressed video, phone-quality audio and poor lighting?
4. How do you detect injected media, virtual cameras and emulators, not just manipulated content?
5. How often are models updated for new generation techniques, and how are customers told?
6. What is the latency for a live decision, and what happens if the service is unavailable?
7. What performance data do you have across demographic groups, languages and accents?
8. Where is biometric and call data processed and stored, for how long, and is it used for training?
9. What evidence do you provide for a disputed decision?
10. How do alerts reach our fraud or security teams, and in what format?

Deployment and integration

1. Score-only pilot: run on one channel in monitoring mode for four to eight weeks to measure alert rates and genuine-user impact.
2. Tune thresholds: set thresholds per channel based on pilot data and the cost of a missed attack versus a rejected customer.
3. Step-up, not block, first: route high scores to an extra verification step, such as a callback to a number on file or a request through an authenticated system.
4. Connect to response: send alerts to fraud case management or the SOC with session details; link to the Deepfake CEO Fraud Response Playbook.
5. Re-test regularly: repeat the attack test set at least quarterly and after vendor model changes.
6. Rollback: keep the ability to switch back to score-only mode if false rejections spike.

Where identity fits: the tool protects human identity decisions, such as onboarding, recovery and payment approval, and the same principle applies to machines. A service or AI agent that trusts a request because of its apparent source, rather than cryptographic proof, faces the same weakness. See the Deepfake-Resistant Identity Verification Guide.

Matching controls to attack scenarios

The pattern is consistent: the detector raises the alarm, but a process that does not rely on a face or voice decides the outcome. The FBI's advice on AI voice and video cloning makes the same point, putting verification through a separate channel, scepticism towards urgency and staff training ahead of technology. For finance teams, see the Business Email Compromise Awareness for Finance Teams Guide.

Commercial and contract terms

• Pricing basis: per verification, per call minute or per seat; model it on peak volumes, because attacks often coincide with busy periods.
• Performance commitments: agreed detection and false rejection levels on your own test set, re-measured at renewal.
• Model change notice: advance notice of material model changes and a test window before they apply to production decisions.
• Data processing: a data processing agreement covering biometric data, sub-processors, regions, retention and deletion on exit.
• Availability: service levels for live channels and a defined fail-open or fail-closed behaviour you have chosen, not one the vendor defaults to.
• Evidence support: commitments to provide analysis records for disputes, complaints and law enforcement referrals.

Red flags

• A single accuracy figure with no attack types, test conditions or false negative rate.
• Claims of detecting "all deepfakes" or future techniques.
• No injection or device integrity controls for identity proofing.
• No demographic performance data.
• Results only on high-quality lab media.
• Biometric data retained by default or used for training without consent.
• No committed model update cadence.

Proof of concept

1. Pick one channel and collect genuine sessions with consent and a lawful basis.
2. Build a test set of synthetic and manipulated media the vendor has not seen, covering the attack types in your requirements and your real media quality.
3. Measure detection and false rejection per attack type, not in aggregate.
4. Test the capture path for injection resistance with your identity verification or security testing provider under an agreed test plan.
5. Measure latency and behaviour when the service is unavailable.
6. Review alert evidence with the investigators who will use it.
7. Complete the data protection impact assessment before going live.

Measuring whether it works

• Detection rate per attack type on the quarterly re-test set, compared with the PoC baseline.
• Genuine-user false rejection or step-up rate per channel, and the resulting abandonment or complaint volume.
• Median time from a live-call alert to a human acting on it.
• Share of high-value payment or credential reset requests verified through an independent channel.
• Confirmed deepfake incidents that the tool missed, found through other controls or reports, reviewed in a post-incident process.

Report these to the fraud and security risk owners together. A rising detection rate with a rising false rejection rate usually means thresholds have been tightened rather than the model improving, and both teams need to see that trade-off.

Pitfalls

• Buying detection instead of fixing process: callbacks, dual approval and authenticated request channels remain the primary controls.
• Trusting aggregate accuracy: a high overall rate can hide poor results on the attack type you face.
• Testing once: generation quality moves faster than procurement cycles.
• Ignoring the genuine user: high false rejection pushes customers and staff to bypass the control.
• Covering one channel and assuming the rest: attackers move to whichever route is unprotected, so map every channel where a face or voice can authorise an action, and record which ones rely on process controls alone.
• No owner for alerts: a live-call alert that reaches nobody within minutes is useless; agree who acts, how, and within what time before go-live.
• Overlooking privacy law: biometric processing carries specific legal duties in many jurisdictions; involve privacy teams early.

Buyer checklist

• Highest-risk channel chosen and process controls in place first.
• Attack types and media conditions written into requirements.
• Per-attack false negative and false positive rates obtained.
• Injection and device integrity controls confirmed for identity flows.
• PAD testing to ISO/IEC 30107-3:2023 confirmed where biometrics are used.
• Demographic performance reviewed.
• Pilot run in score-only mode with thresholds tuned.
• Model update and notification terms in the contract.
• Quarterly re-testing scheduled.

Standards and references

• NIST: SP 800-63A-4 Identity Proofing and Enrollment
• NIST: Open Media Forensics Challenge
• FBI: Warning on cyber criminals using artificial intelligence

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for deepfake detection and identity verification controls, including how they connect to help desk, payment and agent authentication processes. Browse vendors in our NHI and AI products directory or contact us.

Related NHI Mgmt Group resources: Deepfake and AI Impersonation Guide · Deepfake-Resistant Identity Verification Guide · Executive Deepfake and CEO Fraud Guide · Deepfake CEO Fraud Response Playbook