When should firms use alternative remote identification instead of eID or a wallet?

When alternative remote identification is the right fallback

Alternative remote identification is a fallback path, not a parallel default. It belongs where the preferred route is unavailable because the customer cannot reasonably appear with the document in person and cannot use eID or a qualified wallet or trust service. That makes it a contingency for access problems, not a routine shortcut around stronger identity assurance.

Because the fallback sits behind the preferred route, the practical question is whether the organisation can show why the higher-assurance path was not available and why the chosen method still meets the RTS safeguards. Without that justification, the process becomes harder to defend in audit, complaint handling, or supervisory review.

What the RTS safeguard test means in practice

The safeguard test is about whether the alternative method still gives you enough confidence in the person, the document, and the transaction context. That usually means stronger evidence than a simple self-service upload, plus controls that reduce forgery, substitution, and replay risk. The method should be proportionate to the business use case, but it must still be evidence-based and repeatable.

A useful way to think about it is that the fallback must close the specific gap that prevented use of eID or a wallet. If the issue is document presentation, the process must compensate for the lost in-person check. If the issue is access to qualified trust services, the organisation needs a defensible alternative that does not weaken the assurance level below the policy threshold.

How to decide when an exception is justified

The decision should be exception-led and reviewable. Firms should be able to explain who approved the exception, what evidence supported the decision, whether the case was time-bound, and whether the customer can later be moved back to the preferred route. That prevents the fallback from turning into an open-ended convenience channel.

In practice, the best operating model is to use the fallback only when the customer has a genuine access barrier, then record the reason, the checks performed, and the residual limitations. The Digital Identity, eID and Identity Wallets Guide is a useful reference point for understanding why the preferred route is normally stronger and how wallet-based identity fits into the broader digital identity stack.

Risk and Threat Considerations

Alternative remote identification creates more room for impersonation, document fraud, and inconsistent review quality than a preferred high-assurance route. The risk is highest when organisations treat the fallback as a convenience feature, accept weak evidence, or fail to preserve an audit trail of why the exception was granted.

Failure mechanism: The control fails when the organisation cannot show that the person was adequately verified despite the absence of in-person document presentation or preferred electronic identification. Weak evidence, poor reviewer training, or undocumented overrides can allow fraudulent onboarding or later dispute over identity assurance.

Impact: A weak fallback can lead to account abuse, regulatory challenge, remediation work, and loss of trust in the onboarding process. It can also create downstream exposure if the identity is later used to access regulated services or authorize sensitive actions.

Practitioner Guidance

What to verify: Make sure every fallback case records why the preferred route was unavailable, what alternative evidence was used, and who approved the exception. If that record cannot be reproduced cleanly, the process is too weak for operational use.

Decision rule: If the case can still use eID or a qualified wallet, use the preferred route. If not, require a documented exception, apply the RTS safeguards consistently, and treat repeated fallback use as a signal that the customer journey or access design needs improvement rather than as a normal steady state.

Practitioner takeaway: Use alternative remote identification sparingly, because the control is only as strong as the evidence, review discipline, and exception governance behind it.

Related resources from NHI Mgmt Group

• Why is OAuth considered a better alternative for MCP servers?
• Should organisations use remote browser isolation instead of traditional endpoint controls?
• What breaks when firms use blanket de-risking instead of risk-based AML controls?
• What breaks when organisations use masking alone instead of a full HIPAA de-identification method?