eIDAS Trust List Validation

Use the European Commission List Of Trusted Lists (LOTL) as the starting trust anchor for EU trusted-list discovery. The LOTL points to the national trusted lists published by Member States, and the ETSI portal describes it as a signed or sealed, machine-processable XML list. Decision (EU) 2025/2164 is the binding source for the template update that has applied since 29 April 2026; ETSI TS 119 612 v2.4.1 supplies the referenced technical format.

Do not validate qualified status from a copied certificate, supplier screenshot, or stale browser bookmark alone. The evidence should show the LOTL location used, the Member State trusted list reached, the trusted-list signing or sealing certificate accepted, and the publication or sequence information available to the validator. Decision (EU) 2025/2164 is binding; ETSI TS 119 612 v2.4.1 supplies the technical model incorporated by that decision.

A provider name is not enough. The trusted-list entry must match the trust service being relied on, such as a CA issuing qualified certificates, a qualified time-stamping service, a qualified validation service, or another listed qualified trust service.

Check the service type, applicable additional service information, current status, status start time, and status history at the relevant time. Under the updated common interpretation rules, qualified status comes from that combination, not from a provider name or a certificate-policy label alone.

After the trusted-list match, validate the cryptographic and certificate evidence. eIDAS Article 32 requires a qualified electronic signature validation process to confirm, among other things, that the supporting certificate was qualified and valid at the time of signing, the validation data corresponds to what is provided to the relying party, and the signed data integrity has not been compromised.

For qualified certificates, eIDAS also requires validity or revocation status information to be available to relying parties on at least a per-certificate basis, including beyond the certificate validity period. Retain path-validation and revocation-status material; a green result screen cannot reproduce the decision.

The European Commission DSS project is an open-source library for Advanced Electronic Signature creation, augmentation, and validation in line with European legislation and eIDAS. A DSS report is useful when it shows the LOTL and trusted-list checks, certificate path, revocation data, timestamp checks, and signature qualification result.

Review the validation level and report type. A basic validation failure caused by a certificate revoked at validation time may be resolved differently when long-term validation material and a trusted timestamp prove that the signature existed before revocation. The retained report must show that reasoning and the final indication.

A useful evidence package lets a later reviewer reproduce the trust decision without asking the supplier to explain it again. Store the source records or immutable references, the validation report, the policy used, and the business decision that depended on the result.

The record should distinguish legal-status evidence from technical-validity evidence. Legal-status evidence proves the provider and service were qualified at the relevant time. Technical-validity evidence proves the signature, certificate path, revocation data, timestamps, and signed content passed the chosen validation process. Re-run the check when the service status or history changes, a list signature cannot be verified, the LOTL or national-list trust anchor changes, certificate status changes, or the validation policy or software version changes.