Designing a Root CA Ceremony for PKIaaS

Every certificate in a PKI hierarchy traces its chain of trust back to the root CA. The root CA’s private key is the cryptographic anchor on which that trust rests. If the root CA key was generated insecurely, in an uncontrolled environment, without witnesses, without documented procedures, or without appropriate hardware protection, then every certificate ever issued under that CA carries an invisible qualification: the chain of trust is only as trustworthy as the conditions under which the root key was created.

A root CA key ceremony is the formal procedure that establishes the trustworthiness of that cryptographic anchor. It is not a bureaucratic formality. It is the event that auditors point to when they need evidence that a CA hierarchy was established correctly. It is what a compliance program references when asserting that PKI key material was generated under appropriate controls. And for organizations deploying PKI as a Service with customer-hosted or hybrid deployment models, it is a significant operational event that requires careful planning and expert execution.

This guide covers what goes into designing and executing a root CA key ceremony: the pre-ceremony planning work, the roles that must be filled, the equipment required, the ceremony script from HSM initialization through evidence collection, and the post-ceremony storage and governance controls that protect the key material and the ceremony record.

Quick Answer: What Is a Root CA Key Ceremony?

A root CA key ceremony is a formally documented, witnessed, and audited procedure for generating the root CA private key in a FIPS 140-3 Level 3 validated HSM under M-of-N custodian controls. The ceremony produces three things: the root CA key pair (stored in the HSM and never exported in unencrypted form), the root CA self-signed certificate (distributed to trust stores), and the ceremony evidence package (the auditable record that the key generation occurred correctly under the stated controls). Everything in the PKI hierarchy that follows the ceremony depends on the trustworthiness established by it.

Key Takeaways

• The root CA key ceremony is a governance event, not just a technical procedure. The evidence package it produces is an audit artifact referenced by WebTrust for CAs, ETSI EN 319 411, SOC 2 Type II, FedRAMP, CMMC, and PCI DSS auditors. An incomplete or undocumented ceremony is a common finding in PKI audits and a material weakness in the organization’s PKI governance posture.
• Pre-ceremony planning is where most ceremonies succeed or fail. The Certificate Policy, CP/CPS, role assignments, ceremony script, equipment checklist, and HSM configuration must all be finalized before the ceremony date. A ceremony conducted without a reviewed and approved script is operationally risky: errors under time pressure with multiple witnesses present are difficult to recover from gracefully.
• M-of-N controls for root CA operations are a mandatory governance requirement, not an optional security enhancement. M should be set high enough that collusion requires multiple people who do not all work in the same team or reporting chain. N should be large enough that the quorum can be reached without depending on any single individual’s availability. A 3-of-5 or 3-of-7 configuration is common for enterprise root CA ceremonies.
• The ceremony environment must be documented in as much detail as the ceremony procedures themselves. Physical access controls, video surveillance, who entered and exited the room, the HSM’s serial number and firmware version, and the state of all evidence at the end of the ceremony are all part of the evidence package that auditors examine.
• Post-ceremony storage of the HSM, backup key material, and ceremony evidence is as important as the ceremony itself. A root CA whose backup key material is stored insecurely, or whose ceremony evidence is not archived in a retrievable format, has an incomplete governance story even if the ceremony was conducted correctly.

Why the Root CA Ceremony Matters

The root CA private key is used for exactly one type of operation under normal circumstances: signing the certificates of subordinate CAs (intermediate or issuing CAs) that sit below the root in the hierarchy. It is not used for issuing end-entity certificates; it is offline between subordinate CA ceremonies. Its only operational appearances are at the initial ceremony (to generate and sign its own self-signed certificate and sign the first issuing CA certificate) and at subsequent ceremonies to sign new or renewed subordinate CA certificates.

Because the root CA key is used so infrequently, its compromise might not be detected for years. A compromised root CA key allows an attacker to sign any CA certificate they choose, which would allow them to issue certificates for any domain or identity that PKI relying parties would trust as if they were legitimate. The consequences are systemic: every certificate issued under the compromised root is potentially suspect, and the remediation requires replacing the root CA key and re-issuing the entire certificate hierarchy.

This is why the key generation event, the ceremony, matters so much. If the ceremony was conducted correctly, with documented controls, witnessed by multiple parties, and with the key material stored only in hardware that prevents extraction, then the trustworthiness of the root CA key can be asserted with evidence. If it was not, the best the organization can say is that they believe the key is secure, which is not an auditable claim.

Phase 1: Pre-Ceremony Planning (4 to 8 Weeks Before)

CP/CPS Alignment

The Certificate Policy (CP) and Certification Practice Statement (CPS) must be drafted and reviewed before the ceremony, because the ceremony procedures must conform to what the CP/CPS states. If the CP/CPS specifies a 3-of-5 M-of-N configuration for root CA operations and the ceremony is conducted with a 2-of-3 configuration, the ceremony does not conform to the stated policy and the PKI is operating outside its documented governance framework from day one.

The CP/CPS sections most directly relevant to the ceremony are: Section 6 (Technical Security Controls) for the key generation procedure, HSM requirements, and M-of-N configuration; Section 5 (Management, Operational and Physical Controls) for the ceremony environment, physical access requirements, and personnel controls; and Section 4.8 (Certificate Modification) or the relevant section on subordinate CA issuance for the procedures governing signing of subordinate CA certificates. Review these sections against the planned ceremony script before finalizing either document.

CA Hierarchy Design

Before the ceremony, the CA hierarchy design must be finalized: how many tiers (two-tier with root and issuing, or three-tier with root, intermediate, and issuing), which certificate profiles will be used for each CA, what key algorithms and key sizes will be used at each level, and what the validity periods for each CA certificate will be. These decisions cannot be revised after the root CA key is generated without creating a new root CA and repeating the ceremony.

For PKIaaS deployments, the hierarchy design should also account for the enrollment protocols (ACME, EST, SCEP, WSTEP, CMP) that the issuing CAs will support, the certificate profiles (TLS, device, user, S/MIME, code signing) that will be issued, and the OCSP and CRL infrastructure that will be referenced in issued certificate extensions. The root CA certificate itself references no CRL or OCSP AIA (root CAs are self-signed and their own revocation is not checkable through standard mechanisms), but all subordinate CA certificates must include CRL DPs and AIA entries that point to operational OCSP and CRL infrastructure.

HSM Selection and Procurement

The HSM for the root CA must be a FIPS 140-2 Level 3 or FIPS 140-3 Level 3 validated device. FIPS 140-3 Level 3 is the current standard; FIPS 140-2 Level 3 devices remain acceptable for existing deployments. Level 3 validation requires physical tamper-evident and tamper-resistant mechanisms, identity-based authentication for module access, and the ability to zeroize all unprotected CSPs (Critical Security Parameters) in response to a tamper event. The specific HSM model should be selected based on the CA software platform (the HSM must support PKCS#11 or CNG/CryptoAPI as appropriate for the CA software), the key algorithms required (RSA-4096, ECDSA P-384, or PQC algorithms if hybrid certificates are in scope), and the M-of-N implementation supported by the HSM’s firmware.

Order the HSM far enough in advance to receive and verify it before the ceremony. On receipt, verify the HSM’s authenticity using the manufacturer’s verification procedure (most HSM vendors provide a web-based verification service using the device’s serial number and a hardware attestation), record the serial number and firmware version in the pre-ceremony documentation, and confirm that the device has not been tampered with during shipping.

Ceremony Script Development

The ceremony script is the step-by-step procedure document that will be followed during the ceremony. It must be detailed enough that any step can be executed correctly by the assigned personnel without judgment calls or improvisation. Each step in the script should specify: who performs the action, what command or interface operation is performed, what the expected output is, and what the witness must observe and attest to. The script should also specify what to do if a step fails or produces unexpected output: what constitutes a recoverable error (retry, check configuration, proceed with caution) versus an unrecoverable error (stop the ceremony, secure all materials, convene a post-mortem before proceeding).

The ceremony script must be reviewed and approved by the ceremony’s Internal Auditor and the CA Owner before the ceremony date. Changes to the script after approval require a documented change review. On the day of the ceremony, each step in the script is initialed by the person who performed it and at least one witness; these initialed copies become part of the evidence package.

Phase 2: Ceremony Role Assignments

Every person in the ceremony room has a defined role with specific responsibilities. Roles should be assigned to named individuals and confirmed in writing before the ceremony. No role should be held by someone who also holds a conflicting role. The specific role names may vary by organization and PKIaaS provider, but the functional responsibilities are consistent across well-designed ceremonies.

Ceremony Master

The Ceremony Master is responsible for executing the ceremony script step by step and for overall coordination of the ceremony. The Ceremony Master calls each step, confirms that the correct personnel are ready before proceeding, and is responsible for the pacing and completeness of the ceremony. They do not hold a custodian role (to avoid conflicts of interest between coordinating and authorizing) and should be an experienced PKI engineer who has reviewed the ceremony script thoroughly. For organizations without internal ceremony experience, an external PKI consultant in the Ceremony Master role significantly reduces execution risk.

Key Custodians (M-of-N)

Key Custodians are the personnel who hold individual authentication credentials (HSM operator cards, smartcards, or software tokens depending on the HSM’s M-of-N implementation) that are required to authorize high-privilege HSM operations. Each custodian holds exactly one credential; no custodian holds more than one. In a 3-of-5 configuration, five custodians each receive one of five operator cards during the ceremony, and any three of them must cooperate (by presenting their cards simultaneously or in sequence, depending on the HSM implementation) to authorize root CA key operations.

Custodians should be selected from different teams or reporting chains to prevent collusion from being achievable within a single chain of command. In a PKIaaS context where the PKI is managed by the Security team, appropriate custodians might include the CISO, the Head of IT, the Head of Infrastructure, the General Counsel, and an external auditor or executive. The diversity of custodians ensures that authorizing a root CA operation requires cooperation across organizational boundaries.

Internal Auditor

The Internal Auditor observes the ceremony against the approved ceremony script and attests that each step was performed correctly and completely. The Internal Auditor does not perform any technical steps; their role is observation and documentation. They sign the ceremony evidence at each step, and their signature is the attestation that what the evidence documents matches what actually occurred. The Internal Auditor must be independent of the team operating the CA; using the PKI team’s own project manager as the Internal Auditor undermines the independence of the attestation.

External Witness (Optional but Recommended)

An External Witness is a person not employed by the organization who attests to the ceremony proceedings. For organizations seeking WebTrust or ETSI certification, an external auditor in the witness role is part of the certification process. For organizations that are not seeking public trust but want additional assurance on the ceremony evidence, an external PKI consultant or legal counsel in the witness role strengthens the independence of the ceremony attestation.

IT Support / HSM Operator

The IT Support role covers technical operations that are not high-privilege key custodian operations: connecting equipment, installing CA software on the ceremony workstation, initializing the HSM under the direction of the Ceremony Master, and troubleshooting connectivity or configuration issues. IT Support executes the technical steps on the ceremony workstation; they do not hold custodian credentials and cannot authorize key operations independently.

Evidence Recorder

The Evidence Recorder documents the ceremony in real time: recording timestamps for each ceremony step, capturing console output and command history from the ceremony workstation, maintaining the video recording, and collecting the physical evidence items (signed script pages, HSM packaging, custodian token acknowledgment forms). The Evidence Recorder is distinct from the Internal Auditor; the Auditor attests that the process is correct, the Recorder creates the record of what occurred.

Phase 3: Ceremony Environment and Equipment

The physical ceremony environment must satisfy the requirements stated in the CP/CPS for key generation facilities. Typical requirements include: a physically secure room with access controlled by card key or biometric, access logging for the room for the ceremony period, no unauthorized personnel admitted, and a video surveillance system recording the ceremony continuously. The ceremony room should be inspected before participants enter to confirm no unauthorized recording devices or hardware keyloggers are present.

The equipment checklist for the ceremony should be prepared and verified at least 48 hours before the ceremony date. Required equipment typically includes:

• HSM (FIPS 140-3 Level 3 validated), verified authentic, in original packaging until ceremony
• Ceremony workstation: air-gapped laptop or workstation (not connected to any network during the ceremony), operating system freshly installed from verified media, CA software installed and verified, no other software present
• Network-isolated power supply: UPS to prevent the ceremony workstation from losing power mid-operation
• HSM operator cards (N cards, one per custodian, if the HSM uses card-based M-of-N), with card reader
• Backup HSM or HSM backup token (for key backup; the backup must be stored separately from the primary HSM after the ceremony)
• Video recording equipment, positioned to capture the HSM, the workstation screen, and the hands of the operator
• Printed copies of the approved ceremony script (sufficient for all participants to follow along)
• Chain-of-custody forms for each piece of physical media produced during the ceremony
• Tamper-evident bags or containers for post-ceremony storage of HSMs and backup media
• Signing pens (not felt-tip, to produce lasting evidence signatures) for all participants
• Entropy source documentation (if using an external entropy source for key generation in addition to the HSM’s internal entropy)

The ceremony workstation should not have internet connectivity during the ceremony. If CA software requires network connectivity for license validation or software activation, this must be completed before the ceremony begins; the network cable is then physically disconnected and the disconnection is documented before key generation proceeds.

Phase 4: Ceremony Execution

The ceremony execution proceeds through a defined sequence of phases. The following covers the core phases that are common across well-designed root CA key ceremonies; the specific commands and interface operations vary by HSM vendor and CA software platform.

Phase 4.1: Opening and Attendance

The ceremony opens with the Ceremony Master verifying that all required personnel are present, recording each person’s name and role in the ceremony log, confirming that the room is secure and recording equipment is active, and reading the ceremony purpose statement from the script (which is attested to by the Internal Auditor and all participants as accurately reflecting the scope of the ceremony). Each participant signs the ceremony attendance form. Persons not on the approved attendance list are not admitted. If a required role cannot be filled by the assigned individual (illness, unavailability), the ceremony should be postponed rather than conducted with a substitute who has not been vetted for the role.

Phase 4.2: HSM Verification and Initialization

The HSM is removed from its packaging in front of all ceremony participants. The Evidence Recorder documents the serial number, model, and firmware version of the HSM and photographs the packaging. The HSM’s authenticity verification is performed (using the vendor’s verification mechanism) in front of the Internal Auditor, who attests in the ceremony record that the verification succeeded.

The HSM is then initialized: the factory default credentials are cleared, the HSM is placed in a known-good initial state (typically called “factory reset” or “zeroize”), and the initial administrative credentials are set. The zeroization step confirms that no key material from a previous use is present in the HSM before the ceremony’s key material is generated. The Evidence Recorder logs the timestamp and the console output of the zeroization command.

Phase 4.3: M-of-N Configuration and Custodian Initialization

The M-of-N configuration is established on the HSM: the total number of custodians (N), the quorum required for high-privilege operations (M), and the cryptographic parameters for custodian key shares are configured according to the CP/CPS specification. Each custodian’s key share or operator card is then generated and provisioned, one custodian at a time. Each custodian:

• Steps forward to the ceremony workstation while other custodians stand at a designated distance (to prevent shoulder-surfing of PIN or credential entry)
• Sets their personal PIN or password on their operator card
• Receives their operator card or token in an opaque envelope that they seal and sign
• Signs a key custodian acknowledgment form confirming receipt of their credential, their responsibilities as a custodian, and the conditions under which they may use the credential
• Returns to the group

The Evidence Recorder logs each custodian initialization step with a timestamp. The Internal Auditor attests that each initialization occurred correctly and that no other participant was in a position to observe any custodian’s PIN during entry.

Phase 4.4: Root CA Key Generation

Root CA key generation requires M-of-N custodian quorum. The Ceremony Master instructs M custodians (the first M from the list, or as specified in the script) to step forward and present their credentials sequentially or simultaneously as required by the HSM. Once the quorum is authenticated, the Ceremony Master directs the IT Support operator to execute the key generation command.

The key generation command specifies: the key algorithm (RSA-4096, ECDSA P-384, or as specified in the CP/CPS), the HSM partition in which the key will be stored, and the label by which the key will be referenced. The Evidence Recorder captures the full command and the console output of the key generation, including any key identifier, handle, or public key hash returned by the HSM. This output is a critical evidence artifact: it links the root CA certificate subsequently generated to the specific key that was generated in this ceremony.

After key generation, M custodians authenticate again to authorize generation of the root CA self-signed certificate. The certificate generation command specifies the Subject DN (as per the CP/CPS), the certificate validity period, the Basic Constraints extension (CA:TRUE with no path length constraint for a root CA), the Key Usage extension (keyCertSign and cRLSign), and any other extensions required by the CP/CPS. The resulting root CA certificate is exported to a file on the ceremony workstation. The certificate’s fingerprint (SHA-256 of the DER-encoded certificate) is displayed, read aloud by the IT Support operator, and recorded by the Evidence Recorder and attested by the Internal Auditor.

Phase 4.5: Subordinate CA CSR Signing (if included in scope)

If the ceremony scope includes signing one or more subordinate CA certificates (intermediate or issuing CA certificates), these are signed in this phase. Each subordinate CA CSR must have been generated in advance (on the CA software or HSM that will host the subordinate CA), verified for correct content (Subject DN, key algorithm, basic constraints, certificate policies extensions, AIA/CDP extensions) by the ceremony team, and approved by the Internal Auditor before the ceremony. CSRs that were not reviewed and approved before the ceremony should not be signed in the ceremony; signing an unreviewed CSR creates a CA whose certificate content has not been attested.

For each subordinate CA CSR to be signed, M custodians authenticate, the IT Support operator executes the signing command specifying the CSR file and the intended certificate profile, and the Evidence Recorder captures the resulting certificate fingerprint. The signed subordinate CA certificate is exported to a file on the ceremony workstation.

Phase 4.6: Key Backup and HSM Backup Procedures

The root CA private key must have a verified backup to prevent loss in the event of HSM failure. The backup procedure depends on the HSM platform: some HSMs support encrypted key export under M-of-N custodian authorization (where the exported key blob is encrypted with a key that requires M-of-N custodian cooperation to decrypt); others support cloning the key directly to a backup HSM of the same model under custodian control. Either approach is acceptable; what matters is that the backup key material is generated in the ceremony under the same M-of-N controls as the primary key, and that the backup is verified (by attempting to load and use it) before the ceremony concludes.

After the backup is created and verified, the backup media (whether a backup HSM, an encrypted backup token, or an encrypted key file on storage media) is labeled, sealed in a tamper-evident container, signed across the seal by the Internal Auditor and the Ceremony Master, and documented in the ceremony evidence. The backup storage location and access controls are documented in the ceremony evidence package. The backup must be stored separately from the primary HSM: a fire, theft, or physical damage event affecting one should not affect both.

Phase 4.7: Ceremony Closure

The ceremony closure phase includes: exporting all generated certificates to the designated secure distribution media (typically a read-only USB drive for air-gapped ceremonies, or a verified secure channel for connected ceremonies), verifying the integrity of all exported materials by checking file hashes against the values recorded during generation, securely erasing the ceremony workstation (or completing the planned procedures for its retention in a controlled state), and sealing the primary HSM in a tamper-evident container for transport to its operational storage location.

The Ceremony Master reads through the completed ceremony script to confirm all steps have been initialed. Any steps that were skipped or deviated from must be documented with the reason for the deviation and the Internal Auditor’s attestation. The ceremony attendance form is reviewed to confirm all entries are complete. The Internal Auditor certifies the ceremony completion by signing the ceremony completion statement, and all participants who remain in the room countersign.

Phase 5: Evidence Package Compilation

The ceremony evidence package is the collection of documents and records that prove the ceremony occurred correctly. It is compiled by the Evidence Recorder after the ceremony closes and reviewed by the Internal Auditor before being archived. A complete evidence package includes:

• Ceremony attendance record: Names, roles, and signatures of all participants, with arrival and departure timestamps for each.
• Signed ceremony script: The complete script with each step initialed by the performer and at least one witness, and any deviation notes.
• HSM verification record: HSM model, serial number, firmware version, vendor verification result, and photographs of the packaging and device.
• M-of-N configuration record: The M and N values configured, the pseudonymous or real identifiers assigned to each custodian slot, and confirmation that each custodian was initialized.
• Key custodian acknowledgment forms: One signed form per custodian confirming receipt of their credential and their understanding of custodian responsibilities.
• Key generation record: Timestamp, algorithm, key size, HSM partition, key label, and key identifier of each key generated, with the console output of the generation command.
• Certificate fingerprints: SHA-256 fingerprints of all certificates generated or signed during the ceremony (root CA certificate, all subordinate CA certificates), read aloud, recorded, and attested.
• Backup record: Description of the backup method, the seal number(s) on the backup container(s), the designated backup storage location, and the verification result (successful backup use test).
• Video recording: Continuous video of the ceremony from opening to closure, with timestamp overlay. The video must be archived in a format that is retrievable for the duration of the root CA certificate’s validity plus any applicable retention period required by the compliance framework.
• Internal Auditor certification: The Internal Auditor’s signed certification that the ceremony was conducted in accordance with the approved script and the CP/CPS requirements.
• External witness attestation (if applicable): The External Witness’s signed attestation of the ceremony proceedings.

The evidence package is archived in a secure, access-controlled location with a documented access log. For most compliance frameworks, the evidence package must be retained for the lifetime of the root CA certificate (which may be 20 to 25 years) plus the applicable post-expiry retention period. Physical copies should be stored in a fireproof safe; electronic copies should be stored in an access-controlled, encrypted archive with regular integrity verification.

Phase 6: Post-Ceremony Storage and Controls

The ceremony concludes the key generation event, but the governance of the root CA key material continues for the life of the CA hierarchy. Post-ceremony storage and controls address three categories: the primary HSM, the backup key material, and the custodian credentials.

Primary HSM storage: The primary HSM is stored in a secure enclosure (safe or dedicated HSM storage cabinet) in a physically access-controlled location. Access to the HSM must be logged: who accessed it, when, and for what purpose. For an offline root CA, the HSM is powered off between ceremonies; the storage location must have environmental controls (temperature, humidity) appropriate for long-term electronic equipment storage. The HSM’s tamper-evident seal is checked against the ceremony record each time it is accessed.

Backup storage: The backup HSM or encrypted backup key material is stored separately from the primary HSM, in a different physical location and ideally in a different building or facility. The backup must be accessible under the same M-of-N controls as the primary: recovering the backup key material requires M custodians, not a single administrator with access to the backup storage location. The backup’s integrity should be verified periodically (at least annually) by retrieving it, confirming the tamper-evident seal is intact, and logging the verification event.

Custodian credential management: Each custodian’s operator card or token is stored under that custodian’s own control, in a location and manner that meets the CP/CPS requirements for credential storage (typically a personal safe or equivalent secure storage, not a shared office drawer). Custodians should be reminded of their responsibilities annually and should report immediately if their credential is lost, stolen, or potentially compromised. A lost custodian credential reduces the available N count for future ceremonies; if N drops below M (all remaining custodians), root CA operations become impossible until new custodians are initialized using whatever key recovery procedure was established during the original ceremony. The procedure for custodian credential revocation and replacement must be documented and tested before it is needed.

Root CA Ceremony in the PKIaaS Context

In a vendor-hosted PKIaaS deployment, the PKIaaS provider conducts the root CA key ceremony using their own controlled environment, FIPS 140-3 validated HSMs, and ceremony procedures documented in their Certification Practice Statement. Customers receive the ceremony evidence package as documentation of the key generation event. Some providers offer customers the option to send observers to the ceremony, which is worth requesting if the PKI will be used for high-assurance applications where independent witness attestation strengthens the governance story.

In a customer-hosted or hybrid PKIaaS deployment, the customer conducts the root CA key ceremony for the root CA and any CAs they are hosting. The PKIaaS provider supplies the CA software and may supply the ceremony script template and evidence documentation templates, but the physical ceremony, the HSM, the custodians, and the Internal Auditor are the customer’s responsibility. For organizations without prior CA ceremony experience, engaging an external PKI consultant as the Ceremony Master for the first ceremony significantly reduces execution risk and produces a higher-quality evidence package.

Regardless of deployment model, the governance artifacts produced by the ceremony, primarily the CP/CPS and the evidence package, form the foundation of the PKI’s compliance story. Auditors for SOC 2, FedRAMP, CMMC, WebTrust, and ETSI all examine these documents. An organization that can produce a complete, well-documented ceremony evidence package is in a materially stronger position in any PKI-related audit than one that relies on verbal assurances about how the root CA key was generated.

How Encryption Consulting Can Help

• PKI Key Ceremony Services: Encryption Consulting provides end-to-end key ceremony design and execution support: ceremony script development aligned to the CP/CPS, role assignments guidance, HSM selection advisory, and expert Ceremony Master services for customer-hosted and hybrid PKIaaS deployments. We have conducted root CA key ceremonies across financial services, defense, healthcare, and critical infrastructure environments. Contact us at Encryption Consulting to discuss your ceremony requirements.
• PKI as a Service: For organizations using Encryption Consulting’s PKIaaS offering, vendor-hosted root CA key ceremonies are conducted by Encryption Consulting’s PKI team using FIPS 140-3 Level 3 HSMs under documented M-of-N controls, with a complete evidence package delivered to the customer. Customers may request observer access to the ceremony.
• PKI Services (CP/CPS Development): Encryption Consulting’s PKI Services include Certificate Policy and Certification Practice Statement development aligned to the applicable compliance frameworks (WebTrust, ETSI EN 319 411, SOC 2, FedRAMP, CMMC). The CP/CPS is a prerequisite to the ceremony script; we develop both in an integrated engagement.
• PKI Assessment Service: For organizations with an existing PKI whose ceremony evidence package is incomplete, undocumented, or cannot be located, Encryption Consulting’s PKI Assessment Service assesses the governance gaps and produces a remediation plan. In some cases, remediation involves conducting a new ceremony to replace the undocumented root CA with a properly governed one.
• HSM as a Service: For organizations that need FIPS 140-3 Level 3 HSM capacity for a customer-hosted ceremony without managing HSM hardware ownership, Encryption Consulting’s HSM as a Service provides dedicated HSM capacity with full customer control over partition configuration and access credentials.

Conclusion

A root CA key ceremony is not a formality. It is the event that establishes the trustworthiness of every certificate that will ever be issued under the PKI hierarchy. Organizations that conduct it correctly, with documented procedures, witnessed execution, FIPS-validated HSMs, M-of-N custodian controls, and a complete evidence package, build a PKI program on a foundation they can defend to auditors, regulators, and relying parties for the life of the root CA.

The planning is more important than the execution. A ceremony with a well-reviewed script, the right roles filled by the right people, equipment verified in advance, and evidence templates ready to be completed is almost certain to succeed. A ceremony improvised under time pressure, with ambiguous role assignments, on equipment that has not been tested, is likely to produce a ceremony record that raises more questions than it answers.

For organizations deploying PKIaaS for the first time, the ceremony is an opportunity to establish PKI governance practices that will serve the organization for decades. For organizations with an existing PKI whose ceremony documentation is thin, the gap between what the certificate chain implies (a trustworthy key generation event) and what can be proven (a documented, witnessed ceremony) is a governance risk worth addressing proactively rather than in response to an audit finding.

If your organization is planning a root CA key ceremony or needs to assess the completeness of an existing ceremony record, reach out to Encryption Consulting. We have conducted and advised on CA key ceremonies across a wide range of organizational contexts and compliance frameworks.

This post is reviewed annually and when FIPS 140 validation requirements, WebTrust, ETSI EN 319 411, or major compliance frameworks publish updates affecting key ceremony requirements.

Frequently Asked Questions

What is a PKI root CA key ceremony?

A PKI root CA key ceremony is a formally documented procedure for generating the root CA private key in a controlled, witnessed, and audited environment under M-of-N custodian controls in a FIPS 140-3 Level 3 validated HSM. The ceremony produces the root CA key pair, the root CA self-signed certificate, and a ceremony evidence package that is the auditable record of the key generation event for compliance purposes.

What is M-of-N control in a CA key ceremony?

M-of-N control requires that a minimum number of authorized custodians (M) out of the total number of custodians (N) must cooperate to authorize high-privilege root CA key operations. For example, a 3-of-5 configuration requires 3 of 5 designated custodians to present their credentials before the HSM permits a root CA key operation. M-of-N prevents any single administrator from performing unauthorized root CA operations unilaterally. A 3-of-5 or 3-of-7 configuration is common for enterprise root CA ceremonies.

Why does the root CA ceremony evidence package matter for compliance?

The evidence package is the auditable record that the root CA key was generated correctly under documented controls. WebTrust for CAs, ETSI EN 319 411, SOC 2 Type II, FedRAMP, CMMC, and PCI DSS auditors examine it to verify that the CA’s cryptographic foundation meets the stated Certificate Policy requirements. Without a complete evidence package, the organization cannot prove that the root CA key was generated in a trustworthy manner. A missing or incomplete evidence package is a common finding in PKI audits.

How long does a root CA key ceremony take?

Ceremony execution typically takes 4 to 8 hours on the day, depending on the number of CAs created, the number of custodians initialized, and whether subordinate CA CSRs are also being signed. Pre-ceremony planning requires 4 to 8 weeks for CP/CPS alignment, hierarchy design, HSM procurement, ceremony script development, and role assignments. Rushing any of these phases increases the probability of errors that are difficult to recover from gracefully during the ceremony itself.

Can a PKIaaS vendor conduct the root CA key ceremony on behalf of the customer?

Yes. In vendor-hosted PKIaaS deployments, the provider typically conducts the root CA ceremony using their controlled environment, FIPS 140-3 validated HSMs, and CPS-documented procedures, delivering a ceremony evidence package to the customer. Customers may request observer access. In customer-hosted or hybrid deployments, the customer conducts the ceremony using their own HSMs, with the provider supplying the CA software and potentially ceremony script templates; the customer is responsible for the physical execution, custodians, and Internal Auditor.