ETSI EN 319 411-2 Trusted-list validation workflow

Start with one certificate service and one certificate population. Record the issuing TSP, CA or RA components, certificate policy identifier, CP and CPS versions, repository location, relying-party notice, and the relying-party use case that depends on the certificate being EU qualified.

Do not start from a provider-level marketing claim. EN 319 411-2 defines separate qualified certificate policy routes for natural persons, legal persons, QSCD-backed certificates, and website authentication certificates, so the validation file needs the exact profile before it can use trusted-list evidence correctly.

The core validation step is to connect the certificate service to the appropriate EU trusted-list entry. EN 319 411-2 says the relying-party notice must identify the trust anchor through a service digital identifier in the QTSP entry. In ETSI TS 119 612, that field represents a service public key, normally with an X.509 certificate representation; it is not merely a provider name, policy OID, or website URL.

Preserve enough trusted-list data to repeat the decision: list source and scheme territory, issue time or sequence identifier, QTSP and service names, service type, service digital identity, current status, status starting time, relevant service-information extensions, and validation time. Use the current status and its starting time when they cover the relevant point; otherwise use the applicable service-history entry and its starting time. Under eIDAS Articles 21 and 22, the provider may begin the qualified trust service only after qualified status is indicated in the trusted list, so a pre-list issuance or service date requires separate legal and supervisory review.

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 procedure version used, especially when a validation record crosses that migration date.

After the trusted-list entry is identified, check whether the certificate evidence agrees with the EN 319 411-2 profile and the public relying-party notice. The record should show the certificate policy OID, certificate profile, issuer, subject route, website-authentication route where relevant, QSCD indication where claimed, and the CP/CPS or terms text that tells relying parties how to rely on the certificate. Apply trusted-list qualification extensions and filters before concluding that a listed service covers the sampled certificate.

For QSCD profiles, do not infer QSCD use from the provider name. EN 319 411-2 requires evidence around QSCD certification, the certificate request process, public-key origin, and certificate qcStatement handling. For website authentication certificates, keep QEVCP-w, QNCP-w, and QNCP-w-gen separate because they inherit different baseline requirements from EN 319 411-1 and CA/Browser Forum material.

A trusted-list validation record is incomplete if it only says that the QTSP appeared on a trusted list. Trusted-list service status and end-entity certificate revocation status answer different questions. Keep both the service-status evidence for the relevant time and the certificate-status evidence: certificate database result, revocation status, CRL or OCSP evidence, and beyond-validity status handling where the certificate has expired.

EN 319 411-2 maps eIDAS qualified-certificate status duties to certificate lifecycle controls and requires revocation status information beyond the certificate validity period using at least one method used during validity, unless the validity-assured short-certificate exception applies. The validation record should therefore show which status method was used and whether any exception was applied.

Close the workflow with a short decision that a reviewer can repeat: certificate in scope, EN 319 411-2 profile, trusted-list service identifier, relying-party notice location, status evidence, result, owner, and next review trigger. Keep that decision with the audit, customer-assurance, or release-review evidence that relies on it.

The decision should avoid overclaiming. EN 319 411-2 source material supports a standards-based validation workflow for EU qualified certificate services, but the trusted-list entry, supervisory context, and applicable law remain part of the qualified-status determination.