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

Use alternative remote identification only when the customer cannot reasonably present the document in person and does not have access to eID or qualified trust services that meet the preferred route. The fallback must satisfy the RTS safeguards and be justified with evidence. In practice, exceptions should be rare, documented and reviewable.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	IAL — Identity Assurance Level	The question is about choosing a fallback identity-proofing route.
Recommendation — Apply the appropriate identity-assurance level and require evidence that the fallback still meets it.
NIST SP 800-53 Rev 5	IA-8 — Identification and Authentication (Non-Organizational Users)	Alternative remote identification concerns external customer authentication and proofing.
Recommendation — Use IA-8 to verify external-user identity when the preferred route is unavailable.
ISO/IEC 27001:2022	A.5.16 — Identity management	The process hinges on governed identity verification and exception handling.
Recommendation — Document and govern fallback identity decisions under identity-management procedures.
GDPR	Art.25 — Data protection by design and by default	Remote identification methods should minimise data exposure while preserving assurance.
Recommendation — Design the fallback to collect only the data needed for the verification purpose.

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.