Cities should treat the wallet as part of a broader service design, not just a login feature. The core requirement is secure, verified identity with simple onboarding, one-time authentication, and in-app access to services such as payments and contracts. If people must leave the app repeatedly or manage confusing steps, adoption will drop and the programme will fail to deliver value.
Why Cities Should Treat the Wallet as a Service Channel, Not a Standalone App
A city wallet succeeds when it reduces friction in the citizen journey while preserving trust in the underlying identity proofing, consent, and transaction steps. The design goal is not to make the wallet do everything; it is to let residents authenticate once, keep context, and complete high-value tasks without bouncing between systems. That matters because public services are judged by continuity, not by how elegant the login screen looks.
For cities, the hardest part is usually not technical credential issuance but service orchestration across departments that were not designed to share a common flow. The wallet has to feel simple even when the back end is doing identity verification, entitlement checks, payment handoff, and record updates. Standards such as eIDAS 2.0 — EU Digital Identity Framework are relevant here because they show how digital identity is expected to work across services and borders, but the user experience still depends on local service design choices.
In practice, many city programmes fail when they design for policy compliance first and resident flow second.
How the Wallet Should Work in Practice
The cleanest pattern is to separate identity proofing, wallet enrolment, and service access. Residents should verify themselves once through a clear onboarding path, then receive a reusable wallet credential that can be presented to participating services with minimal repeated input. After that, the wallet should act as a persistent service layer, not a constant prompt for fresh logins or redundant document uploads.
That means cities need to decide which steps truly require re-authentication and which can remain context-aware within the same session. A payment, for example, may need step-up confirmation, but an address update inside a trusted transaction flow should not force residents back through a full identity journey. The same principle applies to contracts, permits, benefits, or booking systems: the wallet should pass trusted claims into the service, while the service keeps the user in one coherent journey.
- Use one onboarding path with plain language, clear consent, and visible status so residents know what has been verified.
- Keep the wallet embedded in services where possible, so users do not experience app hopping or repeated context loss.
- Limit re-entry of personal data by reusing verified attributes rather than asking residents to resubmit the same information.
- Apply step-up checks only for higher-risk actions, not for every minor service interaction.
Operationally, this also requires a strong account and entitlement model behind the scenes. If departments each maintain their own identity assumptions, the wallet becomes a front-end veneer over fragmented access control. NHIMG research on Ultimate Guide to NHIs is useful here because it reinforces a broader design truth: identity systems work best when issuance, scope, visibility, and revocation are governed as a lifecycle, not as a one-time login event.
These controls tend to break down when legacy service portals cannot accept shared identity claims and force residents back into separate authentication silos.
Where Simplicity Breaks, and How to Keep It Manageable
Tighter assurance often increases friction, so cities have to balance convenience against the level of trust required for each service. A low-risk transaction can use lightweight confirmation, while a high-impact action such as changing benefits details or signing a legal agreement needs stronger evidence and better auditability. Best practice is evolving, but the direction is clear: user convenience should vary by transaction risk, not by department habit.
Another common edge case is inclusion. A wallet that is smooth for mobile-first users can still fail if it assumes constant connectivity, one device, or a high level of digital literacy. Cities need fallback routes, assisted enrolment, and a clear way to recover access without making the resident restart the entire identity process. That is especially important when the wallet becomes a gateway to essential services, where failed access is not merely inconvenient but exclusionary.
Security and usability also diverge when there are too many claims, too many approvals, or too many participating agencies. The more attributes a city tries to pack into the wallet, the more complex consent, renewal, and revocation become. A practical programme usually starts with a narrow set of high-value services, proves the journey, and expands only when the operational model can support it.
For cities, the right measure of success is not how many identity features the wallet exposes, but how few steps a resident must understand to complete a service safely and confidently.
Risk and Threat Considerations
The main risk is not just poor adoption; it is trust failure created by excessive complexity, inconsistent authentication, or unclear consent. When residents encounter repeated prompts, confusing permissions, or broken handoffs between services, they may abandon the wallet, but they may also bypass intended controls in search of faster paths.
Failure mechanism: Fragmented service design pushes identity checks into separate silos, which increases re-authentication, weakens session continuity, and encourages workaround behaviour such as account reuse, support-mediated access, or reduced verification rigor in edge cases.
Impact: The city gets lower uptake, more support burden, weaker auditability, and a higher chance that sensitive citizen actions are handled through inconsistent fallback processes rather than the intended secure workflow.
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, CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST AI RMF set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Transparency and Human Oversight — Transparency and Human Oversight | Digital identity wallets need clear consent, user control, and understandable processing. |
| Recommendation — Design resident flows to keep consent, purpose, and step-up checks understandable and attributable. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | The wallet must authenticate users and preserve trusted access across services. |
| Recommendation — Align wallet enrolment and access decisions to verified identity and least-necessary access. | ||
| CIS Controls v8 | 5 — Account Management | Cities need lifecycle control over citizen access and recovery paths. |
| Recommendation — Standardise account recovery, entitlement changes, and revocation paths across participating services. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point — Policy Enforcement Point | The wallet should enable contextual, policy-driven access decisions per transaction. |
| Recommendation — Enforce transaction-specific policy checks instead of treating every action as the same trust level. | ||
| NIST AI RMF | MAP 1 — Govern AI Risks | If AI is used in resident-facing flows, governance must bound trust, clarity, and accountability. |
| Recommendation — Assess resident-facing automation for clarity, accountability, and failure handling before rollout. | ||
Practitioner Guidance
What to prioritise: Design the citizen journey before the technical rollout. If the wallet cannot complete the most common service path in one coherent flow, the programme will be judged as failed even if the identity layer is sound.
Decision rule: If a step does not materially change risk, entitlement, or legal assurance, keep it out of the resident-facing path. Reserve stronger checks for actions with real consequence, and do not make every service behave like a high-risk transaction.
What to verify: Confirm that departments can accept the same verified claims, that recovery is supported without full re-enrolment, and that audit trails remain intact when users move between services. Those three conditions usually determine whether the wallet feels unified or fragmented.
What practitioners underestimate: The hardest failure is often not a technical outage but a confusing exception path. If the fallback flow is slower, less clear, or less trusted than the normal flow, residents and staff will route around it.
Practitioner takeaway: The best city wallet is one that makes secure completion feel like the shortest path, not an extra hurdle.
Related resources from NHI Mgmt Group
- How should organisations implement two-factor authentication in high-risk digital services without creating unnecessary user friction?
- How should security teams implement identity-based authentication in high-risk environments without creating a worse user experience?
- How should insurers modernize identity controls across APIs, applications, and services without making digital journeys harder for customers?
- How should organisations implement a simple data classification policy without making category decisions too complex?
