Ask an engineering team how long it takes to accept an EUDI Wallet credential and you will usually get an answer scoped to the OpenID4VP request-and-verify flow: two to four weeks. That estimate is not wrong, but it measures roughly 20% of the actual project. The other 80% is regulatory registration, certificate operations, and the maintenance burden of staying conformant as the Architecture and Reference Framework evolves. This article breaks down both halves so you can compare build-in-house against using an intermediary relying party on realistic numbers.
Phase 1: Engineering effort to integrate the protocol
The protocol layer itself — issuing a presentation request, verifying an mdoc or SD-JWT VC response, checking revocation status and the issuer's presence on the EU Trust List — is genuinely tractable for a competent backend team. Expect the following if you build it yourself:
- 2-4 weeks for a working OpenID4VP request/response flow against one wallet reference implementation.
- 1-2 weeks to add signature verification, trust chain validation and revocation checks correctly, including edge cases around expired or suspended attestations.
- 1-3 weeks per additional wallet ecosystem once you need to support wallets from more than one Member State, since implementations vary in subtle but real ways despite the common standard.
- 1-2 weeks of security review and penetration testing before production, given that this flow sits directly in your identity and fraud perimeter.
A realistic in-house engineering estimate for a single-wallet, single-country pilot is 6-10 weeks of one senior backend engineer plus part-time security review. Multiply roughly by the number of wallet ecosystems and Member States you need to support in parallel.
Phase 2: Regulatory registration lead time
This is the phase almost no internal project plan accounts for correctly. To request attribute presentations from wallets, an organisation must register as a Relying Party under the national process of each Member State where it operates, which typically involves:
- Legal entity verification and submission of relying party registration documentation to the national supervisory body.
- Definition and justification of the specific attribute set you intend to request, since registration is scoped to declared use cases, not open-ended.
- Review and approval cycles that, based on comparable trust service registration processes under the original eIDAS Regulation, commonly run 6-16 weeks per Member State and can extend further during early rollout phases when authorities are still building their own processing capacity.
- Separate repetition of this process for each additional Member State where you need relying party status, since there is no single pan-European registration.
For a business operating in three Member States, national registration alone can add three to twelve months of elapsed time before you can legally request a single attribute presentation — independent of how fast your engineering team finishes the protocol work.
Phase 3: Certificate operations
Presentation requests must be signed with access certificates issued within the trust framework, and these certificates expire and must be rotated without downtime. In-house, this means:
- Establishing a certificate issuance relationship for each Member State and, in some cases, each wallet provider.
- Building rotation automation and monitoring so an expired certificate does not silently break onboarding.
- Handling revocation and re-issuance procedures if a private key is compromised or an intermediate certificate authority changes its chain.
- Repeating all of the above independently for every ecosystem you support, since certificates are not portable across trust frameworks.
This is not a one-time build. It is a recurring operational function that needs an owner, alerting, and a runbook — comparable in scope to TLS certificate management at enterprise scale, but with fewer mature tools available today.
Phase 4: Ongoing conformance maintenance
The ARF and its implementing acts are still being refined. A verifier integration that is conformant today can require rework when a new implementing act clarifies a data format, a new credential type is added to the ecosystem, or a wallet provider updates its SDK. Budget for this as a permanent line item, not a one-off cost — realistically 10-20% of the initial engineering effort per year, concentrated in unpredictable bursts rather than a steady drip.
The part everyone budgets for is the four weeks of API work. The part that actually determines your total cost of ownership is the eighteen months after launch.
Total cost of ownership: build vs. buy
Building in-house across three Member States and two wallet ecosystems over a two-year horizon typically involves:
- Engineering: 3-5 months of senior engineering time spread across initial build and cross-ecosystem variants.
- Registration: 3-12 months of elapsed calendar time and legal/compliance staff hours across multiple national processes, run largely in parallel with engineering but gating go-live.
- Certificate operations: an ongoing operational owner, typically a fraction of an FTE, plus tooling.
- Conformance maintenance: 10-20% of initial engineering cost annually, plus the opportunity cost of a team that must stay current on evolving EU technical standards.
Using an intermediary Relying Party such as Arkadiz collapses most of this into one integration and a subscription or usage-based fee: the intermediary is already registered across Member States, already operates certificate rotation, and already absorbs conformance changes centrally across all its clients. The engineering effort on your side drops to integrating a single API rather than a protocol stack, and the registration and certificate phases move from your critical path to the intermediary's, which has already cleared them once for every client it serves.
When building in-house still makes sense
Very large platforms operating across every Member State with dedicated compliance teams, or organisations for whom wallet verification is a core product differentiator rather than a supporting capability, may find the fixed cost of an in-house team justified over a long enough horizon. For most mid-sized platforms adding wallet acceptance as one identity method among several, the intermediary route reaches production faster and keeps the ongoing conformance risk off your engineering roadmap.