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.

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.

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.

For qualified legal effect, check the service status and the status history at the relevant time. ETSI explains that eIDAS trusted lists have constitutive effect: users benefit from the legal effect associated with a qualified trust service only when that service is listed as qualified.

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. Validation evidence should therefore retain both path-validation and revocation-status material, not just a green result screen.

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. Grounded DSS evidence can be useful when the report 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 still 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, not only 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 files 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.