Presentation Attack Detection: What ISO 30107 Proves
Presentation attack detection (PAD) is the part of a biometric system that spots fakes held up to the camera, such as printed photos, screen replays and masks. ISO/IEC 30107-3 defines how labs test it. So a PAD certificate proves resistance to those physical attacks, but it says nothing about deepfakes injected straight into the video stream.
What a Presentation Attack Is: Print, Screen Replay and 3D Mask
A presentation attack is any attempt to fool a biometric sensor with an artefact instead of a live person. In face verification, the fraudster places something in front of the camera and hopes the system treats it as a real face. ISO/IEC 30107 calls that object a presentation attack instrument, or PAI.
Three families cover most attempts at eKYC onboarding:
- Printed photos. A high-resolution print of the victim, sometimes with the eyes cut out so a real person can blink behind it.
- Screen replay. A video or photo of the victim shown on a second phone, tablet or laptop.
- Masks. Paper, resin, latex or silicone masks, from cheap cut-outs to custom 3D builds.
The standard groups instruments made the same way into a PAI species. For example, “glossy print on an office printer” is one species, while “video replay on a tablet” is another. That grouping matters later, because test results come per species.
Presentation attack detection is therefore narrower than it sounds. It asks one question: is the thing in front of this camera a live human face? It does not check whether that face matches an ID, which is the job of face matching. For the wider picture, see how liveness detection works.
How Presentation Attack Detection Works: Active, Passive and Hardware-Based
PAD systems use three broad approaches, and most products combine at least two. Each approach reads a different kind of evidence, so each one fails in a different way.
| Approach | How it works | Strength | Weak spot |
|---|---|---|---|
| Active (challenge-response) | Asks the user to blink, smile or turn, then checks the response | Hard for a still photo to pass | Adds friction, and replays or real-time face swaps can follow prompts |
| Passive (single capture) | Analyses one image or a short clip for texture, depth cues, reflections and screen artefacts | No extra effort for the user, so drop-off stays low | Depends heavily on capture quality and training data |
| Hardware-assisted | Uses depth sensors, infrared or structured light on the device | Strong against prints and screens | Only works on phones that have the sensor, which rules out most budget models |
For banks and e-wallets with users on mixed Android devices, hardware-assisted PAD is rarely an option. The app simply cannot count on a depth sensor. That is why most remote onboarding relies on software PAD, active, passive or both. It is also why the test conditions behind a PAD result matter so much, as the next sections show.
How ISO/IEC 30107-3 Tests Presentation Attack Detection: APCER vs BPCER
ISO/IEC 30107-3 is the part of the standard that defines how to test and report PAD results. It does not tell you how to build a liveness check. Instead, it gives labs a shared vocabulary and two core error rates, so results from different tests mean the same thing.
APCER: Attacks Wrongly Accepted
APCER stands for attack presentation classification error rate. The standard defines it as the share of attacks using the same PAI species that the system wrongly classifies as genuine. In plain terms, it is how often a given type of fake gets through.
Because APCER is measured per species, a vendor cannot hide a weak spot behind an average. A system might stop every printed photo but miss one replay in ten. The report should show both numbers, and the weakest species is the one an attacker will use.
BPCER: Real Users Wrongly Rejected
BPCER is the bona fide presentation classification error rate. It counts genuine users the system wrongly flags as attacks. For a bank, this is the drop-off number, since every false reject becomes a support ticket or an abandoned application.
However, the two rates pull against each other. A stricter threshold lowers APCER but raises BPCER, and the reverse is also true. So a PAD result only means something when you know both rates at the same threshold. A vendor quoting a low attack error rate without the matching false reject rate is telling you half the story.
PAD Test Levels and What Each One Simulates
ISO/IEC 30107-3 does not define “Level 1” or “Level 2”. Those labels come from test labs, which turn the standard’s idea of attack potential into fixed test budgets. The best-known scheme is from iBeta, a lab accredited under NIST’s NVLAP programme.
| iBeta level | Time per species | Artefact budget | Attacker expertise | What it simulates |
|---|---|---|---|---|
| Level 1 | 8 hours | Up to $30, according to iBeta | None | Prints, screen replays and simple paper masks from home or office equipment |
| Level 2 | 2 to 4 days | Up to $300, according to iBeta | Moderate | 3D-printed, resin and latex masks |
| Level 3 | 7 days | No fixed cap | Significant | Hyper-realistic masks with specialised props and settings |
iBeta also caps the false reject rate. According to iBeta, a Level 1 or Level 2 pass allows a BPCER of up to 15%, while Level 3 tightens that to 10%. So a “pass” does not mean the system is easy on genuine users. It means it stayed under that ceiling during the test.
Two details are easy to miss. First, iBeta issues a confirmation letter that testing conformed to ISO/IEC 30107-3. iBeta itself states that this does not amount to a product certification. Second, a lab tests the exact app version, device set and settings that the vendor submitted. If the vendor later changes the model or the threshold, the letter describes a system you are no longer running.
NIST runs a separate track. Its Face Analysis Technology Evaluation (FATE) for PAD benchmarks algorithms on a common image set. According to NIST IR 8491, published in September 2023, the first round measured 82 passive, software-only PAD algorithms. That is a benchmark, not a pass or fail certificate. Note also that NIST’s better-known FRVT 1:1 evaluation measures face matching accuracy, not liveness.
What a PAD Certificate Does Not Cover: Injection and Deepfakes
A PAD test covers attacks that pass through the camera lens. That is the whole scope of ISO/IEC 30107-3. The mobile profile, ISO/IEC 30107-4:2024, makes the same point. Its scope is limited to attacks at the capture device, and the standard places every other attack outside it.
Fraud in 2026 often skips the lens entirely. In an injection attack, the fraudster feeds a video file or a live deepfake into the app through a virtual camera, an emulator or a hooked SDK. The liveness model then analyses footage that a camera never captured. A system can hold a strong PAD result and still accept that feed, because the test never tried it. Our deepfake guide compares injection vs presentation attacks in more depth.
The standards bodies have noticed. CEN approved CEN/TS 18099 in October 2024, the first specification for testing biometric injection attack detection. ISO has since opened a matching project, ISO/IEC 25456, which uses the CEN document as its starting text. Until that work matures, injection resistance rests on vendor evidence rather than on a widely recognised certificate.
Three gaps sit outside a typical PAD letter:
- Injected media. Virtual cameras, emulators and tampered apps that bypass the sensor.
- Synthetic faces. AI face swaps and generated faces, which need a deepfake detection model rather than a PAD model alone.
- Your own conditions. Low light, older Android phones and slow networks, which may differ from the lab’s device list.
Questions to Ask a Liveness Vendor About Presentation Attack Detection
Start with the evidence, then ask about everything the evidence leaves out. These questions work for procurement reviews at banks, e-wallets and lenders alike:
- Which lab tested you, at which level, and when? Ask for the letter itself, then check the date and the product version.
- What were APCER and BPCER at your production threshold? Results at a demo threshold do not tell you what your users will experience.
- Which PAI species were tested? Prints and replays only, or masks too?
- Was the test active or passive liveness? The two flows differ, so a result for one does not transfer to the other. See our comparison of active and passive liveness detection.
- How do you detect injection? Ask how the SDK handles virtual cameras, emulators, rooted devices and hooking tools.
- How do you detect deepfakes? A separate model with its own evidence should answer this, not the PAD result.
For context, here is how Verihubs answers the last three. Its liveness detection supports both active and passive checks against photos, videos and masks. The product page lists NIST FATE PAD evaluation among its credentials. For injection and synthetic media, the VeriSecure SDK combines active liveness and deepfake detection, and it also adds emulator, root, Frida and injection checks on the device. That split reflects the point of this article: PAD evidence covers the lens, while the rest needs its own controls.
Frequently Asked Questions About Presentation Attack Detection
What is presentation attack detection?
Presentation attack detection (PAD) is the technology that decides whether a biometric sample came from a live person or from an artefact. In face verification, it flags printed photos, screen replays and masks held up to the camera. ISO/IEC 30107 defines the terms and the testing method.
What is the difference between APCER and BPCER?
APCER measures attacks wrongly accepted as genuine, reported per attack type. BPCER measures genuine users wrongly rejected as attacks. Because a stricter threshold lowers one and raises the other, you need both rates at the same threshold to judge a result.
Is iBeta Level 2 better than Level 1?
Level 2 tests against more expensive masks, longer preparation and attackers with moderate expertise. So it is the harder test. Still, both levels only cover physical attacks at the camera, and neither one tests injection or deepfakes.
Does ISO/IEC 30107-3 cover deepfakes?
No. ISO/IEC 30107-3 covers attacks presented to the capture device. Deepfakes fed through virtual cameras or emulators fall outside its scope. CEN/TS 18099, approved in October 2024, is the first specification for testing injection attack detection.
Is presentation attack detection the same as liveness detection?
In practice, people use the terms almost the same way. Liveness detection is the product feature, while PAD is the formal term in ISO/IEC 30107 for the detection task and its testing. A liveness check also needs injection and deepfake controls to cover attacks that skip the camera.
Who certifies presentation attack detection?
No single body certifies PAD. Accredited labs such as iBeta test products against ISO/IEC 30107-3 and issue confirmation letters. NIST benchmarks algorithms in its FATE PAD evaluation, and certification schemes such as FIDO’s biometric programme include their own PAD requirements.
Presentation Attack Detection Results Are Evidence, Not a Guarantee
A PAD letter is useful because it is narrow. It tells you that, on a given date, a lab tried a defined set of physical attacks against a specific build and recorded both error rates. That is real evidence, and it beats any accuracy figure a vendor reports about itself.
The mistake is reading it as a general fraud certificate. The fastest-growing attacks against eKYC now arrive through injection and synthetic video, and no PAD test touches those. So treat presentation attack detection as one layer you can verify on paper, then ask separately how the other layers are tested.
Planning a liveness review for onboarding or step-up checks? Talk to the Verihubs team about how VeriSecure handles presentation, injection and deepfake attacks in one flow.
