ETSI EN 319 411-2 Trusted-list validation workflow
A workflow for checking whether a certificate-service claim is tied to the appropriate EU trusted-list entry for the qualified trust service provider.
Use it to review relying-party notices, service identifiers, certificate policy profiles, and validation evidence before treating a certificate as EU qualified.
ETSI EN 319 411-2 makes trusted-list reliance a concrete validation point: the relying-party notice must tell users that the trust anchor for relying on an EU qualified certificate is identified in the of the appropriate EU trusted-list entry for the qualified trust service provider (QTSP). Certificate-service owners, validation engineers, and assessment teams can use this workflow to document that check.
1
Section 1
1. Identify the certificate service being validated
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, -backed certificates, and website authentication certificates, so the validation file needs the exact profile before it can use trusted-list evidence correctly.
Select the EN 319 411-2 profile in scope: QCP-n, QCP-l, QCP-n-, QCP-l-qscd, QEVCP-w, QNCP-w, or QNCP-w-gen.
Capture the or TSP-allocated OID and the CP/CPS section that explains the profile basis.
Name the relying-party outcome being validated, such as qualified certificate reliance, website-authentication reliance, or signature/seal validation input.
Open a separate record for non-qualified certificate services or for certificates whose profile, policy OID, or service boundary is unclear.
Supports the inherited CP, CPS, repository, subscriber, and certificate lifecycle controls that EN 319 411-2 profiles build on.
Policy and security requirements for Trust Service Providers issuing certificates
2
Section 2
2. Match the QTSP service to the trusted-list entry
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 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.
Record the EU trusted-list source and the Member State list or list-of-the-lists source used by the validation procedure.
Map the service digital identity to the issuing QTSP service and the certificate path. A listed root or issuing CA key can cover more than one certificate population, so apply relevant service-information extensions and certificate filters.
Store the service type, checked status, status start time, applicable , validation timestamp, trusted-list issue or sequence value, procedure used, and reviewer or system owner.
Flag a blocking gap when the certificate chain, policy profile, or relying-party notice cannot be matched to the trusted-list service identifier.
Defines trusted-list service information, including service digital identity, service type, current status, status starting time, service history, qualification extensions, and certificate filters.
Binding source for granting qualified status, the rule that qualified service provision begins only after trusted-list indication, and national trusted-list publication.
Amends Decision 2015/1505 from 29 April 2026 to base the common trusted-list template on ETSI TS 119 612 V2.4.1.
Recommended next step
Apply the trusted-list validation workflow
This EN 319 411-2 workflow helps assign trusted-list checks, relying-party notices, certificate-status evidence, and review triggers before an audit or customer assurance request.
3. Validate the certificate against the profile and relying-party notice
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 profile, issuer, subject route, website-authentication route where relevant, 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 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.
Check that the or TSP policy reference matches the selected EN 319 411-2 profile.
Confirm that the relying-party notice explains the trusted-list trust-anchor condition instead of presenting EN 319 411-2 conformance alone as qualified status.
For QCP-n- and QCP-l-qscd, retain QSCD certification, key-pair origin, qcStatement, and QSCD-status change evidence.
For QEVCP-w, QNCP-w, and QNCP-w-gen, retain domain validation evidence, applicable natural- or legal-person identity validation evidence, and the EN 319 411-1 web-profile requirements used.
Trusted-list standard referenced by EN 319 411-2 for the service digital identifier used in the reliance notice.
Trusted Lists
4
Section 4
4. Preserve status, revocation, and validation evidence
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, or 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. The ETSI exception does not by itself waive the eIDAS Article 24(4) duty to provide per-certificate status beyond validity; confirm the applicable conformity-assessment and supervisory treatment before relying on it.
Record certificate serial number, issuer, validity period, revocation status, status source, response time, and validation result.
Retain or evidence and note whether status information remains available beyond certificate validity.
For expired certificates, record the method used to check historical revocation status or the documented short-certificate exception.
Escalate when a status service is unavailable, stale, inconsistent with the certificate database, or no longer tied to the trusted-list service entry.
OCSP reference used by EN 319 411-2 for online certificate status evidence and the ArchiveCutOff extension.
Online Certificate Status Protocol
5
Section 5
5. Close with a repeatable validation decision
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.
Decision fields: certificate service, certificate sample or population, QTSP, trusted-list , profile, CP/CPS version, and relying-party notice reference.
Evidence fields: trusted-list check, policy OID check, certificate profile check, evidence where claimed, revocation or / evidence, and exception log.
Review triggers: trusted-list entry change, service-status change, CP/CPS update, CA hierarchy change, policy OID change, status change, status-service issue, or assessor finding.
Stop condition: do not publish or reuse a qualified-certificate reliance claim when the certificate cannot be tied to the trusted-list service entry and the service status applicable at the relevant time.
Trusted-list source referenced by EN 319 411-2 for the service digital identifier in the appropriate EU trusted-list entry.
Defines trusted-list service information, including service digital identity, service type, current status, status starting time, service history, qualification extensions, and certificate filters.
Trusted-list standard referenced by EN 319 411-2 for the service digital identifier used in the reliance notice.
Binding source for granting qualified status, the rule that qualified service provision begins only after trusted-list indication, and national trusted-list publication.
Primary ETSI source for EN 319 411-2 qualified certificate profiles, relying-party trusted-list notice, QSCD handling, status-service evidence, and references to trusted-list validation standards.
"service digital identifier of an appropriate EU trusted list entry"