A selfie check takes a few seconds and feels like a single step. Underneath, it is answering several different questions, and a deepfake only has to slip past the one nobody is asking. Knowing what each layer proves, and what it does not, is where a sound identity check starts.
Three questions, not one
To the customer, a selfie check is one moment: look at the camera, wait, done. To the system, it is three separate questions:
- Is this the same face as the one on the document or the record? That is face matching.
- Is a living person in front of the camera right now? That is liveness detection, which the standards call presentation attack detection (PAD).
- Did the images really come from that camera? That is a question about the device, the app and the video stream.
A system can answer one of these well and the others poorly. Deepfakes matter because they are aimed at the gaps between them.
What a match actually tells you
Matching software does not look at two photos the way a person does. It turns each face into a template, a compact set of numbers describing its features, compares two templates and produces a similarity score. A threshold then decides whether that score counts as a match.
A "match" is therefore a judgement about likeness, not proof of identity, and it can be wrong in two ways. A false match lets an impostor through. A false non-match turns away a genuine customer. Moving the threshold swaps one error for the other: tighten it and fewer impostors pass, but more real customers fail. That setting is a risk decision. It belongs to the firm, should be written down and revisited, and should not simply be whatever the supplier shipped.
Two further points limit what a match can prove.
- The task matters. Most onboarding checks are one-to-one: this selfie against this document. Searching one face against a whole database is a different job. At the same threshold it is more likely to throw up a false match, because every record is another chance to be wrong. It also carries more privacy risk, and some jurisdictions restrict it specifically.
- Accuracy is not the same for everyone. NIST's 2019 study of demographic effects (NIST IR 8280) tested 189 algorithms from 99 developers and found error rates that differed between groups in most, but not all, of them. Gaps in false match rates were often a factor of 10 to more than 100. More accurate algorithms generally showed smaller gaps. The practical lesson is to measure on your own customers, group by group, not only overall.
What liveness adds
A perfect match shows only that two faces are alike. It says nothing about whether the face belongs to someone who is actually there. A fraudster can hold up a printed photo, play a video on a screen, or wear a mask, anything from a paper cut-out to a realistic three-dimensional one. These are presentation attacks, and liveness detection is there to catch them.
The international standard ISO/IEC 30107-3:2023 sets out how this kind of detection should be tested and reported. It uses two measures:
- APCER: how often attacks are wrongly accepted, reported separately for each type of attack.
- BPCER: how often genuine people are wrongly flagged as attacks.
Liveness, like matching, has its own threshold and its own trade-off. The security and the friction of the whole journey come from both thresholds working together, not from either one alone.
Where deepfakes come in
A deepfake can be played on a screen and held up to the camera. Then it is a presentation attack like any other replayed video, and liveness detection is the right defence. The harder case is a deepfake that never passes through the lens. In an injection attack, fake images or video are fed directly into the app or the data stream, for example through a virtual camera or a modified app. The liveness check may then be studying footage the camera never recorded.
This is why, for remote onboarding, a check that looks only at the face is not enough. Defending against injection means checking the device, the app and the integrity of the video stream as well. In 2024 the European Committee for Standardization (CEN) published a technical specification on detecting these attacks, CEN/TS 18099 Biometric data injection attack detection.
Liveness can tell you a face was in front of a camera. It cannot, on its own, tell you the camera was honest.
What a selfie check cannot prove
Even with all three layers working, some things sit outside the selfie:
- That the reference photo is genuine. A morphed photo blends two people's faces so that both can match it. If the document photo was morphed, a strong match proves very little. Where that photo came from matters as much as the selfie.
- That the result is equally reliable for everyone. An average can hide weaker performance for some groups. Lighting, camera quality and exposure can affect some people more than others, and a document photo taken many years ago is harder to match because faces change.
- That a headline accuracy figure applies to you. A false non-match rate means little without the false match rate it was measured at, the kind of images used and the people tested. Good passport photos are not cheap phone selfies in poor light.
Independent benchmarks help. NIST runs ongoing public evaluations, known since August 2023 as the Face Recognition Technology Evaluation (FRTE) and, for face analysis tasks such as liveness, the Face Analysis Technology Evaluation (FATE); they were previously called the Face Recognition Vendor Test (FRVT). They are useful for comparing algorithms. They do not replace testing your own journey, with your own customers and your own capture process.
Questions for an identity team
- Who set our matching and liveness thresholds, on what risk grounds, and when were they last reviewed?
- Which attacks was our liveness tested against, by whom, to which standard, and at what error rate for each?
- What do we check beyond the face: the device, the app and the integrity of the video stream?
- Have we measured error rates on our own customers, for each relevant group, and do we count failures to capture an image as well as failed matches?
- What happens to a customer the system rejects? There should always be a route to a trained person and another way to prove who they are.
In Kenya, the Data Protection Act, 2019 includes biometric data in its definition of sensitive personal data (section 2). Using it needs a lawful basis under section 30 and a sensitive-data condition under section 45. The Data Protection (General) Regulations, 2021 count biometric processing as high risk, so a data protection impact assessment under section 31 should be expected for any biometric identity check. Section 35 gives people a right, subject to exceptions, not to be subject to decisions based solely on automated processing that significantly affect them, and the Office of the Data Protection Commissioner has published guidance notes on biometric data. Unfair rejection rates can also raise questions under Article 27 of the Constitution, which protects against direct or indirect discrimination, and the Act's duty to process data fairly (section 25).
Our free course Biometrics: Face Matching, Liveness and Accuracy covers face matching, accuracy, fairness, liveness and attacks, and the lawful handling of biometric data in depth, with a knowledge check and a certificate.
Sources
- US National Institute of Standards and Technology, NIST IR 8280: Face Recognition Vendor Test, Part 3: Demographic Effects (2019)
- US National Institute of Standards and Technology, Face Technology Evaluations (FRTE and FATE)
- International Organization for Standardization, ISO/IEC 30107-3:2023: Biometric presentation attack detection, Part 3: Testing and reporting
- European Committee for Standardization, CEN/TS 18099:2024: Biometric data injection attack detection (via iTeh Standards catalogue)
- Kenya Law, Data Protection Act, 2019 (No. 24 of 2019)
- Kenya Law, Data Protection (General) Regulations, 2021
- Office of the Data Protection Commissioner, Kenya, Guidance Notes on Biometric Data (2025)