When should governments prioritise a mixed delivery model over a fully custom wallet build?

When mixed delivery becomes the better public-sector choice

Mixed delivery is the stronger option when the government’s real constraint is time-to-compliance, not a lack of policy intent. A custom wallet build makes sense only when the state must create genuinely novel service logic, local legal rules, or high-trust integration points that a baseline platform cannot cover. If the common identity mechanics already exist, reinvention usually adds delay without improving the citizen experience.

A practical way to judge the decision is whether the country is trying to solve a platform problem or a localisation problem. If the core trust layer, credential handling, and wallet lifecycle can be reused, the main value of custom work shifts to service orchestration, national branding, language, revocation rules, or sector-specific integrations. That is where mixed delivery usually wins.

One reason this model is attractive is that governments rarely get unlimited specialist capacity. Building everything in-house forces the team to own product design, security engineering, standards alignment, interoperability, and long-term operations all at once. A mixed model reduces that burden by letting the state focus on policy choices and assurance while buying or reusing the parts that are already mature.

What governments should keep custom, and what they should reuse

The most defensible split is to keep the trust architecture and citizen policy layer under government control, while reusing proven components for wallet foundations. That usually means reusing enrollment patterns, credential issuance mechanics, secure storage patterns, and interoperability building blocks, while customising eligibility logic, local document types, service journeys, and integration with domestic registers or relying parties.

This works best when the country can define a narrow set of non-negotiables. For example, the wallet must enforce national assurance rules, support local language and legal requirements, and connect to mandated public services. Everything else should be tested against a reuse question: does custom development materially change the trust model, or only the interface and administration model?

eIDAS 2.0, the EU Digital Identity Framework is a useful reference point because it shows why a common baseline matters: governments can standardise the wallet core while still preserving room for national implementation choices. Where that baseline already exists, mixed delivery is often the faster route to a compliant rollout.

How to avoid the hidden costs of a fully custom build

The hidden risk in a fully custom wallet is not only schedule slippage, it is also lifecycle drag. Once the state owns every component, it also owns every patch cycle, integration fix, security review, support escalation, and future standards update. That becomes expensive fast, especially when the wallet must remain interoperable across agencies and private-sector relying parties.

Mixed delivery reduces that burden, but only if the government avoids the common mistake of treating the vendor product as a black box. The state still needs contractual control over update cadence, assurance evidence, exit rights, logging visibility, and key policy decisions. Otherwise the apparent speed gain becomes dependency risk.

CIS Controls v8 is relevant here because the build-versus-buy decision should still be anchored in asset visibility, account management, logging, and secure configuration. A mixed model only works when those baseline operational controls are explicit, not assumed.

Risk and Threat Considerations

Mixed delivery changes the risk profile, but it does not remove it. The main exposure is concentration of trust in reused identity components, external suppliers, and integration points that sit between the wallet and the rest of the national digital stack. If those interfaces are weak, the country can inherit a fast rollout with brittle trust boundaries.

Failure mechanism: A rushed custom build can miss security and interoperability requirements, while an overreliance on reused components can hide defects in the common trust layer until they are deployed at national scale.

Impact: The result can be delayed launch, inconsistent assurance, difficult recovery, or a compromise that affects many services at once because the same wallet foundation is reused everywhere.

Practitioner Guidance

What to prioritise: Prioritise mixed delivery when the delivery risk is higher than the localisation risk. If the country can accept a standard wallet core but cannot afford a delayed rollout, the decision should tilt toward reuse plus policy customisation.

What to verify: Verify that the reused layer covers the trust mechanics you do not want to rebuild, and that the custom layer is limited to the parts that genuinely need national differentiation. If the “custom” work mainly repeats common wallet functions, it is usually a sign the scope is too broad.

Practitioner takeaway: The best mixed model is narrow on custom engineering and strict on governance, because governments gain the most when they buy time and reliability without surrendering control of policy, assurance, or interoperability.

Related resources from NHI Mgmt Group

• When should teams prioritise hosted login pages over a fully custom authentication flow?
• When should businesses prioritise co-managed IT over full outsourcing or a fully internal model?
• How should security teams prioritise NHI remediation in cloud environments?
• Should organisations prioritise external exposure or internal credential governance first?