ETSI and eIDAS: qualified signatures, trust services, and the EU Digital Identity Wallet

Every other page in this section describes a body that publishes documents or a program that tests products. eIDAS is different in kind: Regulation (EU) No 910/2014 on electronic identification and trust services is EU law, directly applicable in every Member State without national transposition. It replaced the 1999 Electronic Signatures Directive, whose national implementations had diverged enough that a signature valid in one country could be hard to rely on in another. Its trust-service rules have applied since 1 July 2016.

The regulation itself is technology-neutral. It defines trust services, sets their legal effects, and says what a 'qualified' service or device must achieve. The technical detail comes from European standards: ETSI's Electronic Signatures and Trust Infrastructures committee (TC ESI) writes the policy, profile, and format standards, and CEN writes the protection profiles for signature devices and HSMs. The Commission then cites specific standards in implementing acts, and a service or device that meets them is presumed to meet the regulation's requirements.

In 2024 the regulation was substantially amended by Regulation (EU) 2024/1183, usually called eIDAS 2.0, which entered into force on 20 May 2024. It amends 910/2014 rather than replacing it, so article numbers from the original still apply, with new ones such as Article 5a (the EU Digital Identity Wallet) and Article 29a (remote signature devices) inserted between them.

eIDAS defines three tiers of electronic signature for natural persons, and the same three tiers of electronic seal for legal persons such as companies. The tiers differ in what they prove technically and in what a court must assume about them.

Article 25(1) sets the floor: no electronic signature may be denied legal effect or admissibility as evidence just because it is electronic, or because it isn't qualified. Article 25(2) sets the ceiling: a qualified electronic signature has the equivalent legal effect of a handwritten signature, and under Article 25(3) one based on a qualified certificate issued in any Member State is recognized as qualified in all of them. Everything in between is weighed as evidence. For seals, Article 35 gives a qualified seal a presumption of the integrity of the data and the correctness of its origin.

A trust service is something like issuing certificates for signatures, seals, or websites, time-stamping, validating or preserving signatures, or registered electronic delivery. eIDAS 2.0 adds electronic attestation of attributes (Articles 45b to 45h), electronic archiving (45i and 45j), electronic ledgers (45k and 45l), and the management of remote signature creation devices (29a). Any provider can offer a trust service; 'qualified' is a status the provider has to earn for each service.

To be granted qualified status, a provider is audited by a conformity assessment body, itself accredited against ETSI EN 319 403 (on top of ISO/IEC 17065), against the regulation and the relevant ETSI policy standards. The national supervisory body reviews the report and decides. Under Article 20 the provider must then be re-audited at its own expense at least every 24 months, and since eIDAS 2.0 the audit also checks the cybersecurity risk-management measures of Article 21 of the NIS2 Directive.

Status is published, not just asserted. Under Article 22 every Member State maintains a trusted list of its qualified providers and services, in the machine-readable format of ETSI TS 119 612, signed by the Member State. The Commission publishes the list of those lists. A validator decides whether a certificate is qualified by checking that its issuing CA appears on a trusted list as a qualified service of the right type at the time of signing, not by trusting a flag in the certificate alone.

Annex II of eIDAS lists what a qualified signature creation device must ensure: that the signature creation data is confidential and can practically occur only once, that it can't be derived and the signature can't be forged with current technology, that the legitimate signatory can reliably protect it against use by others, and that the device doesn't alter the data being signed. Only a qualified trust service provider may generate or manage that data on a signatory's behalf. Under Article 30, conformity is certified by bodies the Member States designate, and certified devices go on the Commission's public list of QSCDs.

The classic QSCD is a smart card or USB token evaluated under Common Criteria against the EN 419211 protection profiles, which is what Implementing Decision (EU) 2016/650 cites. Most qualified signatures today are created remotely instead: the key sits in an HSM operated by a qualified provider, and the signatory authorizes each signature from their phone. Keeping 'sole control' in that model needs two certified pieces, an HSM evaluated against EN 419221-5 and a Signature Activation Module (SAM) evaluated against EN 419241-2, which only lets the HSM use a signatory's key after verifying the signatory's own authentication through the Signature Activation Protocol. ETSI TS 119 431-1 covers how the provider must operate the surrounding server signing application. eIDAS 2.0 turned remote QSCD management into a qualified trust service of its own (Article 29a), with Implementing Regulation (EU) 2025/1567 setting its reference standards.

This is where the Common Criteria page connects: EN 419221-5 is the protection profile it describes, typically evaluated at EAL4 augmented with AVA_VAN.5.

ETSI (the European Telecommunications Standards Institute, founded in 1988 and based in Sophia Antipolis) is one of the three European standardization organizations, alongside CEN and CENELEC. Its trust-services work follows a numbering scheme: documents in the x19 000 range, where EN 319 numbers are European Norms that went through national approval and TS 119 or TR 119 numbers are technical specifications and reports under the same subject. The second digit groups the subject: 1xx for signature creation and validation, 4xx for trust service providers, 5xx for trust application service providers such as registered delivery, and 6xx for trust service status lists.

A handful of documents carry most of the load. Since 2025, implementing regulations such as (EU) 2025/1943 for qualified certificates and (EU) 2025/1945 for validation cite specific versions of them as reference standards, so conforming to them is how a provider or validator gets the presumption of meeting the regulation.

A signature has to be verifiable long after it was made, by someone who may not have the signer's software. ETSI defines one AdES format per container type, all built on existing signature syntaxes and all sharing the same validation model in EN 319 102-1: CAdES (EN 319 122) on CMS, the same syntax as S/MIME; XAdES (EN 319 132) on XML-DSig, common in e-invoicing and public administration; PAdES (EN 319 142) inside PDF documents; and JAdES (TS 119 182-1) on JSON Web Signatures, for APIs. Each format adds signed attributes such as a hash of the signing certificate, so the certificate can't be substituted after the fact.

The bigger problem is time. The signing certificate will expire, its CA may be revoked, the OCSP responder may go offline, and the hash and signature algorithms will eventually weaken. The baseline levels add evidence to the signature to survive each of those.

The original regulation's electronic identification part relied on national eID schemes that other Member States could choose to accept, and uptake was uneven. eIDAS 2.0 adds Article 5a: every Member State must provide at least one European Digital Identity Wallet, free to natural persons, within 24 months of the entry into force of the core implementing acts, which puts the deadline in December 2026. A wallet holds person identification data (PID) issued by the state, plus electronic attestations of attributes such as a diploma, a driving licence, or a professional qualification, and can create qualified electronic signatures, free of charge for non-professional use.

Two design choices matter cryptographically. Holders present only the attributes a relying party needs (selective disclosure, such as 'over 18' without a birth date), and the wallet has to prove it is a genuine, certified wallet whose keys sit in secure hardware. The Commission's Architecture and Reference Framework builds on the ISO/IEC 18013-5 mdoc format and SD-JWT VCs, issued and presented over OpenID4VCI and OpenID4VP. Acceptance is the other half: under Article 5f, public-sector services that require electronic identification must accept the wallet, and private relying parties that are required to use strong user authentication, including very large online platforms, must accept it within 36 months of the implementing acts entering into force, so by the end of 2027.