Skip to main content

WSCA and WSCD: where the EUDI Wallet's keys actually live and how they are protected

This article explains the Wallet Secure Cryptographic Device (WSCD) and the Wallet Secure Cryptographic Application (WSCA), the secure hardware and software layer in which an EUDI Wallet generates and protects the cryptographic keys that bind its credentials. It is grounded in the European Digital Identity Wallet Architecture and Reference Framework (ARF) [1], the ARF discussion on the secure cryptographic interface between the Wallet Instance and the WSCA [2], and the EUDI Technical Specification 3 (TS3) for Wallet Unit Attestation [3].

It is a companion to our Wallet Unit Attestation (WUA) article. The WUA's Key Attestation asserts that a wallet's keys live in a certified WSCD at a stated level of assurance. This page explains what that device and its application actually are, so that the attestation has something concrete to point at.

Target audience: Developers, solution architects, and product managers building or integrating EUDI Wallet and European Business Wallet issuance and signing flows.

Every credential an EUDI Wallet holds is only as trustworthy as the private key it is bound to. A Person Identification Data (PID) credential, a Qualified Electronic Attestation of Attributes (QEAA), or an organisational attestation in a European Business Wallet is presented by proving control of a key. If that key could be copied, extracted, or used by software the user never authorised, the credential would be worthless, no matter how carefully it was issued.

So the ARF does not leave key protection to the wallet app. It places keys inside a dedicated, certified, tamper-resistant component and keeps the app at arm's length from them. That component is the Wallet Secure Cryptographic Device (WSCD), and the secure application that runs on it is the Wallet Secure Cryptographic Application (WSCA). Together, they are the parts of the wallet that the ordinary user never sees and that an issuer cares about most.

The secure cryptographic stack inside an EUDI Wallet: the Wallet Instance talks through the Secure Cryptographic Interface to the WSCA, which runs on the tamper-proof WSCD where keys are generated and stored. The Wallet Provider issues a Key Attestation vouching for these keys, which an issuer checks before binding a credential.

Figure 01: The secure cryptographic stack. The Wallet Instance reaches keys only through the Secure Cryptographic Interface, the WSCA performs the operations, and the WSCD holds the key material.

The principle is simple to state and important to keep in mind throughout: the keys are generated inside the WSCD and never leave it. The Wallet Instance requests that operations be performed; it does not hold the private key itself.

The WUA article frames an issuer's central worry as a single question: are the keys safe? The WSCD and WSCA are the components that let the honest answer be "yes". They address three concerns.

  • Isolation. The private keys must be generated in and remain within a protected environment that the wider operating system, the wallet app, and any malware on the device cannot access. Reading or exporting a key must be infeasible even for a sophisticated attacker with the device in hand.
  • Controlled use. Keys may only be used for sanctioned operations, typically after the user has authenticated with a gesture such as a PIN or biometric. The WSCA mediates this so that signing occurs based on the user's intent rather than silently in the background.
  • Provable protection. It is not enough for keys to be safe; an issuer with no prior relationship to the wallet must be able to verify that they are safe. The protection level of the WSCD has to be certified and then asserted in a way the issuer can check. This is exactly what the Key Attestation does, in addition to the WSCD described here.

In a closed system, a provider could simply trust its own hardware. The EUDI ecosystem is open by design, as the WUA article explains, so the protection has to be both real and demonstrable to strangers.

The secure layer is not one thing. It is a device, an application that runs on that device, and a carefully guarded interface that connects it to the rest of the wallet.

The WSCD is trusted hardware that provides a secure environment and storage for cryptographic assets such as keys and runs the WSCA [1]. It is tamper-proof and duplication-proof: the design goal is that key material cannot be extracted or cloned, even by an attacker with physical possession of the device.

The ARF describes the WSCD in two parts [1]:

  • the WSCD hardware, the physical component issued by the WSCD vendor, such as a secure element or a hardware security module; and
  • the WSCD firmware, the security-related software supplied by the vendor, such as the operating system and cryptographic libraries that run on that hardware.

The WSCD is the root of the assurance the rest of the system relies on. When the Key Attestation states that keys are at the iso_18045_high level, it is making a claim about this device and its certification.

The WSCA is the secure application that runs on and uses the functions of the WSCD [1]. It manages the critical assets, generating keys, performing signatures, and enforcing that keys are only used as permitted. One WSCA is associated with at most one Wallet Instance, and it manages the keys for that specific instance [1]. This one-to-one binding matters: it is what lets the ecosystem reason about "this wallet's keys" rather than a shared pool.

What form the WSCA takes depends entirely on the kind of WSCD it runs on, which is the subject of Section 5.

The Wallet Instance does not reach into the WSCD directly. It communicates with the WSCA across the Secure Cryptographic Interface (SCI), the channel over which sensitive operations such as key generation and signing are requested, and results returned [1][2]. Keeping this boundary explicit is what allows the same Wallet Instance to work with very different WSCDs, from a chip inside the phone to a remote hardware security module, without the app ever handling raw key material. The ARF considers the security of this interface significant enough to warrant a dedicated discussion [2].

Placing the components in the ARF's architecture makes the relationships concrete. The Wallet Instance is the app the user interacts with, holding the user interface and the issued credentials. Beneath it, across the SCI, sits the WSCA, and beneath that the WSCD with its hardware and firmware. To the side, the Wallet Provider backend issues the Wallet Unit Attestation and provides support and maintenance, while issuers and relying parties connect over the standardised OpenID4VC interfaces.

Two related components are worth distinguishing from the WSCD, because they often appear alongside it in ARF diagrams:

  • a keystore, the more general store the wallet uses for keys that do not require the full assurance of a WSCD; and
  • a QSCD (Qualified Signature Creation Device), the device used specifically for qualified electronic signatures, which is a related but distinct certified component.

For the high-assurance binding keys that hold a PID or a (Q)EAA, it is the WSCD and WSCA that carry the weight, and that the WUA attests.

The ARF does not mandate a single piece of hardware. It allows four implementation options for the WSCD, and a wallet may combine them (a hybrid WSCD) [1]. The WSCA changes shape to match.

Four deployment options for the WSCD and its WSCA: Remote (a remote HSM offered as a service), Local external (a smartcard such as an NFC eID card), Local internal (an eSIM or embedded secure element in the device), and Local native (the device maker's built-in secure hardware exposed through the OS). Each requires a different WSCA implementation, and all must be certified to the required level.

Figure 02: The four WSCD deployment options, with the form the WSCA takes in each.

  • Remote. The WSCD is a remote device, such as a Hardware Security Module (HSM), reached over the network, often offered as a Hardware-Security-Module-as-a-Service. Cryptographic operations and key storage happen in a highly secured data centre, and the WSCA is the server-side application running there.
  • Local external. The WSCD is a separate secure chip outside the phone, such as a chip-based, NFC-enabled national identity card that the user taps. Here, the WSCA typically takes the form of a dedicated JavaCard applet running on the card.
  • Local internal. The WSCD is an embedded secure element accessible from inside the device, such as an eSIM or an embedded Secure Element (eSE). The WSCA is again usually a JavaCard applet, this time on the embedded element.
  • Local native. The WSCD is the device manufacturer's own built-in secure hardware, exposed through the operating system's keystore. The WSCA takes the form of a trusted service application or the platform keystore itself.

Each option trades reach, cost, and assurance differently. A remote HSM can serve devices without secure hardware of their own; a smartcard adds a tangible token but requires the user to carry it; native hardware is the most seamless but depends on what the manufacturer ships. What they share is the requirement to be certified to the level the use case demands.

Not all secure hardware is equal, so the ARF ties key protection to measurable, certified levels rather than vendor claims. The relevant scale is the attack-potential resistance defined in ISO/IEC 18045, and for the highest-value credentials, the requirement is the high level [1][3].

This is where the WSCD meets the WUA in practice. TS3 requires that, for a PID, the keys report iso_18045_high and that the attestation carries a mandatory certification claim describing the scheme, the evaluated requirements, and the level [3]. In other words, the abstract promise "these keys are safe" is reduced to a checkable statement about which certified WSCD the keys live in and to what level it was evaluated. An issuer that needs the high level will refuse keys that can only demonstrate a lower one.

Certification also explains why the WSCD is a standing concern rather than a one-off. If a vulnerability is later found in a particular WSCD model, the affected Key Attestations must be revoked, and because issuers recheck revocation status regularly, the credentials bound to that hardware are no longer trusted [3]. The security of the device is therefore tracked across the credential's whole life, not just at issuance.

This page describes the components; the WUA is how their trustworthiness travels to an issuer. The two fit together as a single chain.

The trust chain from secure hardware to an issuer decision: keys are generated inside the certified WSCD and WSCA; the Wallet Provider issues a Key Attestation stating that those keys live in that certified WSCD; the Key Attestation, together with the Wallet Instance Attestation, forms the WUA presented at issuance; and the issuer verifies the chain to the Trusted List and the assurance level before binding the credential. Figure 03: The WSCD is the physical root of the assurance of the Key Attestation claims. Without a certified WSCD, there is nothing for the WUA to vouch for.

Reading the chain from the bottom up:

  1. The WSCD and WSCA generate and hold the keys in certified hardware so that the keys cannot leave the device.
  2. The Key Attestation (the WUA's Key Attestation) is a signed statement from the Wallet Provider that the listed keys were generated in, and are bound to, the same certified WSCD at a stated level.
  3. The WUA combines that Key Attestation with the Wallet Instance Attestation and is presented during OpenID4VCI issuance.
  4. The issuer verifies the chain up to the Wallet Provider Trusted List and checks that the assurance signals meet the use case, as set out in the WUA article's verification steps, before binding a credential.

The short version: the WSCD is the thing that is true, and the WUA is how that truth is proven to someone who has never met your wallet.

The deployment choice has real consequences for builders and for users.

A government PID Provider needs keys at iso_18045_high. Only a WSCD certified to that level, whether a native secure element, an embedded element, a smartcard, or a remote HSM, can satisfy it. If the device a user holds cannot reach the high level natively, the wallet must fall back to another option, for example, a remote HSM or an external smartcard, before a PID can be bound. The WSCD choice is therefore not just an implementation detail; it gates which credentials a given device can hold.

An older or lower-cost phone may lack a secure element that the wallet can use. The remote WSCD option allows such a device to retain high-assurance credentials by performing key operations in a certified HSM accessible over the network, with the WSCA running server-side. The user experience stays the same; the assurance comes from the data centre rather than the handset.

The same components serve organisations. When a European Business Wallet holds an organisational attestation, the binding keys still live in a WSCD and are operated by a WSCA, and the same Key Attestation vouches for them. A remote HSM is a common choice here, since business processes often run on servers rather than a single handset.

If a flaw is found in a WSCD model, the protection asserted by Key Attestation is no longer warranted. The Wallet Provider revokes the affected Key Attestations, and issuers stop trusting the credentials bound to that hardware at the next revocation check. The WSCD's certification status is, in effect, a live input to every trust decision.

The WSCD and WSCA are the EUDI Wallet's foundation of trust in hardware. The WSCD is the certified, tamper-proof device where keys are generated and stored; the WSCA is the secure application that runs on it and performs the cryptographic operations for exactly one Wallet Instance; and the Secure Cryptographic Interface is the guarded boundary that lets the wallet app use those keys without ever holding them. The ARF allows four ways to deploy this layer, remote, local external, local internal, and local native, each certified to a measurable level of assurance. Everything the Wallet Unit Attestation claims about key protection ultimately rests on this layer: the WSCD is the fact, and the WUA is the proof.

  1. European Commission, 'The European Digital Identity Wallet Architecture and Reference Framework (ARF)', Available at: https://eudi.dev/latest/architecture-and-reference-framework-main/
  2. European Commission (2026), 'ARF Discussion Topic P: Secure Cryptographic Interface between the Wallet Instance and the WSCA', Available at: https://eudi.dev/latest/discussion-topics/p-secure-cryptographic-interface-between-the-Wallet-Instance-and-WSCA/
  3. EU Digital Identity Wallet (2026), 'Technical Specification 3 (TS3): Wallet Unit Attestation', Available at: https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts3-wallet-unit-attestation.md
  4. European Parliament and Council (2024), 'Regulation (EU) 2024/1183 (eIDAS 2.0)', Available at: https://eur-lex.europa.eu/eli/reg/2024/1183/oj
  5. iGrant.io (2026), 'Wallet Unit Attestation (WUA)', Available at: https://docs.igrant.io/concepts/wallet-unit-attestation/