A centrally issued wallet is provided by the state as a national identity layer, while a city-managed implementation focuses on integrating that identity into local services. The distinction matters because cities can still deliver usable access to municipal services without building the identity mechanism themselves. They need local integration, not a separate identity standard.
Why the Difference Matters in Service Delivery
A centrally issued national wallet and a city-managed digital identity implementation solve different problems. The national wallet is about the identity layer itself: issuance, trust, and citizen portability across services. A city-managed implementation is about service integration: letting municipal systems accept and use that identity without trying to become the identity authority. That distinction affects governance, procurement, interoperability, and how quickly residents can use local services without each city inventing a separate stack.
This matters because identity projects often fail when local teams confuse integration with issuance. If a city treats wallet adoption as a reason to build its own identity scheme, it can create duplicated assurance rules, inconsistent user journeys, and avoidable support burden. By contrast, if the city focuses on consuming a national trust layer, it can spend effort on the service edge, where residents actually experience the system. The eIDAS 2.0 — EU Digital Identity Framework is a useful reference point because it frames digital identity as an interoperable trust model rather than a purely local application feature.
In practice, many public-sector teams discover the difference only after they have already committed to separate local identity workflows, procurement paths, and support models.
How It Works in Practice
In a centrally issued model, the state defines the wallet, the identity assurance model, and the core trust relationships. Municipal services then verify assertions from that wallet rather than creating a parallel identity source. In a city-managed implementation, the city usually owns the user-facing service integration, consent flow, account linking, and local policy decisions, while relying on the national layer for proof of identity. That division keeps the city from becoming a second identity authority and reduces fragmentation across jurisdictions.
The practical benefit is that residents can reuse one trusted identity across multiple services, while each city still controls the service rules that matter locally. A good implementation separates:
- identity issuance, which belongs to the national trust layer;
- service enrolment, which belongs to the municipality;
- attribute consumption, which should be limited to what the service actually needs;
- fallback handling, so residents without the wallet can still access required services through alternative paths.
That separation is also why broad governance frameworks matter. The NIST Cybersecurity Framework 2.0 helps teams think about identity as part of a larger governance and resilience problem, while NHIMG’s Ultimate Guide to NHIs is a practical reminder that identity systems also fail when ownership, lifecycle, and visibility are unclear. For municipal teams, the key is not to recreate the wallet, but to define exactly which claims, tokens, or proofs are accepted at the service boundary and how exceptions are handled.
These controls tend to break down when each department negotiates its own identity integration, because the city then inherits a patchwork of trust decisions that are hard to govern consistently.
Where the Boundary Gets Confusing
Tighter identity governance often increases coordination overhead, so cities need to balance local flexibility against the cost of running a second identity programme. The confusing cases are usually not technical first; they are organisational. A city may want branding control, custom onboarding, or separate resident portals, but those preferences do not require local identity issuance. They require local configuration around a shared trust layer.
Current guidance suggests treating the wallet as the portability mechanism and the city system as the relying party. That becomes important in edge cases such as cross-border residents, temporary access, delegated family use, or services that need only age, residency, or eligibility attributes rather than full identity data. The city should ask whether it truly needs to know the person, or only needs to trust a claim about the person.
Another common edge case is service continuity. If the national wallet is unavailable, the city should have a fallback path that preserves access without permanently weakening assurance. That is a service design decision, not an identity-issuance decision. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because lifecycle ownership and revocation discipline are often what determine whether a trust model remains reliable after launch.
What practitioners underestimate is that the strongest local implementation is usually the one that does the least locally at the identity layer.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organisational Context | Sets the boundary between national identity governance and local service delivery. |
| GV.RM-01 — Risk Management Strategy | Fits the governance tradeoff between local flexibility and duplicated identity risk. | |
| PR.AA-01 — Identity and Access Control | Applies to accepting national wallet assertions at the municipal service layer. | |
| Recommendation — Define the city’s identity boundary and assign ownership for service integration. Treat duplicate identity issuance as a governance risk, not a service preference. Accept trusted wallet assertions only at the service boundary you control. | ||
Practitioner Guidance
What to prioritise: Define the trust boundary first. If the city is only consuming identity assertions, document which national claims are accepted, which local attributes are added, and which decisions remain local.
Decision rule: If a design choice would require the city to issue, recover, or revoke identity credentials on its own, treat that as a separate identity programme rather than a municipal integration.
What to verify: Confirm that service owners can explain the difference between identity proofing, wallet use, and service enrolment. If those concepts are blurred in policy or procurement, the implementation will likely drift into duplication.
What practitioners underestimate: The operational burden is often not authentication itself, but support for exceptions, accessibility, and account linking. Those are the areas where local teams feel pressure to overbuild identity logic.
Practitioner takeaway: The right municipal posture is to govern the service edge rigorously while leaving identity issuance to the national layer, because that is what preserves interoperability without multiplying trust systems.
Related resources from NHI Mgmt Group
- What is the difference between a super app approach and individual point solutions for digital government services?
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between self-sovereign identity and traditional centrally managed identity?
- What is the difference between a digital identity wallet and a digital payment wallet?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
