ETSI EN 319 411-1 Certificate Services FAQ

ETSI EN 319 411-1 sets policy and security requirements for trust service providers issuing certificates. It is the general certificate-service standard in the ETSI ESI family. This page uses V1.5.1, published in April 2025. Its normative reference to ETSI EN 319 401 is non-specific, and clause 2.1 says the latest version of a non-specific reference applies. ETSI published EN 319 401 V3.2.1 in January 2026, so the assessment file should identify the EN 319 411-1 edition, the EN 319 401 edition, and the assessment date.

The standard is not limited to one certificate type. It defines requirements that apply generally and then marks additional requirements for policy families such as LCP, NCP, NCP+, DVCP, OVCP, IVCP, and EVCP. A useful implementation starts by naming the certificate policy, the certificate profile, the relying-party use case, and the CA or RA functions in scope.

A Certificate Policy, or CP, states what rules apply to a certificate for a community or class of use. A Certification Practice Statement, or CPS, explains how the trust service provider operates the service to meet those rules.

That distinction matters in review. The CP anchors applicability and relying-party expectations, while the CPS should connect the policy to operating reality: facilities, trusted roles, key controls, registration procedures, certificate issuance, renewal, re-key, modification, revocation, repositories, and status services.

The evidence should prove the service actually ran under the named CP and CPS during the assessment period. The file should link each certificate policy requirement to the control, owner, system, log, or record that demonstrates the requirement was performed.

For certificate services, the core evidence usually includes CP and CPS versions, certificate profiles, subscriber agreements or terms, identity validation records, RA role records where registration work is delegated, certificate application and issuance logs, revocation and suspension records, CRL or OCSP operation records, repository publication records, CA key management evidence, trusted-role approvals, incident records, and conformity assessment material.

The CA remains the issuing function for certificates, while an RA can support identification, authentication, certificate application, and revocation processes. The CP, CPS, agreements, access controls, and evidence should show exactly which registration tasks the RA performs.

An RA setup should name the registration officers or trusted roles, identity-proofing method, approval workflow, data exchanged with the CA, confidentiality and integrity protections for registration data, and records retained for later audit.

Subscribers and relying parties need enough information to decide whether the certificate is suitable for the intended use. ETSI EN 319 411-1 expects documentation such as the CPS, terms and conditions, and PKI disclosure material to explain the certificate type, validation procedure, usage limits, subscriber obligations, revocation contact route, status-checking expectations, applicable agreements, and audit or trust-list context.

This disclosure should be concrete. A relying party should be able to find the CP being applied, the certificate policy identifier, the certificate usage limits, how to check revocation status, and where the TSP publishes the relevant repository information.

eIDAS changes the answer when the certificate service falls within the EU trust-service framework or is being positioned as a qualified trust service. ETSI EN 319 411-1 is still useful for certificate-service controls, but qualified certificate requirements are handled through the qualified-certificate standard and the applicable eIDAS framework.

For public content, avoid saying that EN 319 411-1 alone proves eIDAS qualified status. State the certificate policy, whether the service is qualified or non-qualified, the conformity assessment or supervisory context, and the additional ETSI or legal sources that support the claim.