How do you test Presentation Attack Detection (PAD)?

What a good PAD test is actually proving

A useful PAD test is not just a demo of whether one spoof works once. It is an exercise in showing that the detector resists realistic presentation attack while still accepting legitimate users under normal operating conditions. That means testing the whole capture path, not only the model output, because camera quality, lighting, presentation medium, and device settings can all change the result.

The test should cover more than the obvious spoof class. Printed photos, phone or tablet replays, screen glare, partial face coverings, masks, and camera injection paths can stress different failure modes, so a narrow test suite can create false confidence. The most valuable result is evidence that the system behaves consistently across the environments where it will actually be used, not just in a lab setup.

A strong test also separates attack resistance from user experience. A detector that rejects every risky input but also blocks too many genuine users will fail operationally, especially in remote onboarding or step-up verification flows. For that reason, practitioners should measure attack detection and false reject behavior together, then interpret both against the business threshold for the journey being protected. Biometric Authentication and Verification Guide is useful here because it ties liveness and presentation attack detection to the broader biometric verification pipeline.

How to structure the test so it is repeatable

Start with a controlled matrix of attack types, capture conditions, and device classes. A repeatable PAD test usually includes multiple spoof media, several lighting conditions, different camera types, and both still and moving targets. If the system is used remotely, include the actual onboarding device mix, because a detector that looks strong on one sensor often degrades on another.

Use the same identity journey the production flow will use, including enrollment, verification, retry logic, and any fallback or escalation path. That matters because PAD sometimes fails at the edges: a spoof may be blocked by the detector, but a weaker bypass path may still allow fraud through a manual review, alternate factor, or customer support workflow. Testing should therefore include the surrounding process, not just the PAD decision itself.

It is also worth repeating tests after firmware, model, threshold, or SDK changes. PAD systems can drift when image preprocessing, sensor drivers, or model calibration changes, even if the underlying product name has not changed. Identity Proofing and KYC Guide is relevant because it connects liveness testing to the broader assurance model used in remote onboarding and account opening.

When the journey is customer-facing, the test plan should also reflect assurance requirements, because PAD is only one control in the evidence chain. A well-run test records whether the system rejects spoofing, whether it accepts genuine users at an acceptable rate, and whether operational staff can explain and reproduce the result when a dispute or fraud review occurs.

What to look for in the results

Review the logs first, then the thresholds, then the bypass paths. Logs should let you see when a rejection was caused by PAD, when a fallback was triggered, and whether the event was tied to a particular device or environment. If you cannot trace those steps, you may have a working control with poor observability, which is usually hard to operate and even harder to audit.

Threshold tuning deserves special attention because PAD often trades security for usability. Lowering the threshold can reduce false rejects but increase attack acceptance, while tightening it can improve spoof resistance at the cost of more friction for real users. The right setting depends on the risk of the transaction, the quality of the sensor, and how much manual review the business can absorb.

SANS Security Resources is a practical source for detection and incident-handling thinking, which helps when PAD results need to be interpreted as operational evidence rather than as a one-time validation exercise. For attackers, the attractive failure mode is simple: find the path where spoof rejection is weak, then use the weakest journey step, not necessarily the most sophisticated attack.

The most useful comparison is between attack success rate and legitimate-user acceptance across conditions. If spoof resistance only holds in one lab setup, the control is not production-ready. If genuine users fail more often under low light, motion, or poor device quality, the rollout needs tighter device requirements, better capture guidance, or a different assurance step.

Practitioner Guidance

What to verify: Confirm that your PAD test covers the real capture stack, including the exact app, device class, camera path, and fallback logic used in production. A detector that works in a narrow demo but fails under real lighting or on real mobile hardware is not operationally reliable.

Decision rule: If the system can be bypassed by a practical spoof medium, treat that as a control failure even if the model performs well on other attack types. If false rejects climb sharply when conditions are imperfect, tune the journey or step-up policy rather than assuming the detector alone can absorb the variance.

What practitioners underestimate: The biggest weakness is often not the PAD model itself but the surrounding process, especially retries, fallback channels, and manual review paths. Those paths need the same scrutiny as the detector because attackers usually look for the easiest accepted path, not the hardest one.

Practitioner takeaway: Treat PAD testing as an end-to-end assurance exercise, not a model benchmark, and judge it by spoof resistance, user acceptance, and bypass resilience together.

Related resources from NHI Mgmt Group

• Presentation Attack Detection (PAD)
• What does presentation attack detection add that face matching does not?
• What happens when face verification is used without presentation attack detection in e-KYC?
• Why do passive liveness detection and injection attack detection reduce risk more effectively than presentation attack detection alone?