---
title: "ETSI EN 319 411-1 CA Key Management"
canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/ca-key-management"
source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/ca-key-management"
author: "Sorena AI"
description: "CA key management guidance for ETSI EN 319 411-1: CPS commitments, key ceremonies, secure cryptographic devices, backup, recovery, and lifecycle evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "ETSI EN 319 411-1"
  - "CA key management"
  - "CPS"
  - "key ceremony"
  - "secure cryptographic device"
  - "certificate policy"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

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

*Artifact Guide* *GLOBAL* *ETSI 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.

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.

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

Sources for this answer:

- [ETSI EN 319 411-1 V1.5.1, clauses 5.2 and 6.5](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the need to document CPS practices for CA-key use and the detailed key-management controls in clause 6.5.
- [ETSI EN 319 401 V3.1.1, clauses 6.1 and 7.10](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the broader TSP practice-statement and evidence-retention duties that EN 319 411-1 builds on.

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

Sources for this answer:

- [ETSI EN 319 411-1 V1.5.1, clause 6.5.1](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the key-generation ceremony procedure, report contents, signing expectations, and pre-generated-key checks.

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

Sources for this answer:

- [ETSI EN 319 411-1 V1.5.1, clause 6.5.2](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports secure cryptographic device assurance, operating-configuration, key containment, backup-copy protection, tamper, and retirement controls.

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

Sources for this answer:

- [ETSI EN 319 411-1 V1.5.1, clauses 6.5.2 to 6.5.4](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports dual-control backup and recovery, lifecycle-use limits, end-of-life destruction, and activation-data handling.
- [ETSI EN 319 401 V3.1.1, clauses 7.10 and 7.11](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports evidence retention for key-management events and continuity planning when private signing keys or other credentials are compromised.

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

Sources for this answer:

- [ETSI EN 319 411-1 V1.5.1, clause 6.5](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the checklist items for ceremony evidence, device protection, backup, recovery, key usage limits, activation data, and subject-key handling.
- [ETSI EN 319 401 V3.1.1, clause 7.10](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports keeping accessible evidence for significant key-management events and service continuity.

*Recommended next step for ETSI EN 319 411-1 CA key management*

*Placement: after practical guidance*

## Operationalize CA key management

Use this ETSI EN 319 411-1 guidance to organize CPS clauses, ceremony reports, device records, backup and recovery evidence, and lifecycle reviews.

- [Open Assessment Autopilot for ETSI EN 319 411-1](/solutions/assessment.md): Convert CA key-management controls into owned evidence requests and review milestones.
- [Research ETSI EN 319 411-1 source questions](/solutions/research-copilot.md): Use cited ETSI source material to resolve CPS, ceremony, secure-device, and lifecycle questions before implementation.
- [Talk through CA key-management evidence](/contact.md): Review CA key scope, ceremony records, device evidence, and next actions with Sorena.

## Primary sources

- [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - 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.
  - Quote: "Private key protection and cryptographic module engineering controls"
- [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports general TSP practice-statement, evidence retention, time-recording, continuity, and private signing-key compromise context.
  - Quote: "Collection of evidence"

## Related Topic Guides

- [CP vs CPS under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md): 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](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-en-319-411-2.md): 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](/artifacts/global/etsi-en-319-411-1/audit-file-evidence.md): 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](/artifacts/global/etsi-en-319-411-1/certificate-lifecycle-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/faq/re-key.md): 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](/artifacts/global/etsi-en-319-411-1/faq/suspension.md): 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](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md): 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](/artifacts/global/etsi-en-319-411-1/compliance.md): 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](/artifacts/global/etsi-en-319-411-1/cp-and-cps-template.md): 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](/artifacts/global/etsi-en-319-411-1/faq.md): 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](/artifacts/global/etsi-en-319-411-1/identity-validation.md): 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](/artifacts/global/etsi-en-319-411-1/identity-validation-evidence-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/ra-delegation.md): 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](/artifacts/global/etsi-en-319-411-1/ra-delegation-review-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/requirements.md): 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](/artifacts/global/etsi-en-319-411-1/revocation-evidence-workflow.md): 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](/artifacts/global/etsi-en-319-411-1/revocation-ocsp-and-crl-operations.md): 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](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-ca-browser-forum-baseline-requirements.md): 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?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md): 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](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md): 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](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md): 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](/artifacts/global/etsi-en-319-411-1/faq/subscriber-identity-validation.md): How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1/ca-key-management