Liveness Detection SDK: A Checklist for Integration

A liveness detection SDK runs the face capture on the user’s phone, so it controls what the server receives. Before go-live, check four things: what the SDK protects beyond the face, how it handles poor capture conditions, where users drop off, and whether your server verifies the result instead of trusting the app.

Liveness Detection SDK vs API: What Runs on the Device

An API-only setup receives a selfie or short video and analyses it on the server. That works, but the server only sees the file. It cannot tell whether a real camera produced it, or whether a script on a rooted phone fed it in.

An SDK moves part of the work onto the device. It opens the camera, guides the user, checks frame quality in real time and inspects the environment the app runs in. Then it packages the capture and sends it for analysis. So the SDK decides two things the API cannot: what a good capture looks like, and whether the capture path is trustworthy.

That makes the SDK choice a security decision, not just a UX one. If you only need a refresher on the underlying checks, start with our liveness detection fundamentals. This guide assumes you already know what liveness does and focuses on getting it into production.

What a Liveness SDK Must Protect Besides the Face

Most fraud against a liveness flow no longer targets the face model. Instead, it targets the app around it. Ask any vendor how the SDK handles these four threats:

• Emulators. A fraudster runs your app on a virtual Android device on a PC, which makes it easy to script signups and swap in video.
• Rooted or jailbroken phones. Root access lets other apps read and change what your app does, including the camera feed.
• Hooking tools. Frameworks such as Frida attach to the running app and change its functions, for example to skip a check or return a fake “pass”.
• Injection and MITM. Virtual cameras push prerecorded or deepfake video into the flow, while man-in-the-middle tools alter the payload on its way to the server.

Verify the Result on the Server, Never in the App

This is the most common integration mistake. A team reads a “liveness passed” flag inside the mobile app, then lets the user continue. Anyone with a hooking tool can flip that flag. So the app should only forward a session reference, and your backend should fetch or verify the result directly with the vendor. Treat the client as untrusted, even when the SDK itself is hardened.

Also confirm that the SDK signs or encrypts the capture payload, and that you pin certificates for the upload. Then ask what happens when a threat is detected. Some SDKs block silently, while others return a risk signal you can route to review. The second option gives your fraud team far more to work with.

Capture Quality: Blur, Low Light and Accessories

Most failed liveness checks are not attacks. They are genuine users with a bad capture. A good SDK catches those problems before upload and tells the user how to fix them.

Capture problem	What causes it	What the SDK should do
Motion blur	Shaky hands, a moving bus, a slow shutter in dim light	Reject the frame and ask the user to hold still
Low light or backlight	Night use, a window behind the user	Show a live brightness hint, or brighten the screen as a fill light
Face too far or cut off	Small oval, phone held at arm’s length	Give distance guidance with a clear frame
Accessories	Sunglasses, masks, caps, heavy shadows	Detect the attribute and ask the user to remove it
Weak camera	Older budget Android phones with low-resolution front cameras	Adapt capture settings and test on those models before launch

Ask vendors which of these the SDK detects on the device, and which ones only fail later on the server. A failure on the server costs the user a full upload and a retry. A hint on the device costs them two seconds.

Where Users Abandon Liveness Checks and How to Fix It

Drop-off clusters at a few predictable points. Watch your funnel at each one, because the fixes are cheap once you know where the leak is.

1. Camera permission. Users deny access when the request appears without context. So show a short screen first that explains why the app needs the camera.
2. Unclear instructions. Vague prompts such as “verify your face” leave users guessing. Use one instruction at a time, with a live visual cue.
3. Repeated failure. Three silent rejections in a row will lose most users. Give a reason after each failure, then offer a fallback such as manual review.
4. Slow upload. Large video payloads stall on weak mobile networks. Ask the vendor about payload size and compression.

Active versus passive liveness also affects drop-off. Active checks add prompts, which some users struggle with, while passive checks need only one capture. Our guide to active vs passive liveness covers when each one fits. For the onboarding steps around this one, see liveness checks in eKYC.

Thresholds, False Accepts and False Rejects in Production

Every liveness SDK returns a score, and a threshold turns that score into pass or fail. The vendor’s default threshold is a starting point, not a setting for your users. So plan to tune it with real traffic.

Two error rates move against each other. A strict threshold lets fewer attacks through but rejects more genuine users. A loose one does the reverse. Agree with risk and product teams which side matters more for each journey, since a loan application and a balance check rarely need the same setting.

Then watch the numbers after launch. Track the pass rate by device model, OS version and time of day, because a sudden drop on one phone model usually signals a capture problem rather than an attack wave. Also keep a sample of rejected sessions for manual review each week, so you can tell genuine friction from real fraud.

Accessibility in Liveness Detection Flows

A liveness step can lock out users who are blind, have limited mobility or have facial differences. That is a fairness problem and, in many markets, a legal one. WCAG 2.2 gives a useful baseline, built on four principles that accessibility teams shorten to POUR.

Two WCAG 2.2 success criteria matter most here. Under SC 2.2.1, users must be able to turn off, adjust or extend time limits, so avoid hard countdowns. Under SC 1.3.3, instructions should not rely only on shape, colour or position, so pair a green oval with spoken or written guidance. Finally, keep a non-biometric fallback path for users who cannot complete the check at all.

Privacy and Data Handling in a Liveness SDK

A liveness SDK handles face images, which most privacy laws treat as sensitive data. So ask early what leaves the device, where it goes and how long it stays there.

• Data in transit. Captures should travel encrypted, with the SDK signing each payload.
• Retention. Agree how long the vendor keeps images and templates, and whether it uses them to train models.
• Location. Check where processing happens if your market restricts cross-border transfers.
• Consent. Show a clear notice before the camera opens, and log the user’s consent with the session.

Liveness SDK Evaluation Checklist and Test Plan

Run this before you sign, and again before go-live. Use your real devices and your real users’ conditions, not the vendor’s demo phone.

Security Tests

• Print, screen replay and mask attempts against the production threshold.
• A virtual camera on a rooted Android phone, and the same app on an emulator.
• A hooking attempt that tries to force a “pass” response.
• A replayed or altered upload sent straight to your backend.

Experience Tests

• At least three low-end Android models popular in your market, plus current iOS.
• Dim indoor light, harsh backlight and outdoor daylight.
• Glasses, headscarves and face masks, with the expected prompts.
• Time to complete, retry count and pass rate for genuine users in each case.

Integration Checks

• Server-side result verification, with no trust in client flags.
• SDK size, minimum OS versions and the vendor’s update schedule.
• Platform coverage: native Android and iOS, web, and wrappers for any cross-platform framework you use.
• Regression tests on every SDK update, since a new model can shift pass rates overnight.
• Data retention: what the vendor stores, where, and for how long.
• A deepfake check on the same capture, since liveness alone does not catch synthetic faces. Our deepfake detection guide explains why.

For reference, the VeriSecure SDK covers several items on this list in one package. It runs emulator, root, Frida, injection and MITM detection on the device, plus blur, darkness and attribute checks during capture. It also detects forced app closures mid-flow, combines active liveness with deepfake detection, and follows the POUR accessibility principles.

Frequently Asked Questions About Liveness Detection SDKs

What is a liveness detection SDK?

A liveness detection SDK is a software library you add to your mobile or web app. It runs the face capture, guides the user, checks frame quality and device integrity, then sends the capture for a liveness decision. An API-only setup, by contrast, only analyses a file it receives.

Should I use a liveness SDK or an API?

Use an SDK when you control a mobile app and need protection against emulators, rooted devices and injected video. An API can work for low-risk web flows, but it cannot see how the capture was produced.

Why do genuine users fail liveness checks?

Most genuine failures come from blur, poor lighting, the face being too far from the camera, or accessories such as sunglasses. Real-time guidance in the SDK fixes most of these before upload.

How do I test a liveness SDK before go-live?

Test on the low-end phones your users own, in poor lighting, and against print, replay, emulator and virtual camera attacks. Then confirm that your backend verifies every result with the vendor instead of trusting the app.

Is liveness detection accessible to users with disabilities?

It can be, if the flow avoids hard time limits, gives spoken or written guidance with visual cues, and offers a fallback path. WCAG 2.2 provides the baseline criteria for that design.

What is the difference between on-device and server-side liveness?

On-device liveness runs the model inside the app, which works offline and returns results fast. Server-side liveness sends the capture to the vendor for analysis, which makes models easier to update and harder for attackers to inspect. Many SDKs combine both, with capture checks on the device and the final decision on the server.

A Liveness Detection SDK Is Only as Strong as Its Integration

Vendors compete on model accuracy, but most production failures happen around the model. A pass flag trusted in the app, a camera prompt with no context, or a test plan run on a flagship phone will each undo a good model. None of those show up in a vendor demo.

So judge a liveness SDK the way you would judge a payment SDK. Ask what it protects on the device, how it fails, how it recovers, and what your backend must still verify. The answers tell you more than any headline accuracy figure.

Integrating liveness into a mobile app this quarter? Request a VeriSecure trial and run the checklist above on your own devices.