Liveness, PAD and injection testing
Liveness describes confidence that a biometric sample comes from a live person; presentation-attack detection addresses artefacts shown to a sensor; injection protection addresses manipulated media introduced elsewhere in the capture chain. Buyers should ask which problem was actually tested.
Published standards and tests cover defined scopes. A logo or headline pass does not establish protection against every attack, channel, operating system or deployed configuration.
For: security, fraud, procurement and assurance teams. This is independent information, not legal, compliance or security advice.
Three different questions
| Question | Typical control |
|---|---|
| Is a live human at the sensor? | Active or passive liveness/PAD |
| Was an artefact presented to the sensor? | Presentation-attack classification |
| Did media bypass or replace the sensor feed? | Injection, device integrity and capture-path controls |
Read the scope
- Which attack species and difficulty levels were used?
- Was the submitted production build tested?
- Which devices, cameras, browsers and SDK versions are covered?
- Are results reported at the threshold you will deploy?
- Does testing cover demographic and environmental variation?
- When must the product be retested after material changes?
Operational evidence matters
Laboratory results should be combined with production monitoring, anomaly investigation, attack intelligence, change control and rapid response. The control can also be bypassed through weak document validation, recovery or reviewer procedures.
A PAD report is not an injection-resistance report
ISO/IEC 30107-3:2023 addresses testing and reporting for presentation attacks at the biometric capture device. CEN/TS 18099:2024 addresses biometric-data injection-attack detection and test planning with a different scope. Public summaries, not the full standards, were reviewed for this update. Neither should be presented as certification of every component in an onboarding service.
Require interpretable results
- Exact product, model, SDK, platform, configuration and threshold assessed.
- Attack categories included and excluded, with genuine and attack attempt counts.
- APCER and BPCER where applicable, plus separate comparison, injection, capture-failure and abandonment outcomes.
- Laboratory, commissioning party, applicable accreditation scope and report date.
- Session binding, callback handling, fail-open behaviour and staff overrides in the integrated service.
- Retesting triggers after model, threshold, SDK, capture-flow or platform changes.
For every rate, request its numerator, denominator, exclusions and uncertainty. No accepted attack in a bounded test does not establish zero production risk.
Procurement outcome
Record a claim as narrow evidence: for example, a named version was evaluated by a named laboratory against a named test and date. Do not translate that into the unsupportable conclusion that the service is 'deepfake-proof'.
Evidence and limits
MyID separates enacted rules, official implementation material, testing and vendor claims. A source can establish what its publisher says; it does not prove that every product, deployment or interpretation works as claimed. Where Irish implementation remains unsettled, this page says so.
- ENISA Remote Identity Proofing: Attacks and Countermeasures
- NIST SP 800-63A-4 identity proofing
- NIST FATE Part 10 presentation-attack evaluation
- ISO/IEC 30107-3:2023 public scope
- CEN/TS 18099:2024 public scope summary
Sources checked 5 October 2026. Re-check the linked primary material before making a consequential decision.
In this topic: Fraud and security
How can remote onboarding and recovery be attacked and controlled?
View all 6 pages in this topic
Next useful pages
Follow the Irish evidence
Get the business briefing when Irish wallet, verification and age-assurance evidence changes.
Join the business briefing