ChecklistEU

EU eIDAS trust services checklist

Use this checklist to review eIDAS evidence for qualified trust services, electronic signatures, electronic seals, electronic time stamps, certificates, trusted lists, and EUDI Wallet relying-party use.

It is written for legal, product, security, procurement, and operations teams that need records showing whether a service is qualified, how signatures or seals were validated, and what relying-party data was requested.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

eIDAS covers notified electronic identification schemes, European Digital Identity Wallets, and trust services such as electronic signatures, electronic seals, time stamps, registered delivery, website authentication certificates, electronic attestations of attributes, archiving, and ledgers. A useful checklist should not stop at saying that a provider is 'eIDAS compliant'. It should show the service type, whether qualified status is claimed, which trusted-list and certificate evidence was checked, how validation results were produced, and what operational controls keep the evidence current.

Section 1

1. Classify the eIDAS service and claimed status

Start by naming the exact electronic identification or trust-service function. The same product may involve a certificate authority, remote signing service, validation service, preservation service, time-stamping authority, website-authentication certificate, EUDI Wallet relying-party integration, or more than one of those roles.

Treat qualified status as a specific supervised status, not a marketing label. Under eIDAS, a qualified trust service provider may begin providing the qualified trust service only after qualified status has been indicated in the trusted list.

Record the service category: electronic signature, electronic seal, electronic time stamp, certificate service for website authentication, validation, preservation, registered delivery, attestation of attributes, electronic archiving, electronic ledger, or EUDI Wallet reliance.
State whether the provider claims to be a qualified trust service provider, a non-qualified trust service provider, a wallet provider, an issuer, or a relying party.
For qualified trust services, capture the Member State supervisory body, the trusted-list entry, the service type, current service status, and status start date from the trusted list.
If the provider uses the EU trust mark, verify that the provider website links to the relevant trusted list for the qualified service it advertises.
Do not accept a contract clause, logo, or certificate chain alone as proof of qualified status without matching the trusted-list service entry.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports the need to distinguish trust-service categories, qualified trust service providers, trusted-list status, and the EU trust mark.

Commission Implementing Decision (EU) 2015/1505 on trusted lists

Supports using trusted lists as the authoritative record of qualified trust service providers and qualified trust services.

Section 2

2. Check qualified trust-service provider controls

For a provider-side review, collect evidence that the qualified service is supervised, assessed, and operated with the controls eIDAS expects. For a buyer-side review, ask for enough evidence to verify the service without requesting confidential assessment material unnecessarily.

The control record should make clear whether the review covers provider qualification, a particular qualified service, or a relying-party validation of a signature, seal, certificate, or time stamp.

Confirm that a conformity assessment report was issued by a conformity assessment body for the qualified trust service, and record the report date, scope, and service names supplied by the provider.
Track the recurring audit obligation for qualified trust service providers and evidence that the provider notified the supervisory body before planned audits where applicable.
Keep the provider's terms and conditions, service limitations, certificate policy, practice statement, and relying-party guidance with the procurement or service record.
Check operational controls for trustworthy systems, protected processes, authorised data changes, certificate databases where qualified certificates are issued, continuity, and termination planning.
For incidents affecting the trust service or related personal data, record notification handling, supervisory-body communications, affected-service scope, and any trusted-list status change.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports the qualified trust service provider audit, conformity assessment, risk, incident, continuity, and certificate-database controls in this checklist.

ETSI EN 319 401 general policy requirements

Supports using ETSI trust-service provider policy requirements when reviewing provider practices, terms, security controls, and evidence.

Section 3

3. Validate signatures, seals, and certificates with evidence

For each signed or sealed document, preserve the validation result and the inputs that made the result reproducible. eIDAS distinguishes the legal effect of electronic signatures and seals from the stricter conditions for qualified electronic signatures and qualified electronic seals.

A validation record should answer three questions: what was validated, which certificate and trusted-list information was used, and what the validation system returned to the relying party.

For a qualified electronic signature, verify that the supporting certificate was a qualified certificate for electronic signature at signing time, was issued by a qualified trust service provider, was valid at signing time, and that the signature was created by a qualified electronic signature creation device.
For an advanced electronic signature based on a qualified certificate, verify the qualified certificate, issuer, validity at signing time, signatory data, pseudonym indication where used, signed-data integrity, and advanced-signature requirements.
For an electronic seal, identify the legal person creating the seal and check integrity and origin evidence; for a qualified electronic seal, preserve evidence supporting the presumption of data integrity and correctness of origin.
Capture certificate validity information, revocation or suspension status, OCSP or CRL evidence where available, validation time, validation policy, and the validator report result.
If a qualified validation service is used, keep the provider identity and the signed or sealed automated validation result supplied to the relying party.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports the signature, seal, qualified-certificate, QSCD, revocation, and validation evidence checks.

Commission Implementing Decision (EU) 2015/1506 on advanced signature and seal formats

Supports format and reference-method checks where public-sector services require advanced electronic signatures or seals.

European Commission eSignature building block

Supports keeping validation-tool outputs, trusted-list browser checks, and DSS-style signature verification evidence with the record.

Section 4

4. Review trusted lists and certificate qualification

Trusted-list handling is a control in its own right. The checklist should show how the list was obtained, how its signature or seal was trusted, which entries were selected, and how status changes are detected.

For certificate-based services, do not assume that every certificate from a listed provider is qualified for every purpose. Trusted-list service information and extensions distinguish qualified certificates for electronic signatures, electronic seals, and website authentication.

Use the Commission list of trusted lists or the relevant Member State trusted list as the starting point, and record the list URL, issuer, signature or seal validation, sequence or issue time where available, and retrieval time.
Load trust anchors according to a written validation policy rather than ad hoc browser or operating-system trust alone.
For qualified certificates, verify whether the trusted-list information indicates QCForESig, QCForESeal, QCForWSA, QSCD support, or non-qualified status.
Recheck trusted lists for changes to provider status, service status, new entries, withdrawals, revocations, or service history when revalidating stored evidence.
Keep validation outputs as valid, invalid, or indeterminate with reasons, not merely a pass/fail screenshot.

Sources for this answer

ETSI TS 119 612 trusted lists

Supports trusted-list retrieval, trust-anchor management, qualification extensions, and validation outputs.

Commission Implementing Decision (EU) 2015/1505 on trusted lists

Supports the EU technical and format basis for trusted lists under eIDAS Article 22.

Section 5

5. Check time stamps, preservation, and long-term proof

A time stamp can be critical evidence for proving when data existed and whether a signature or seal was created before certificate expiry or revocation. The checklist should distinguish ordinary electronic time stamps from qualified electronic time stamps.

For long-lived documents, validation evidence should not depend only on a live certificate status endpoint that may later stop returning historical information.

For a qualified electronic time stamp, verify that it binds date and time to data so later changes are detectable, uses an accurate time source linked to Coordinated Universal Time, and is signed or sealed by the qualified trust service provider or equivalent method.
Record the Time-Stamping Authority, time-stamp token, policy identifier, signing certificate, UTC time source evidence, and token validation result.
For archived or preserved signatures, keep validation data, time stamps, trusted-list snapshots or references, certificate status evidence, and preservation-service records needed to revalidate later.
Where a provider offers qualified preservation or archiving, confirm that the relevant service, not just the provider, appears with the expected qualified status in the trusted list.
Define when evidence must be refreshed: certificate status changes, algorithm-policy updates, provider withdrawal, trusted-list status changes, or preservation migration.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports the legal effect and technical requirements for qualified electronic time stamps.

ETSI EN 319 421 time-stamping requirements

Supports TSA policy, time-stamping operations, UTC clock synchronization, and time-stamp evidence controls.

Section 6

6. Add EUDI Wallet relying-party checks where wallets are used

When a service relies on European Digital Identity Wallets, the checklist must cover relying-party registration and data-request discipline. Wallet integration is not only an authentication feature; it creates records about who requested which user data, for what intended use, and under which legal or contractual basis.

Only apply these checks to wallet use cases that actually rely on EUDI Wallets. They should not be retrofitted to ordinary e-signature validation or non-wallet login flows.

Before relying on EUDI Wallets, record the Member State registration for the relying party, the relying-party name and registration number where applicable, contact details, intended wallet use, and the data requested from users.
Ensure the live data request does not ask for data beyond the intended use recorded at registration.
Identify the relying party to the user and keep evidence that wallet use was requested by the user where eIDAS makes wallet acceptance conditional on voluntary user request.
For wallet-presented person identification data or electronic attestations of attributes, record the authentication and validation procedure used by the relying party.
For intermediaries acting on behalf of relying parties, confirm they are treated as relying parties and do not store transaction-content data.

Sources for this answer

Regulation (EU) 2024/1183 establishing the European Digital Identity Framework

Supports EUDI Wallet relying-party registration, data-request limits, identification, validation responsibility, and voluntary-user-request checks.

European Commission - Wallet for service providers

Supports using Commission EUDI Wallet service-provider material when documenting relying-party onboarding and wallet data-request controls.

EUDI Wallet Architecture and Reference Framework

Supports wallet ecosystem roles, relying-party authentication context, privacy, and attestation-presentation evidence design.

Recommended next step

Build a sourced eIDAS evidence record

Sorena can help convert these eIDAS checks into a maintained evidence pack for signatures, seals, time stamps, trusted lists, QTSP reviews, and EUDI Wallet relying-party onboarding.

Research workflow

Open Research Copilot for eIDAS

Ask source-linked questions about eIDAS trust services, qualified status, signatures, seals, time stamps, trusted lists, and EUDI Wallet relying-party checks.

Explore next step

Talk to Sorena

Review an eIDAS evidence pack

Check whether your eIDAS records connect provider status, validation outputs, wallet data requests, and trusted-list evidence.

Explore next step

Primary sources