- News
The build vs. partner decision every digital identity product team is facing
ㅣ
Sean Scully
The hardest part of the eIDAS 2.0 build vs. partner decision isn't the technical complexity. It's realising the decision isn't really a technical one. It's a product strategy call, and it needs to be made before your engineering team has even started scoping.
Here's why that matters, and what it actually takes to get it right.
The deadlines are closer than your roadmap suggests
You know AML-R and eIDAS 2.0 are coming. Your clients probably know it too. The question is whether your product will be ready when they come asking, and that conversation is closer than most identity product teams think.
The July and December 2027 deadlines for AML-R and eIDAS 2.0 respectively sound comfortable until you do the math. Building compliant support for eID-based verification from scratch typically takes 18 to 24 months. And that's before you account for the complexity of connecting to 27 different member state trust registries, each with its own technical requirements, credential formats, and accreditation process.
If your roadmap doesn't have this scoped and resourced today, you're not ahead of the deadlines. You're already behind them.
This isn't a European problem
Here's where a lot of identity product teams make a costly assumption: AML-R and eIDAS 2.0 are EU regulations, so they're someone else's problem.
They aren't. Not if your clients operate in Europe, and the vast majority of enterprise clients in banking, fintech, crypto, telecom, and payments do. By December 2027, those businesses will be legally required to accept EUDI Wallet-based identification. They'll be looking to their identity verification provider to make that possible. If you can't support it, they may look for one who can.
For product managers, the risk isn't just technical. It's competitive. The clients you've spent years onboarding will have a reason to evaluate alternatives, and your competitors are already having those conversations.
What "ready" actually means for your product
Supporting AML-R and eIDAS 2.0 isn't a feature update. It's a new category of verification, and understanding that distinction is the most important thing a product team can internalise before making the build vs. partner call.
The traditional document-based model — passport upload, liveness check, manual review — gets supplanted by something fundamentally different: cryptographically-signed identity attributes, issued by government authorities, presented directly from a user's wallet. There's no document. There's no image. There's a signed credential and a trust framework that either recognises your platform or doesn't.
To accept that, your product needs to connect to the trust registries of each EU member state you want to support, handle credential formats and protocols specific to decentralised identity — ISO 18013-5, SD-JWT, OpenID4VP — pass and maintain accreditation as a relying party within the eIDAS trust framework, and stay current as standards, wallet versions, and implementing acts continue to evolve.
That's a significant and permanent engineering and compliance surface. And it doesn't get smaller over time. It gets larger as wallet adoption grows and more member states roll out their implementations. A product manager who scopes this as a one-time integration is scoping the wrong thing.
Start with what already exists
The EUDI Wallet isn't fully deployed yet. But the eID infrastructure it builds on largely is. BankID in Sweden and Norway, itsme in Belgium, SPID in Italy, MitID in Denmark, France Identité in France, Personalausweis in Germany, these are government-issued digital identity schemes already used by tens of millions of Europeans. From a user experience standpoint, they work very similarly to how the EUDI Wallet will work.
Identity product teams that integrate national eIDs today aren't just preparing for 2027. They're unlocking real value now: better conversion rates, lower fraud risk, faster onboarding in markets where eID adoption is already high. They're also building the product muscle: the flows, the trust framework integrations, and the internal knowledge that makes EUDI Wallet support significantly less painful when the moment arrives.
For product managers, this is the most underused lever available right now. The path to 2027 readiness doesn't have to start with a 24-month build. It can start with a working integration in a single high-adoption market, and expand from there.
The build vs. partner decision and when to make it
This is the call that defines your product's trajectory for the next three years. And it needs to be made at the product strategy level, not handed to engineering to scope first.
Here's why that sequencing matters: once scoping starts, organisational momentum builds in the build direction. Estimates get produced. Resources get discussed. By the time engineering comes back with a 20-month timeline, you're already politically committed, even if the numbers don't support it. The partner conversation never gets a fair hearing because it was never properly opened.
So make the call deliberately, before the scoping starts, with both options genuinely on the table.
Building in-house gives you control and keeps the capability inside your product. It also means owning the full technical, regulatory, and operational complexity indefinitely. Standards evolve. Implementing acts get updated. New member states add national variations. That's not a one-time integration, it's a permanent engineering commitment with a compliance dimension that most product teams aren't currently staffed to maintain.
Partnering with an infrastructure layer purpose-built for this problem means working with an organisation that already holds the trust registry connections, handles the standards compliance, and absorbs the ongoing maintenance as the regulation matures. Under the eIDAS 2.0 Architecture Reference Framework, this role is formally defined as an Intermediary which is an organisation that acts on behalf of relying parties to connect to wallets and request user attributes.
For most identity product teams, the intermediary model doesn't replace your product. It extends it. You stay in the verification layer your clients already rely on. You add eID and wallet support without rebuilding your stack from the ground up, and without inheriting the compliance surface that comes with it.
The question worth asking now
If your most important enterprise client called today and asked whether your platform supports AML-R and eIDAS-compliant eIDs, what would you say?
If the honest answer is "not yet," the next question is how quickly that changes, and whether that change is going to be driven by a build decision your team hasn't fully costed, or a partner integration that could be live in weeks.
The providers who move now will enter 2027 with a tested product, optimised conversion flows, and clients who never had reason to look elsewhere. The ones who wait will spend 2027 explaining why they're still 12 months away.
Hopae Connect gives identity product teams a single API to support eIDs and EUDI Wallets across Europe, without building or maintaining the trust infrastructure themselves.
See how you can go live with eID-based verification without rebuilding your stack.
