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
May 9, 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 May 9, 2026
Overview

Use this page when an ETSI EN 319 411-1 certificate service needs a defensible CA key-management record. The page focuses on what the standard says about CA signing-key use, generation ceremonies, secure cryptographic devices, backup and recovery, activation data, and lifecycle closeout.

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, secure cryptographic device 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 secure cryptographic device 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 secure cryptographic device 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.

For a visitor reviewing a CA program, the important question is not only whether an HSM exists. The record should prove the device was operated in its certified or equivalent secure configuration, shipment and storage tamper controls were checked, access controls prevent key extraction, and the device was functioning correctly when relied on.

  • 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 secure cryptographic device 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.

  • 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.
Section 5

Checklist for reviewing EN 319 411-1 CA key management

Use 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 secure cryptographic device 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.
  • 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 general certificate-service requirements with EN 319 411-2 EU qualified certificate requirements, including policy scope, CP/CPS evidence, and audit 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, 24-hour CRL or OCSP publication controls, and audit evidence.
ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements
Compare how EN 319 411-1 incorporates CA/B Forum BRG concepts for DVCP, OVCP, IVCP, [WEB] requirements, CPS disclosure, domain validation, and conflict handling.
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.