Artifact GuideGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 How should certificate authorities handle certification audit evidence under ETSI EN 319 411-1

A focused answer for CAs and TSP teams preparing evidence for an ETSI EN 319 411-1 assessment.

Use it to structure assessor-ready evidence without exposing confidential operating procedures in public-facing material.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

Keep as a traceable file that connects the assessed CA service, certificate policy, CPS, assessment period, requirement identifiers, and retained operational records. This page applies ETSI EN 319 411-1 V1.5.1 (April 2025). Its technical requirements enter the audit boundary through the selected certificate policy, conformity-assessment scheme, contract, or applicable law; the standard does not create a worldwide certification law. ETSI EN 319 411-1 points auditors toward the CP/CPS, registration and certificate-lifecycle evidence, revocation evidence, audit logs, records archival, and CA key lifecycle records. Its informative Annex B points to a separate ETSI TR 119 411-4 conformity assessment checklist; the annex is assessment guidance, not a certification claim.

Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

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

Start with the audit boundary. The evidence file should identify the TSP or CA service being assessed, the applicable certificate policy, the CPS version, the certificate profiles and policy OIDs in use, the assessment period, and whether registration, certificate generation, dissemination, revocation management, revocation status, and subject-device provisioning are in scope.

Then map the file to requirement identifiers and operating records. EN 319 411-1 requirement IDs identify registration (REG), certificate generation (GEN), revocation (REV), certificate status (CSS), dissemination (DIS), subject-device provisioning (SDP), and general requirements (OVR). Informative Annex B points to the separate ETSI TR 119 411-4 conformity assessment checklist. An should be able to follow each sampled requirement from the CP/CPS commitment to the retained record that proves operation during the assessment period.

  • Keep a scope sheet naming the CA hierarchy, certificate policies, certificate profiles, repository locations, revocation-status methods, RAs, outsourced components, and excluded services.
  • Trace each evidence request to the CP/CPS clause, EN 319 411-1 requirement ID, assessed period, record owner, evidence location, and sampling result.
  • Separate public CP/CPS and terms from confidential procedure evidence; EN 319 411-1 allows sensitive operational detail to remain outside the published CPS.
  • Record open findings with the affected requirement, evidence gap, corrective-action owner, and retest evidence rather than closing them with a certification label alone.
Question 2

Which operating records should the audit file contain?

The core evidence should prove that the certificate service operated as documented. For registration, keep application and identity-validation records, subscriber-agreement evidence, the accepting entity, validation method, RA handoff, and the location of supporting documents. For certificate lifecycle events, keep certificate requests, accuracy and authorization checks, issuance links to registration, renewal, re-key, modification, and dissemination evidence.

For revocation and status services, retain authenticated revocation requests, event reports, resulting actions, timing evidence, CRL or OCSP publication records, and exception records where confirmation or publication timing could not be met. For CA keys, keep key lifecycle logs and ceremony evidence, including the ceremony requirements and collected evidence for CA key generation or installation.

  • Registration evidence: certificate application, identity and attribute validation, proof of possession or control, subscriber authorization, subscriber agreement, and RA transfer records.
  • Certificate lifecycle evidence: request source, completeness checks, issuance record, certificate profile and CP identifier, renewal/re-key/modification checks, and dissemination evidence.
  • Revocation evidence: authenticated request or report, authorization check, status-change timing, exception justification, CRL or OCSP publication, and relying-party status availability.
  • Operations evidence: security-event logs, registration logs, certificate lifecycle logs, CA key lifecycle logs, archive access controls, and retention proof.
Question 3

How should teams package the evidence for assessment?

Package the file so the assessor can sample without reconstructing the service from scratch. Use one index for scope and documents, one matrix for EN 319 411-1 requirement IDs, and separate folders for registration, certificate lifecycle, revocation/status, CA key management, audit logs, records archival, supplier or RA evidence, and corrective actions.

Retention should be explicit by record class. Clause 6.4.6 requires the TSP to retain CA-managed key-lifecycle logs and the documentation identified in clause 6.3.4 for at least seven years after any certificate based on those records ceases to be valid. Do not apply that sentence automatically to every audit artifact: show the ETSI requirement, disclosed terms, legal or scheme rule, archive location, integrity control, and access path that govern each record class.

  • Index public documents separately from confidential procedures: CP, CPS, terms and conditions, PKI disclosure statement, repository URLs, and certificate policy identifiers.
  • For each sampled requirement, keep the request, artifact, owner, assessment period, system or repository location, and assessor conclusion in the same evidence row.
  • Flag reused evidence from previous certifications or third-party evaluations with scope, date, scheme, test report, and assessor verification status.
  • Keep remediation evidence separate from original operating evidence so the audit trail shows both the finding and the corrective action.
Question 4

Questions and answers

What should a file identify first?

Start with the audit boundary. The evidence file should identify the TSP or CA service being assessed, the applicable certificate policy, the CPS version, the certificate profiles and policy OIDs in use, the assessment period, and whether registration, certificate generation, dissemination, revocation management, revocation status, and subject-device provisioning are in scope.

Which operating records should the audit file contain?

The core evidence should prove that the certificate service operated as documented. For registration, keep application and identity-validation records, subscriber-agreement evidence, the accepting entity, validation method, RA handoff, and the location of supporting documents. For certificate lifecycle events, keep certificate requests, accuracy and authorization checks, issuance links to registration, renewal, re-key, modification, and dissemination evidence.

How should teams package the evidence for assessment?

Package the file so the assessor can sample without reconstructing the service from scratch. Use one index for scope and documents, one matrix for EN 319 411-1 requirement IDs, and separate folders for registration, certificate lifecycle, revocation/status, CA key management, audit logs, records archival, supplier or RA evidence, and corrective actions. State the retention basis for each record class. Clause 6.4.6 sets at least seven years after the relevant certificate ceases to be valid for CA-managed key-lifecycle logs and the certificate-acceptance documentation identified in clause 6.3.4; other records follow their applicable ETSI, legal, contractual, and disclosed retention rules.

Primary sources

References and citations

etsi.org4 citations
Referenced sections
  • Primary ETSI source for general TSP policy, evidence collection, management, security, continuity, legal, termination, and supplier-control obligations that support certification-service audit evidence.
  • Clause 7.10 supports retaining accessible, confidential, integrity-protected operational records for evidence and service continuity.
  • Supports keeping general TSP operational evidence for access control, backup, continuity, incident handling, termination planning, and supplier arrangements where they affect the assessed service.
Show 1 more
  • Supports retaining general trust-service records and evidence needed to show legal, trustworthy, secure, continuous, and supplier-controlled operation.
"General Policy Requirements for Trust Service Providers"
More quoted passages
"record and keep accessible for an appropriate period of time"
"Collection of evidence"
"provide evidence"
etsi.org4 citations
Referenced sections
  • Primary ETSI source for the page's CP/CPS, service component, registration, certificate lifecycle, revocation, audit logging, records archival, CA key lifecycle, and conformity-checklist claims.
  • Supports using the CP, CPS, service components, requirement identifiers, and Annex B checklist as the structure for audit evidence.
  • Supports the listed evidence categories for registration, certificate application processing, certificate issuance, revocation, status services, audit logging, and CA key lifecycle records.
Show 1 more
  • Supports packaging evidence by CP/CPS and service component, and clause 6.4.6's seven-year minimum for the specific CA-managed key-lifecycle logs and clause 6.3.4 documentation it lists.
"Policy and security requirements"
More quoted passages
"Conformity assessment checklist"
"All events related to registration"
"at least seven years"
Show all related guides (22)

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.

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.

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.

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.