eIDAS and ETSI EN 319 — the European Trust Landscape

Chapter 2 · eIDAS and ETSI EN 319

Raw PKI gives you cryptography. eIDAS and ETSI EN 319 give you a trust service. Cryptography proves a key signed something; a trust service proves the right key signed it, and that the resulting signature has legal effect across all 27 Member States of the European Union. The atlas of practitioners begins here because most of what makes EU digital signatures useful is not in the algorithm.

2.1 Why this chapter exists

If you arrived from chapter 1 with an X.509 certificate and a working signing pipeline, you are technically able to produce signatures. You are not yet able to produce signatures with legal effect across an EU border, and you are not yet able to produce signatures whose verification will still hold up to audit five years from now. The gap between technical signature and legal-effect signature is what eIDAS and ETSI EN 319 close.

Two things motivate the chapter beyond bureaucratic curiosity:

Reuse over reinvention. The AI Act high-risk regime asks for integrity and audit-trail. The eIDAS regime has provided exactly those primitives, with cross-Member-State legal effect, since 2014. Reusing them costs an engineer one afternoon of reading; reinventing them costs a project two years and a regulator’s confidence.
The Estonian case. Estonia is the largest production sample of “what does qualified e-signature deployment look like at population scale?” — over a million holders out of ~1.3M residents, daily use across government, banking, and private contracts. We refer to it throughout as a sanity check on what’s actually feasible.

By the end of this chapter you will know which standard prescribes which behaviour, when “qualified” status matters and when it doesn’t, and how to reach a Trusted List from code.

2.2 Regulation 910/2014 — the original eIDAS

The European Union’s electronic identity and trust services regime dates from Regulation (EU) No 910/2014, which entered into force in 2014 and replaced the earlier e-signature Directive 1999/93/EC. The Regulation creates a single, EU-wide legal framework for:

Electronic identification (eID) — Member-State-issued identity schemes that other Member States are required to accept, under specified assurance levels (low / substantial / high).
Electronic trust services, comprising:
- Electronic signatures (for natural persons)
- Electronic seals (for legal persons — corporations, institutions)
- Electronic timestamps
- Electronic registered delivery services
- Website authentication certificates (eIDAS QWAC)
- Long-term preservation services

For each trust-service category, the Regulation defines a qualified tier produced by a Qualified Trust Service Provider (QTSP) under audit. The “Q” prefix matters: a Qualified Electronic Signature (QES) is, under Article 25(2), legally equivalent to a handwritten signature across the entire Union. A non-qualified Advanced Electronic Signature (AdES) carries non-discrimination protection (Article 25(1)) but does not carry the same evidentiary weight in court.

For an engineer, the operational implication is brisk:

If you need…	You produce…	Under…
Internal audit trail, no cross-border court effect	AdES (advanced)	EN 319 102-1 + EN 319 132-1
EU-wide handwritten-equivalent signature	QES (qualified)	QSCD + QTSP under audit
Corporate-issued document attestation	AdES seal / QES seal	Same, but issued to a legal person
Trusted timestamp for long-term validation	Qualified TSA token	RFC 3161 + EN 319 421

Most AI evidence-signing applications end up at AdES or AdES-with- qualified-timestamp; full QES is overkill for the vast majority of agent-output use cases, and the atlas defaults to AdES throughout unless we say otherwise.

2.3 Regulation 2024/1183 — eIDAS 2 / European Digital Identity

Regulation (EU) 2024/1183, commonly called “eIDAS 2”, amended 910/2014 in 2024 to introduce the European Digital Identity Wallet (EUDI Wallet) and to refresh several trust-service categories. The most engineering-relevant changes:

A new category of qualified electronic attestations of attributes (QEAA), allowing a QTSP to issue verifiable attribute claims about a subject — birth date, professional qualification, residency status — independent of a full identity certificate.
New requirements around the EUDI Wallet as a pan-EU identity vehicle, with associated trust-service obligations on attestation issuers and verifiers.
Tightened serial-uniqueness language for qualified certificates: the draft 2025/1943 implementing act extends uniqueness from per-CA to TSP-wide (we cover this in chapter 6 as an operational case study; the companion preprint discusses architectural options).
A clearer mandate for post-quantum migration in trust services, though concrete deadlines have been deferred to secondary instruments.

eIDAS 2 is, from the practitioner’s perspective, an additive update: most deployments built under 910/2014 do not need to change urgently, but new deployments should plan for QEAA, EUDI Wallet, and the serial-uniqueness shift from day one.

2.4 The ETSI EN 319 family

The Regulation tells you what the law requires. ETSI EN 319 tells you how to build it. The relevant standards form a hierarchy:

       EN 319 401  (general TSP policy)
            │
            ├── EN 319 411-1  (cert-issuing TSP requirements)
            │       │
            │       └── EN 319 412-x  (certificate profiles)
            │
            ├── EN 319 421  (TSP issuing time-stamps)
            │       │
            │       └── EN 319 422  (time-stamping protocol profiles)
            │
            ├── EN 319 102-1  (AdES creation/validation procedures)
            │       │
            │       ├── EN 319 122-x  (CAdES — CMS-based AdES)
            │       ├── EN 319 132-x  (XAdES — XML-based AdES)
            │       ├── EN 319 142-x  (PAdES — PDF-based AdES)
            │       └── EN 319 162-x  (ASiC containers)
            │
            └── EN 319 521 / 531 / 532  (registered delivery TSP)

A practitioner does not memorise all of these. The four that matter for the atlas are:

EN 319 102-1 — Procedures for Creation and Validation of AdES Digital Signatures. The single most-cited standard in this book. If a verifier disagrees with a signer about whether a signature is valid, this is the document that adjudicates.
EN 319 132-1 — XAdES Digital Signatures. The XML profile. Notorious for canonicalisation hazards (see chapter 1 §1.5); used in DigiDoc and many government contexts.
EN 319 401 — General Policy Requirements for Trust Service Providers. The umbrella policy frame; everything below it inherits from it.
EN 319 411-1 — Policy and security requirements for TSPs issuing certificates; Part 1. The standard you will read if you are operating or auditing a CA under qualified status.

We mostly leave 411-1 and the certificate profiles to specialists. The atlas’s load-bearing claim is: if your AI evidence-signing pipeline produces signatures that validate under EN 319 102-1, with timestamps from a TSA conforming to EN 319 421, you have inherited everything the EU regime offers without inventing a new format.

The CAdES vs XAdES vs PAdES vs JAdES choice is a separate question that is mostly answered by your downstream container:

If your output container is…	Use the AdES profile…
CMS / PKCS#7 (binary, common in code-signing)	CAdES
XML	XAdES (with reluctance — see ch 1 §1.5)
PDF	PAdES
JSON	JAdES
ZIP-of-anything (multi-file)	ASiC container with one of the above
CBOR (this atlas’s `.aep` format)	None of the above; we use a CBOR-native envelope inspired by COSE [@rfc8152].

The EATF / Aletheia choice for .aep is CBOR-native because the existing AdES profiles all carry XML or DER overhead that does not earn its keep in a high-throughput agent-output pipeline. Where qualified legal effect is needed, an .aep package can be re-wrapped as a CAdES-conformant signature; we discuss this bridge in chapter 6.

2.5 TSP vs QTSP — the practical difference

A Trust Service Provider (TSP) is anyone who runs a service that falls within the eIDAS taxonomy. A Qualified Trust Service Provider (QTSP) is a TSP that has been audited against the Regulation’s qualified-tier requirements and listed in a Member State’s national Trusted List. The audit is non-trivial:

A conformity assessment body (CAB) audits the TSP’s policy pack, key-management practices, operational procedures, business continuity, and incident response.
The Member State’s supervisory body (in Estonia, the Riigi Infosüsteemi Amet — RIA) reviews the audit and either grants qualified status or sends the TSP back for remediation.
The qualified status is recorded in the national Trusted List (TL), which is published as an XML document over HTTPS, signed by the supervisory body.
The European Commission publishes a List of Trusted Lists (LOTL), which links to the 27 national TLs, signed by the Commission.

The chain of trust for a verifier wanting to confirm “is this TSP qualified?” is: LOTL → national TL → TSP → certificate. Most verifying software automates this; the operational concern is ensuring the LOTL fetcher is fresh, the signature checks are honoured, and you do not silently fall back to “trust the host operating system” when the TL fetch fails.

Engineering implications:

AdES does not require qualified status. You can produce a perfectly valid AdES signature with an internally-issued certificate, no TSP, no TL, no LOTL. The signature is just not qualified.
Qualified Electronic Signatures (QES) require all three. The signing key lives in a Qualified Signature Creation Device (QSCD) — a smart card, a HSM operated by a QTSP, or an equivalent — and the certificate must trace back to a QTSP in a national TL, which is in turn referenced from the LOTL.
Qualified Timestamps require a QTSP TSA. If your audit story depends on time provenance with cross-border legal effect, you need a QTSP-operated TSA. There are several commercial options across the EU; we list specific ones in chapter 6.

For most AI evidence-signing applications, the question is “do I need cross-border legal effect on the timestamp?”. For most deployer-internal audit, the answer is no, and a non-qualified RFC 3161 TSA suffices. For evidence intended to be admissible in court across Member States, the answer is yes, and the operational complexity of QTSP integration is worth paying.

2.6 Trusted Lists and how to consume them

The Trusted List is the public registry of qualified trust services in a Member State. It is published as XML following ETSI TS 119 612, signed by the supervisory body. A consumer of the TL must:

Fetch the TL XML over HTTPS.
Validate the signature against the supervisory body’s public key (the LOTL says where to find it).
Parse the TL to extract a list of qualified TSPs and their trust anchors (root certificates, certificate-issuing key identifiers).
Cache the result with attention to freshness — TLs typically carry an expiry; a stale TL is not authoritative.
Use the extracted trust anchors as the qualified-tier trust anchors for path validation in step §1.3 of chapter 1.

The List of Trusted Lists (LOTL) is the EU-Commission-published index of Member-State TLs. It is itself signed XML; verifiers typically fetch it once per day and cross-check the embedded TL URLs and signing keys against the TLs they fetch.

In code, a typical Java-based TL consumer (e.g. the one used by Aletheia / EATF in production) is roughly:

TrustedListClient client = TrustedListClient.builder()
    .lotlUrl("https://ec.europa.eu/.../eu-lotl.xml")
    .commissionPublicKey(commissionKey)
    .cacheDir(Paths.get("/var/cache/eatf/tls"))
    .build();

TrustAnchorSet anchors = client.fetchAndValidate();
PathValidator validator = new PathValidator(anchors);
ValidationResult result = validator.validate(certPath, signingTime);

The Estonian Trusted List (https://sr.riik.ee/.../EE-TL.xml) is particularly tractable to consume, and the Open-EID stack provides a reference C++ implementation if you need something non-Java. We use the Estonian TL as the smoke-test target in chapter 6.

2.7 RFC 3161 timestamps and qualified TSAs

RFC 3161 specifies the Time-Stamp Protocol (TSP) that the EU regime, through ETSI EN 319 421 and EN 319 422, profiles for trust-service use. The flow is unchanged from chapter 1:

The signer hashes the content to be timestamped.
The signer sends a TSP request containing the hash to a TSA.
The TSA returns a Time-Stamp Token (TST) — a CMS structure binding the hash to the TSA’s claimed time, signed by the TSA’s certificate.
The signer attaches the TST to the signature container (CAdES, XAdES, PAdES, or — in EATF’s case — embeds it in the .aep’s tsa field).
A verifier checks the TST signature, validates the TSA cert path, and uses the TSA’s claimed time as the signed-content’s “signing time”.

A qualified TSA conforms additionally to EN 319 421 (policy) and EN 319 422 (protocol profile), and is listed in a national Trusted List. The legal effect is straightforward: a qualified timestamp is, under Article 41 of eIDAS, “presumed accurate” as to the time and integrity of the data. A non-qualified RFC 3161 timestamp is just a third-party time witness — useful, but not presumed accurate.

For AI evidence packages, our operational guideline is:

Default to a qualified TSA if the deployer’s policy envisions cross-Member-State court use of the evidence.
Default to a non-qualified RFC 3161 TSA otherwise — they are cheaper, faster, and operationally simpler, and the evidence is still tamper-evident.
Capture the OCSP state of the TSA’s own certificate at TST issuance time, so that long-term validation can prove the TSA was operational on the claimed date (this matters once the TSA cert expires).

2.8 The Estonian sanity check

Estonia is unusual among EU Member States in that nearly every adult holds a qualified certificate via one of three schemes:

ID-card — a national identity smart card. The chip carries two qualified certificates: one for authentication (TLS client, web login), one for digital signatures (QES). The cards are issued by the Police and Border Guard Board, with the qualified certificates issued by SK ID Solutions, the Estonian QTSP.
Mobiil-ID — a SIM-based scheme for mobile phones. The signing keys live on a special SIM. Qualifications equivalent to the ID-card.
Smart-ID — a software-based scheme using server-side HSMs and split-key cryptography. Qualified status required some legal manoeuvring but was achieved in 2018. Particularly popular for cross-border use because no physical card is needed.

The Estonian DigiDoc tooling — open-source, cross-platform — implements end-to-end XAdES / ASiC-E signature creation and verification using any of the three schemes. Estonian government services accept DigiDoc-signed .bdoc and .asice containers across the public sector; private contracts routinely use them too.

For practitioners, the Estonian deployment is worth studying because it answers, with a decade of evidence, the question what does qualified e-signature look like when normal people use it daily? The answer is: it works, the UX is acceptable (if not delightful), the trust anchors are stable, and the courts treat it like a handwritten signature without controversy. Where applications get stuck is rarely the cryptography — it’s the UX of cross-border verification, the price of commercial Smart-ID API access, and the inevitable Windows driver conflicts on government laptops.

2.9 Where this leaves us

After chapter 2 you should be able to answer, for any AI evidence-signing decision:

Do I need qualified status? Default no; default to AdES.
Which AdES profile do I use? Match it to the container format your downstream consumes.
Where do my trust anchors come from? From the LOTL → TL chain, fetched and validated at startup.
Where do my timestamps come from? From an RFC 3161 TSA; qualify it if cross-border legal effect is in scope.
What does my verifier need to do? Path-validate under EN 319 102-1 against the TL-derived anchors, with revocation state captured at sign time.

These five questions are what take you from “I have a signing key” to “I have a trust service”. Chapter 3 picks up where this chapter ends, with the question: and what does it take to keep all of this working when the cryptographic primitives shift to post-quantum?

2.10 Diagrams

2.10.1 eIDAS trust service taxonomy

flowchart TB
    classDef qual fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef adv fill:#fef9c3,stroke:#a16207,color:#713f12

    Root[eIDAS trust services]
    Root --> Sig[Electronic signature &lt;br&gt; natural persons]
    Root --> Seal[Electronic seal &lt;br&gt; legal persons]
    Root --> TS[Electronic timestamp]
    Root --> Del[Registered delivery]
    Root --> Web[Website auth &lt;br&gt; QWAC]
    Root --> Pres[Long-term preservation]
    Root --> EID[Electronic identification &lt;br&gt; eIDAS 1] 
    Root --> Wallet[European Digital Identity Wallet &lt;br&gt; eIDAS 2 / 2024/1183]

    Sig --> SigQ[Qualified &lt;br&gt; QES]:::qual
    Sig --> SigA[Advanced &lt;br&gt; AdES]:::adv
    Seal --> SealQ[Qualified seal]:::qual
    Seal --> SealA[Advanced seal]:::adv
    TS --> TSQ[Qualified timestamp]:::qual
    TS --> TSA[RFC 3161 timestamp]:::adv

Qualified instruments (green) carry cross-Member-State legal effect under Article 25(2). Advanced instruments (yellow) carry the Article 25(1) non-discrimination protection but require additional evidence in court.

2.10.2 ETSI EN 319 family hierarchy

flowchart TB
    classDef policy fill:#e0e7ff,stroke:#3730a3,color:#1e1b4b
    classDef cert fill:#fef3c7,stroke:#92400e,color:#78350f
    classDef sig fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
    classDef ts fill:#fce7f3,stroke:#831843,color:#500724

    P401[EN 319 401 &lt;br&gt; General TSP policy]:::policy

    P401 --> P411[EN 319 411-1 &lt;br&gt; Cert-issuing TSP]:::cert
    P411 --> P412[EN 319 412-x &lt;br&gt; Cert profiles]:::cert

    P401 --> T421[EN 319 421 &lt;br&gt; TSA TSP policy]:::ts
    T421 --> T422[EN 319 422 &lt;br&gt; TSA protocol profile]:::ts

    P401 --> S102[EN 319 102-1 &lt;br&gt; AdES create / validate]:::sig
    S102 --> CAdES[EN 319 122-x &lt;br&gt; CAdES]:::sig
    S102 --> XAdES[EN 319 132-x &lt;br&gt; XAdES]:::sig
    S102 --> PAdES[EN 319 142-x &lt;br&gt; PAdES]:::sig
    S102 --> ASiC[EN 319 162-x &lt;br&gt; ASiC]:::sig

Policy (401) is the umbrella; specialised by 411-1 for certificate issuers, profiled by 412-x, and consumed by 102-1 at signing time. The four AdES profiles (CAdES / XAdES / PAdES / JAdES) match different container formats; ASiC bundles them.

2.10.3 TL / LOTL verifier journey

sequenceDiagram
    autonumber
    participant V as Verifier (your software)
    participant LOTL as EU Commission LOTL
    participant TL as National TL (e.g. EE)
    participant TSP as Qualified TSP
    participant Cert as End-entity certificate

    V->>LOTL: Fetch list of trusted lists (XML)
    LOTL-->>V: LOTL signed by Commission
    V->>V: Validate Commission signature, parse TL URLs
    V->>TL: Fetch national TL (e.g. EE-TL)
    TL-->>V: TL signed by RIA (supervisory body)
    V->>V: Validate, extract qualified TSPs and trust anchors
    V->>TSP: Verify cert chains to a qualified TSP
    TSP-->>V: Chain confirmed
    V->>Cert: Path validation under EN 319 102-1
    Cert-->>V: Valid for the time of interest

2.10.4 Estonian three-scheme picture

flowchart LR
    classDef hw fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
    classDef sw fill:#fce7f3,stroke:#831843,color:#500724
    classDef hsm fill:#fef3c7,stroke:#92400e,color:#78350f

    A[ID-card &lt;br&gt; physical chip]:::hw
    B[Mobiil-ID &lt;br&gt; SIM-based]:::hw
    C[Smart-ID &lt;br&gt; software with split-key]:::sw

    A --> KA[2 qualified certs &lt;br&gt; auth + sign]
    B --> KB[Qualified cert &lt;br&gt; on SIM secure element]
    C --> KC[Server-side HSM &lt;br&gt; client share]:::hsm

    KA --> Pop[~1.3M Estonian residents]
    KB --> Pop
    KC --> Pop

    Pop --> Use[DigiDoc / Open-EID &lt;br&gt; cross-platform tooling]
    Use --> Apps[Government services &lt;br&gt; banking &lt;br&gt; private contracts]

All three schemes produce QES-grade signatures under SK ID Solutions (Estonia’s QTSP). For practitioners, the Estonian deployment is the sanity check on what qualified e-signature looks like at population scale: the cryptography works, the UX is acceptable, the courts treat it as a handwritten signature.

2.11 Key references

Regulation (EU) 910/2014 (eIDAS), and amending Regulation (EU) 2024/1183 (eIDAS 2).
ETSI EN 319 102-1 — Procedures for Creation and Validation of AdES Digital Signatures.
ETSI EN 319 401 — General Policy Requirements for Trust Service Providers.
ETSI EN 319 411-1, 412-1 — Certificate-issuing TSP requirements and certificate profiles.
ETSI EN 319 421, 422 — Time-Stamping TSP and protocol profiles.
ETSI TS 119 612 — Trusted Lists.
RFC 3161 — Internet X.509 PKI Time-Stamp Protocol (TSP).
Open-EID and DigiDoc tooling — https://github.com/open-eid.

2.12 Outgoing links

→ Chapter 3 · Post-quantum migration is the next thing the regime needs to absorb.
→ Chapter 5 · The AI Act mapping draws explicitly on the levers introduced here.
→ Chapter 6 · Operational playbooks for TL fetching, TSA selection, OCSP discipline.