A build estimate for biometrics usually prices one thing, the first release. Your team scopes the liveness model, the face matcher, the SDK, and a launch date, and the number might look manageable. Then the running costs arrive, in lab fees, platform updates, retests, and new attacks. If you lead product or engineering at an IDV provider weighing build vs buy biometric verification, this post walks through the full cost of ownership, and gives an honest answer on when building still wins.

In a Nutshell

• A certified biometric layer takes research, attack data, and accredited lab testing against ISO/IEC 30107-3, CEN/TS 18099, and ISO/IEC 19989-3.
• The capability has to work, and be evidenced, on iOS, Android, and web, which multiplies most of that effort by three.
• ETSI TS 119 461 requires presentation and injection attack detection to be tested by an accredited laboratory every second year, and your regulated customers will expect that evidence from you.
• Deepfake and injection techniques keep moving, so defending against them is a standing research program with its own budget line.
• Building still makes sense for a few vendors. For most, embedding a certified biometric engine is faster to market and cheaper to run.

The car you can buy but cannot afford to run

Nobody budgets for a car by looking only at the sticker price. You ask what it costs to insure, how thirsty it is, and when it needs servicing. Biometric verification deserves the same questions, and a first-release estimate rarely asks them.

The first release is the purchase. It covers building a liveness model, a face matcher, capture flows, and an SDK your platform can call. That work is real, and a capable team can do it. What sits outside most estimates is everything that keeps the capability credible and effective once it ships.

For an IDV provider selling to banks, fintechs, and trust service providers, that list is long and recurring. The capability has to be certified by an accredited lab against the standards your customers' regulators reference. It has to keep working on iOS, Android, and web, each of which updates on its own timetable and can change how the camera behaves. It has to be retested every two years. And it has to keep up with deepfake and injection techniques that change far faster than any two-year cycle.

None of those costs appear on day one. All of them are permanent. The rest of this post takes each one in turn, so you can put a realistic number next to your build estimate before you commit to it.

What does building a certified biometric layer actually take?

Start with the engineering. A compliant flow needs presentation attack detection (PAD) to catch fakes shown to the camera, such as printed photos, screen replays, masks, and deepfakes played on a display. It needs injection attack detection to catch content fed straight into the capture pipeline through virtual cameras, emulators, or tampered SDKs. It needs 1:1 face matching accurate enough to bind a person to their identity document. And because ETSI TS 119 461 treats injection as an attack on the data capture process as a whole, the document capture path needs the same protection as the face.

Each of those models needs data. That means diverse, consented face data collected in line with GDPR, and a steady supply of attack samples, from printed photos and 3D masks to fresh deepfakes, to train and test against. Building that library is a project on its own.

Then comes the proof, which is where build estimates tend to thin out. Your customers will ask for accredited test reports before they sign, and three standards carry most of the weight.

• ISO/IEC 30107-3 sets the methodology for testing and reporting presentation attack detection. It is the tested foundation most of the market certifies against.
• ISO/IEC 19989-3 covers the security evaluation of biometric PAD using Common Criteria methodology, with attack potential levels defined through ISO/IEC 19989-1.
• CEN/TS 18099 covers biometric data injection attack detection, the threat surface that PAD alone does not address.

ETSI TS 119 461 lists all three among its normative references. Getting certified to them means preparing a target of evaluation, booking an accredited lab, running the evaluation, fixing what it finds, and often testing again. At the higher levels, the lab tests against attackers with more expertise, better equipment, and more time.

Put together, the team you need spans machine learning research, security engineering, mobile and web development, and certification management. Reaching a first certificate usually takes several rounds of building, testing, and fixing, so plan for a sustained program rather than a single release.

The three-platform tax, iOS, Android, and web

Your customers' users will arrive on whatever device they have. So the capability has to work on iOS, on Android, and in the browser, and each of those is a different vehicle to maintain.

The camera APIs differ. So does the attack surface. On Android, rooted devices, emulators, and virtual camera apps are common injection routes. iOS is more locked down, but jailbroken devices open similar doors. In the browser, virtual webcam software and tampered media streams are the usual way in. Capture hardening that works on one platform does not carry over automatically to the next, so each needs its own engineering, its own testing, and its own evidence.

Certification follows the same logic. A lab tests the specific product, version, and platforms it is given, and its report records them. If your web SDK was not part of that test, the report says nothing about it, and your customer's auditor will spot the gap.

The platforms also keep moving. Apple and Google each ship a major OS release every year, and browsers update every few weeks. Every one of those can change camera behavior, permissions, or the tools attackers use. A vendor that owns biometrics in-house owns the regression testing for all three, indefinitely.

The mandatory service every two years

Regulated identity proofing now comes with a mandatory retest. ETSI TS 119 461 v2.1.1, published in February 2025, sets out how identity proofing meets the requirements of Article 24 of eIDAS 2.0. In clause 4.5 it states that it "requires an IPSP's means for biometric injection attack detection and presentation attack detection to go through independent testing by an accredited laboratory every second year." The same clause sets the first independent testing for before the end of 2026.

If your platform does the identity proofing for a QTSP or another regulated customer, that obligation reaches your roadmap. Your customer has to show current, independent test results for the biometrics in its flow, and when those biometrics are yours, the evidence has to come from you. Separately, eIDAS Article 20 requires QTSPs to be audited by a conformity assessment body at least every 24 months, so your customers will be asking on a regular cycle.

If you build in-house, you own the retest. Every two years you prepare the current version of your product, book lab time, go through the evaluation again, and remediate whatever the lab finds. The product you submit in 2028 will not be the one you certified in 2026, because you will have spent those two years updating it against new attacks and new OS releases.

This is the line most build estimates leave out entirely. It is also the one that never goes away.

What does keeping pace with deepfakes cost?

ENISA's work on remote identity proofing has documented how attacks on remote onboarding have moved from photos and replays toward deepfakes and injected video streams. Those tools get cheaper and better every few months. A model that performed well at certification can meet attack techniques a year later that did not exist when it was tested.

ETSI TS 119 461 anticipates this. It expects the provider to run a documented and effective threat intelligence process that keeps the service adapted to new threats. In practice, that means a standing research effort. Someone has to track new attack tools, generate fresh attack samples, retrain and validate models, and ship the updates across all three platforms without breaking the user experience or the pass rate for genuine users.

That work does not end, and it does not scale down when budgets tighten. If anything, it grows as attackers industrialize. For a vendor whose core business is running an identity platform, it is a second business to fund alongside the first.

When does building still make sense?

Building is sometimes the right call, and it is worth being clear about when.

It can make sense if biometrics is your differentiator. If you plan to compete on your own models and put biometric research at the center of your roadmap, owning it end to end is part of the business model.

It can make sense if you already have the bench. A team that runs its own ML research, has an established relationship with accredited labs, and has budgeted for retesting and threat research over many years is buying something it already knows how to maintain.

It can make sense if your scope is narrow. A single-platform, lower-assurance use case, with no customers doing regulated identity proofing under ETSI TS 119 461, carries far less certification weight.

And many vendors land on a middle path. They own the parts that define their platform, such as orchestration, the user journey, risk rules, and decisioning, and they embed a certified biometric engine underneath, under their own brand. That keeps control where it creates value and moves the upkeep to a supplier whose job is to carry it.

If none of those describes you, the lifetime math usually favors embedding.

Where Youverse stands

At Youverse, we build the biometric engine that sits inside your identity platform, so you do not have to carry its upkeep. YouLive handles liveness and anti-spoofing, YouFace handles 1:1 face matching, and YouAuth handles returning-user authentication. Our presentation attack detection is certified to ISO/IEC 30107-3 at Levels 1 and 2, and our face matching is NIST-recognized. We are aligned with CEN/TS 18099 and ISO/IEC 19989-3, with certification to both in progress, and we are pursuing CEN/TS 18099 at High. Injection attack detection covers both the face and the identity document, as a capability aligned with CEN/TS 18099.

You embed those components through developer-first SDKs and APIs across iOS, Android, and web, white-labeled in your own flows. We carry the independent testing and the two-year re-evaluation that ETSI TS 119 461 sets, and you pass our evidence straight to your customers. Youverse is compliant with GDPR, CCPA, and PSD2.

If you have a build estimate on the table, bring it and we will walk through the lifetime costs together. Start a partnership conversation.

FAQ

How long does it take to build certified biometrics in-house?

There is no standard timeline, and it depends on scope and starting point, but expect a sustained program rather than a single release. The work covers presentation and injection attack detection, face matching, attack data collection, and hardening on iOS, Android, and web. Accredited lab evaluation against ISO/IEC 30107-3, ISO/IEC 19989-3, and CEN/TS 18099 then adds its own cycles of testing and remediation.

How often does ETSI TS 119 461 require recertification?

ETSI TS 119 461 v2.1.1 requires the means for presentation attack detection and injection attack detection to be tested independently by an accredited laboratory every second year, as set out in clause 4.5. The first independent testing is due before the end of 2026. If your biometrics sit inside a regulated customer's identity proofing, expect that customer to ask you for current results on that cycle.

Do I need certification on iOS, Android, and web separately?

A lab evaluates the configuration it was given, so your evidence needs to cover every platform you ship. Each platform has its own camera stack and its own injection routes, which is why each needs its own hardening and testing. Confirm the scope of any certificate, yours or a supplier's, before you offer it to a customer.

When is building biometrics in-house the right call?

Building makes most sense when biometrics is your differentiator, when you already run research and lab relationships, or when your scope is narrow and outside ETSI TS 119 461. Many vendors choose a middle path, owning orchestration, the user journey, and decisioning while embedding a certified biometric engine. For most IDV providers, embedding costs less over the product's lifetime.