Artifact GuideGLOBALETSI EN 319 411-1

ETSI EN 319 411-1 CA Key Management

A focused guide to the EN 319 411-1 controls that protect CA signing keys from generation through retirement.

Use it to align CPS commitments, key ceremony records, device controls, backup, recovery, and end-of-life evidence.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
10

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

Build the CA key-management record around signing-key use, generation ceremonies, a , backup and recovery, activation data, compromise response, and lifecycle closeout. Each control should point to the CPS commitment, device evidence, ceremony record, role authorization, or event log that supports it. This page applies EN 319 411-1 V1.5.1 (April 2025). Its EN 319 401 reference is non-specific, so clause 2.1 makes the latest edition applicable; record the EN 319 401 edition and assessment date used.

Section 1

Start with the CPS commitments for CA key use

ETSI EN 319 411-1 requires the Certification Practice Statement to include the signature algorithms and parameters used by the TSP, and to specify the practice for using CA keys to sign certificates, CRLs, and OCSP. Treat those CPS clauses as the control baseline for the key-management file.

A useful CA key-management record should identify every CA signing key, whether it is for a root or subordinate CA, how it is authorized for certificate issuance or revocation-status signing, and which CP/CPS text limits its use. Keep internal ceremony procedures private when necessary, but make sure the CPS and retained evidence still prove the public commitment.

  • List each CA signing key with its CA role, certificate policy, key identifier, algorithm, key size, public key fingerprint, and intended signing purpose.
  • Tie each key to CPS language for certificate signing, CRL signing, OCSP signing, and any restrictions on cross-use.
  • Record which certificate profiles and policy OIDs the key supports, especially when NCP, NCP+, LCP, DVCP, OVCP, IVCP, or EVCP policies are in scope.
  • Keep a change record when CPS text, signing algorithms, certificate profiles, or revocation-status architecture changes.
Section 2

Build a complete CA key ceremony file

Clause 6.5.1 requires a documented procedure for CA key pair generation for all CAs, including root CAs and subordinate CAs that issue end-user certificates. The ceremony file should show that the procedure was followed and that the integrity and confidentiality of the generated key pair were protected.

The standard is specific about ceremony evidence. The report should identify participating roles, functions performed in each phase, responsibilities during and after the ceremony, evidence collected, the ceremony date, generated-key inventory, details, and the configured generation algorithm and settings.

  • Prepare the ceremony script before generation, including internal and external roles, phase-by-phase duties, approval points, and evidence to collect.
  • Capture the generated-key inventory with unique key identifiers, algorithms, key sizes, and public key fingerprints using SHA-256 or stronger.
  • Record the identifier and model, plus generation settings such as mode, random-number generator, and other cryptographic parameters.
  • Have the report signed by the required trusted role, and for a root CA include the independent witness expected by EN 319 411-1.
  • If keys are pre-generated for later use, mark them clearly and reassess algorithm, length, device, and RNG suitability before putting them into operation.
Section 3

Protect CA private signing keys inside approved devices

EN 319 411-1 expects TSP key pair generation, including keys used by revocation and registration services, to be carried out in a that meets the standard's assurance options. The CA private signing key must be held and used within that device, and any protection outside the device has to provide the same level of protection.

An HSM label is not enough. The record should identify which assurance route is used, prove the device was operated in its certified guidance configuration or an equivalent configuration that achieves the same security objective, document shipment and storage tamper controls, and show that access controls prevent key extraction. The ISO/IEC 15408 route permits equivalent recognized criteria only where the security target or protection profile meets this standard, based on risk analysis and relevant physical and non-technical measures.

  • Keep device assurance evidence for the selected route, such as ISO/IEC 15408 EAL 4 or higher, ISO/IEC 19790, or FIPS 140-2 or FIPS 140-3 level 3.
  • Retain the device configuration baseline and any certification guidance showing how the device must be operated.
  • Document tamper checks for shipment and storage before key generation, backup, recovery, or installation events.
  • Limit access so CA private signing keys and copies are not accessible outside the dedicated unless equivalent protection is evidenced.
  • Record device-retirement actions that destroy the CA private signing key instance stored on the retired device.
Section 4

Control backup, recovery, activation data, and key lifetime

Backup and recovery are part of the CA key-management surface, not a separate IT housekeeping task. EN 319 411-1 requires CA private signing-key backup, storage, and recovery to be performed only by personnel in trusted roles, using at least dual control in a physically secured environment, and with the number of authorized personnel kept to a minimum.

The same file should prove that the key was used only for its authorized lifecycle and purpose. EN 319 411-1 says CA signing keys used for certificate generation or revocation-status information are not to be used for any other purpose, are not to be used beyond lifecycle end, and copies are destroyed at lifecycle end. The business continuity or disaster recovery plan must treat compromise, loss, or suspected compromise of a CA private key as a disaster. In the case of compromise, the standard also requires notification and CA-certificate revocation actions.

  • Maintain a trusted-role roster for backup, storage, recovery, installation, and activation events, including dual-control evidence.
  • Log key-management events with precise time records, synchronized time sources, and records retained under the TSP evidence-retention practice.
  • Keep activation data procedures separate from device delivery where secure devices and associated activation data are issued.
  • Verify that CA signing-key use matches the hash algorithm, signature algorithm, signature key length, and intended certificate or revocation-status purpose.
  • Close the lifecycle with evidence that keys are withdrawn, destroyed, or replaced before CA certificate expiration creates disruption for relying parties.
  • For compromise, retain the incident decision, notifications to subscribers and established relying parties, public notice to other relying parties, the warning that affected certificates and status information may no longer be valid, and revocation of any CA certificate the TSP issued for the compromised CA. For loss or suspected compromise, retain the incident decision and actions taken under the continuity plan.
Section 5

Checklist for reviewing EN 319 411-1 CA key management

Treat this checklist as an audit-file review before a key ceremony, CA changeover, conformity assessment, or major CPS update. Each item should be answered with a document, log, ceremony report, device record, or exception note rather than a generic statement of intent.

  • CPS coverage: the CPS names signature algorithms, parameters, and CA-key practices for certificates, CRLs, and OCSP.
  • Ceremony evidence: the key-generation report includes roles, functions, responsibilities, collected evidence, date, key inventory, device details, and device generation settings.
  • Device assurance: the evidence matches the assurance route and configuration relied on for key generation and use.
  • Backup and recovery: trusted-role, dual-control, physically secured backup, storage, and recovery records exist for CA private signing keys and copies.
  • Purpose and lifecycle: CA signing keys are not used outside certificate generation or revocation-status purposes, and no key is used beyond its lifecycle.
  • Compromise response: the continuity plan covers compromise, loss, and suspected compromise; for a compromise, required parties are informed, affected validity is communicated, and CA-certificate revocation decisions are recorded.
  • Subject-key edge cases: if the CA generates subject keys, the file shows secure generation, delivery, deletion of retained copies after delivery, and revocation when unauthorized disclosure is known.
  • Changeover and retirement: new CA certificates, relying-party distribution, device retirement, and key destruction actions are planned before existing CA certificates or keys reach end of life.
Primary sources

References and citations

etsi.org
Referenced sections
  • Supports keeping accessible evidence for significant key-management events and service continuity.
"all relevant information concerning data issued"
etsi.org
Referenced sections
  • Supports evidence retention for key-management events and continuity planning when private signing keys or other credentials are compromised.
"key management and clock synchronization events"
etsi.org
Referenced sections
  • Primary source for EN 319 411-1 CA key generation, ceremony reports, secure cryptographic devices, CA private-key protection, backup, recovery, activation data, and key lifecycle controls.
"Private key protection and cryptographic module engineering controls"
etsi.org
Referenced sections
  • Supports the checklist items for ceremony evidence, device protection, backup, recovery, key usage limits, activation data, and subject-key handling.
"Other aspects of key pair management"
etsi.org
Referenced sections
  • Supports the key-generation ceremony procedure, report contents, signing expectations, and pre-generated-key checks.
"documented procedure for conducting CA key pair generation"
etsi.org
Referenced sections
  • Supports secure cryptographic device assurance, operating-configuration, key containment, backup-copy protection, tamper, and retirement controls.
"held and used within a secure cryptographic device"
etsi.org
Referenced sections
  • Supports the need to document CPS practices for CA-key use and the detailed key-management controls in clause 6.5.
"practice regarding the use of CA keys"
Related guides

Explore more topics

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