Passive Liveness Check

Passive liveness check is a process of determining whether the presented face is a real person without requiring the user to perform any additional actions (unlike active liveness check).

This check is recommended for applications, where the user experience an seamless app flow is in the first place.

Mobile app libraries provide the passive liveness check in several ways. The passive liveness can be obtained from the quality attributes returned by Face Capture UI component.

Another way to get passive liveness in a mobile app is to run the face detector on an image of a face.

Core server can provide passive liveness check.

DOT passive liveness check achieved iBeta Level 2 PAD accreditation in accordance with the ISO 30107-03 PAD standard. See the confirmation letter. More on the test specification.

Passive Liveness steps

In order to evaluate the passive liveness, following steps must be performed:

  • Face detection - find position of the face in the image
  • Passive liveness evaluation - calculates the passive liveness score and whether evaluation conditions were met. If conditions were not met, the result should taken with consideration.

Face detection

The first step of performing passive liveness check is face detection. This is an important step, because there may be no face or multiple faces present in the picture. Once a face is detected it can be used to evaluate the passive liveness. There are various face detection modes available, fast mode provides lower latency, in accurate mode detection is more precise. Mobile devices only support fast mode.

Passive liveness evaluation

A facial image with sufficient background should be submitted for evaluation. Minimum requirements for the image are:

  • image size at least 600x600px
  • distance between the eyes at least 90px
  • image width should be at least 4x distance between the eyes in px
  • face present in the center of the image
  • not too strong backlight or sidelight
  • no overexposed or underexposed images
  • ICAO attributes are recommended to be compliant with table below

PassiveLivenessQualityProvider used in mobile components, ensures all these conditions were met during capture.

Presentation attack detection

Our algorithm has been trained to detect real faces and also various kinds of spoof attacks. These include:

  • Faces displayed on electronic screen
  • Printed faces
  • 2D masks
  • 3D masks

We understand that new attacks might emerge, and we regularly retrain the models to incorporate new attack vectors. It is also important that our customers keep components up to date as we release them.

Passive liveness threshold

The final decision if the face is real or a spoof should be determined by the passive liveness score and the threshold. If the score is above the threshold, this can be interpreted as accepted. If the score is below the threshold, it is rejected.

Thresholds for Core Server v6.7.1 and DOT Face v2.3.1 and older


Thresholds for Core Server v6.8.0 and above


Thresholds for DOT Face v4.0.0 and above



Let’s set the threshold of passive liveness for Core Server to 89.76. If we have a representative set of 10000 real faces, statistically 220 of the faces will be in average incorrectly marked as spoofs even though they were real faces (False Reject Rate). If we have set of 10000 spoofs, statistically 10 of the spoofs will be in average wrongly marked as real faces (False Accept Rate).

Setting the correct threshold depends on the security/convenience balance that is required for the specific use case.

Integration hint

During the initial configuration of the system, two thresholds can be set. If the score is below the bottom threshold, result is automatically set to rejected. If the score is above the top threshold it is automatically accepted. If the score is between the two thresholds, images go for review to a back office operator for final decision.


Passive liveness has to be always combined with face verification if possible. Passive liveness ensures the presented face is real, but it must be also checked whether it belongs to the person expected. This applies for onboarding and login use cases.