How should organisations approach strong authentication for EU digital identity wallets and remote signing services?

Organisations should treat strong authentication as a core design requirement, not an add-on. The revised eIDAS direction points toward secure credential protection, portability, and recovery for digital wallets, plus WebAuthn-based authentication for remote signing. The practical goal is to preserve user control, reduce reliance on weak authentication, and align wallet access with standards that support interoperable trust across member states.

What strong authentication has to achieve in wallet and remote signing flows

For EU digital identity wallets and remote signing, strong authentication is doing more than proving a user can log in. It has to bind the person to the wallet or signing action with enough assurance that a relying party can trust the transaction, while still preserving portability across devices, providers, and member states. That means the authentication design must support the wallet lifecycle, not just the first access event.

The practical design problem is that wallets and remote signing sit at the intersection of identity proofing, credential protection, and transaction authorisation. If authentication is weak, the wallet becomes easier to hijack, and if recovery is clumsy, users lose the ability to access legitimate credentials after device loss or migration. A robust model therefore needs secure enrolment, phishing-resistant day-to-day use, and controlled recovery paths.

For wallet-based use cases, the strongest pattern is to keep the credential under user control and limit exposure of any reusable secret material. For remote signing services, the authentication step should be tied to the signing event itself, because the risk is not just unauthorised access, but unauthorised signature creation. The more valuable the signature, the more important it is that the authentication method resists phishing, replay, and credential relay.

When the implementation aligns with the direction of eIDAS 2.0, the EU Digital Identity Framework, strong authentication becomes part of interoperable trust rather than a local product choice. Organisations should therefore design for methods that can travel across ecosystems without weakening assurance, and they should avoid building flows that depend on passwords or other low-assurance factors as the primary gate to wallet access or remote signing approval.

Authentication patterns that fit the use case

For remote signing services, current guidance increasingly points to phishing-resistant authenticators, especially WebAuthn-based flows, because they reduce the risk of credential theft and origin confusion. That matters when the signing event itself is the high-value action, since attackers often target the step that authorises the signature rather than the signing backend.

Wallet authentication should also support strong device binding and secure recovery. A good implementation does not treat recovery as a back door with weaker controls; it treats recovery as a controlled trust transition that must preserve assurance while allowing legitimate device replacement or wallet restoration.

A useful way to think about the architecture is:

Authenticate the wallet holder with a phishing-resistant method where possible.
Protect any recovery flow with assurance appropriate to the value of the wallet.
Separate simple access from high-risk actions such as signing, changes to wallet settings, or credential export.
Prefer standards-based mechanisms that preserve interoperability across providers and relying parties.

That approach is consistent with NIST SP 800-63 Digital Identity Guidelines, which is useful here because it frames authenticator assurance, phishing resistance, and identity proofing as distinct design choices rather than one generic “strong login” requirement. It also aligns with the browser-based authentication model used in modern sign-in and signing flows, where the security of the authenticator depends heavily on origin binding and resistance to phishing.

Risk and Threat Considerations

Weak authentication in wallet and remote signing flows creates a direct path to account takeover, fraudulent signature creation, and loss of trust in the wallet ecosystem. The main danger is not only initial compromise, but also the ability of an attacker to use a stolen session, relayed code, or socially engineered recovery step to impersonate the legitimate holder at a moment of high-value action.

Failure mechanism: Phishing, token relay, MFA fatigue, or insecure recovery can let an attacker reach the wallet or approve a remote signature without controlling the real user’s device or intent.

Impact: The result can be unauthorised transactions, repudiation disputes, failed reliance on the signed action, and broader confidence loss in cross-border digital identity services.

Practitioners should also recognise that authentication weakness often appears first at the edges of the flow, not in the core signing service. Social engineering, replayable factors, and poorly governed fallback paths are common failure points because they are designed for convenience and recovery, yet they frequently become the attacker’s easiest entry point.

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, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Phishing-resistant authenticators — Phishing-Resistant Authentication	Remote signing and wallet access need resistant authenticator choices.
	Authenticator assurance — Authenticator Assurance Levels	The subject depends on matching assurance to access and signing risk.
	Recovery and lifecycle — Identity Proofing and Recovery	Wallet recovery must preserve trust without weakening assurance.
Recommendation — Use phishing-resistant authenticators for wallet access and signing approval. Match authenticator assurance to the value and impact of the signing action. Harden recovery so it does not become a lower-assurance bypass path.
NIST Zero Trust (SP 800-207)	Session- and action-bound access — Zero Trust Architecture	Remote signing should be authorised per action, not by broad trust.
Recommendation — Bind access decisions to the specific signing action and current trust state.
CIS Controls v8	Account Management — Account Management	Wallet and signing services require controlled account and credential lifecycle.
Recommendation — Tighten account lifecycle and revoke access paths that outlive their purpose.

Practitioner Guidance

What to prioritise: Treat the wallet unlock step, the signing approval step, and the recovery step as separate assurance decisions. A flow that is acceptable for everyday access may still be too weak for signature authorisation.

What to verify: Confirm that the chosen authenticator is phishing-resistant, that recovery does not downgrade assurance below the signing requirement, and that the user experience preserves control without creating an easy bypass path.

Decision rule: If a method can be replayed, relayed, or approved without a trustworthy origin binding, do not use it as the primary control for remote signing.

Practitioner takeaway: Strong authentication for wallets and remote signing should be judged by the assurance of the highest-risk action, not by the convenience of the login screen.