How Liveness Detection Is Bypassed: Presentation Attacks, Replay, and Virtual Cameras

Presentation Attacks: What PAD Is and What Is Used to Substitute a Live Face in Front of the Camera

Liveness detection answers a single question: is a live person present in front of the camera. A presentation attack arises in a situation where someone tries to deceive the system by showing the camera a substitute for a person’s face: a photograph, a video on a screen, or even a three-dimensional mask. In the ISO/IEC 30107 standard, such a substitution object is called a Presentation Attack Instrument (PAI). The methods that detect such deception attempts are grouped under the term Presentation Attack Detection (PAD).

PAD is assessed by two metrics. APCER (Attack Presentation Classification Error Rate) shows what share of attacks the system let through as a genuine face. BPCER (Bona Fide Presentation Classification Error Rate) shows what share of real users it erroneously rejected. The metrics are inversely related: the stricter the filter, the fewer attacks are missed, but the more false rejections there are. The engineer’s task is to find a threshold at which both indicators remain acceptable for the specific business scenario.

The ISO/IEC 30107-3 standard (second edition, January 2023) defines the methodology for testing PAD and the classification of attack complexity levels. In certification at accredited laboratories, the artifacts are grouped by level: Level 1 covers simple forgeries costing up to 30 dollars (printouts, on-screen playback), Level 2 covers more realistic PAIs costing up to 300 dollars (high-quality 3D masks, composite dummies). In 2025, a number of laboratories began Level 3 evaluation, which involves laboratory-grade attacks using custom-made materials and professional tools.

Below we break down three classes of presentation attacks on facial liveness detection, the mechanisms for detecting them, and approaches to strengthening PAD without harming the user experience.

Using Photographs to Pass Liveness: Why It Sometimes Works and How It Is Detected

A photo attack is the most accessible type of presentation attack. The attacker holds up a printed photo or a photo on a smartphone screen to the camera. According to industry reports for 2024, the overwhelming majority of recorded presentation attacks involve 2D artifacts — paper photos and on-screen playback.

A photograph can pass the check in several situations. If the system relies only on face matching without a liveness module, a static image of sufficient quality will yield a positive matching result. If the liveness module is configured with low sensitivity or trained on a limited dataset, the probability of a miss increases. An additional factor is the quality of the device’s camera: at low resolution, it is harder for the algorithm to extract the features that distinguish a flat image from a three-dimensional face.

Detection is built on several groups of features.

Texture analysis reveals artifacts characteristic of printing: paper graininess, a limited color range, a raster grid uncharacteristic of living skin. Neural-network models trained on datasets with attack examples (CASIA FASD, Replay-Attack, MSU MFSD, and their successors) isolate micro-texture features even at high image resolution.

Depth analysis determines that the object in front of the camera is flat. If the device is equipped with structured lighting or a stereo camera, the absence of relief is detected directly. When working with an ordinary RGB camera, depth is estimated indirectly — through parallax during micro-movements, lighting gradients, and perspective distortions characteristic of three-dimensional objects.

Dynamics analysis complements texture and spatial analysis. A live face continuously makes micro-movements: blinking, twitching of the facial muscles, imperceptible changes in head tilt. In a photograph these signals are absent or look unnatural. Passive PAD systems record the absence of micro-movements across several frames; active ones request a specific action (a turn, a smile) that cannot be reproduced from a static image.

The fundamental limitation of a photo attack is the artifact’s inability to respond to random stimuli. Even a cut-out photo with slits for the eyes gives itself away through the mismatch of the iris geometry, the boundaries of the face and background, and the unnatural rigidity of the contour.

When a Screen Is Shown to the Camera: How Liveness Systems Detect the Substitution

A second-screen attack differs from a photo attack in that a display is in front of the camera, playing back a video recording or a live video stream of the victim’s face. The video contains natural movements — blinking, head turns, facial expressions — and is capable of passing the simplest dynamics checks.

The key physical sign of a screen-based substitution is the moiré pattern. It arises when the display’s pixel grid is overlaid on the camera’s pixel matrix: two regular rasters with different pitches produce characteristic wave-like artifacts. Studies (Patel, Han, Jain, 2015; Garcia, de Queiroz, 2015) showed that analysis of moiré patterns in the frequency domain is one of the most reliable ways to detect on-screen playback. Modern PAD models detect moiré in different color channels and under different shooting conditions.

Besides moiré, a screen attack leaves additional traces. The display’s backlight creates a uniform glow that is not characteristic of natural facial lighting. The edges of the screen form a straight-line contour that stands out against the surroundings. When the screen’s refresh rate does not match the camera’s, flicker artifacts and rolling bands appear (rolling shutter distortion). The display’s color gamut differs from the natural shade of skin: LCD screens and OLED matrices have characteristic spectral profiles that the system can learn to distinguish from the spectrum of a live face.

Modern PAD algorithms combine these features into a single model. Neural networks trained on multi-frame sequences simultaneously analyze texture anomalies (moiré, pixel artifacts), spatial features (flatness, uniformity of backlighting), and temporal characteristics (flicker, unnatural synchrony of movements). Such a combination makes bypassing difficult even when using high-resolution screens.

Screens with a refresh rate of 120 Hz and above reduce the prominence of moiré and flicker but do not eliminate them completely: the difference in the pixel pitches of the camera and the display remains. The screen stays a flat object, which becomes apparent when a head turn to profile is requested — the relief of the nose and chin on the display is not reproduced correctly.

3D Masks as a Presentation Attack Instrument: Signs of Detection

A three-dimensional mask is the most sophisticated presentation attack instrument. Unlike a photograph and a screen, a high-quality mask reproduces the volume of the face, and when made of silicone or latex, partially imitates the texture and shade of skin. 3D masks are the primary subject of Level 2 testing under ISO/IEC 30107-3, and custom-made laboratory-grade masks are the subject of Level 3.

The cost and availability of masks vary. Simple masks made of resin or PLA plastic are produced by 3D printing based on facial photographs. Professional silicone masks that reproduce the shape of a specific person’s face cost hundreds and thousands of dollars and require taking a cast or high-precision 3D scanning. Such masks are capable of deceiving systems that rely only on geometric correspondence and basic depth analysis.

Even a high-quality mask does not reproduce the biological properties of a living face. This creates several lines of detection.

Optical properties of the surface. Silicone, latex, resin, and plastic reflect light differently than living skin. Human skin partially transmits light (subsurface scattering), forming a soft transition at the edges of shadows, whereas a mask produces sharper or excessively uniform shadows. Multispectral analysis in the near-IR range (850–940 nm) enhances the contrast between natural skin and synthetic material, since their spectral characteristics diverge significantly.

Absence of physiological micro-movements. A mask does not pulse, does not sweat, does not change color when blood rushes in. Remote photoplethysmography (rPPG) records the pulse wave on a living person’s face through micro-changes in skin color between frames. On a mask this signal is absent or has an anomalous character. The rPPG signal is subject to noise from ambient lighting and is not the sole criterion — it works as an additional factor in a comprehensive assessment.

The mask boundary and geometry anomalies. Most masks do not cover the face entirely: visible transitions remain around the eyes and at the junction with the skin of the forehead or neck. Even full-face masks have slits for the eyes, through which the wearer’s irises are visible, not matching the irises of the mask’s «face». Algorithms track the consistency of texture in the boundary areas, the correspondence of pupillary reaction, and the connectivity of the facial contour.

Mechanical rigidity. A silicone mask conveys the wearer’s facial expressions only partially: the amplitude and speed of movement of the lips, eyebrows, and cheeks are lower than those of a living face. Algorithms that analyze the kinematics of facial landmarks from the video stream record a decrease in the diversity and dynamic range of facial expressions.

Mask detection is effective when several approaches are combined. None of them individually provides absolute reliability — high-quality silicone can deceive texture analysis, and controlled lighting can lower the reliability of rPPG. Multimodal PAD, combining texture, spectral, geometric, and physiological features, demonstrates significantly higher resilience.

How to Strengthen PAD While Keeping a Low Level of False Rejections

Strengthening PAD comes with a side effect: the stricter the detection, the more real users receive a false rejection (a rise in BPCER). For systems with mass traffic — bank onboarding, marketplaces, government services — every percent of false rejections translates into lost conversion and increased load on manual verification. The task is to increase resilience to attacks while keeping BPCER within acceptable limits.

A cascaded verification architecture. Instead of a single «heavy» classifier, a chain of models with increasing depth of analysis is applied. At the first stage, a fast filter weeds out obvious attacks (clear screen edges, coarse flatness, complete absence of micro-movements). At the second, a detailed model analyzes texture and dynamics. Only borderline cases, where multimodal assessment or a request for an additional action is required, are passed to the third level. This approach reduces the computational load and cuts down the number of situations in which a legitimate user is subjected to excessive verification.

Adaptive thresholds based on risk signals. The decision to pass is not necessarily made at a single fixed threshold. Contextual parameters — device type, camera characteristics, geolocation, session history, behavioral metrics — make it possible to dynamically adjust the sensitivity. If a session is assessed as low-risk (a familiar device, typical geolocation, standard camera metadata), the threshold can be less strict. With anomalous signals — an unknown device, an uncharacteristic region, signs of an emulator — the threshold is tightened. Such a mechanism reduces the average share of false rejections while maintaining protection in zones of elevated risk.

Continuous updating of models on current attack data. The landscape of presentation attacks changes: new mask materials appear, screen resolutions grow, deepfake generators improve. PAD trained on year-old data may let through fresh types of artifacts. Regular retraining on current attack samples, including those synthesized through data augmentation (modeling moiré, print noise, color distortions), maintains the system’s accuracy. Retraining must include a sufficient quantity of diverse bona fide examples — otherwise the model will begin to reject legitimate users with unusual shooting conditions (poor lighting, a non-standard angle, the presence of glasses or a medical mask) more aggressively.

Correct handling of borderline decisions. Not every uncertain PAD result should lead to a final rejection. For cases where the liveness assessment falls into a «gray zone» — above the rejection threshold but below the threshold of unconditional passing — a repeat capture with instructions, a request for an alternative angle, or handoff to an operator for manual review is provided for. This makes it possible not to lose real users in non-standard conditions and not to let suspicious sessions through.

Independent testing and production monitoring. Laboratory certification (iBeta, Ingenium, BixeLab) confirms PAD’s resilience to known attack types under controlled conditions but does not replace monitoring of real data. In production, the distribution of devices, lighting, and user behavior is broader than in the laboratory. Tracking APCER and BPCER on real traffic, segmented by device type, region, and scenario, makes it possible to promptly detect degradation and adjust the models before noticeable losses.

The balance between protection and convenience is not a static point but an ongoing process. The listed tools are applied jointly, and their configuration is determined by the risk profile and the requirements of the business process. At the pilot-implementation stage, it is useful to measure the baseline level of BPCER and APCER and then monitor the dynamics with each configuration change.

Replay Attacks: How Recorded Selfie Video Is Reused

Presentation attacks deceive the camera here and now: the attacker holds a photo, a screen, or a mask up to the lens. A replay attack works differently — it exploits previously captured data. The attacker intercepts or records a legitimate biometric session and then resubmits it to the system, expecting to pass verification without a person’s physical presence.

For liveness, this is a fundamentally different threat vector. A presentation attack creates artifacts at the moment of capture — moiré patterns, glare, uncharacteristic texture. A replay attack can broadcast a recording in which all these signs are absent, because the source material was captured from a real face through a real camera. Protection against replay requires separate mechanisms that cannot be reduced to analyzing the «liveness» of a frame.

Why Active Liveness Does Not Always Rule Out Replay

Active liveness requests an action from the user: turning the head, smiling, pronouncing digits. The logic of the protection is to verify that the person responds to a random request in real time. The resilience of this mechanism depends on several conditions whose fulfillment cannot be guaranteed by default.

Unpredictability of the request. If the set of possible actions is limited (three or four gestures), the attacker can prepare a library of recordings covering all variants in advance and substitute the needed fragment at the moment of the session. The lower the entropy of the challenge set, the easier it is to enumerate.

Binding the response to the session. The request must be cryptographically linked to the session identifier and a timestamp. If the server accepts the response without such a check, a recorded gesture execution can be resubmitted. In December 2025, a practical scenario was added to the MITRE ATLAS knowledge base in which researchers bypassed the active liveness of a financial application by feeding a deepfake video through a virtual camera on a non-rooted Android device. The real-time deepfake reproduced the requested movements, and the system did not verify the video stream source.

Integrity of the channel from the camera to the server. If there is no data signing and runtime-environment verification between the SDK and the liveness server, the attacker can intercept a legitimate response and reproduce it in another session or substitute the video stream before it reaches the analysis module. In that case, active liveness verifies the correctness of the gesture but not the authenticity of the source.

Active liveness complicates replay but does not rule it out. Resilience is determined not by the fact of the challenge request itself, but by the implementation of challenge generation, the binding of responses to the session, and channel integrity control.

How Liveness Is Protected Against Resubmission of Media and Results

Protection against replay is built on several levels, each of which closes its own replay vector.

How Replay Is Detected Through Session Links and Artifact Recurrence

Even if an individual replay attempt is not detected in the analysis of a single frame, a systematic approach to session monitoring makes it possible to detect replay through indirect signs.

Correlation of biometric templates. If the same face passes verification multiple times over a short period — especially from different devices or IP addresses — this is a signal of the possible use of a recording. The system accumulates a history of checks and compares biometric vectors. Matches beyond the statistical norm trigger additional checks or a block.

Bit-level and perceptual deduplication. A resubmitted video may be bit-for-bit identical or contain minimal differences (transcoding, cropping). Perceptual hashes detect matches even under minor transformations. If a media file is too similar to a previously processed one, the system regards this as a likely replay.

Analysis of device and environment metadata. Each session is accompanied by telemetry: device model, OS version, camera parameters (resolution, EXIF, frame rate), network connection characteristics. Replay from a different device or an emulator creates discrepancies between the declared and actual parameters. Video with the camera characteristics of an iPhone arriving from an Android device is a clear indicator of substitution.

Detection of the camera’s PRNU fingerprint. Each camera sensor leaves a unique noise pattern — Photo Response Non-Uniformity. Video processed through deepfake tools or recorded from a screen loses the original PRNU fingerprint. Comparing the noise pattern of the incoming stream against the reference of a specific device camera makes it possible to detect both replay and synthetic substitution.

Analysis of compression artifacts. Re-encoding a video introduces characteristic traces of double compression: JPEG/H.264 artifacts of certain generations, changes in quantization, patterns uncharacteristic of a direct stream from a camera. Machine-learning models trained on «original — re-encoded copy» pairs detect these differences with high accuracy.

The aggregate of methods forms a multi-layered defense in which it is not enough for a replay attack to deceive a single detector. Even if the media data is visually flawless, a mismatch in session metadata, a repetition of the biometric vector, or the absence of a correct PRNU pattern exposes the fact of replay.

Virtual Cameras: How the Video Stream Is Substituted Before Liveness Detection

Presentation attacks target the camera: the attacker shows it a photo, a screen, or a mask. Virtual camera injection works differently — the physical sensor is completely excluded from the chain. Instead of a real video stream, a pre-prepared digital signal is fed into the application or browser: a recorded video, a static image, or a deepfake generated in real time. To the liveness system, such a stream looks as if it was captured by the device’s standard camera module.

The scale of the threat is growing rapidly. According to industry reports for 2024, the number of injection attacks increased ninefold compared with the previous year, and the use of virtual cameras increased 28-fold. A separate trend is native virtual cameras: applications that intercept the camera stream at the level of the operating system’s standard permissions without root access or jailbreak. In 2024, the frequency of such attacks grew more than 26-fold. Such tools have been found in official app stores — the attack vector has moved from a narrowly specialized environment to the mass market.

A significant difference from presentation attacks is the absence of physical artifacts. When a screen is shown to the camera, moiré patterns, glare, and backlighting inhomogeneities remain in the frame. With injection, the stream is formed digitally and does not pass through the optical path, so there are no such traces. Detecting injections is a separate engineering task that cannot be solved by algorithms for recognizing physical forgeries alone.

Where the Risk of Video Source Substitution Arises in the Client Journey

The risk arises at every point where program code receives a video stream and passes it further — to the liveness module, the recognition server, or the API. There are three key scenarios.

Desktop web verification through a browser. The browser requests camera access through a standard interface (the MediaDevices API). If a virtual camera driver is registered in the system, it is displayed in the list of available devices on equal footing with the physical camera. It is enough for the user to select the virtual source in the system dialog. Programs like OBS Studio with the virtual camera feature, SplitCam, or ManyCam provide such a driver and make it possible to broadcast arbitrary content — a file, the screen, a stream from a generative model. From the browser’s point of view, there is no difference between a physical and a virtual source: both provide video frames through the same system API.

Mobile applications combined with an emulator. The attacker launches an Android emulator on a computer, installs the target application, and connects a virtual camera as the video source for the emulated device. For the application inside the emulator, the stream is indistinguishable from the signal of a real smartphone camera. The method combines the convenience of desktop content-generation tools with access to a mobile application, bypassing the restrictions of native SDKs.

Native virtual cameras on a mobile device. No emulator is needed: a specialized application intercepts the camera stream directly on the device, substituting synthetic content. Such applications operate within the operating system’s standard permissions and do not require firmware modification. The device metadata, camera characteristics, and platform information remain genuine, which makes detection at the environment-verification level difficult.

In all three cases, the attack occurs before the data reaches the liveness algorithm. The verification module analyzes frames without knowing that they never existed in the physical world. Protection must begin not with analyzing the content of the video, but with verifying its source.

How Virtual Camera Injection into an Application and Browser Is Detected

Virtual Camera Detection (VCD) works as a separate protective layer that triggers before the liveness module. Its task is to determine whether the video stream comes from a physical sensor or from a software source. The most reliable results come from combining several approaches.

Session metadata analysis. When capturing video through a browser or native API, the system collects device parameters: the camera identifier, supported resolutions, the frame-rate range, autofocus and exposure capabilities. Physical cameras and virtual drivers behave differently when parameters are changed dynamically — for example, when a non-standard resolution is requested. A study published in December 2025 (Kurmankhojayev et al., arXiv:2512.10653) showed that machine-learning models trained on the metadata of real authentication sessions achieve an AUC-ROC above 0.9 in distinguishing physical and virtual cameras. The method is notable for its low computational load: a metadata-based classifier runs in the browser and does not require a GPU.

Runtime environment integrity verification. In mobile applications, the SDK can use platform attestation mechanisms — the Google Play Integrity API on Android and App Attest on iOS. These services confirm that the application is running on a real device, has not been modified, and operates in a trusted environment. If the environment is identified as an emulator or a device with debugging modes enabled, the verification session is aborted before video capture. The approach verifies not the content of the stream, but the context in which the stream is formed.

Cryptographic sensor attestation. The most reliable mechanism is confirmation that specific pixels were obtained from the physical camera sensor. Modern mobile devices are equipped with a Trusted Execution Environment (TEE), which cryptographically signs the data coming from the camera. The server side verifies the signature, relying on the device manufacturer’s public keys. If the signature is absent or does not match the expected one, the stream is considered untrusted. The method forms a chain of custody from the hardware sensor to the server-side verification module.

Obfuscation of client code. In browser scenarios, where sensor attestation is unavailable, protection of the SDK’s JavaScript code serves as an additional barrier. Obfuscation and binary packing complicate reverse engineering — it is harder for the attacker to find a point to intercept the stream and substitute the data source. The protection is not absolute, but it increases the cost of the attack and the time to prepare it.

Which Signs Help Distinguish a Synthetic Stream from a Real Camera

Even if a virtual camera has passed the check at the level of device metadata, a synthetic video stream contains differences from the signal of a physical sensor. These differences are not always noticeable to the eye, but they lend themselves to instrumental analysis.

Behavior when changing resolution. When a new resolution is requested, a physical camera reconfigures the capture pipeline, which takes an unequal amount of time for standard and non-standard values. A virtual camera, as a rule, either scales the output frame in software or fixes the resolution, ignoring the request. In the aforementioned 2025 study, this feature showed high discriminating power: the physical camera varied the switching time, whereas OBS Studio stopped changing the resolution beyond a certain threshold.

Temporal characteristics of the frames. A real sensor produces frames with a natural dispersion of the intervals between them — the micro-fluctuations are related to the operation of auto-exposure, autofocus, and buffering. An injected stream often exhibits either perfectly uniform intervals (exactly 33.33 ms at 30 FPS) or characteristic rendering micro-jitter on the side of the generative model. Statistical analysis of the timestamps reveals anomalies without touching the content of the video.

Hardware camera parameters. A physical sensor continuously adjusts exposure, focal length, and white balance depending on the lighting. These values are available through the camera API and change in real time. For virtual cameras, the parameters are either static or return default values that do not respond to external conditions. Stable focus and ISO readings while the lighting of the scene changes are a signal of a software source.

Forensic frame analysis. A more resource-intensive but effective method is pixel-level image analysis. A physical camera leaves a characteristic noise fingerprint (sensor pattern noise) unique to the specific matrix. Generative models and software sources do not reproduce such a fingerprint. Analysis of residual co-occurrence features makes it possible to distinguish a real frame from a synthetic one. The approach requires more computational resources but complements metadata analysis in cases where the attacker has learned to imitate camera behavior at the API level.

Correlation with the challenge response. If the liveness system illuminates the user’s face with a unique sequence of colors, the reflection of the signal must be present in the frame and correspond to the sequence sent. A synthetic stream, formed in advance or generated by a model, will not reproduce a correct color reaction to an unpredictable stimulus. The principle links injection detection with the liveness check, turning them into a single loop.

None of the signs is absolute on its own. Attackers refine their tools, learn to imitate the behavioral patterns of cameras, and manipulate metadata. Resilience is ensured by a combination of several detectors and regular updating of the models on new attack samples.

How to Block Virtual Cameras While Preserving Convenience for the User

Protection against injections should not create friction for a legitimate user. All the listed measures work in the background and require no additional actions from the person.

Built-in detection in the SDK. Verification of the video stream source is performed on the side of the client SDK — mobile or browser — before the frames are transmitted to the server. For a legitimate user, the process passes unnoticed: the SDK collects metadata, verifies the runtime environment, and sends the result along with the video. The time to collect metadata fits within 2–3 seconds — it coincides with the natural pause while the user positions their face in the frame.

Device attestation at session start. In mobile applications, the device integrity check is performed once at the start of the verification session, before the camera is opened. No steps are added to the user scenario: the integrity token is requested in the background while instructions are displayed on the screen. If the environment is identified as untrusted, the user is offered verification by another method — without error messages that ruin the experience.

Server-side validation and threshold logic. The results of VCD, environment attestation, and liveness are aggregated on the server. The thresholds are configured depending on the risk level of the operation: for low-risk scenarios (login confirmation), less strict control is acceptable; for high-risk ones (opening an account, a large transfer), the full set of checks is used. The graduated approach reduces the share of false rejections in typical scenarios while maintaining maximum protection where it is critical.

Regular updating of models. The landscape of virtual cameras changes: new drivers appear, existing ones are updated, methods of metadata obfuscation improve. VCD models need to be retrained on fresh data — samples of new tools and current versions of known ones. Without regular updating, detection effectiveness falls as attackers adapt to the current signatures.

Monitoring and feedback. Suspicious sessions — with signs of injection but which passed liveness — are recorded for manual analysis and model retraining. This makes it possible to detect new attack methods at an early stage and adjust the detection logic before mass incidents.

When choosing a biometric solution provider, it is worth clarifying: whether the liveness module includes injection attack detection, whether it has passed testing under CEN/TS 18099 or similar methodologies, and how the updating of VCD models is organized. Resilience to virtual cameras directly affects the real, rather than declared, security of the identification process.

Active and Passive Liveness: How They Differ in Resilience to Liveness Attacks

All three bypass vectors — presentation attacks, replay, and virtual cameras — pass through a single protection node: the liveness check. The check mode determines which vulnerabilities will prove critical and which will be neutralized before the analysis even begins.

Passive liveness requires no actions from the user. The system analyzes a single frame or a short sequence: skin texture, the nature of light reflection, depth maps, pixel artifacts, and micro-movements invisible to the naked eye. Active liveness prompts the user to perform an action — blink, turn the head, smile, follow a point on the screen. The system records the response and compares it against the expected sequence.

The difference in mechanics creates fundamentally different vulnerability profiles. The passive mode does not reveal the verification criteria to the attacker, making it harder to prepare a targeted bypass. The active mode makes part of the logic visible: the attacker knows which action is requested and can prepare a response in advance. At the same time, the active check creates an additional barrier for static forgeries, while the passive one relies more heavily on the physical properties of the image, which are hard to synthesize in software.

Which Bypasses Are More Often Successful Against Passive Liveness

The passive mode works with a single image or a minimal set of frames. This makes it resilient to simple photo attacks and playback of video on a screen: modern models based on convolutional neural networks (CNNs) confidently detect the texture anomalies of printed images, display moiré patterns, and the absence of three-dimensional facial geometry. Solutions that have passed ISO/IEC 30107-3 Level 2 testing demonstrate an APCER of 0% for such artifacts.

The passive approach has zones of elevated risk.

High-quality 3D silicone masks with realistic skin texture and depth geometry. If the mask correctly conveys light reflection and reproduces volume, single-angle analysis may fail to detect the substitution. The risk increases when using a camera without infrared illumination or a depth sensor.

Video stream injection through a virtual camera. The passive mode does not request an interactive response, and if the attacker feeds a synthetic frame with correctly generated texture and lighting, the algorithm has fewer behavioral signals to check. Injection attacks bypass not so much the liveness model itself as the data capture channel, but the absence of challenge-response makes the passive mode more vulnerable in this scenario.

New-generation deepfakes generated in real time. With sufficient generation quality, a synthetic face can reproduce texture, lighting, and even micro-movements with high accuracy. Current passive detectors, trained on large datasets of synthetic images, recognize pixel anomalies and GAN/diffusion artifacts inaccessible to the human eye.

The general rule: passive liveness is most vulnerable where the attacker controls both a high-quality physical forgery and the data transmission channel. Against mass low-budget attacks — photos, screens, paper masks — the passive mode works reliably.

Which Bypasses Are More Often Successful Against Active Liveness

Active liveness creates a barrier through the unpredictability of the request: the system asks the person to perform a specific action, and the correct response at the correct moment confirms physical presence. This effectively blocks static photographs, pre-recorded videos, and simple replay attacks — the recording does not contain the required action in the required phase.

The active mode has its own limitations.

Vulnerability to real-time deepfakes. Modern face-generation systems imitate blinking, head turns, smiles, and other gestures with minimal latency. If the attacker uses a face-swap tool paired with a virtual camera, they see the request on the screen and pass it to the generator, which forms a synthetic response. The simpler and more predictable the set of gestures, the higher the probability of a bypass.

Disclosure of the verification logic. The active request is visible to the user — and to the attacker. They can initiate sessions many times, catalog the types of requests, and prepare response templates. Randomizing the sequence reduces the risk but does not eliminate it completely: if the pool of actions is limited to three or four gestures, enumeration takes minutes.

Sensitivity to adaptive replay attacks. If the attacker intercepts the challenge (for example, «turn your head left»), they can launch a pre-prepared video fragment with this action in fractions of a second. Protection against such a scenario requires server-side binding of the challenge to the specific session and timestamp control — this relates not to liveness but to the interaction protocol.

Besides security, the active mode creates an operational risk — a decline in conversion. Each additional step in the verification scenario increases the share of drop-offs. Industry data show that switching from active to passive liveness can raise the percentage of successful passes from 60% to 95% and above. This is not a vulnerability in the classic sense, but a business factor that directly affects the choice of mode.

How Liveness Modes Are Combined Without Complicating the Scenario

In practice, the opposition of «active or passive» loses its meaning with proper design. The greatest resilience is provided by an adaptive (risk-based) scheme in which the liveness mode is chosen dynamically — depending on the risk profile of the specific session.

A typical architecture: by default, the system launches a passive check. The user takes a selfie, and the algorithm analyzes texture, depth, reflections, and artifacts — in fractions of a second, without additional instructions. If the passive analysis yields a high level of confidence, the session ends successfully. If the score falls into the «gray zone» — insufficient data, indirect signs of substitution detected, an atypical device, or suspicious metadata — the system automatically switches to an active challenge. The user receives a request for an action, and only after successfully passing it is the session confirmed.

The cascaded approach solves several tasks at once. For most legitimate users (by industry estimates, 85–95% of the flow) the process remains instant and seamless: conversion does not suffer, and there are no additional steps. For suspicious sessions, enhanced verification is engaged, creating a barrier precisely where the risk is higher. The attacker does not know in advance which mode awaits them and cannot prepare for a fixed scenario.

In parallel with liveness, measures independent of the check type work in both modes: application integrity control (detection of root/jailbreak, emulators, camera interceptors), binding of the session to the device through the camera’s PRNU fingerprint or a device fingerprint, server-side validation of timestamps and one-time tokens, and analysis of media file metadata. These layers close off injection and replay attacks regardless of the active liveness mode.

When choosing a configuration, it is worth considering several parameters: the acceptable level of friction for the target audience, regulatory requirements (a number of standards directly prescribe an active challenge for certain classes of operations), the profile of typical attacks in the specific industry, and the capabilities of the client devices. Pilot testing on real traffic makes it possible to tune the switching thresholds so that the share of false escalations (legitimate users directed to an active check) remains within a specified percentage.

The ultimate goal is not to choose one «best» mode, but to build an adaptive loop in which each subsequent layer is engaged when necessary. This preserves speed for legitimate users and at the same time raises the cost of an attack to a level at which it ceases to be economically justified.