Talk to usTry the demo

Real-Time Face Swaps and Interactive Liveness: What Recent Research Shows

Liveness, deepfakes and presentation attacks

For: Security architect or product owner who must decide how a remote selfie step should respond to live face-swap attacks

What studies of live face-swap attacks say about interactive liveness: which challenges expose a swap, where they fail, what virtual camera and motion signals add, and what guidelines ask.

A remote selfie step assumes that the camera shows a live person. This article asks what current research says about the attack that breaks that assumption, a real-time face swap routed into the verification session, and about the defence that most flows reach for first, asking the person to perform a short randomized action. It is written for the security architect or product owner who has to decide how much to trust interactive liveness against live swaps, and which questions to ask of any evidence offered for it.

The evidence is a mix of laboratory studies, a field-style study with live sessions, a vendor-independent threat report and the injection provisions of a US federal guideline. Each result is attributed to the paper or document that states it, and each paper's own limits are reported along with its numbers. Where a number comes from a small study, the article says so, because most of the studies discussed are small.

The attack in plain terms

A real-time face swap replaces the face of the person in front of the camera with another face while the video is being recorded. The GOTCHA paper describes the generic pipeline: a physical webcam feeds a face and landmark detector, a face alignment step, a segmentation step that finds regions such as lips and eyes and the boundary around occluding objects, a face swapper that is typically an autoencoder, a blending operator and colour correction, and finally a virtual webcam that is piped into the video application. The same paper notes that the pipeline has optimal operating conditions at each component, and that inputs outside those conditions lead to visible artefacts.

Two cost factors have shaped the attack over time. First, the effort per target: the GOTCHA authors state that a face-swapping framework such as DeepFaceLab typically needs about 4,000 diverse images of the target, while facial reenactment techniques expect only a single image that is then animated. Second, computing power: the same paper measured the inference speed of one such pipeline at 1.2 frames per second on an eight-core processor and 23.5 frames per second with a consumer graphics card, against a threshold of 15 frames per second that it treats as live for video calls. A public tool of this kind exists: the DeepFaceLive repository describes itself as a real-time face swap for PC streaming or video calls, and its owner archived it on 13 November 2024, which makes it read-only but does not remove copies.

The European Union Agency for Cybersecurity described the same development in 2022. Its report on remote identity proofing says that deepfake videos and interactive deepfake puppets can be created in real time, that the attacker's camera captures the video and an algorithm modifies it with the learned face of the target, and that in this case every randomness added to the process could be ineffective, because the operator effectively talks with a real person. The report adds that high-quality real-time mode then required a great deal of computing power, and that the technological barrier was diminishing. Four years later, the Brno study cited below describes the situation in one sentence: a single public photo feeds a real-time face-swap pipeline on a consumer graphics card, and the attacker routes the synthesized stream into the call through a virtual camera driver.

Presentation attack versus injection

The vocabulary matters for reading the results. A presentation attack puts a physical artefact such as a printed photo, a replayed video or a mask in front of the camera. A video injection attack bypasses the physical camera interface entirely and injects a pre-recorded or synthetic stream into the pipeline, often using face swapping and virtual camera software. The European Union Agency for Cybersecurity report makes the same distinction: it describes video injection as not a presentation attack instrument, because the video is injected and not physically presented to the camera, and as a way to circumvent the camera of the device used for the proofing. The report also records that, according to market players, video injection was the most promising attack method, while its own conclusion said that the main attacks on remote identity proofing at that time were low-tech and had a low probability of success, and that the last frontier was the deepfake attack presented through video injection or high fidelity screens.

The CEN technical specification on biometric data injection attack detection was introduced to give this class of attack its own definitions and test approach. Its scope covers definitions of biometric data injection attacks, use cases, injection attack instruments, guidance on detection systems and mitigation, and the creation of a test plan for evaluating injection attack detection. Presentation attack testing is outside its scope, because other standards cover it, although presentation attack detection systems and bona fide testing remain in scope as defence mechanisms and as a check that legitimate users are classified correctly.

What the guidelines ask

The US federal guideline on identity proofing, Special Publication 800-63A-4, has a dedicated section on digital injection prevention and forged media detection. It states that many emerging attacks on both attended and unattended remote proofing pair digital injection with increasingly effective generative AI tools, and that injection attacks insert modified or forged media between the capture point and the component that performs the comparison. It adds two sentences that matter for design. A biometric comparison performed with a captured sample does not prevent these attacks, and live document capture and presentation attack detection provide some protection by making injection of viable forged media more challenging, although even these mechanisms are not sufficient to address all possible cases.

For all remote proofing the provider must implement technical controls to increase confidence that digital media is produced by a genuine sensor, for example by detecting a virtual camera, a device emulator or a jailbroken device. It must analyse all submitted media for artefacts of modification, manipulation, tampering or forgery, test its analysis against available attack artefacts and genuine media, and document the kinds of attack artefacts tested and the corresponding false negative rates for relying parties on request. It must use only authenticated protected channels. The guideline recommends, as a should and not a shall, that automated analysis be augmented by manual review, that capture sensors be authenticated or device attestation be used, and that media be analysed for signatures of known generative tools. For attended sessions, it requires random human-in-the-loop cues in the capture process, for example requesting user movements or asking the user to move objects between the sensor and the face, and training for agents to look for indications of manipulated media such as high latency and synchronisation issues.

The authors of the Oulu study describe the European picture in their own words. They state that the standard on identity proofing for trust services, ETSI TS 119 461, updated to version 2.1.1, introduces baseline and extended levels of identity proofing and requires independent testing of biometric injection attack detection according to the CEN technical specification. That is the authors' summary, and a reader who needs the exact text should read the standard itself.

Why frame-level detectors alone are not enough

A frame-level detector looks at pixels for signs of synthesis. The Brno authors state that such detectors catch older generators but generalise poorly as new tools appear. The Deepfake-Eval-2024 benchmark measured the effect on in-the-wild material: it consists of 45 hours of video, 56.5 hours of audio and 1,975 images from 88 websites in 52 languages collected in 2024, and the authors found that the AUC of open-source state-of-the-art detectors fell by 50% for video, 48% for audio and 45% for images compared with previous benchmarks. They also found that commercial detectors and detectors fine-tuned on the new benchmark scored higher than off-the-shelf open-source models, but did not yet reach the accuracy of deepfake forensic analysts.

The same study explains why academic scores had looked so high: many existing benchmark datasets use outdated manipulation techniques, so detectors reach AUC values approaching one on them. The lesson for liveness is practical. A detector that scores well on a published set of swaps tells you little about a swap made with a tool released after the set was built. The GOTCHA authors make the related point that existing detection techniques are asynchronous and operate offline, which makes them ill-suited to live impersonation where the imposter can refine models in advance.

What the earlier studies showed about liveness checks

An influential 2022 study of facial liveness verification services, presented at a security conference, tested what it calls action-based, voice-based, silence-based and image-based services with a deepfake-powered attack framework. Its abstract reports that most liveness APIs do not use anti-deepfake detection, and that even for those that do, the defence may detect high-quality synthesized videos but fail on low-quality ones. The paper also reports that the security gain from the random element in voice-based and action-based services, such as a random voice code or action sequence, was marginal, and it suggests that action-based services should adopt actions that are difficult for deepfakes to synthesize. The study dates from February 2022, and the tools and services it tested have changed, but its structure, a liveness decision that can be satisfied by a synthesized response, is the one that later studies examine.

The GOTCHA study of 2024 proposed the opposite design principle: instead of asking for any action, choose actions that stress the weak points of a live swap pipeline. It defined a challenge as a task that degrades real-time deepfakes, can be performed during a live call and can be specified by randomizable parameters. Its taxonomy has four families: head movement, face occlusion by a hand or an object, facial deformation such as pressing a finger against the cheek or changing expression sharply, and changes in face illumination. The authors recorded 47 users performing eight challenges and generated deepfakes of them with three pipelines, which produced a dataset of 56,247 videos. Human evaluators and an automated fidelity score both saw degradation of the deepfakes, with AUCs of 88.6% and 80.1% respectively. The study states its own limits: a dataset of 47 identities, a controlled setting with cooperative participants, and no test of every adversarial tactic.

The Brno study of live sessions

The Brno study, accepted at the BIOSIG 2026 conference and posted in October 2026, is the most recent test of the principle against live tools. It evaluates randomized gesture challenges in 108 live sessions with six subjects, 24 impersonated identities and two real-time face-swap tools injected through a virtual camera. The sessions consist of 36 genuine sessions, 36 with DeepFaceLive and 36 with FaceFusion. The authors call it a proof-of-concept study, and the limits stated in the paper are that it includes six subjects from one broad demographic group and two tools, so the results hold within the tested population and attack configurations.

The design of the test

The pipeline is a thin client design: the browser only captures the webcam stream and shows instruction overlays, and the analysis runs on the server. A state machine draws random actions from a challenge generator and enforces a timeout per action. Two branches analyse the frames in parallel: a branch that scores every frame for deepfake artefacts with two detectors using frozen public weights that were not trained on outputs of the two tools, and a branch that validates the requested action. The gesture pool has four categories: pose, such as head rotations and leans; expression, such as a smile or open mouth; occlusion, such as covering an eye, the nose or the mouth; and complex, which combines two constraints in one hold, such as covering the mouth while turning left. A session starts with a two-second calibration in which the person holds still, followed by 5, 6 or 9 randomized active actions.

Capture used a webcam at 1280x720 and 30 frames per second, with subjects seated 50 to 70 cm from the camera. One of the tools runs community pre-trained models, and the other swaps identities from reference photos with an optional occlusion mask that preserves foreground objects such as a hand. The analysis unit is the action window, and the headline comparison uses the raw spatial score of one detector, bypassing the fusion weights of the deployed system. Confidence intervals come from 2,000 subject-clustered bootstrap resamples, and the authors state that they are descriptive and unadjusted for multiplicity because there are only six subject clusters.

The results

The calibration segment, in which the person holds still, separates attack sessions from genuine ones with a session-level AUC of 0.878. The mean across the active-gesture windows reaches 0.988, a paired difference of +0.110, with an interval from +0.032 to +0.161. Restricting each session to its first five active actions gives a similar 0.987, and across six leave-one-subject-out analyses the active-window AUC ranges from 0.983 to 0.998. The authors conclude that under the tested conditions, aggregating responses across randomized actions improves separation without retraining the detector.

The deployed system, with fusion and gesture-completion logic, reaches 94.4% accuracy on the 108 sessions, with an attack presentation classification error rate of 2.8% and a bona fide presentation classification error rate of 11.1%. The authors remark that the second figure shows that reducing the rejection of genuine users remains an important requirement for practical deployment.

The gesture-level results are less tidy than the session-level ones. Pose and complex actions have the highest point estimates against DeepFaceLive, but their intervals include zero, and expressions show no clear improvement. The clearest category-level difference points downward: occlusion against FaceFusion reaches an AUC of 0.840, compared with 0.910 for the hold-still baseline, a paired difference of -0.069. FaceFusion was tested with its occlusion mask enabled, so the authors read the result as consistent with the mask preserving foreground occluders and reducing visible swap artefacts, and they state that the experiment cannot isolate the causal effect because no matched run with the mask disabled was made. The paper says this illustrates that a challenge reported as effective against earlier pipelines may provide less evidence against an attack configuration designed to handle it. Single-gesture cells were too small for inference; a smile against DeepFaceLive reached an AUC of 0.643.

The paper also looks at time. Attack sessions took longer to satisfy the validator for all six subjects, with a median within-subject difference of +1.0 s. Pooled over gestures, the median is 3.1 s for genuine sessions, 4.0 s for DeepFaceLive and 3.6 s for FaceFusion. The mean latency per session separates attacks from genuine sessions with an AUC of 0.732, and occlusion gives the highest latency AUC at 0.800. The authors stress that the latency includes synthesis and virtual camera transport and not only human response time, and that timed-out sessions were not retained, so the signal needs local calibration and is deployment specific. Their conclusion supports active capture as a design principle and not universal performance values or a fixed ranking of gestures.

How to read the study

Three cautions follow from the paper itself. The population is six people and the attack set is two tools, so the numbers are read as a direction. The detector in the headline comparison was never trained on the two tools, which is the right setup for the question, but it also means that the result applies to that detector and that set of tools on the day of the test. The category ranking is explicitly not established, so a product team should not copy a gesture list from it. What the paper does support is the process: test the challenge set against current attack configurations, and re-test when tools change.

Signals beyond the face

The device and the camera

If the stream is injected, the camera it claims to come from may not be a camera. A December 2025 paper from a biometric vendor studies virtual camera detection with browser-side tests. The application asks the camera driver, through the browser interface, to change frame height and frame rate, and records the requested value, the value the browser reports, the value actually applied and the response time. The idea is that reconfiguring a physical camera takes time because it involves hardware, while a virtual camera handles the change in software and often more quickly, and that some virtual cameras report a change that did not happen.

The data set is more than 30,000 sessions, with 2,812 attack sessions and 30,000 bona fide sessions across several platforms and browsers. Camera labels were not used as a feature, because in most attack sessions the label was omitted or replaced with a custom name. Three models reached an AUC above 0.9. The paper's most useful table is the operating-point table. At a 10% attack acceptance rate the rejection of genuine users was 14.6%; at 1% it rose to 68.3%; and at 0.1% it reached 91.7%. The authors say that, in a layered design, the detector can be run at the looser setting, with later modules catching what it lets through. Whatever the layer, the numbers show how quickly a stricter setting costs legitimate users, and that is the number to ask for.

Motion during the selfie

The Oulu study asks a different question: does the way the phone moves during a handheld selfie carry evidence? It introduces a dataset of 375 bona fide multi-sensor sequences recorded at 50 Hz from 30 participants, with stationary, handheld and temporally shifted attack proxies. For spoof screening, an accelerometer-only model obtained 0.00% false rejection and 43.8% false acceptance, and another obtained 32.0% false acceptance at 2.37% false rejection, with both rejecting all stationary proxies. A user verification model reached 1.07% equal error rate using nine channels in the same-device, same-session setting.

The paper is candid about what this does not show. Temporally shifted sequences, which model a delay between camera and motion in injection settings, remained difficult, with a false acceptance no lower than 67.8%, because they contain genuine handheld motion. The dataset has 30 participants, one smartphone model, one posture and one session, the attack proxies are few, and no real software-level injection pipeline was exercised. The authors conclude that motion is a low-friction auxiliary signal for layered decisions and not a standalone verifier or a complete injection attack detector.

Putting the evidence together

Five statements are supported by more than one source discussed above.

  • A live swap can answer a random instruction, because it transfers the motion of the person driving it.
  • Randomness alone buys little, as the 2022 study found for random codes and sequences, and the Brno study found for expressions.
  • Actions that stress the swap pipeline add separation, with pose, combined actions and aggregation over several actions showing the clearest gains, but the effect depends on the attack configuration, and an occlusion mask can reduce it.
  • Signals from outside the face, such as the source of the video, the timing of responses and the motion of the device, add evidence and carry their own error rates.
  • A guideline-level response combines controls: genuine sensor checks, analysis of media, tested and documented false negative rates, and manual review.

A checklist for evaluating a liveness design against live swaps

  • Which tools and configurations were used as attacks, and are they current?
  • Was the detector trained on those tools, or on older generators?
  • Does the evidence come from live sessions or from recordings replayed later?
  • How many people and how many impersonated identities does the result rest on, and are the intervals reported?
  • Which challenge categories were measured separately, and did any perform below a still baseline?
  • What is the rejection rate of genuine users at the operating point, and how does it move when the attack acceptance rate is tightened?
  • Does the design look at the video source, such as a virtual camera, or does it analyse only the face?
  • How are timing and device signals calibrated, and on whose population?
  • What happens to a session that fails: a second attempt, a manual review, or a refusal?
  • When will the test be repeated as swap tools change?

Where this sits in a verification flow

The liveness step of a NeuroVision verification session is active: the person moves the face closer through two ovals. Deepfake and face-swap detection works inside the selfie and liveness steps. A verification flow built on NeuroVision KYC places these steps in one session: document, selfie, liveness and face match, with the scenario assembled in an editor. The research above is a reason to test any liveness configuration on your own devices and capture population, and the team can describe how to do that for your scenario. To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 27 October 2026.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us