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 Certificate Services FAQ

Answers for TSP teams applying ETSI EN 319 411-1 to certificate policies, CPS commitments, certificate lifecycle controls, and audit evidence.

Based on ETSI EN 319 411-1 V1.5.1 and ETSI EN 319 401. Use it as implementation guidance, not for legal interpretation.

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

This FAQ explains how ETSI EN 319 411-1 applies to trust service providers issuing certificates. It focuses on the recurring questions behind selection, CPS evidence, CA and RA responsibilities, subscriber validation, revocation, status services, and records that auditors and relying parties expect to trace.

Browse sub-FAQs

Choose the question set you need

These focused FAQ modules break this artifact into narrower answer sets so teams can move straight to the right source-backed guidance.

Browse all FAQ items28
Focused FAQ modules
8
Showing 8 of 8
FAQ module

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.

3 items
FAQ module

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.

3 items
FAQ module

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.

3 items
FAQ module

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.

4 items
FAQ module

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.

3 items
FAQ module

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.

4 items
FAQ module

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.

4 items
FAQ module

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.

4 items
Question 1

What does ETSI EN 319 411-1 cover?

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 , the certificate profile, the relying-party use case, and the CA or RA functions in scope.

The reference policy names are Lightweight (LCP), Normalized Certificate Policy (NCP), and Extended Normalized Certificate Policy (NCP+). Website policy names identify Domain Validation Certificate Policy (DVCP), Organizational Validation Certificate Policy (OVCP), Individual Validation Certificate Policy (IVCP), and Extended Validation Certificate Policy (EVCP).

  • Use ETSI EN 319 411-1 as the general policy-and-security baseline for certificate services; it is not limited to a single certificate type or legal regime.
  • Add the applicable EN 319 411-2 profile and eIDAS evidence when the service claims EU qualified certificate status; Part 1 alone does not establish qualified status.
  • For TLS and website authentication certificates, check the ETSI policy marking and the CA/Browser Forum dependency before treating the ETSI text as the complete rule set.
  • Keep the selected policy OID, certificate profile, CPS version, and service boundary together in the audit file.
Question 2

What is the difference between a Certificate Policy and a CPS?

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

  • Do not let the CPS merely repeat the CP; it should describe the provider-specific practices used to satisfy the policy.
  • Do not publish internal runbooks unnecessarily; ETSI recognizes that low-level operational procedures can remain private while still supporting the CPS.
  • Make the CP and CPS cross-reference each other so subscribers, subjects, relying parties, and auditors can understand the service without guessing.
  • When the TSP supports a CP created by another body, document how the service complies with that CP and where any permitted variances are handled.
Recommended next step

Operationalize ETSI EN 319 411-1 certificate questions

This FAQ is the starting point for CP/CPS review, certificate lifecycle evidence, subscriber disclosures, and audit-ready records.

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

Convert certificate policy questions into accountable controls, evidence requests, and audit review tasks.

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

Resolve CP, CPS, CA, RA, revocation, and status-service questions against cited ETSI source material.

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

Review certificate-service scope, evidence gaps, and the next CP/CPS actions with Sorena.

Explore next step
Question 3

What evidence should an ETSI EN 319 411-1 audit file contain?

The evidence should prove the service actually ran under the named CP and CPS during the assessment period. The file should link each 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.

  • Apply the seven-year minimum in clause 6.4.6 to the records it names: CA-managed key-lifecycle logs and the certificate-acceptance documentation identified in clause 6.3.4. Set other retention periods from the applicable ETSI requirement, disclosed terms, law, contract, or scheme rule.
  • Keep evidence separated by and certificate profile so an auditor can distinguish, for example, LCP evidence from NCP or EVCP evidence.
  • Record exceptions as scoped decisions tied to a requirement, not as free-text explanations hidden in the CPS.
  • Make CRL, OCSP, repository, issuance, renewal, re-key, modification, revocation, and suspension evidence traceable to the same certificate population.
  • Identify any short-term certificate population that the CPS says cannot be revoked; EN 319 411-1 allows specified revocation-management requirements to be omitted for that population and adds problem-notification and audit-log requirements.
Question 4

How should CA and RA responsibilities be handled?

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.

  • Define the CA, RA, subscriber, subject, relying-party, and repository roles before issuing under a policy.
  • Tie each RA activity to the CP/CPS clause that authorizes it and to logs showing the activity occurred.
  • Protect registration data in transit and at rest, especially when it moves between distributed TSP components.
  • Use multi-factor authentication and trusted-role access controls for accounts that can directly cause certificate issuance.
Question 5

What should subscribers and relying parties be told?

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 identifier, the certificate usage limits, how to check revocation status, and where the TSP publishes the relevant repository information.

  • Name the applicable CP, CPS, subscriber agreement, terms and conditions, and any PKI disclosure statement.
  • Describe subscriber obligations such as protecting private keys, checking certificate content, and requesting revocation when required by the policy.
  • Tell relying parties how certificate status should be checked and which CRL or OCSP service applies.
  • Expose audit or conformity information carefully: say what was assessed, for which policy, and under which scheme rather than implying blanket coverage.
Question 6

When does eIDAS change the ETSI EN 319 411-1 answer?

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

  • Use EN 319 411-1 to explain general certificate-service controls.
  • Use EN 319 411-2 and the eIDAS context when the service is issuing EU qualified certificates.
  • Keep qualified-status, trust-list, and supervisory claims separate from ordinary CP/CPS implementation evidence.
  • Do not use broad phrases such as "eIDAS compliant" unless the page identifies the exact service, policy, assessment, and legal basis.
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 the page's certificate policy families, CP/CPS distinction, CA/RA roles, certificate lifecycle, revocation, status services, records archival, and audit evidence guidance.
  • Supports the page scope: ETSI EN 319 411-1 is Part 1 for TSPs issuing certificates and defines policy families including LCP, NCP, NCP+, DVCP, OVCP, IVCP, and EVCP.
  • Supports the CP/CPS distinction and the expectation that the CPS describes provider practices while low-level internal procedures may remain private.
Show 4 more
  • Supports the certificate lifecycle, repository, revocation, certificate status, records archival, audit logging, short-term-certificate exceptions, and the scoped seven-year retention rule summarized here.
  • Supports the RA role, registration data protection, trusted-role controls, and multi-factor authentication for accounts capable of directly causing issuance.
  • Supports the PKI disclosure, subscriber obligation, relying-party status-checking, applicable agreement, and audit-context points in this answer.
  • Supports the distinction between this Part 1 general standard and references to ETSI EN 319 411-2 for EU qualified certificates.
"Policy and security requirements for Trust Service Providers issuing certificates"
More quoted passages
"what is to be adhered to"
"at least seven years"
"responsible for identification and authentication"
"not intended to replace a CP or CPS"
"Part 1: General requirements"
ETSI EN 319 401 V3.2.1 general policy requirements for TSPs
etsi.org4 citations
Referenced sections
  • Supports the general trust-service management, policy, risk, security, continuity, incident, access-control, and audit context imported by ETSI EN 319 411-1.
  • Confirms the January 2026 edition of the general TSP standard that applies through EN 319 411-1's non-specific normative reference; the assessment file should identify the editions and assessment date used.
  • Supports the wider trust-service practice statement, policy, risk, management, security, incident, continuity, and audit context used by ETSI EN 319 411-1.
Show 1 more
  • Supports general TSP management controls such as segregation of duties, human resources, asset management, access control, operation security, monitoring, and incident response.
"General Policy Requirements for Trust Service Providers"
More quoted passages
"ETSI EN 319 401 V3.2.1 (2026-01)"
"TSP management and operation"
Regulation (EU) No 910/2014, current consolidated text
eur-lex.europa.eu2 citations
Referenced sections
  • Supports the EU trust-services context and the caution that qualified-status claims need the applicable eIDAS and qualified-certificate basis, not EN 319 411-1 alone.
  • Supports the EU trust-services context for qualified status, supervisory framing, and public claims about eIDAS.
"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 Compliance Guide

Build an ETSI EN 319 411-1 compliance file for certificate policies, CPS commitments, certificate lifecycle controls, revocation services, CA keys, and audit evidence.

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.

Show all related guides (14)

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.