TL;DR: National eIDAS 2.0 and EUDI wallet programmes can consume years and triple-digit million budgets when countries try to build everything themselves, while mixed delivery can shorten setup time and reuse specialist know-how, according to Procivis. The core governance lesson is that identity infrastructure is rarely a clean software project, but a lifecycle, compliance, and operating-model decision.
At a glance
What this is: This is a Procivis perspective on eIDAS 2.0 rollout strategy that says full DIY national wallet builds can become slow, expensive and operationally heavy, while mixed delivery can reduce time to implementation.
Why it matters: It matters because identity programmes fail when governments underestimate operating model, integration and governance complexity, not just the software build itself.
Context
National digital identity programmes often stall because teams treat them like a software build rather than a regulated identity and trust infrastructure programme. eIDAS 2.0 and the EUDI wallet add compliance, interoperability, and lifecycle obligations that make sourcing and operating model decisions as important as technical design.
For identity practitioners, the real question is how much of the stack should be engineered in-house versus assembled from existing components and specialist capability. That question is especially relevant where governments must align citizen identity, signatures, wallet infrastructure, and local service integrations without delaying delivery.
Procivis uses the eIDAS 2.0 rollout debate to show that a pure DIY model can become a budget and skills trap. The starting position described here is typical of large public-sector identity programmes, where mandates arrive before teams, controls, and implementation capacity are fully mature.
Key questions
A: It usually fails at the boundaries between policy, integration, and operating capacity, not in the first code release. Teams underestimate the time needed to assemble specialist knowledge, align existing systems, and keep compliance, support, and interoperability coherent across rollout phases.
Q: When should governments prioritise a mixed delivery model over a fully custom wallet build?
A: They should prioritise mixed delivery when deadlines are fixed, specialist staff are limited, or the country needs a compliant baseline faster than it can create one internally. Mixed delivery is most defensible when common identity mechanics can be reused and local policy or service integration is the real differentiator.
Q: What are the signs that a digital identity rollout is accumulating governance debt?
A: Warning signs include repeated refactoring, inconsistent assumptions across teams, slow procurement cycles, and growing dependence on a few people who understand the entire stack. In identity programmes, governance debt shows up when delivery progress keeps moving but operational readiness keeps lagging behind.
Q: How should public-sector teams decide what to keep in-house and what to reuse in eIDAS 2.0?
A: Keep in-house the policy choices, citizen experience decisions, and national trust relationships that define the programme. Reuse the common identity foundation, integration patterns, and backend capability where they do not create a local differentiation need. That balance reduces duplication without handing away control of the national model.
Technical breakdown
Why national identity wallet programmes become integration problems
A national identity wallet is not just a user app. It depends on trust anchors, issuing workflows, verifier integrations, signature support, backend services, and assurance processes that must work together under regulatory constraints. Once a country already has existing government apps and source systems, the challenge shifts from building one product to coordinating multiple identity components across a public ecosystem. That is why a wallet programme is as much about interface governance and lifecycle control as it is about software delivery. The hard part is usually not the visible front end, but the invisible interoperability and operating assumptions behind it.
Practical implication: Treat wallet delivery as an integration and governance programme, not a standalone app build.
Why full DIY increases delivery risk in identity infrastructure
Full DIY creates two compounding risks: capability build-up and rework. Teams must hire specialist talent, develop implementation know-how, and learn the regulatory and technical model at the same time they are shipping the platform. That often leads to refactoring, schedule drift, and hidden operating costs, especially where the goal is a production-grade identity service rather than a proof of concept. In IAM terms, this is a lifecycle problem, not a one-time deployment problem. The programme must sustain issuance, updates, support, and assurance long after the initial release.
Practical implication: Budget for operating maturity and rework, not only for initial development.
What mixed delivery means for eIDAS 2.0 architecture
Mixed delivery uses a shared foundation for common identity functions while reserving local effort for country-specific services, user experience, and integration detail. That model fits national identity better than a pure off-the-shelf or pure DIY stance because it recognises that some controls and patterns are reusable while local trust frameworks and service ecosystems are not. The architecture question is therefore where to standardise and where to differentiate. For identity governance teams, the practical issue is preserving compliance and interoperability without forcing every jurisdiction to recreate the same base platform from zero.
Practical implication: Standardise the common identity foundation and localise only the country-specific layers.
NHI Mgmt Group analysis
National identity delivery is an operating-model decision, not a build-versus-buy slogan. eIDAS 2.0 programmes succeed when governments decide what must be owned locally and what can be composed from shared capability. The article’s core point is that time, skills, assurance, and integration are part of the security and governance burden, not side effects. Practitioners should treat national identity delivery as a controlled ecosystem design problem.
DIY identity infrastructure creates governance debt before the first user goes live. If teams spend years assembling expertise, reworking architecture, and negotiating dependencies, the programme accumulates avoidable delay and control drift. That debt matters in identity because trust frameworks, lifecycle controls, and verifier relationships must remain coherent across the full rollout. Practitioners should measure readiness as an operating capability, not as completed code.
Mixed delivery is the realistic pattern for large-scale identity ecosystems. The article implicitly argues for a reusable base with local implementation on top, which is the same logic many identity programmes already use for federation, lifecycle governance, and service integration. The important lesson is that countries should not reinvent the foundation when the real value sits in national policy, local service alignment, and assurance. Practitioners should preserve differentiation at the edge and reuse where identity mechanics are common.
National identity stack reuse: the repeated reuse of a shared identity foundation across jurisdictions reduces duplication but increases the need for strict integration governance. That concept captures the article’s central trade-off: reuse speeds delivery, but only if countries control configuration, trust boundaries, and integration drift. For identity architects, the implication is simple. Reuse the common stack, but govern every local extension as a controlled variance.
What this signals
The practical lesson for identity programmes is that delivery architecture and governance architecture are the same decision. When governments try to separate them, schedules slip, integration complexity grows, and the wallet or credential stack becomes harder to operate than to design.
National identity stack reuse: shared components can accelerate rollout, but only if every country controls its own integration boundaries and assurance model. That is where the real programme risk sits: not in whether code is written internally, but in whether the stack can be governed consistently once it is live.
For practitioners
- Define the ownership boundary early Separate the nationally unique policy, user journey, and trust decisions from the reusable technical foundation before procurement or build work starts.
- Estimate the full lifecycle cost Model not just delivery cost but onboarding, integration, support, compliance change, and maintenance across the full rollout period.
- Test vendor and open-source fit-for-purpose Validate that any external component fits source systems, signature services, wallet flows, and national operating constraints before committing to it.
- Reserve local engineering for differentiation Use in-house effort where it improves citizen experience, local service integration, or policy control, and reuse shared building blocks elsewhere.
Key takeaways
- The article’s central warning is that national identity delivery can become slower and more expensive when teams treat it as a pure DIY build.
- The main evidence is the scale of time, skills, and integration effort required once compliance, backend services, and local systems are all in scope.
- The practical implication is to reuse common identity foundations and keep local effort focused on national policy, service design, and operating control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | National identity delivery requires explicit governance over delivery risk, timeline risk, and operating risk. |
| Recommendation — Use GV.RM-01 to define how programme risk is assessed, owned, and accepted across the identity rollout. | ||
| NIST SP 800-63 | SP 800-63C — Federation | EUDI wallet programmes depend on trust federation, interoperability, and exchange across identity systems. |
| Recommendation — Apply SP 800-63C to structure trust relationships and federation boundaries in the wallet ecosystem. | ||
| GDPR | Art.32 — Security of Processing | National identity systems process personal data and must preserve security, availability, and resilience. |
| Recommendation — Use Art.32 to require security and resilience controls across the identity processing lifecycle. | ||
Key terms
- Digital Identity Wallet: A digital identity wallet is software that stores and presents credentials for a person or organisation. It is a portability layer, not an authorization system. The wallet moves verified proof between parties, while the relying party still has to decide whether the proof is sufficient for the requested action.
- Identity Federation: Identity federation is the practice of trusting one identity system to authenticate a user or workload for another system. It reduces login friction, but it also creates a dependency on assertion trust, policy consistency, and strong control over downstream authorization.
- Operating Model: An operating model is the practical way a governance programme is run, including decision ownership, workflow design, integrations, and control boundaries. For identity security, the operating model determines whether policy intent survives real execution across human, NHI, and AI-assisted processes.
- Reference Implementation: A reference implementation is a working version of a standard or protocol used to prove how the specification should behave in practice. It helps developers test compatibility, validate new features, and understand expected behavior before building their own integrations or production systems.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and workload identity in a way that helps teams handle complex identity programmes. It is useful for practitioners who need to connect identity architecture decisions to governance and operational control.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org