How should organisations implement digital identity verification without making it compulsory for users?

Make digital identity one pathway, not the only pathway

The implementation choice matters more than the label. A well-designed digital identity flow should sit alongside other verification routes so users can choose the method that fits their situation, their device access, and their comfort level. That preserves usability without turning verification into a single point of failure for onboarding, recovery, or service access.

That design is most defensible when the organisation defines digital identity as an option for eligible cases, not a gate that silently excludes users who cannot or will not use it. For practitioners, the practical test is whether the alternative path is genuinely usable at the same decision point, with comparable service outcomes and clear instructions. If the fallback is hard to find or materially slower, the “choice” is only nominal.

For identity assurance-heavy use cases, the implementation should also be consistent with the trust level of the transaction. Digital identity can be appropriate for higher-friction or higher-assurance journeys, but the organisation still needs a parallel route for people who lack the required device, identity wallet, or account setup. The goal is not to weaken verification, but to avoid making one technology mandatory when the underlying business process does not require it.

Preserve a fallback that is operationally real

A fallback works only if staff, systems, and scripts support it end to end. Physical ID review or paper document submission should not be treated as an exception handled ad hoc by individual teams, because that tends to create inconsistent outcomes and delays. If the organisation offers a non-digital route, it should be documented, supported, and measured like any other intake path.

That matters because compulsory digital verification often fails at the edges: lost devices, accessibility barriers, poor connectivity, device incompatibility, or users who simply prefer not to share a digital credential. Where the alternative route exists, the organisation should specify who can approve it, what evidence is acceptable, and how long it should take. A fallback that depends on informal discretion usually becomes slower and less fair than the digital path it was meant to balance.

Current practice in digital identity schemes increasingly reflects this layered approach, especially where assurance, adoption, and inclusion all have to coexist. Standards such as NIST SP 800-63 Digital Identity Guidelines are useful for thinking about assurance strength, while eIDAS 2.0, the EU Digital Identity Framework is a reminder that digital identity deployment must still support broad participation across real populations and use cases.

Practitioner checks for usability, trust, and policy fit

What to verify: Verify that the digital path and the fallback path both reach the same business decision, with the same ownership model and no hidden penalties for choosing the non-digital route. If one path grants faster service or fewer steps, that should be an explicit policy choice rather than an accident of implementation.

Common mistake: Treating “optional” as synonymous with “undocumented.” Optional verification still needs clear eligibility rules, support scripts, evidence handling, escalation criteria, and auditability. Without that, the fallback becomes a manual workaround instead of a governed control.

Trade-off: Optional digital identity usually reduces friction and can improve adoption, but it also adds process complexity because the organisation must maintain two trusted routes. That complexity is worth it when the user population is mixed or the service has meaningful accessibility and inclusion requirements.

Practitioner takeaway: The best implementation is not the most digital one, it is the one that preserves user choice while keeping both verification paths equally governed, supportable, and trustworthy.

Related resources from NHI Mgmt Group

• How should government agencies implement identity verification at high-risk service moments without creating unnecessary friction for legitimate users?
• How should security teams implement digital credential verification without rebuilding their identity stack?
• How should organisations implement decentralized identity for age or attribute verification without exposing unnecessary personal data?
• How should organisations implement document-free identity verification without weakening fraud controls or compliance checks?