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 trusted-list trust anchor through the service digital identifier of the QTSP entry; the validation record should therefore preserve the trusted-list source, QTSP name, service digital identifier, service status considered, and date checked.

Treat the trusted-list entry as current evidence, not a static attachment. If the service identifier, service status, issuing CA, CP/CPS, or certificate profile changes, reopen the validation record and decide whether relying-party notices, customer evidence, or assessment files need an update.

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.

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. Keep the certificate status evidence that supports reliance at the time of validation: 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. This is the artifact that should travel into audits, customer assurance packets, and release reviews.

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.