From first conversation to final report
Every PAD evaluation follows a structured, transparent process designed to deliver independent, defensible results. Here’s what to expect at each stage of an engagement with Ingenium.
Structured by design. Valuable at every step.
A high-quality PAD evaluation is built on more than the testing itself. Careful planning, controlled execution and rigorous analysis all contribute to producing results that are objective, repeatable and meaningful.
While every engagement is tailored to the system being evaluated, the overall process remains consistent. From initial scoping through to reporting and follow-up, each stage is designed to ensure the evaluation reflects your deployment, your risks and your assurance requirements.
The engagement process
The nine stages of an Ingenium PAD engagement
Stage 1: Discovery
Purpose: Understand the biometric system, its deployment environment, user population, threat model and any regulatory or procurement requirements. This ensures the evaluation is designed around the risks that matter, rather than applying a generic testing approach.
Outcome: A shared understanding of the system, its intended deployment and the level of assurance required.
Stage 2: Proposal and scoping
Purpose: We design a tailored evaluation based on what we have learned. This includes selecting the appropriate test tier (Levels 1 to 5), defining the mix of presentation attack species across Level A, B, and C sophistication, defining the number of genuine test subjects, specifying devices, and agreeing commercial terms. Nothing proceeds until scope is agreed and understood by both parties.
Outcome: A written proposal that makes your PAD programme legible. It sets out what will be tested, at what level of coverage, using which attack species, the volume of genuine subjects and why. For many organisations, this document becomes an internal reference point for communicating the rationale for testing to stakeholders who were not in the room.
Stage 3: Kick-off
Purpose: We align on practical working arrangements: access requirements, data flows, points of contact, confidentiality, and timelines. We establish how transaction log data will be shared, methodology for interpreting data, and confirm the agreed SDK, app or browser version and system device configuration to be used in testing.
Outcome: A shared operating framework that removes ambiguity from the process. For regulated organisations, this is also when we establish how findings will be documented and what level of detail your compliance or legal team will need.
Stage 4: Environment setup and QA
Purpose: We configure the test environment and conduct quality assurance checks to validate the setup before testing begins. This includes confirming device readiness, verifying software versions are baselined under change control, and ensuring all attack instruments and subject cohorts are prepared and assigned unique identifiers.
Outcome: Confidence that results will be defensible. If the test environment is not correctly configured, results cannot be relied upon. This stage protects the integrity of everything that follows, and it is where corners are never cut.
Stage 5: Test launch (entry gate)
Purpose: A formal checkpoint. We confirm that all conditions are met, all parties are ready, and all prerequisites are satisfied before live testing begins. If anything is not right, we pause, not proceed.
Outcome: An independent quality control mechanism that protects the validity of your results. The entry gate exists because a compromised test produces compromised evidence, and compromised evidence is worse than no evidence at all.
Stage 6: Test execution
Purpose: We conduct rigorous testing aligned to your agreed scope and tier. Each presentation attack instrument is presented to the biometric sensor multiple times to reduce the likelihood of one-off errors. Testing covers both APCER transactions, using attack instruments spanning Level A, B, and C species, and BPCER transactions, using live subjects from a diverse cohort representing a range of ethnicities, ages, and genders.
Outcome: Empirical evidence of how your PAD subsystem performs under laboratory and real-world conditions. Not a theoretical assessment. Not a vendor-controlled benchmark. A reproducible, methodologically sound record of how your system behaves against the presentation attack methods and genuine users operating today.
Stage 7: Test completion (exit gate)
Purpose: A structured close to the testing phase. We verify completeness, confirm expected vs. achieved test volume, validate the integrity of the transaction log, and formally conclude the live testing period. Nothing moves to analysis until the test is exited successfully.
Outcome: An unambiguous endpoint. For organisations operating in regulated environments, the exit gate creates a clear audit trail, confirming when testing concluded and that all agreed activities were completed before analysis began.
Stage 8: Analysis and reporting
Purpose: We analyse the full dataset and produce a detailed report covering APCER and BPCER results by attack species and device type, alongside conclusions and recommendations. Reports are structured to serve multiple audiences, from technical teams who need granular metrics to executive stakeholders and regulators who need clear conclusions.
Outcome: A report that works as hard as the testing did. Findings are presented with the evidence to support them, the context to interpret them. For vendors, this document becomes part of your product’s independent assurance story. For buyers, it becomes the foundation for procurement decisions, regulatory conversations, and internal risk management.
Stage 9: Results presentation and ongoing support
Purpose: We present findings directly, answer questions, and support you in communicating results, whether internally, to regulators, to procurement partners, or to the market. We do not hand over a report and disappear.
Outcome: An expert partner in the room when the results matter most. We understand how regulators read test data and metrics. We understand what procurement teams need to see. The value of a test report is only realised if the findings are understood and acted upon. This stage is where that happens.
Testing is not a one-time event
Presentation attacks continue to evolve, and so do biometric systems. Software updates, new devices, changing deployment environments and emerging attack techniques can all affect PAD performance over time. Many organisations return to Ingenium to evaluate new software releases, assess resilience against newly developed presentation attack instruments, or increase the level of assurance as their systems, user base or risk profile evolve.
Your first PAD evaluation establishes a baseline. Each subsequent evaluation builds on that evidence, helping you maintain confidence that your system continues to perform as expected in an evolving threat landscape.
Practical details
Ingenium typically requires a four-week lead time from contract award before test execution begins. Once the agreed system, devices or access arrangements have been received, testing typically starts within five working days.
The overall duration of an evaluation depends on the agreed scope, including the testing tier, number of devices, presentation attack coverage and any bespoke project requirements. A detailed project timeline is agreed during the scoping phase.
What your system passed yesterday may not be what it faces tomorrow.
Whether you are evaluating a system for the first time, preparing for regulatory scrutiny, or looking to go further than your current programme allows, we will begin where it makes sense: with a straightforward conversation about your objectives, your systems, and what you need to know.