In 2024, a finance employee at a multinational firm transferred $25 million after participating in a video call with people he believed were his CFO and colleagues. Every face on the call was a deepfake. The attack succeeded not because the technology was perfect, but because the victim had no mechanism to verify the identity of the people he was looking at beyond visual inspection — and visual inspection is no longer a reliable identity control. Digital onboarding faces the same structural vulnerability at scale.
The Deepfake Threat Has Crossed a Threshold
For most of the past decade, deepfake quality was a limiting factor. Artefacts — unnatural blinking, hair rendering failures, lip-sync delays — were reliably detectable by trained reviewers and, increasingly, by automated systems. That limitation is gone. Contemporary deepfake generation models trained on large video datasets produce synthetic faces that fool human reviewers at rates that make manual review operationally unreliable. The adversarial improvement cycle — where deepfake generators are trained against liveness detectors — has produced an arms race in which the commercial liveness detection market is perpetually responding to capabilities that already exist in the attack tooling.
The specific attack pattern affecting digital onboarding is synthetic identity fraud at the point of KYC. An attacker combines a genuine stolen identity document — obtained from a data breach, purchased on criminal marketplaces, or fabricated using generative AI — with a synthetic face generated to match the document photo. The onboarding flow requests a selfie and a liveness check. The attacker injects a pre-recorded or real-time-generated deepfake video into the camera feed at the driver level, bypassing the device camera entirely. The liveness detector receives what appears to be a live face performing the requested challenges. Without injection attack detection, the synthetic face passes.
This attack vector has moved from specialist capability to commodity. Commercial deepfake injection kits — purpose-built tools for bypassing identity verification systems — are available on criminal forums for a few hundred dollars. The barrier to entry for synthetic identity fraud at the onboarding layer is lower than at any point in the history of digital identity verification.
Presentation Attacks vs Injection Attacks: A Critical Distinction
Liveness detection was originally designed against presentation attacks: a fraudster holding a printed photograph in front of the camera, replaying a video on a screen, or using a three-dimensional mask. Presentation attack detection (PAD) works by analysing the real-world physical properties of what the camera sees — texture, depth, reflection patterns, and the micro-movements that distinguish a live face from a static image or a flat display. ISO/IEC 30107-3 defines the conformance standard for presentation attack detection, and compliant solutions perform reliably against the attacks they were designed for.
Injection attacks bypass the camera entirely. Rather than presenting a fake face to the physical camera, an injection attack replaces the camera's output signal at the driver or API level — the liveness detector receives a synthesised video stream that it analyses for liveness signals and finds them convincing, because the synthetic face has been generated specifically to exhibit those signals. PAD techniques that analyse optical properties of the camera image are irrelevant against an attack that never passes through the physical camera.
Detecting injection attacks requires a different class of controls: signal integrity verification. This means confirming that the video stream originates from the expected hardware camera, has not been intercepted or modified in transit, and exhibits the noise characteristics of a real sensor rather than a rendered output. Solutions from iProov, Onfido (now part of Entrust), and Jumio implement signal integrity analysis as a layer beneath their liveness detection — verifying the provenance of the video stream before applying PAD algorithms to its content.
ISO/IEC 30107-3 conformance certifies a liveness solution against presentation attacks — physical artefacts presented to a real camera. It says nothing about injection attack resistance. An ISO-conformant liveness product can be bypassed by an injection attack. Before selecting or auditing a liveness vendor, explicitly ask for injection attack detection capability evidence — it is a separate technical capability from PAD, not included by default.
Active vs Passive Liveness: Trade-offs at Scale
Liveness detection approaches fall into two broad categories: active and passive. Active liveness requires the user to perform a specific action — turn their head left, blink twice, smile — which the system verifies. The action requirement provides a challenge-response signal that is harder to fake with a static deepfake. The trade-off is user experience: active challenges add friction to the onboarding flow, have higher failure rates for users with limited mobility or poor camera conditions, and can be replayed if an attacker captures a genuine user completing the challenge and replays that recording.
Passive liveness requires no user action. The system analyses a brief video of the user's natural face — typically two to five seconds — and extracts liveness signals from micro-expressions, involuntary motion, depth cues, and signal characteristics. The experience is frictionless: the user simply looks at the camera. The security trade-off is that passive systems must work harder to distinguish a sophisticated deepfake from a live face, because there is no action requirement to constrain the attack space.
iProov's Flashmark technology takes a third approach: projecting a randomised sequence of coloured light onto the user's face and verifying the reflection — a challenge that cannot be replayed or pre-recorded because the sequence is unique to each session and the physiological response is physically impossible to fabricate in real time. This approach provides challenge-response security without requiring deliberate user action, at the cost of specific hardware requirements (adequate ambient light, a front-facing camera capable of detecting subtle colour changes).
For most enterprise onboarding programmes, the practical choice is a hybrid: passive liveness as the baseline, with an active challenge escalation path for borderline confidence scores. This balances throughput — the majority of legitimate users pass passively with minimal friction — against security — suspicious cases trigger an additional verification layer before acceptance.
The Vendor Landscape: What to Evaluate
The commercial liveness detection market has consolidated around a tier of vendors with demonstrable ISO 30107-3 certification at Level 1 or Level 2, injection attack detection, and NIST face recognition accuracy benchmarks. The leading solutions each make distinct technical trade-offs worth understanding before selection.
iProov provides hardware-based liveness assurance using its Flashmark illumination technology. It is used by major financial institutions and government identity programmes, including HMRC in the UK and several EU member state digital identity schemes. Its assurance level is highest for the attack classes it is designed for, but the illumination requirement creates environmental constraints. Onfido (now operating under the Entrust umbrella) combines document verification, biometric match, and liveness detection in an integrated SDK with broad device compatibility and well-documented passive liveness performance. Jumio offers a full identity verification platform with liveness, document verification, and fraud signal enrichment — its strength is the integration of network-level fraud signals (shared across its customer base) with biometric liveness, which improves detection of synthetic identities that have appeared elsewhere in the fraud ecosystem.
For organisations already embedded in hyperscaler ecosystems, Microsoft Azure Face API and AWS Rekognition both offer liveness detection capabilities integrated with their respective cloud identity and ML platforms. Their accuracy at the highest assurance levels trails the specialist vendors, but their integration simplicity and existing commercial relationships make them viable for lower-risk onboarding flows where ISO 30107-3 Level 2 is not a hard requirement.
Implementation Considerations for Enterprise Onboarding
Integrating liveness detection into an existing onboarding flow requires decisions at four layers: the integration model, the device scope, the confidence threshold policy, and the fallback workflow.
The integration model — SDK versus API — determines where liveness analysis occurs. SDK integration processes biometric data on the device, which reduces latency and limits data transmission but requires SDK maintenance across mobile platforms and browser environments. API integration sends video to the vendor's servers for analysis, which simplifies device-side implementation at the cost of latency and data transmission requirements that may conflict with data residency obligations under GDPR or sector-specific regulations. For EU-regulated financial institutions, confirm the vendor's data processing location and legal basis before selecting an API model.
Device scope determines which onboarding channels can offer biometric liveness. Mobile native applications offer the most reliable camera signal quality and the most straightforward SDK integration. Browser-based flows introduce variability in camera API access across browsers and operating systems, and require additional hardening against injection attacks that operate at the browser level. For high-assurance onboarding, requiring a native mobile app — rather than browser — for the biometric step provides a materially more controlled environment.
The confidence threshold policy defines what score constitutes a liveness pass, and what happens below that threshold. Setting the threshold too high creates false rejection rates that damage user experience and disproportionately affect specific demographic groups — liveness systems have documented performance variation across age, skin tone, and lighting conditions. Setting it too low allows synthetic identities to pass. Pilot data from your specific user population, analysed against demographic segments, is the only reliable basis for threshold setting. Vendor-published accuracy figures are measured on benchmark datasets that may not represent your users.
Compliance Implications: DORA, NIS2, and AML/KYC
For financial institutions, the regulatory driver for liveness detection is primarily AML/KYC — the obligation to verify customer identity at onboarding to a standard that satisfies anti-money laundering requirements. The EBA's remote customer onboarding guidelines explicitly reference biometric liveness checks as an acceptable method for remote identity verification at the highest assurance level, making liveness detection a compliance component rather than an optional enhancement for regulated onboarding flows.
Under DORA, financial entities that rely on third-party identity verification providers for onboarding must assess those providers as ICT third-party risk. The liveness vendor is an ICT service provider under DORA's framework — your due diligence obligations apply, including reviewing their security posture, their incident notification capabilities, and their contractual commitments. A liveness system outage during peak onboarding hours is an operational resilience event with regulatory implications, not just a UX problem.
The maturity standard for enterprise deepfake defence at onboarding has four components: a liveness solution with injection attack detection capability (not just PAD), a demographic performance audit before deployment, an operational monitoring programme that tracks liveness pass rates and manual review escalation rates by channel and device type, and a vendor due diligence programme that treats the liveness provider as a critical ICT dependency. Organisations that have all four in place are equipped for the current threat environment. Organisations with only a PAD-capable liveness check and no injection attack detection are not — regardless of how recently they implemented their current solution.