Organisations should treat digital identity as an optional convenience layer, not a compulsory gateway. The strongest approach is to offer digital and non-digital routes side by side, make consent understandable, and ensure people can choose how their data is used. That balance supports adoption while reducing exclusion, privacy concerns, and resistance from users who do not want a single digital pathway.
Why digital identity should remain a choice, not a choke point
The policy question is not whether digital identity is useful, it is whether it becomes the only acceptable way to access a service. In public and commercial settings, the main design tension is between convenience, fraud reduction, and inclusion on one side, and consent, privacy, and service accessibility on the other. A good model treats digital identity as one access route among others, not a replacement for every non-digital pathway.
That matters because “digital first” can quickly become “digital only” in practice. Once a service assumes everyone can and will use one digital identity flow, the organisations that run it start to shape eligibility, support, and user experience around that assumption. The result can be exclusion for people who lack suitable devices, stable connectivity, confidence, or willingness to share data, as well as friction for users who simply prefer another route.
Privacy is part of the same design problem. Identity systems collect, correlate, and reuse personal data, so the question is not just whether the system works, but whether it collects more than the service genuinely needs. The EU General Data Protection Regulation (GDPR) is useful here because it reinforces purpose limitation, data minimisation, and privacy by design as practical constraints on identity adoption.
Where the service involves a formal national or cross-border digital identity scheme, the policy and trust model become even more important. The eIDAS 2.0 EU Digital Identity Framework shows how digital identity can be standardised without removing the need to think carefully about proportionality, user choice, and the scope of information disclosed in each transaction.
A practical balance usually means: digital identity for users who want speed, reuse, or remote access; non-digital or lower-friction alternatives for users who need them; and clear separation between identity verification and unnecessary data collection. That approach supports adoption without turning identity into a gatekeeper for essential services.
What balanced service design looks like in practice
Balanced identity adoption is mainly a service design decision, not a technology decision. Organisations should define the minimum identity assurance needed for each transaction and then offer the least intrusive route that still meets that need. For some use cases, a simple logged-in digital account is enough. For others, stronger verification is justified, but it should still be proportionate to the actual risk.
The strongest implementations keep alternative pathways genuinely usable. A phone-based, assisted, branch, or in-person route should not be treated as an exception that is deliberately harder to use. If the fallback path is slow, opaque, or penalised, the organisation has effectively created digital compulsion even if a paper or assisted option technically exists.
It also helps to distinguish identity proofing from ongoing service access. Not every interaction requires the same level of identity assurance, and not every service needs the same dataset. In privacy terms, the organisation should ask whether the digital identity flow is proving who the person is, authorising a specific action, or simply making the service easier to use. Those are different design choices with different privacy implications.
Identity systems are often justified on the basis of security, but the control value depends on the workflow around them. User consent must be understandable, revocable where appropriate, and linked to a real choice rather than a forced click-through. Without that, adoption rises on paper while trust falls in practice.
For organisations operating in Europe or serving regulated users, the digital identity discussion also intersects with privacy governance, consent handling, and data disclosure boundaries. A useful reference point for that broader governance lens is the NIST Privacy Framework, which helps teams structure data processing decisions around risk rather than convenience alone.
Practitioner guidance: how to avoid digital identity becoming exclusion by design
What to prioritise: Treat the user journey, not the identity product, as the unit of design. The first question should be whether the service can be delivered with a lighter identity burden for low-risk interactions, and whether every mandatory digital step is truly necessary.
What to verify: Check that the non-digital route can complete the same outcome without hidden penalties, excessive delays, or extra fees. If staff must manually translate the alternative route into an inferior process, the organisation has not preserved meaningful choice.
Trade-off: Stronger digital identity can improve fraud resistance, auditability, and convenience, but it also increases the blast radius of poor data governance and can create single-path dependency. The right balance is not maximum digitisation, it is proportionate assurance with real alternatives.
What practitioners underestimate: People often accept digital identity when it is optional and clearly beneficial, but resist it when it is tied to essential access, broad data reuse, or unclear consent. The trust problem is usually caused by compulsion and opacity, not by the technology itself.
Practitioner takeaway: A service is well balanced when digital identity is available for those who want it, but nobody loses access, privacy control, or dignity because they choose another route.
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, NIST SP 800-63 and CIS Controls v8 set the technical controls, while EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organizational Context | Identity choice must fit service objectives and user needs. |
| PR.AC — Access Control | Access decisions should preserve legitimate alternative routes and least privilege. | |
| PR.DS — Data Security | Digital identity adoption must be bounded by data minimisation and protection. | |
| Recommendation — Define service goals and user constraints before making digital identity the default path. Design access controls so no single digital path becomes the only way in. Minimise collected identity data and protect it across every route. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Assurance should match the risk of the transaction, not force one level everywhere. |
| AAL — Authenticator Assurance Level | Different access events need different authentication strength. | |
| FAL — Federation Assurance Level | Federated digital identity can reduce friction while changing disclosure and trust boundaries. | |
| Recommendation — Match identity proofing strength to the specific transaction risk. Select authenticators in line with the access sensitivity being protected. Set federation controls to limit unnecessary attribute sharing. | ||
| CIS Controls v8 | 6 — Access Control Management | Access control should support multiple service routes without weakening governance. |
| 3 — Data Protection | Identity adoption increases privacy exposure unless data handling is tightly governed. | |
| Recommendation — Implement access controls that support optional, proportionate identity flows. Protect identity data and restrict collection to what the service needs. | ||
| EU AI Act | Risk management and transparency | If digital identity uses AI-driven decisions, transparency and oversight become material. |
| Recommendation — Apply transparency and oversight when AI influences identity or access decisions. | ||
Related resources from NHI Mgmt Group
- How should organisations balance digital identity wallet convenience with privacy and tracking risk?
- How can organisations balance privacy and security in identity design?
- How should organisations govern reusable digital identity across multiple services?
- What do organisations get wrong about digital identity in financial services?
