ETSI EN 319 411-2 Trusted-list evidence

Start with the exact reliance claim: a certificate is being presented or used as an EU qualified certificate under an EN 319 411-2 qualified certificate policy. The evidence should connect that claim to the issuing QTSP, the certificate service, the certificate policy identifier, and the trusted-list service digital identifier that relying parties are told to use.

Do not treat a certificate chain, policy OID, CP/CPS statement, or repository page as enough by itself. EN 319 411-2 ties qualified-certificate reliance to the appropriate EU trusted-list entry for the QTSP, while eIDAS supplies the binding legal rule: the provider may begin the qualified trust service only after qualified status has been indicated in the national trusted list. The evidence must therefore match the exact provider, service type, status, certificate population, and relevant time rather than only proving that the provider appears somewhere on the list.

A useful trusted-list evidence record should be reviewable without opening private systems first. It should show the public statement made to relying parties, the trusted-list entry used for that statement, and the validation procedure used to interpret the trusted-list data. The service digital identity normally represents the service public key through X.509 certificate data; a provider name or URL is not a substitute.

Keep this evidence per qualified certificate service or certificate population. Preserve the list source and scheme territory, issue time or sequence identifier, service type, service digital identity, current status and status starting time, relevant service-information extensions or certificate filters, validation time, result, and reviewer or system owner. When the conclusion concerns an earlier time that predates the current status starting time, retain the applicable service-history record instead of relying only on today's status.

Since 29 April 2026, Commission Implementing Decision (EU) 2025/2164 has updated the common trusted-list template in Decision 2015/1505 to ETSI TS 119 612 V2.4.1. Record the trusted-list format and validation-procedure version used so a reviewer can repeat decisions made before or after that migration.

Use EN 319 411-2 to identify the relying-party notice obligation, then use the trusted-list standards it references to document the validation route. ETSI TS 119 612 is referenced for the trusted-list service digital identifier, and ETSI TS 119 615 is referenced for procedures for using and interpreting EU Member State national trusted lists.

Keep certificate validation evidence separate from signature or seal validation evidence. EN 319 411-2 points to ETSI TS 119 172-4 for a validation policy describing how to validate a digital signature against EU trusted lists when the outcome is whether it can be considered a qualified electronic signature or seal.

Refresh trusted-list evidence when the fact pattern behind the reliance claim changes. Relevant triggers include a new list sequence or issue time, service status or status-start change, service-history entry, digital-identity rollover, qualification-extension or filter change, certificate-service change, validation-method change, or relying-party notice update.

When a check fails or the trusted-list entry does not match the claim, record the issue as an exception before publishing or reusing the qualified-certificate claim. Use the current status and its starting time when they cover the certificate or signature event; otherwise use the applicable service-history entry and its starting time. The exception should identify whether the gap is a standards implementation issue, a trusted-list recognition issue, a CP/CPS publication issue, or a legal or supervisory question outside the standard.