ETSI EN 319 411-1 compliance guide

ETSI EN 319 411-1 applies to TSPs issuing public key certificates, including trusted website certificates, and defines policy and security requirements for issuance, maintenance, and lifecycle management. The first compliance decision is therefore the service boundary: which CA hierarchy, certificate types, certificate profiles, subscriber communities, RA processes, repositories, revocation services, and status services are in scope.

Separate EN 319 411-1 general compliance from adjacent regimes. The standard includes certificate policies for LCP, NCP, NCP+, DVCP, OVCP, IVCP, and EVCP, and it references CA/Browser Forum requirements for web-authentication policies. EU qualified certificate services need the additional qualified-certificate context instead of treating Part 1 alone as proof of qualified status.

The compliance file should show the difference between the Certificate Policy and the Certification Practice Statement. EN 319 411-1 explains the CP as the named rules for a community or class of application, while the CPS describes how the TSP operates the CA service and implements those rules in its own facilities, procedures, and systems.

A practical evidence map should therefore pair each CP commitment with the CPS clause and the operational record that proves it. Examples include certificate profile rules, signature algorithms and parameters, CA key use, subscriber registration, RA handoffs, repository publication, revocation handling, and status-service availability.

ETSI EN 319 411-1 compliance depends on reconstructable lifecycle evidence. Registration records need to show how subject identity and attributes were verified, how subscriber authority was established when subscriber and subject differ, and how contact attributes and applicable data-protection evidence were handled.

Certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, and status-service records should be traceable to the CP/CPS. The page should not claim compliance from a policy statement alone if the service cannot also show the logs, agreements, requests, validations, and status publications behind the certificate.

Revocation is one of the clearest places where compliance becomes operational. The CPS should document who can submit revocation requests or reports, how requests are submitted and confirmed, why certificates can be revoked or suspended, how status information is distributed, and the maximum delays for status changes.

The control evidence should prove availability and consistency, not only policy intent. EN 319 411-1 requires revocation requests and reports to be processed on receipt, authenticated as authorized, and reflected in status information within the required maximum delay. Status services need public, internationally available revocation status information, protected integrity and authenticity, and support for CRL or OCSP.

The audit file should make CA key protection and operational controls reviewable. EN 319 411-1 includes requirements for physical security around certificate generation and revocation management, trusted roles, CA key generation, secure cryptographic devices, CA private-key backup and recovery, activation data, network zones, access control, and monitoring.

Do not reduce this evidence to screenshots of a control dashboard. For certificate services, reviewers need ceremony reports, role assignments, dual-control evidence, HSM or secure cryptographic device assurance, CA key lifecycle logs, configuration baselines, access reviews, alarm records, and exception handling tied to the CA and assessment period.

Use this checklist before a conformity assessment, customer trust review, repository update, or public certificate-service claim. Each item should point to a specific document, log, export, or approval record rather than a generic statement that the TSP follows EN 319 411-1.