Liveness and Deepfake Detection for OEM Integration: Embedding Face Checks in Devices and Platforms

What OEMs and Platforms Actually Embed

Original equipment manufacturers, identity verification vendors, kiosk makers and app platforms embed face checks so that their customers do not have to build them. The embedded component usually has three jobs: capture a good face image or short video, establish that the capture came from a real sensor on a trustworthy device, and decide whether the face is live and unmanipulated. The host product then makes the business decision, such as granting account access, opening a wallet or approving an enrollment.

Liveness and deepfake detection overlap but are not the same. Presentation attack detection, often called liveness, checks for physical artefacts held up to the camera: printed photos, screens and masks. Deepfake detection checks the media for generation, face swapping and pixel-level editing, including media injected into the pipeline without ever passing in front of the lens. An OEM component needs both.

Can Deepfake Detection Run On-Device in a Mobile SDK?

It can, with trade-offs that usually favour a hybrid design. Lightweight models can run on modern phones and give an instant first-pass result without sending media off the device. Three constraints limit how far that goes. Compute and battery cap model size, and smaller models generally generalise less well to new generators. Updates depend on app releases and user upgrades, so a new face-swap tool can outpace the deployed model for weeks. And the device may belong to the attacker: on a rooted phone or emulator, an on-device verdict can be tampered with or bypassed before it reaches the server.

A common pattern is to keep capture, sensor and device integrity checks in the SDK, where they need direct access to the hardware, and run the heavier manipulation analysis on a server the OEM or its customer controls. That server can be updated centrally, its result cannot be altered by the client, and the media can stay inside a private cloud or on-premises environment when privacy rules require it.

Standards and Certifications OEMs Are Asked About

Buyers of embedded face verification increasingly ask for evidence against named standards. NIST SP 800-63A-4 (July 2025) requires credential service providers to implement controls that increase confidence media came from a genuine sensor, such as detecting a virtual camera, device emulator or jailbroken device, and to analyze all submitted media for manipulation. It says they SHOULD authenticate capture sensors or use device attestation, and requires remote biometric PAD tested to ISO/IEC 30107-3:2023 with an impostor attack presentation accept rate below 0.07.

FIDO Alliance biometric requirements (version 4.1) include a face verification profile for identity verification. For it, each presentation attack instrument species must have an IAPAR of 7% or less, and the vendor must document the protections implemented around the component against injection and replay attacks, which the test lab verifies. In Europe, CEN/TS 18099:2024, valid from 16 December 2024, covers biometric data injection attack detection: definitions, injection attack instruments, detection systems, mitigation and how to plan an evaluation. It explicitly leaves presentation attack testing to the ISO/IEC 30107 series.

An Integration Architecture That Holds Up

A defensible embedded design keeps responsibilities clear between the SDK, the analysis service and the host product:

• SDK: guided capture, sensor and device integrity signals (virtual camera, emulator, root or jailbreak), session binding and signed transmission over an authenticated channel.
• Analysis service: liveness, face manipulation, generative model and pixel-level analysis on the received media, returning signal-level results and a model version.
• Host product: policy thresholds, retries, fallback routes and the final business decision.
• Evidence: log signals, model version and decision per session so the OEM's customers can audit outcomes and answer regulators.
• Updates: version the analysis models centrally and let customers pin or test versions before switching.

Limits OEMs Should Disclose to Customers

No embedded component can guarantee that a person is who they claim; it can only report whether a capture looks live and unmanipulated and whether it matches a reference. Performance changes with camera quality, lighting, compression and population, so OEMs should give customers results on representative data and the means to test their own. Certification under one standard does not imply coverage of another: a PAD certificate says nothing about injection resistance, and an injection evaluation says nothing about deepfake detection on uploaded images.

Customers also need to know which parts of the decision are theirs. Thresholds, fallbacks for users who cannot complete a capture, and adverse decisions belong to the host product's policy.

How NeuroVerify Fits OEM and Platform Products

NeuroVerify is Neural Defend's API for checking face images, video and audio for deepfakes and manipulation beyond liveness. One request returns six signals: Visual Safety Screening, Live Presence Verification, Face Manipulation Detection, AI Generative Model Analysis, AI Pixel-Level Manipulation and AI Content Compliance, with a unified risk score and signal-level evidence the host product can map to its own policy. Results arrive in under 200 ms at p95 on eligible image requests under defined test conditions.

For embedding, Neural Defend offers mobile SDKs for Android (Kotlin), iOS (Swift) and Flutter, backend SDKs for Python, TypeScript and Node.js, Go and Java, a REST API and an MCP server for AI agents, and describes integration as two lines and live in under 24 hours. OEMs and their customers can run it as a managed cloud API or in a private cloud or VPC, as a secure container, on premises or air-gapped, scoped during evaluation. Neural Defend holds ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 42001 and SOC 2 Type II certifications. On the public VendorBench-100 benchmark of adversarial still images it ranked first of 36 systems, with an MCC of 0.876 against 0.646 for the next-best vendor; that benchmark does not test injection or video, which OEMs should evaluate separately. NeuroVerify does not analyse ID documents.