How should public-sector teams decide what to keep in-house and what to reuse in eIDAS 2.0?

What to keep sovereign in an eIDAS 2.0 programme

The in-house boundary should sit around the parts of the programme that define public authority, not the plumbing that can be shared safely. That includes the policy model, citizen-facing decisions about journey and assurance, onboarding rules, assurance thresholds, dispute handling, and the trust relationships the state must own directly. Those choices shape accountability and legitimacy, so they are poor candidates for blind reuse.

For the legal and operational baseline, the eIDAS 2.0 text itself is the anchor point for what Member States are expected to implement and coordinate across the European Digital Identity Framework, so programme teams should keep the interpretation and governance layer close to the ministry or competent authority that owns the national model. eIDAS 2.0, the EU Digital Identity Framework is the right reference when teams are deciding which functions are mandatory, which are nationally discretionary, and which can be standardised without losing sovereign control.

The same principle applies to the public-sector identity layer itself. NHIMG’s Public Sector Identity Security Guide is useful here because public identity programmes usually fail when they outsource policy judgement along with technical delivery. Keep the decision rights for identity proofing policy, trust assurance, and citizen access rules with the public body, even when delivery components are outsourced or centrally hosted.

What should be reused across agencies and vendors

Reuse works best in the layers where consistency creates interoperability instead of losing differentiation. Common identity foundations, integration patterns, credential and wallet plumbing, verifiable credential handling, and shared backend services are usually the right reuse targets when they can be consumed as a platform without forcing every agency into a different trust model. Reuse reduces duplicated engineering, shortens delivery time, and makes cross-border or cross-agency interoperability easier to maintain.

That does not mean every component should be centralised. Teams should separate the reusable core from the policy edge: standard protocols, schema, APIs, logging patterns, and conformance test assets can often be shared, while the user journey, legal basis, and operational thresholds remain local. The practical test is whether the component can be reused without changing who is accountable for trust decisions or how citizens experience the service.

In implementation terms, this is where a shared national platform can make sense if it preserves local governance. A common platform should expose reusable services, not absorb the national decision-making role. If a service can be reused across ministries, municipalities, and private relying parties without altering assurance rules or consent boundaries, it belongs in the shared layer.

For teams looking at the technology side of reuse, the eIDAS 2.0 framework supports exactly this kind of split: harmonise the technical and interoperability layer where possible, then let Member States preserve the parts that make the national trust model meaningful.

How to draw the line without creating duplication or lock-in

The cleanest decision rule is to ask whether a choice changes the national trust model, the citizen relationship, or the legal and accountability boundary. If it does, keep it in-house. If it mainly improves interoperability, delivery speed, or operational consistency, reuse it. This is the most reliable way to avoid the two common failure modes: overbuilding bespoke national stacks and over-centralising the parts that should remain sovereign.

Teams should also watch for hidden dependency drift. A component that begins as reusable infrastructure can become de facto policy if the team stops challenging its defaults. That is where reuse turns into lock-in, because the technical platform starts deciding experience, data handling, or assurance posture by accident rather than by mandate. The governance model needs explicit review points so reused services remain subordinate to the programme, not the other way around.

Where cross-agency harmonisation is the goal, reuse should be paired with a clear exception process. If an agency needs a different citizen journey or assurance path, the reason should be explicit, temporary where possible, and tied to a real legal or operational need. That keeps reuse from becoming an excuse for uniformity, while still preventing every team from rebuilding the same core capability.

Risk and Threat Considerations

Public-sector identity reuse concentrates trust, so the main risk is that a weak shared layer can amplify into many services at once. If a reused integration pattern, wallet service, or backend credential path is misconfigured or compromised, the impact can spread quickly across agencies, vendors, and relying parties. The other risk is strategic: if the state outsources the wrong layer, it can lose practical control over the citizen trust model.

Failure mechanism: A shared service, default integration pattern, or centrally managed trust component becomes a high-value failure point, and its compromise, misconfiguration, or bad default propagates across multiple programme participants.

Impact: The result can be wider service disruption, inconsistent trust decisions, reduced national autonomy over identity policy, and harder recovery because many downstream services inherit the same weakness.

Practitioner Guidance

What to prioritise: Define the sovereign boundary first, then map every component into one of three buckets: policy, reusable platform, or local exception. If the component determines assurance, consent, or trust acceptance, it belongs in the sovereign bucket even when delivery is outsourced.

What to verify: Check that reused services do not encode hidden policy choices in defaults, workflow constraints, or integration assumptions. If the reused layer can change citizen experience or trust decisions without a formal national decision, the boundary is wrong.

Trade-off: More reuse improves speed and consistency, but only when it does not flatten legitimate national differences. The best programmes standardise interfaces and infrastructure while preserving the authority to vary the trust model where the law or public policy requires it.

Practitioner takeaway: The right balance is not “build everything yourself” or “reuse everything,” but “own the trust decisions, reuse the machinery.” That is the difference between a national identity programme and a shared platform that quietly starts making national choices.

Related resources from NHI Mgmt Group

• Guide: Digital Identity, eID and Identity Wallets Guide
• How should security teams decide which SOC functions to keep in-house?
• How should public sector teams implement low-code platforms when requirements keep changing during digital transformation programmes?
• How should public sector security teams decide between PTaaS and bug bounties when budgets are uncertain?
• How should ecommerce teams decide what to keep in-house versus outsource as they scale operations?