Biometric liveness detection is a check that helps confirm a selfie or short video comes from a real person who’s physically present, not a spoof. It runs before face matching or identity verification takes place. Without it, face recognition systems can be tricked by printed photos, replayed videos, 3D masks and increasingly convincing deepfakes.
In this guide, we break down how liveness detection works in practice, from camera capture through to the final verification decision. We cover passive and active liveness, presentation attack detection (PAD), injection attack detection (IAD) and how these controls fit into a modern eKYC onboarding journey. We’ve also included a practical vendor evaluation checklist focused on measurable PAD performance and independent testing evidence.
This guide was last updated in 2026. We draw on public sector research and peer-reviewed sources covering biometrics and PAD. It’s intended as an informational resource, not legal advice, so be sure to assess your regulatory and risk obligations before implementing any identity verification controls.
Quick definitions that separate liveness, PAD, face matching and eKYC
Confusion between liveness detection, face matching and presentation attack detection is common. The definitions below align with the International Organization for Standardization’s ISO/IEC 30107 and are useful when assessing vendors or documenting policy decisions.
Biometric liveness detection is a check performed at capture time to estimate whether a biometric sample comes from a real, physically present person rather than a spoof such as a printed photo, replayed video or mask. It does not prove identity on its own. It answers one question only: is this a real person, present right now?
Presentation attack detection (PAD) refers to the methods used to identify whether a biometric sample is being presented through an artefact rather than a genuine live capture. Under ISO/IEC 30107, a presentation attack is the use of an artefact or human characteristic intended to interfere with system policy, as outlined in the National Institute of Standards and Technology’s (NIST) FATE PAD evaluation framework.
Face matching compares a captured face image against a trusted reference, such as an ID document portrait or previously enrolled image. It answers a different question: “Is this the same person as the reference image?” Face matching and liveness are separate controls and both matter.
eKYC (electronic Know Your Customer) refers to digital identity verification processes used to remotely verify customers. This typically combines document verification, biometrics and risk decisioning within a single onboarding flow.
Put simply, liveness answers “Are you real and present right now?” while face matching answers “Are you the same person as the reference image?” Effective eKYC journeys usually require both.
The risk is real. This peer-reviewed PAD survey found that some face recognition systems could be spoofed with success rates of around 70% depending on the attack type. That’s why modern biometric verification programmes need strong PAD controls built in from the start.
These distinctions matter when evaluating vendors and designing onboarding flows. Some providers use ‘liveness’ to describe basic passive checks, while others include full PAD capabilities with active challenges and layered fraud controls. Understanding what each control actually does makes it easier to identify gaps in your eKYC process.
Identity verification controls and what they answer
| Control | Question answered | Typical inputs | Output |
|---|---|---|---|
| Liveness detection | Is this a real, present person? | Selfie or short video | Liveness score / pass-fail |
| Face matching | Is this the same person as the reference? | Captured face + ID | Match score |
| Document authenticity | Is this a genuine ID document? | Document images (front/back) | Authenticity verdict |
| Anti-Money Laundering (AML) screening | Does this person appear on sanctions or watchlists? | Name, date of birth, nationality | Screening result |
How does biometric liveness detection work in identity verification software?
Biometric liveness detection works through a capture-to-decision pipeline designed to reduce the risk of accepting spoofed or low-quality biometric samples.
At its core, liveness detection is a set of techniques used to assess whether a biometric sample was captured from a real, living person at the moment of capture rather than from a reproduction such as a photo, replayed video or mask. In identity verification software, liveness checks usually happen before face matching, to filter out spoofed inputs before you compare them to a real person’s reference image.
Here’s how a typical liveness detection pipeline works:
Capture session starts
The SDK or web capture module opens the device camera. Anti-tamper protections such as device permission checks and session binding are initiated at this stage.
Quality checks run
The system checks lighting, blur, pose and occlusions. Poor image quality increases false rejections and weakens PAD reliability, so these checks help catch problems early.
Passive analysis (where applicable)
Machine learning (ML) models analyse texture patterns, motion consistency, depth signals and screen artefacts such as moiré patterns (telltale visual interference caused by screens interacting with camera sensors) or reflections. This happens silently in the background with no extra effort from the user.
Active challenge (where applicable)
The system may issue random prompts such as blinking, turning your head or following a dot on screen. Randomisation makes pre-recorded attacks harder to use.
PAD and liveness scoring
The liveness engine produces a score or risk label. Thresholds vary depending on the risk level of the journey. A low-risk onboarding flow may accept a lower confidence threshold than a high-value transaction.
Face detection and normalisation
The captured face is cropped and aligned to prepare it for comparison.
Face matching
The normalised image is compared against a trusted reference, such as an ID document portrait or previously enrolled image, using facial matching biometrics to generate a match score.
Decisioning
The platform combines liveness results, face match scores, document authenticity checks, device signals and AML screening outputs. Based on the combined risk picture, the case is approved, rejected, retried or escalated for review. This is where multi-layered verification becomes important.
Audit trail
Decision metadata including timestamp.
(Probability scores, device identifiers and outcomes are stored for governance and dispute handling. Depending on your retention policy, the biometric media itself may or may not be stored).
Quality checks are not just about improving the user experience. They also directly affect PAD accuracy. A blurry or poorly lit capture gives liveness algorithms less reliable signal to work with. The order of the pipeline matters too. Running liveness before face matching helps prevent spoofed inputs from ever reaching the identity comparison stage.
Liveness detection is not a standalone security control. It works as part of a broader identity verification flow alongside biometric authentication, document verification and risk analysis. Skip one layer and the entire chain becomes weaker.
Workflow gates, failures, and next steps
| Step | What is checked | Common failure reasons | What the app should do next |
|---|---|---|---|
| Quality checks | Pose, lighting, blur, occlusions | Low light, face partially hidden, extreme angle | Prompt user with guidance (remove sunglasses, improve lighting); allow retry |
| Liveness / PAD | Live-presence signals, artefact indicators | Screen reflection detected, texture anomaly, challenge not completed | Allow limited retries; escalate to manual review only after repeated failures |
| Face matching | Similarity to reference image | Poor image quality, ageing difference, different person | Retry if quality-related; route to manual review if score is borderline |
| Decisioning | Combined risk signals | Conflicting signals, edge-case scores | Apply risk rules; approve, reject, or flag for human review |
Passive vs active vs hybrid liveness detection (and when to use each)
- Passive liveness works best when low friction is the priority and the capture environment is reasonably controlled
- Active liveness provides proof of live presence for higher-risk scenarios but can increase drop-off and create accessibility challenges
- Hybrid liveness combines both approaches, typically using passive analysis with a lightweight prompt for moderate-risk use cases
Active liveness uses challenge-response prompts to generate stronger evidence that a real person is present. Passive liveness works silently in the background, analysing texture, motion, depth cues and artefacts to produce a liveness score with minimal friction. The right approach depends on your fraud risk, user experience requirements and where the check sits in your eKYC flow.
Passive liveness detection
Passive liveness detection analyses a selfie or short video without asking the user to perform any actions. The goal is to reduce friction while still detecting spoof attempts. Passive liveness detection has rapidly become the industry standard owing to its superior overall security against advanced threats.
The system looks for indicators such as moiré patterns, screen glare, texture inconsistencies, motion signals and depth cues. All of this happens silently using machine learning (ML) models trained on large datasets of genuine and spoofed captures. According to Market Intelo data, AI-based technologies accounted for more than 70% of revenue in the passive liveness detection market in 2024.
Active liveness detection
Active liveness detection uses prompts to confirm live presence. The user may be asked to blink, turn their head or follow a moving object on screen. Randomised prompts can help prevent attackers from using pre-recorded videos or scripted responses but because the prompts used are predictable, advanced deepfake generators can be scripted to mimic these responses in real-time.
Active liveness offers an alternative method of protection for perceived higher-risk actions such as step-up biometric authentication or high-value payouts, but the trade-off is increased session time and potentially lower completion rates. Accessibility also matters here, as prompts requiring specific movements may not work for everyone.
Hybrid liveness
Hybrid liveness combines passive analysis with lightweight active prompts when needed. Passive checks run first, with additional prompts triggered only if the confidence score is unclear or the risk level is higher.
This approach works well for onboarding journeys with moderate fraud risk where passive checks alone may not provide enough assurance, but full active flows would add unnecessary friction.
The key is choosing the least intrusive liveness method that still matches the risk of the event being protected. Onboarding a low-risk customer is very different from approving a high-value transaction or resetting account credentials.
Here’s how the three approaches are commonly used in eKYC flows:
- Onboarding (standard risk): Passive liveness is often enough and helps keep conversion rates high.
- Re-verification or account recovery: Passive or hybrid, depending on account sensitivity.
- Step-up before a high-value action: Active or hybrid liveness adds a stronger layer of assurance before approving payments or credential changes.
Real-world capture conditions affect all three methods. Low lighting, older Android devices and weak mobile connectivity can all increase false rejection rates. Any liveness testing implementation should be validated against the actual mix of devices and environments your customers use.
Capture conditions to plan for include:
- Variable indoor lighting that changes throughout the day and across seasons
- Older mobile devices still widely used across some demographics
- Mobile connectivity gaps in rural areas and underground transport networks
- Accessibility requirements for users with motor or visual impairments
Passive vs active vs hybrid liveness comparison
| Method | User effort | Typical capture | Spoof resistance | Common failure modes | Best-fit eKYC moments |
|---|---|---|---|---|---|
| Passive | None (selfie only) | Single selfie or short video | Good against prints and basic replays; highly effective at stopping standard deepfakes and spoofing; weaker against high-quality 3D masks | Low light, blurry capture, older cameras | Standard onboarding, re-verification |
| Active | Moderate (follow prompts) | Video with challenge-response | Randomisation can help block pre-recorded attacks; vulnerability to deepfakes as required actions can be calculated by advanced AI | User drop-off, accessibility issues, slow connections | High-value step-up, account recovery |
| Hybrid | Low (occasional prompt) | Selfie plus optional prompt | Balanced; adapts evidence level to risk | Prompt timing can confuse users if poorly designed | Moderate-risk onboarding, conditional step-up |
Presentation attack detection (PAD) and what liveness can and cannot stop
Presentation attack detection (PAD) refers to the methods used to identify whether a biometric sample is coming from a real live capture or from an artefact such as a printed photo, replayed video or mask. A peer-reviewed survey on face presentation attack detection found spoofing success rates of around 70% in some scenarios, highlighting why PAD matters to the biometric verification process.
Classic presentation attacks
- Printed photos
A printed image of someone’s face held up to the camera. Common indicators include flat depth, paper texture and a lack of natural micro-movements. - Replay attacks on a screen
A photo or video displayed on a phone, tablet or monitor and presented to the camera. Systems often look for moiré patterns, screen glare and unnatural edge boundaries. - Paper or 2D masks
Printed masks with cut-outs around the eyes or mouth. Rigid movement and inconsistent lighting are common signals. - 3D masks
Silicone or resin masks designed to mimic real facial contours. These are harder to detect and may require depth sensing or active challenges to identify reliably.
Synthetic media attacks
Deepfake video is an increasingly important threat category. These attacks use generative AI to create highly realistic facial imagery, making them more difficult to detect using single-signal analysis alone.
This is where multi-signal PAD becomes important. Combining texture analysis, motion behaviour, temporal signals and depth cues is far more effective against deepfakes than relying on a single detection method.
Liveness is best thought of as a PAD capability. It helps filter spoof attempts at the capture stage before a biometric sample is trusted for authentication or identity proofing.
What PAD systems analyse
Liveness detection models look for a range of visual and behavioural signals, including:
- Moiré patterns caused by screen interference
- Screen glare and reflections
- Unnatural edge transitions
- Inconsistent lighting or shadows
- Flat versus three-dimensional depth signals
- Irregular micro-movements
NIST’s FATE evaluation independently tested 82 passive face PAD algorithms in NISTIR 8491 (September 2023), helping benchmark how effectively different systems interpret these signals.
The limits of liveness detection
No single PAD method can stop every attack type.
High-quality 3D masks may bypass texture-only analysis. Advanced deepfakes can sometimes pass passive checks if the detection model has not been trained on similar attack samples. That’s why layered identity verification can matter.
Liveness works best when combined with document authenticity checks, face matching, device intelligence and (depending on the sophistication of the technology used) manual review. Together, these controls create a much stronger defence than any single layer on its own.
Attack types, indicators, and mitigations
| Attack type | Typical artefact | Common indicators | Best-suited liveness method | Recommended additional controls |
|---|---|---|---|---|
| Printed photo | Paper print of a face | Flat depth, paper texture, no micro-movement | Passive | Document checks, device signals |
| Replay video | Video played on a screen | Moiré patterns, screen glare, edge artefacts | Passive | Capture integrity, session binding |
| 3D mask | Silicone or resin mask | Unnatural texture at edges, depth inconsistencies | Passive*, Active or Hybrid | Depth sensing, manual review* for high-risk cases |
| Deepfake video | AI-generated face imagery | Temporal flicker, boundary artefacts, inconsistent lighting | Passive* or Hybrid with multi-signal analysis | Injection defences, fraud analytics, manual review* |
Presentation attacks vs injection attacks and why camera trust matters in 2026
Not every biometric attack happens in front of the camera.
In a traditional presentation attack, someone presents a printed photo, replayed video or deepfake to the device camera. In an injection attack, the attacker bypasses the camera entirely, intercepting the capture media data stream and injecting pre-recorded or AI-generated content directly into the verification pipeline.
The camera never sees the spoof because the camera was never involved.
That’s the key difference between presentation attacks and injection attacks. Presentation attacks rely on artefacts shown to the camera. Injection attacks target the capture process itself.
An injection attack attempts to feed manipulated media directly into the biometric system while bypassing genuine camera or microphone input. This changes what matters in a liveness solution. High model accuracy alone is not enough. Strong capture integrity controls are needed to prove the media actually came from the device sensor in real time.
Common defences against injection attacks
- SDK integrity checks that detect tampering with the capture module
- Rooted or jailbroken device detection to identify compromised environments
- Secure capture pipelines with encrypted media transport
- Replay protection using nonce-based session tokens (one-time random number generation)
- Server-side session correlation that binds liveness results to specific capture events
If the capture channel cannot be trusted, neither can the liveness result. Modern identity verification programmes increasingly combine liveness with ‘camera trust’ controls to reduce injection risk. ID-Pal’s injection attack detection capability is designed to address this threat category directly.
The financial impact is significant. The Internet Crime Complaint Center 2024 Annual Report recorded fraud losses exceeding $10.3 billion in 2023. Identity verification systems without injection attack protections leave a serious gap in fraud prevention strategies.
Six questions to ask a liveness vendor about injection attack protection
- How is non-camera input detected during capture?
- How are liveness results bound to the device and session?
- What protections exist against rooted or jailbroken devices?
- Is the capture pipeline encrypted end-to-end?
- How is replay protection implemented, for example through nonce, timestamp or session token controls?
- Can independent test evidence for injection attack scenarios be shared?
Presentation attack defences vs injection attack defences
| Presentation attack defences | Injection attack defences |
|---|---|
| Passive liveness analysis (texture, depth, motion) | API/SDK integrity verification |
| Active challenge-response prompts | Rooted/jailbroken device detection |
| Multi-signal ML models | Secure, encrypted capture pipeline |
| Depth sensing (where available) | Nonce-based replay protection |
| Manual review for borderline cases | Server-side session and device binding |
Where liveness fits into an eKYC onboarding flow
Liveness is one layer within a broader identity proofing programme. On its own, it only confirms that a real person is present during capture. It does not confirm who that person is or whether their identity document is genuine.
In eKYC, liveness is the control that helps establish trust in the selfie. It’s designed to confirm that the face being matched to the ID belongs to a real person physically present at that moment.
Document-first vs selfie-first flows
Most eKYC journeys follow a document-first approach. The user captures their identity document first, the system checks whether the document is genuine and extracts the portrait, then the user takes a selfie for liveness and face matching.
A selfie-first approach reverses this order by capturing the biometric sample before document verification.
Document-first flows are more common in financial services because they validate the document before processing biometric comparisons, helping reduce unnecessary processing and fraud risk earlier in the journey.
Linking identity across verification controls
A standard eKYC flow typically combines three connected controls:
Document authenticity
The system runs checks on the ID document to confirm it is genuine and unaltered.
Portrait extraction
The reference portrait is extracted from the verified identity document.
Liveness capture and face matching
The user takes a selfie. Liveness detection confirms live presence, while the face matching engine compares the selfie against the document portrait.
The Financial Inclusion Global Initiative and International Telecommunication Union’s security report explains, modern eKYC systems increasingly rely on biometrics and liveness detection to support secure remote identity verification at scale.
The decisioning layer
The final onboarding decision combines multiple signals including:
- Liveness results
- Face match scores
- Document authenticity outcomes
- Device intelligence
- AML screening outputs
Together, these inputs create a composite risk score that routes the case to one of three outcomes: approve, retry or manual review.
Combining biometric verification, document checks and AML controls creates a stronger eKYC framework capable of addressing multiple fraud and compliance risks at once. For more information on AML controls, see ID-Pal’s AML compliance guide.
Retry logic matters
Most onboarding flows should allow two or three retries with clear guidance such as improving lighting, removing sunglasses or holding the device steady.
After repeated failures, cases should move to manual review rather than allowing unlimited attempts. Unlimited retries give attackers more opportunities to refine spoof attempts and bypass controls.
Privacy and transparency
People should be clearly informed when biometric data is being captured and why.
Transparency around what data is collected, how it is processed and how long it is retained helps build trust and supports compliance with data protection requirements. This is general guidance rather than legal advice, so you should always seek your own regulatory counsel where needed.
eKYC steps, risks, and controls
| eKYC Step | Primary risk | Control(s) |
|---|---|---|
| Document submission | Fake or altered ID document | Document authenticity checks, fraud analytics |
| Selfie capture | Spoofed biometric (photo, video, mask, deepfake) | Biometric verification via liveness detection (passive/active/hybrid) |
| Face matching | Different person than the document holder | Biometric comparison to document portrait |
| Risk decisioning | Synthetic identity, account mule | Composite scoring, AML screening, device signals |
How to evaluate liveness detection vendors
Don’t buy based on a single accuracy figure alone. At ID-Pal, we’re proud of our 99% accuracy rate on verification results, but it’s important you understand which attacks were tested, which devices were used and under what capture conditions the testing took place.
Liveness should be evaluated using independent PAD testing evidence, not just headline accuracy claims. Ask vendors for results expressed through PAD-specific error rates such as the APCER and BPCER (see below), along with testing that reflects the threat, user device and environment.
Independent evaluation matters
NIST’s PAD evaluations measure how effectively face presentation attack detection algorithms distinguish genuine users from spoof attacks under controlled test conditions.
The NIST FATE PAD evaluation, published in NISTIR 8491 in September 2023, tested 82 passive face PAD algorithms. Independent testing like this provides a more reliable benchmark for comparing vendor performance claims against standardised evidence.
Metrics worth requesting from vendors
PAD-specific error rates provide far more insight than a single ‘accuracy’ percentage:
- Attack Presentation Classification Error Rate (APCER):
The percentage of attack attempts incorrectly classified as genuine. Lower is better. - Bona Fide Presentation Classification Error Rate (BPCER):
The percentage of genuine users incorrectly rejected. Lower is better.
Alongside PAD metrics, it’s also important to review operational KPIs including:
- Completion rate (how many users successfully finish the liveness check)
- Retry rate (how often users need another attempt)
- Manual review rate (how many sessions are escalated for human review)
Match the testing to the threat model
Any evaluation should clearly define which attacks are being tested, including:
- Printed photo attacks
- Screen replay attacks
- 2D masks
- 3D masks
- Deepfake video
- Injection attacks
A vendor may perform well against simple print attacks but still lack protection against injection attacks or sophisticated synthetic media.
Device coverage matters
Liveness performance varies significantly across devices and environments.
Older Android devices with lower-resolution cameras often produce weaker PAD signals. Low lighting and poor bandwidth can also increase friction and false rejections.
Testing should reflect the actual devices and conditions used across your customer base. Accessibility should also be considered, particularly where active liveness prompts may create challenges for some users.
Security controls beyond liveness
Liveness is only one part of a broader fraud prevention strategy. Look for additional controls including:
- SDK hardening (techniques to protect the software) and capture integrity protections
- Injection attack detection
- Fraud analytics integration
- Retry rate limiting
- Device reputation and risk signals
These controls work alongside liveness to strengthen the overall onboarding process. See ID-Pal’s security and compliance information for how these protections are implemented in practice.
Governance and configurability
A reliable identity verification solution vendor should be able to explain, with measurable evidence, how their system performs against the attacks most relevant to your business.
Ask whether the platform supports:
- Configurable risk thresholds
- Decision audit trails
- Monitoring for model drift
- Updates for emerging attack patterns
ISO/IEC 30107 provides the standards framework commonly used to evaluate presentation attack detection systems.
Implementation support matters too
Deployment support can be just as important as detection performance. Ask vendors about:
- Phased rollout support
- A/B testing capability
- Manual review tooling
- Incident response processes
- Access to test environments
Without this support, even strong technology can create delays, integration issues and operational friction during rollout.
Vendor evaluation scorecard
| Evaluation area | Questions to ask | Evidence to request | Pass criteria |
|---|---|---|---|
| PAD evidence | Which attacks have been tested? Against which ISO/IEC 30107 attack types? | NIST FATE results, third-party test reports | APCER/BPCER within your risk tolerance per attack type |
| Injection defences | How do you detect non-camera input? | SDK hardening documentation, penetration test results | Demonstrated detection of common injection vectors |
| User experience | What is the average completion rate and retry rate? | Anonymised completion metrics across client base | Completion rate above your target threshold |
| Device coverage | How does performance vary across device types? | Device-specific test results (older Androids, low light) | Acceptable performance on devices your users carry |
| Configurability | Can thresholds be adjusted by use case or risk tier? | Platform configuration documentation | Separate thresholds for onboarding vs step-up |
| Audit and compliance | How are decisions logged and how long is data retained? | Audit trail examples, data retention policy | Meets your regulatory and governance requirements |
| Integration | What SDKs, APIs, and environments are supported? | Technical documentation, sandbox environment | Compatible with your tech stack and deployment model |
2026 to 2028 trends in liveness and eKYC
Passive and AI-driven liveness detection will continue to dominate over the next few years. According to Market Intelo, the passive liveness detection market was valued at $1.2 billion in 2024 and is projected to reach $7.8 billion by 2033, growing at a CAGR of 22.5%.
For most eKYC programmes, this points towards passive-first architectures becoming the standard, with active prompts used mainly for higher-risk step-up checks.
On-device processing will grow
More liveness processing is expected to move onto the user’s device to improve privacy and reduce response times.
Running models locally means less biometric data needs to leave the device, while verification decisions can happen faster with lower latency. The challenge is device fragmentation. Older smartphones may not have the processing power needed for reliable on-device inference, and maintaining model updates across large device ranges adds operational complexity.
Security and compliance teams planning beyond 2026 should evaluate whether vendors support both on-device and server-side processing models.
Multi-signal identity proofing is becoming the norm
Single-layer verification is no longer enough. Modern identity verification increasingly combines:
- Liveness detection
- Document authenticity checks
- Face matching
- Fraud prevention analytics
- Step-up authentication flows
Layered identity verification reduces the risk of a single failure leading to successful fraud. If one control is bypassed, additional signals still help detect suspicious behaviour.
The real challenge is no longer ‘deepfakes versus liveness’. It’s the speed of attack innovation versus the strength of layered controls and measurable evaluation.
Evaluation and governance expectations will increase
Expect stronger focus on independent testing, measurable performance benchmarks and governance frameworks across eKYC programmes.
As biometric regulation and industry standards continue to evolve, organisations investing in structured evaluation and auditability now will be better positioned for regulatory scrutiny in 2027 and beyond.
Fraud pressure will continue
Identity fraud remains a major financial threat. Reported fraud losses exceeded $10.3 billion in 2023 alone. The future of liveness detection will depend on:
- Continuous model training and updates
- Broader attack coverage
- Stronger injection attack protections
- Tighter integration with passive liveness detection and eKYC decisioning systems
As attack methods evolve, liveness systems will need to evolve with them.
Trends, impact, and actions for 2026
| Trend | Impact | Action this quarter |
|---|---|---|
| Passive-first liveness architectures | Lower user friction, higher completion rates | Evaluate your current liveness approach against passive alternatives |
| On-device processing | Better privacy and latency; device fragmentation challenges | Audit your user device mix and test on-device performance |
| Multi-signal identity proofing | Stronger layered defence; reduces single-point-of-failure risk | Map gaps between your current controls and a full layered model |
| Independent evaluation maturity | More rigorous vendor comparison; clearer audit evidence | Request PAD error rates and third-party test results from vendors |
| Persistent fraud pressure | Continuous attack evolution; higher stakes for weak controls | Build model update and incident response plans into vendor contracts |
How ID-Pal builds liveness into a multi-layered eKYC programme
If you’re implementing or upgrading an identity verification programme in 2026, a sensible starting point looks like this:
- Combine liveness testing, document authenticity checks and face matching within a single workflow
- Configure liveness thresholds based on risk level, for example standard onboarding versus high-risk step-up actions
- Include capture integrity protections against injection attacks
- Build retry and review paths that support genuine users without allowing unlimited attempts
- Involve security and compliance teams from the earliest planning stages
An identity verification programme is more than a single technology layer. It combines policies, operational processes and verification controls that determine when to approve, challenge or manually review an identity claim.
This is the approach ID-Pal takes through a connected workflow that combines facial matching biometrics, liveness testing, document verification and risk-based decisioning in one platform.
ID-Pal supports configurable liveness approaches and thresholds depending on the verification moment. Standard onboarding journeys can use passive liveness with lower thresholds to reduce friction, while higher-risk actions such as large transactions can apply stricter confidence levels or active prompts.
Capture integrity now matters as much as liveness
Modern attacks increasingly target the capture process itself rather than the camera image alone.
ID-Pal’s injection attack detection capability is designed to address attacks that bypass the camera entirely. The system ensures it’s not being bypassed at the software layer, offering best-in-class levels of security to effectively protect against hacking, tampering, and spoofing. This creates an additional defence layer beyond liveness analysis alone.
The most effective approach is not a standalone ‘selfie check’. It’s a multi-layered workflow that links a genuine document to a live person and applies risk-based decisioning across the full onboarding process.
Security and compliance should be involved from day one
A KPMG study found that 74% of financial services organisations involve cybersecurity teams during the earliest stages of technology investment planning.
The same principle applies to identity verification. Security and compliance teams should be part of the design process from the start, not introduced after implementation.
ID-Pal also provides guidance on KYC compliance to help organisations build end-to-end eKYC workflows aligned with UK regulatory expectations.
Implementation checklist for liveness in eKYC
| Control | Owner | Done-when criteria |
|---|---|---|
| Liveness method selected (passive/active/hybrid) | Product + Risk | Method matches threat model and risk tier |
| PAD thresholds configured by use case | Product + Engineering | Separate thresholds live for onboarding vs step-up |
| Injection attack defences active | Engineering + Security | SDK hardening and session binding verified in test |
| Retry and review paths tested | Product + Operations | End-to-end flow tested with real devices and edge cases |
| Audit trail and data retention confirmed | Risk + Legal | Decision metadata logged; retention policy documented |
| Device and accessibility coverage validated | Engineering + QA | Tested across target device mix; accessibility gaps documented |
Frequently asked questions
What is biometric liveness detection?
Biometric liveness detection is a set of techniques used to confirm whether a biometric sample comes from a real, physically present person rather than a spoof such as a photo, replayed video or mask. It is commonly combined with face matching and document verification within eKYC flows to reduce the risk of biometric spoofing.
How does liveness detection work in identity verification software?
Most identity verification platforms begin with capture quality checks before running passive and/or active liveness analysis to produce a liveness score.
That score acts as a gate before face matching and final decisioning take place. If image quality or liveness confidence is too low, the system may request another attempt. Influenced by the sophistication and success rate of the technology used, repeated failures are typically escalated to manual. Modern platforms also need capture integrity protections to defend against injection attacks that bypass the camera entirely.
What is the difference between liveness detection and face matching?
Liveness detection confirms that a real person is physically present during capture. Face matching checks whether the captured face matches a trusted reference image.
The two controls solve different problems and work together.
Liveness helps prevent spoofed inputs entering the system, while face matching confirms the claimed identity against a known reference such as an ID document portrait. Effective biometric authentication flows generally require both.
What is a presentation attack in biometrics?
A presentation attack happens when an attacker presents an artefact or manipulated human characteristic to a biometric sensor to interfere with system policy, as defined in ISO/IEC 30107.
Examples include:
- Printed photos
- Replayed videos shown on a screen
- 3D masks
- Deepfake video displayed to the camera
NIST’s FATE evaluation framework provides standard definitions and testing methodologies for these attack categories.
Can passive liveness detect deepfakes?
Passive liveness can reduce the success of many replay and deepfake attacks by identifying visual artefacts, inconsistencies and abnormal motion patterns.
However, it should not be treated as a standalone defence. Stronger protection comes from combining passive liveness with capture integrity controls, injection attack detection and step-up active challenges for higher-risk or borderline cases subject to the sophistication of the technology used.
What metrics should be used to evaluate liveness detection?
PAD-focused error rates such as APCER and BPCER provide a more meaningful measure than a single ‘accuracy’ percentage.
Operational KPIs also matter, including:
- Completion rate
- Retry rate
- Manual review rate
Independent testing evidence is important too. A headline accuracy claim reveals very little unless the underlying attacks, devices and test conditions are clearly defined. NIST PAD evaluations provide a standardised benchmark for comparing algorithm performance.
What is the difference between presentation attacks and injection attacks?
Presentation attacks attempt to fool the camera using a physical or digital artefact displayed during capture. Injection attacks bypass the camera completely by feeding manipulated media directly into the capture pipeline.
The controls required for each attack type are different. Presentation attack detection relies on ML models analysing spoof signals within the capture itself, while injection attack protection depends on SDK integrity, session binding and trusted capture controls.
This is where ‘camera trust’ becomes important. Before trusting a liveness result, the system must confirm the media genuinely came from the real device sensor.
Where should liveness sit in an eKYC flow?
Liveness detection typically runs after capture quality checks and before face matching.
This allows spoofed inputs to be filtered before the system compares the selfie against an ID portrait or enrolled reference image.
A typical eKYC sequence looks like this:
- Document capture and authenticity checks
- Portrait extraction from the document
- Selfie capture with liveness analysis
- Face matching against the document portrait
- Composite risk scoring
- Approve, retry or manual review decision
Putting liveness detection into practice
Biometric liveness detection works best as part of a multi-layered identity verification flow that moves from camera capture through to risk-based decisioning.
On its own, no single check can stop every attack type. The strength comes from combining liveness with document authenticity checks, facial matching, capture integrity protections and risk-based governance.
If you’re reviewing or upgrading an eKYC programme, see how ID-Pal combines liveness testing, document verification, facial matching and fraud prevention controls within a single workflow.
You can also speak with the ID-Pal team about configuring a risk-based approach for UK onboarding requirements or request a free audit to test current risk profiles, operational efficiency, regulatory compliance and threat readiness.