Four Architectures, One Regulation: Choosing the Right WSCD for Your EUDI Wallet

The European Digital Identity Wallet regulation does not tell you how to build your wallet. It tells you what security outcome you must reach, and leaves the architecture up to you.

The Architecture and Reference Framework (ARF) defines the Wallet Secure Cryptographic Device (WSCD), the tamper-resistant component that protects a wallet's cryptographic keys, and recognizes four ways to build one. Each reaches the same assurance bar through a different technical path, with different tradeoffs at scale.

For Wallet Providers, QTSPs, and PID Providers finalizing infrastructure ahead of the 2026 deadline, this determines your certification path, your operating cost, and how easily you scale across millions of wallet instances.

The Four WSCD Architectures

• Local Native WSCD. Integrated directly into the smartphone's operating system, using platform capabilities like Apple's Secure Enclave or Google's StrongBox.
• Local Internal WSCD. An internal secure element embedded in the device, such as an eSIM.
• Local External WSCD. An external component, such as a smartcard, connected to the user's device.
• Remote WSCD. The cryptographic function sits on infrastructure the provider controls. The ARF is explicit about what this looks like: a remote WSCD is “a remote device, such as a Hardware Security Module (HSM).”

For a citizen signing on their own phone, a local architecture may be sufficient. But for organizations building the ecosystem, the question is what happens on the backend, and the ARF's own language decides that for you: remote signing, credential issuance, and Wallet Unit Attestation issuance are HSM-based by definition.

Why Remote Is the Default at Scale

Three roles cannot avoid the remote WSCD architecture, because their function requires it.

QTSPs offering remote qualified signatures. The signing key never touches the citizen's device. It lives in a Qualified Signature Creation Device the QTSP operates, and for a remote deployment, that QSCD is an HSM. CIR 2024/2981, Annex IV, sets the bar directly: the WSCD must be assessed against assurance level high under Implementing Regulation 2015/1502 as a prerequisite for national certification.

PID Providers. Signing credentials at the highest assurance level carries the weight of government-issued identity and must happen inside a certified secure environment.

Wallet Providers. Every wallet instance needs a Wallet Unit Attestation, a signed proof it is genuine. At national scale, that means signing millions of attestations from backend infrastructure.

The ARF's own definition makes the scaling logic explicit: “one WSCD may be a part of multiple Wallet Units,” citing the remote HSM as the example. A smartcard belongs to one device. A remote HSM, correctly deployed, serves many wallet instances from shared, certified infrastructure. That is the difference between provisioning hardware per citizen and provisioning it per data center.

Worth watching: recent ARF discussion work proposes splitting the Wallet Unit Attestation into a Wallet Instance Attestation for the app and a Key Attestation for the WSCD's security properties. Not yet final, but certification is heading toward more granular, not less.

Mapping the Architecture to Infrastructure

For organizations on the remote WSCD path, the decision comes down to four requirements.

Recognized certification. Utimaco's u.trust GP HSM Se-Series and CSe-Series are FIPS 140-3 Level 3 certified by NIST and included in Spain's CCN STIC catalog in its highest qualified category. Starting from a platform with that certification track record shortens the path to QTSP approval.

Multi-tenancy at the ecosystem's scale. The ARF anticipates one remote WSCD serving multiple wallet units. Utimaco's u.trust GP HSM Se-Series and CSe-Series support up to 31 fully isolated, containerized tenants on one device, letting a QTSP consolidate workloads without weakening cryptographic separation.

Crypto-agility. A qualified signature created in 2026 may need to stay legally valid for years. Quantum Protect adds NIST-standardized ML-KEM and ML-DSA, plus hash-based LMS and XMSS, to existing u.trust GP HSM Se-Series and CSe-Series hardware via in-field upgrade, no hardware swap. That matters more now: Cloudflare and Google have both moved their post-quantum authentication targets to 2029, a sign the industry's planning horizon is compressing across the board.

Deployment flexibility. Utimaco offers its HSM capability on-premises, as Trust as a Service in certified European data centers with sole customer control of keys, and as a managed signing service for those who don't want to run the infrastructure themselves.

The Architecture Decision Is the Business Decision

The ARF gives organizations a genuine choice among four WSCD architectures, but for those building the trust infrastructure behind the wallet, the choice narrows fast. Remote, HSM-backed WSCDs are what the regulation's own language points to for qualified signing, credential issuance, and attestation at scale. Treat your HSM platform as a long-term architectural decision, not a one-time procurement, and you scale cleanly as the ARF evolves toward the 2027 deadline.

Getting Started

Test u.trust GP HSM capabilities before you commit to an architecture. The GP HSM Simulator lets you explore multi-tenancy, crypto-agility, and PQC readiness in your own environment, free of charge.

Talk to our specialists. Our team can help you map your WSCD architecture decision against your certification timeline and sovereignty requirements.

Explore GP HSM Simulator | Contact Us

About the Author

Amani Karchoud

Product Marketing Manager, Utimaco