Testing quality
Not all testing is created equal
Having your biometric and identity systems tested is a meaningful step. What determines whether that testing is genuinely protective is how it is designed, what it tests against, and whether it reflects the threats your systems actually face in practice.
The variables that determine what testing tells you
The quality of a biometric and identity testing programme is determined by several interconnected factors. Understanding them is important both for evaluating what you have received and for specifying what you actually need.
Currency of attack methods
A testing programme is only as current as the attack methods it deploys. Threat actors continuously develop new instruments and delivery mechanisms. Testing conducted against last year's attack species will not reveal vulnerabilities to this year's methods. labs that invest in ongoing threat intelligence and methodology development will produce different results to those that do not.
Breadth of coverage
The number of Injection Attack Methods (IAMs) and Injection Attack Instruments (IAIs) tested determines the range of threat scenarios a system is evaluated against. A programme covering two IAMs and ten IAIs leaves measurable gaps in coverage compared to one covering a broader spread. Those gaps correspond directly to threat scenarios the system has not been evaluated against.
Depth of methodology
How testing is designed and executed matters as much as what is tested. Empirical testing under laboratory conditions, with reproducible metrics and documented methodology, produces findings that can withstand regulatory scrutiny, independent review, and comparison over time. Process-based assessments and desk audits serve a different purpose.
Independence of the laboratory
A laboratory without commercial relationships to the vendors whose products it tests produces findings that are structurally free from influence on the outcome. That independence is the source of the report's credibility, for internal risk decisions, regulatory conversations, and market-facing claims alike.
The limits of minimum-threshold testing
Compliance-level testing is testing designed to meet the minimum requirements of a published standard and has clear value. It produces a defined, auditable result against a recognised benchmark. It is the right starting point for many organisations.
What it does not do is evaluate system resilience beyond that benchmark. A system that passes CEN/TS 18099 Substantial testing has been evaluated against the IAMs and IAIs required by that level. It has not been evaluated against the additional methods and instruments that more sophisticated threat actors are currently deploying.
For organisations operating in high-risk environments, processing sensitive personal data, or facing well-resourced adversaries, minimum-threshold testing may leave meaningful gaps in their assurance picture.
The question is not whether minimum-threshold testing is legitimate. It is. The question is whether it is sufficient for your specific risk profile.
Independent. Current. Scientifically rigorous.
We invest in staying ahead of the threat
Ingenium maintains active partnerships with public sector bodies, academic institutions, and international standards working groups. These relationships give us access to emerging attack methods and threat intelligence before they appear in commercial attack toolkits or published standards. Our testing programmes are updated continuously, not on the publication cycle of standards documents.
What academic and research institutions contribute in terms of deep research and scientific advancement is not always matched in speed and practical deployment. Buyers and vendors require commercial-scale testing that meets their stakeholder needs and keeps pace with the rate of technological change. That is what Ingenium is built to deliver.
We test as attackers behave
Our methodology is designed around genuine adversarial behaviour, not idealised conditions. We design test scenarios that reflect how organised threat actors actually approach systems: using multiple methods in combination, iterating when initial approaches fail, and targeting the layers of the stack most likely to yield results.
We measure with scientific rigour
Our results are empirical, reproducible, and generated under ISO/IEC 17025 accredited laboratory conditions. That means findings that can be presented to regulators, referenced in procurement processes, and used as a meaningful baseline for assessing change over time.
We report with clarity
A test report should tell you what the findings mean, not just what they are. Ingenium’s reporting is structured to support specific downstream uses, whether that is an internal risk conversation, a regulatory submission, or a market-facing claim about system performance.
The credibility that vendor testing alone cannot provide
Vendor testing is testing conducted by or for a technology provider. It plays a legitimate role in product development and is part of how good products are built.
It is not, however, independent. When a vendor tests their own product, the methodology, conditions, and reporting are all within their control. That is not a criticism of any particular vendor, it is a structural feature of how vendor testing works.
Independent testing introduces a layer of external scrutiny that vendor testing cannot replicate. For buyers assessing a product, independent results produced by an accredited laboratory carry different weight to vendor-provided documentation, because the interests of the testing party are different.
For vendors, that distinction is a commercial opportunity: independent testing results are credentials that differentiate a product in ways that compliance certification alone cannot.
The question isn't whether to test. It's how thoroughly.
If you’d like to understand how the quality and coverage of your current testing compares to what your risk profile requires, or how independent testing can strengthen your market position, our team is here to help.