We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 compliance guide

A practical guide for turning ETSI EN 319 411-1 into a certificate-service compliance file.

Uses ETSI EN 319 411-1 V1.5.1 and the latest edition of its non-specific normative reference to ETSI EN 319 401.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
6 sections3 primary sources
Overview

Define the certificate-service boundary, match each Certificate Policy and CPS commitment to evidence, and collect lifecycle, revocation, key-management, and audit records for that scope. The file should show what the offers, which policy OIDs apply, which requirements are conditional or inherited, what subscribers and relying parties are told, and where the supporting records are kept. EN 319 411-1 V1.5.1 cites EN 319 401 without a version; clause 2.1 therefore makes the latest EN 319 401 edition applicable, so record the edition and assessment date used. This page is an implementation aid, not a legal opinion or a conformity assessment.

Section 1

Start with the certificate service boundary

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 the profile layers before claiming conformance. Unless the standard says otherwise, NCP+ and EVCP include NCP requirements, while DVCP, OVCP, and IVCP include LCP requirements. The four web-certificate profiles also require the applicable full and latest CA/Browser Forum Baseline Requirements or Extended Validation Guidelines. EU qualified certificate services need the additional qualified-certificate and legal framework; Part 1 alone does not establish qualified status.

Before choosing the assessment scope, distinguish the baseline policies: Lightweight Certificate Policy (LCP), Normalized Certificate Policy (NCP), and Extended Normalized Certificate Policy (NCP+). The website profiles are Domain Validation Certificate Policy (DVCP), Organizational Validation Certificate Policy (OVCP), Individual Validation Certificate Policy (IVCP), and Extended Validation Certificate Policy (EVCP).

  • List each certificate service, CA, subordinate CA, RA, repository, CRL or OCSP service, and certificate profile covered by the claim.
  • Identify the policy family used for each certificate type and document inherited requirements: LCP, NCP, NCP+, DVCP, OVCP, IVCP, EVCP, or a policy built under clause 7.
  • Record whether the service issues natural-person, legal-person, website, device, short-term, or publicly trusted certificates because the evidence differs.
  • Name the governing CP, CPS, terms and conditions, PKI disclosure material, and any customer or regulatory requirement that adds constraints.
Section 2

Map CP and CPS commitments to evidence

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 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.

  • For each supported CP, record the policy OID, target user community, certificate profile, allowed usage, and any variance from EN 319 411-1 baseline policies.
  • Confirm the CPS is publicly disclosed online on a 24x7 basis and states the signature algorithms, CA key-use practices, and service-specific procedures it relies on.
  • Keep internal operating procedures separate from public CPS text, but link them in the audit file so reviewers can verify implementation without exposing confidential runbooks.
  • When a defines a policy beyond the named EN 319 411-1 policies, keep the approval body, risk assessment, review process, subscriber/relying-party disclosure, and unique OID evidence together.
Recommended next step

Operationalize ETSI EN 319 411-1 certificate-service compliance

This guide helps map certificate policies, CPS clauses, lifecycle controls, revocation services, CA key controls, and evidence owners before an audit or customer trust review.

Assessment workflow
Open Assessment Autopilot for ETSI EN 319 411-1

Convert EN 319 411-1 certificate-service requirements into owners, evidence requests, and review milestones.

Explore next step
Research workflow
Research ETSI EN 319 411-1 source questions

Use cited ETSI source material to resolve CP/CPS, lifecycle, revocation, key-management, and audit-evidence questions.

Explore next step
Talk to Sorena
Talk through ETSI EN 319 411-1 compliance implementation

Review the certificate-service scope, evidence model, and next implementation steps with Sorena.

Explore next step
Section 3

Build lifecycle evidence from registration through status checking

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. A policy statement alone is not operational evidence. Clause 6.4.6 sets an explicit minimum of seven years after the affected certificate ceases to be valid for CA-managed key-lifecycle logs and the documentation identified in clause 6.3.4; other record periods follow the applicable requirement, disclosed practices, and terms.

  • Registration: retain identity and attribute verification evidence, document references, subscriber authority evidence, contact attributes, and the validation method used.
  • Application and issuance: link each request to registration evidence, authorization, completeness checks, proof of possession or control when the subject key is not CA-generated, and the certificate profile selected.
  • Acceptance and subscriber duties: preserve durable terms and conditions, traceable acceptance, subject consent where required, and notice to relying parties about revocation checking and usage limits.
  • Renewal, re-key, and modification: show whether the subject key changed, whether attributes changed, whether previous validation may still be reused, and whether changed terms were re-accepted.
Section 4

Test revocation, repository, and status-service controls

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 evidence should prove availability and consistency. EN 319 411-1 requires revocation requests and reports to be processed on receipt, authenticated and checked as coming from an authorized source, and reflected in status information within the applicable maximum delay. The general status-service rules require public, internationally available revocation status information, protected integrity and authenticity, and CRL or OCSP support, but the standard has defined branches for short-term certificates and certificates carrying the validity assured extension.

  • Keep test evidence that revocation or suspension status changes become available to relying parties within the applicable maximum delay, including the 24-hour maximum where EN 319 411-1 applies it.
  • For CRL services, retain publication records, nextUpdate values, signature evidence, and proof that end-user CRLs are published at least every 24 hours unless a final CRL applies.
  • For OCSP services, retain responder profile evidence, access-control evidence, monitoring for non-issued certificate requests, and results for issued, revoked, suspended, expired, and unknown certificate cases.
  • When both CRL and OCSP are supported, document the source of any update delay and how relying parties should interpret temporary differences.
  • For short-term certificates, record whether revocation is available; if it is not, the CPS must identify the non-revocable groups and explain problem notification and information-request handling. For a certificate with the validity assured extension, assess the clause 6.3.10 status-service exception and the No Revocation Available extension guidance instead of assuming CRL or OCSP is mandatory.
Section 5

Include CA key, facility, and audit-log evidence

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.

  • CA key generation: keep the documented ceremony procedure, trusted-role attendance, dual-control evidence, witness signatures, algorithm and key-length rationale, and certification of the public key.
  • Private key protection: retain secure cryptographic device assurance, operating configuration evidence, backup and recovery records, destruction evidence, and access-control reviews.
  • Operations: preserve physical-security evidence, secure-zone and high-security-zone diagrams, hardened CA system configuration checks, MFA for certificate-issuance accounts, and monitoring records.
  • Audit logs: include registration events, certificate lifecycle events, CA key lifecycle events, revocation requests and reports, status-service changes, and retained records by assessment period.
Section 6

Compliance file checklist

Review 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 follows EN 319 411-1.

  • Scope register: certificate services, CA hierarchy, RAs, repositories, certificate profiles, CP families, CPS version, status-service methods, and assessment period.
  • Policy evidence: CP OIDs, CPS publication URL, terms and conditions, PKI disclosure material, subscriber and relying-party notices, and policy-change approvals.
  • Lifecycle evidence: registration records, subscriber authority, certificate request and issuance logs, acceptance records, renewal/re-key/modification records, certificate-profile checks, and the applicable retention rule for each record class.
  • Revocation evidence: authorized request routes, authentication checks, processing logs, status publication tests, CRL or OCSP outputs, consistency notes, short-term certificate branches, and validity-assured certificate branches where used.
  • Security evidence: CA key ceremony reports, HSM or secure cryptographic device assurance, trusted-role records, secure-zone controls, access reviews, monitoring records, incident/continuity records, and retained audit logs.
Primary sources

References and citations

ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements
etsi.org7 citations
Referenced sections
  • Primary source for EN 319 411-1 scope, certificate policy families, CP/CPS requirements, certificate lifecycle controls, revocation and status services, CA key controls, audit logging, and records evidence.
  • Supports the page scope: EN 319 411-1 covers generally applicable policy and security requirements for TSPs issuing public key certificates, including trusted website certificates.
  • Supports the CP/CPS distinction, public CPS disclosure requirement, policy identifiers, and clause 7 framework for other certificate policies.
Show 4 more
  • Supports the lifecycle evidence topics for identity validation, application processing, issuance, acceptance, renewal, re-key, modification, and subscriber/relying-party obligations.
  • Supports the revocation, suspension, CRL, OCSP, status-service availability, and consistency controls in clauses 6.2.4, 6.3.9, 6.3.10, 6.6.2, and 6.6.3.
  • Supports facility, trusted-role, audit logging, CA key generation, secure cryptographic device, private-key protection, network security, and monitoring evidence expectations.
  • Supports the compliance-file checklist by supporting the needed CP/CPS, lifecycle, revocation, status-service, key-management, logging, and operational evidence areas.
"Policy and security requirements for Trust Service Providers issuing certificates"
More quoted passages
"policy and security requirements for Trust Service Providers"
"what is to be adhered to"
"Certificate Life-Cycle operational requirements"
"Revocation status information shall be available"
"Facility, management, and operational controls"
"issuance, maintenance and life-cycle management"
ETSI EN 319 401 V3.2.1 general policy requirements for TSPs
etsi.org4 citations
Referenced sections
  • Current general TSP source referenced by EN 319 411-1 for policy, management, security, continuity, incident, practice-statement, evidence, and supply-chain controls.
  • Provides the current general TSP policy framework referenced without a version number by EN 319 411-1, including management, practice statements, risk, security, continuity, evidence, and supply-chain controls.
  • Supports the trust service practice statement and general policy requirements imported by EN 319 411-1.
Show 1 more
  • Supports the general TSP control areas imported by EN 319 411-1, including management, security, continuity, incident, and audit controls.
"General Policy Requirements for Trust Service Providers"
Regulation (EU) No 910/2014 (eIDAS)
eur-lex.europa.eu3 citations
Referenced sections
  • Provides legal context for EU trust-service and qualified-trust-service claims that may sit alongside EN 319 411-1 certificate-service controls.
  • Provides EU trust-service context for services that position certificate issuance under eIDAS or qualified trust-service frameworks.
  • Supports the caution that EU trust-service or qualified-status positioning needs the applicable legal and qualified-certificate basis in addition to EN 319 411-1.
"electronic identification and trust services"

Related guides

EN 319 411-1 vs EN 319 411-2 Certificate Policy

Compare ETSI EN 319 411-1 V1.5.1 with EN 319 411-2 V2.6.1, including policy profiles, inherited controls, QSCD routes, trusted-list status, and evidence boundaries.

ETSI EN 319 411-1 Audit File Evidence

Build an ETSI EN 319 411-1 audit evidence file for CA logging, registration records, revocation records, CA key lifecycle evidence, and records archival.

ETSI EN 319 411-1 CA Key Management

CA key management guidance for ETSI EN 319 411-1: CPS commitments, key ceremonies, secure cryptographic devices, backup, recovery, and lifecycle evidence.

ETSI EN 319 411-1 certificate lifecycle workflow

Workflow for EN 319 411-1 certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and evidence records.

ETSI EN 319 411-1 CP and CPS template

Build a certificate policy and Certification Practice Statement template for ETSI EN 319 411-1 certificate services, with fields for policy identifiers, subscribers, relying parties, revocation, publication, and evidence.

ETSI EN 319 411-1 FAQ for Certificate Services

Answers to common ETSI EN 319 411-1 questions on certificate policies, CPS content, CA and RA boundaries, subscriber evidence, revocation, status services, and record retention.

Show all related guides (22)

ETSI EN 319 411-1 Identity Validation

Identity validation requirements in ETSI EN 319 411-1 for subscribers, subjects, RAs, certificate requests, registration evidence, and issuance records.

ETSI EN 319 411-1 Identity Validation Evidence Workflow

A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls.

ETSI EN 319 411-1 RA Delegation Guide

How to scope registration authority delegation under ETSI EN 319 411-1, including delegated RA tasks, external provider controls, registration records, and audit evidence.

ETSI EN 319 411-1 RA Delegation Review Workflow

Review delegated registration authority work under ETSI EN 319 411-1: retained CA responsibility, recognized registration service providers, secure data exchange, CPS coverage, and audit evidence.

ETSI EN 319 411-1 requirements map for certificate services

Map ETSI EN 319 411-1 requirements for certificate policies, CP/CPS content, registration, revocation, certificate status, and CA key-management evidence.

ETSI EN 319 411-1 Revocation Evidence Workflow

Build a revocation evidence workflow for ETSI EN 319 411-1 covering CPS procedures, request authentication, 24-hour status updates, CRL/OCSP publication, logs, and retention.

ETSI EN 319 411-1 Revocation, OCSP, and CRL Operations

Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, applicable 24-hour timing, CRL and OCSP controls, exceptions, and audit evidence.

ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements

Compare ETSI EN 319 411-1 V1.5.1 with the CA/Browser Forum TLS Baseline Requirements, including [WEB] controls, DVCP, OVCP, IVCP, CPS duties, and change monitoring.

CP vs CPS under ETSI EN 319 411-1

Understand how ETSI EN 319 411-1 separates Certificate Policy from Certification Practice Statement work for certification authorities and trust service providers.

ETSI EN 319 411-1 certificate re-key FAQ

What ETSI EN 319 411-1 requires when a TSP re-keys an existing certificate with a new subject public key.

ETSI EN 319 411-1 Certificate Suspension FAQ

How CAs should handle certificate suspension under ETSI EN 319 411-1: CPS disclosure, validated requests, status publication, subscriber notice, and audit evidence.

ETSI EN 319 411-1 Certification Audit Evidence FAQ

How CAs should prepare ETSI EN 319 411-1 audit evidence for CP/CPS scope, registration records, revocation records, CA key logs, and retained assessment files.

How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?

What ETSI EN 319 411-1 expects CAs to evidence for certificate revocation requests, status publication, CRL or OCSP updates, and archived revocation records.

RA delegation under ETSI EN 319 411-1

How certificate authorities can delegate registration authority work under ETSI EN 319 411-1 while keeping identity validation, secure data exchange, role controls, and audit evidence traceable.

Subscriber agreements under ETSI EN 319 411-1

How ETSI EN 319 411-1 expects CAs and TSPs to inform subscribers, record acceptance, handle subject consent, and retain subscriber-agreement evidence.

Subscriber identity validation under ETSI EN 319 411-1

How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records.