A key ceremony is the scripted, witnessed event in which an organization generates a high-value private key inside a hardware security module (HSM), a tamper-resistant device that stores and uses keys, and records how the key was made. Later ceremonies cover the key’s backup, rotation, recovery, and destruction. Certificate authorities run ceremonies for the root keys that browsers trust. ICANN, through its IANA function, runs them for the key-signing key (KSK) at the top of DNSSEC, the system that lets resolvers check that DNS answers are authentic. Banks and device makers run them for payment keys and for the keys that sign firmware.
Every RSA or elliptic-curve key among them will need a post-quantum successor. In its final transition plan, published on October 27, 2026, NIST deprecates those algorithms after 2030 and disallows them after 2035. For U.S. national security systems (NSS), NSA wrote in the October 2026 version of its FAQ on the Commercial National Security Algorithm Suite 2.0, known as CNSA 2.0, that “starting in 2027, no new product for NSS should have a burned-in root of trust relying on a non-QR primitive,” meaning a firmware trust anchor built on a quantum-vulnerable algorithm.
Post-quantum key ceremonies require every classical control plus one that classical ceremonies never needed: a stateful hash-based signing key must never sign twice from the same state. Organizations that sign firmware with LMS or XMSS keys should settle HSM support and backup procedures before their first post-quantum ceremony, because restoring a copied stateful key can reuse one-time keys and allow forgeries.
What a key ceremony is
The CA/Browser Forum, an industry body of certificate authorities and the companies that make web browsers, writes the rules for publicly trusted TLS certificates. In version 2.3.1 of its Baseline Requirements, in force since October 4, 2026, the Forum defines a Key Generation Script as “A documented plan of procedures for the generation of a CA Key Pair.” People in assigned roles follow that plan during a ceremony, in front of witnesses, with a log and usually video.
Public certificate authorities run ceremonies for root keys and for the intermediate keys that sign subscriber certificates. The Forum applies the same ceremony rules to code-signing CAs in a separate document, the Code Signing Baseline Requirements. Since June 1, 2023, those CAs have also had to obtain each subscriber’s contractual representation that it keeps its code-signing private keys in hardware certified to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+. The subscriber can meet that with its own hardware module, a qualifying cloud key-protection service, or a signing service that meets the Forum’s requirements.
IANA generated KSK-2024, the key now at the top of DNSSEC, at Ceremony 53 on April 26, 2024, in its key management facility in Culpeper, Virginia. IANA published the proposed and annotated scripts, footage from three audit cameras, the key generation log, the signing computer’s audit log, and the operating-system image that computer booted, with its SHA-256 hash. IANA put the new key into use in the root zone on October 11, 2026.
ICANN said on October 15 that the rollover was complete and that the previous key’s revocation remained scheduled for January 2027. It was still assessing reports of issues on a limited number of systems. Post-quantum DNSSEC would need a post-quantum key at the root as well, Cloudflare engineers wrote when their resolver began validating ML-DSA-44 signatures in September. ML-DSA-44 is a parameter set of ML-DSA, the signature standard formerly called CRYSTALS-Dilithium.
Device makers sign firmware with keys that their products check at boot. NSA wrote in its FAQ that the code validating firmware signatures is often hard to update, so “firmware-signing algorithms are frequently locked in for the life of a system.”
In payment networks, mostly symmetric keys are generated and loaded in HSM ceremonies from components held by separate custodians. In its 2018 summary of the changes that produced version 3.0 of the PCI PIN Security Requirements, the PCI Security Standards Council clarified that key generation “must occur within an SCD,” a secure cryptographic device. The Council also wrote that, as of version 3.0, dual control “includes use of separate key-loading devices for each component/share,” so that no single custodian loads a whole key.
What good practice requires
Multi-person control
Under the Baseline Requirements, a CA must generate every CA key pair “using personnel in Trusted Roles under the principles of multiple person control and split knowledge,” in a physically secured environment. Multiple person control means that at least two people must take part in each sensitive step. Split knowledge means that each participant knows only part of a key or credential.
IANA sets out the root zone’s version of these controls in its KSK Key Management Procedure, in force since September 21, 2026. Each of IANA’s two key management facilities must have seven Crypto Officers (COs), and activating its HSM takes “3 of 7 shares assigned solely to COs,” under the procedure. Seven Recovery Key Share Holders, who are not admitted to the facilities, each hold one of seven shares of the Storage Master Key that protects backups, of the Domain Key, and of the CO key.
A Ceremony Administrator runs the script, and Internal Witnesses attest that the team followed it. Auditors and other External Witnesses observe under escort and have no trusted role.
Scripts, witnesses, and auditors
A CA must “prepare and follow a Key Generation Script” for a root key and for any subordinate CA operated by someone other than the root’s operator or its affiliates. For those keys, the CA must also either have a Qualified Auditor witness the generation or record a video of the entire process, and must have the auditor “issue a report opining that the CA followed its key ceremony,” the Forum wrote. For the issuing intermediates a CA runs for itself, the script and the witness or video are only a “SHOULD” under the Baseline Requirements, with no auditor report.
In October 2026, browsers and operating-system vendors blocked eight eMudhra intermediate certificates, six of them for TLS, after a researcher showed that each private key was a number between 4 and 237. eMudhra filed a full incident report with Mozilla in November that superseded its October explanation. In it, the company wrote that “the original on-board key pairs were generated correctly” at a ceremony on April 30, 2025.
The ceremony included a step to move the keys to other HSMs by key wrapping, in which a key leaves one module encrypted under another key. For that step, the team used “a custom python key-handling script created by the PKI Operations team,” eMudhra wrote. When the script read each unwrapped key back, “a single line in that read-back truncated the private value to its leading byte,” the company wrote.
A certificate signing request (CSR) contains the public key that an applicant asks a CA to certify. “Almost identical object labels allowed the wrong object to be selected,” the company wrote. In eMudhra’s words, “this re-created object (not the originally generated key) was used to produce the CSR and was certified.”
It added that “nothing in the ceremony tested CA key strength or compared the certified key to the originally generated key.” According to eMudhra’s timeline, its compliance function witnessed the ceremony. “The devices themselves operated correctly,” the company wrote of its HSMs. In the same report, eMudhra wrote that it had “decided to exit the public TLS business.”
BDO USA reported on the September 3, 2025, ceremony in Utah at which Let’s Encrypt created its ISRG Root YE and Root YR keys. The auditors assessed the ceremony against “CA Key Generation Criterion 4.1 of the WebTrust Principles and Criteria for Certification Authorities v2.2.2.” BDO’s procedures included “physical observation of all procedures performed during the root key generation process” and a review of “the detailed CA key generation script for conformance with industry standard practices,” it wrote. BDO identified each root by its Subject Key Identifier and the SHA-256 thumbprint of its certificate.
HSM security levels
FIPS 140-3, the U.S. federal standard for cryptographic modules, “provides four increasing, qualitative levels of security,” NIST wrote in the standard. Under the Baseline Requirements, a CA must protect its private keys in a device validated to FIPS 140-2 or FIPS 140-3 at Level 3, or to an appropriate Common Criteria protection profile or security target at EAL 4 or higher. NIST moved FIPS 140-2 certificates to its Historical list after September 21, 2026, though it still supports their use in existing systems.
The ceremony team has to produce the evidence of how a key was generated, because NIST validates the module as tested and configured. On Crypto4A’s FIPS 140-3 certificate for its QASM module, for example, NIST’s validation program gives “No assurance of minimum security” for keys and other sensitive security parameters “that are externally loaded” into the module.
Records
Under version 1.8 of its Chrome Root Program Policy, Google removes “Any root CA certificate with corresponding key material generated more than 15 years ago” from Chrome’s store. Google measures that age from “a key generation report issued by a Qualified Auditor that distinctly represents the corresponding key” or from the earliest certificate containing the key, whichever comes first. New applicants must submit written evidence identifying “the date(s) of the key generation ceremony” to the CCADB, the Common CA Database that root programs share.
IANA requires the team to “Announce the generated key’s fingerprint (hash) to participating witnesses” during key generation. A witness who records that fingerprint can check every later certificate request and certificate against it.
What post-quantum migration changes
Post-quantum ceremonies keep every control above. Five things change: the key types and their sizes, HSM support, state for hash-based keys, the number of keys behind each certificate, and how often ceremonies happen.
New key types and sizes
On August 13, 2024, NIST published ML-DSA, formerly CRYSTALS-Dilithium, as FIPS 204. It published SLH-DSA, formerly SPHINCS+, a stateless hash-based scheme, as FIPS 205 the same day. NIST had specified two stateful hash-based schemes, LMS and XMSS, in SP 800-208 in 2020.
| Algorithm and parameter set | Public key (bytes) | Signature (bytes) | Source |
|---|---|---|---|
| ECDSA with P-384 | 97 (uncompressed point, derived) | 96 (raw r and s, derived) | Derived from FIPS 186-5 |
| ML-DSA-44 | 1,312 | 2,420 | FIPS 204 |
| ML-DSA-65 | 1,952 | 3,309 | FIPS 204 |
| ML-DSA-87 | 2,592 | 4,627 | FIPS 204 |
| SLH-DSA-SHA2-128s | 32 | 7,856 | FIPS 205 |
| SLH-DSA-SHA2-256f | 64 | 49,856 | FIPS 205 |
An ML-DSA-87 signature is about 48 times the size of a P-384 signature. ML-DSA keys start from a 32-byte random seed. In RFC 9881, an October 2025 specification for ML-DSA in X.509 certificates, the IETF defined three formats for the private key (the seed, the expanded key, or both) and recommended the seed for storing and transmitting keys.
Expanding a seed is one-way, so “the seed cannot be recreated, even if the full expanded private key is available,” the IETF wrote. A ceremony team therefore has to decide which format the HSM stores and which format to use for backups. It also has to show that a restored key matches the generated one. The IETF wrote that a recipient of a key in both forms “SHOULD perform a seed consistency check” before accepting it.
HSM support
By September 21, 2026, NIST’s Cryptographic Module Validation Program (CMVP) had validated at least two HSMs at Level 3 that support ML-DSA, Thales’s Luna T7 on July 29 and Crypto4A’s QASM on August 19, Quantum Observer reported. Both certificates list LMS key generation, signing, and verification among their approved algorithms, and neither lists XMSS.
Google sets HSM rules for post-quantum CAs in its draft quantum-resistant root program policy, version 0.4.0 of October 28, 2026. Google requires CA cosigner keys, the keys that sign in Chrome’s Merkle Tree Certificate (MTC) design, to be generated and used in an HSM formally validated to FIPS 140-3 Level 3 or Common Criteria EAL 4+ or higher. In that design, CA cosigners sign the state of a log of issued certificates, and each certificate includes a proof that it appears in the log.
Until an HSM’s CMVP certificate covers ML-DSA and ML-KEM, formerly CRYSTALS-Kyber, Google accepts a Level 3 module with an implementation of both that has passed NIST’s algorithm validation program. From January 1, 2029, HSMs storing CA cosigner keys not already trusted by Chrome must have CMVP certificates covering both algorithms.
NSA’s rule for national security signers is stricter. Signers that are themselves NSS must produce LMS and XMSS signatures “according to NIST SP 800-208, which requires hardware validated by NIST’s Cryptographic Module Validation Program (CMVP), or via other NSA guidance.” NSA wrote that waivers “will not be granted” for that rule.
NIAP, the National Information Assurance Partnership, certifies commercial security products for national security systems against Protection Profiles, sets of security requirements for each type of product. Where firmware is signed outside the evaluated product, “Protection Profile requirements only apply to signature verification,” NSA wrote. A NIAP evaluation therefore does not cover a vendor’s signing ceremony or its handling of state.
State for LMS and XMSS keys
An LMS or XMSS key is a Merkle tree, a tree of hashes whose leaves are one-time signing keys, under a single public key. Each signature uses one leaf, so a tree of height h can make at most 2^h signatures. The signer must record which leaves it has used.
Researchers at PQShield, Germany’s Federal Office for Information Security (BSI), Google, and Crypto4A wrote RFC 10033, an informational RFC on state and backup management published in September 2026. They warned that “double-signing with the same OTS key allows forgeries,” where an OTS key is one leaf. “Cloning is another concern, as it can easily lead to re-using the same state,” they added.
In SP 800-208, NIST requires that “key and signature generation be performed in hardware cryptographic modules that do not allow secret keying material to be exported, even in encrypted form,” and that those modules provide FIPS 140 Level 3 or higher physical security. Because “simply copying the private key would create a risk of OTS key reuse,” NIST wrote, “this recommendation prohibits exporting private keying material” for these schemes.
IANA, by contrast, backs up the classical KSK, encrypted under its Storage Master Key, to two portable media or backup HSMs at each facility. Google’s draft policy allows encrypted backups and wrapped transfers between HSMs “provided that the plaintext key material never exists outside of a validated HSM boundary,” under multi-person control. ML-DSA keys are stateless, so that classical pattern still applies to them.
In eMudhra’s April 2025 ceremony, plaintext key material reached the host computer, by the company’s account. The team’s script read each unwrapped ECDSA private key “out of the module (in host side memory),” eMudhra wrote. The team had run the source HSM “with FIPS-approved mode disabled for the wrap/unwrap step, as an approved deviation recorded in the ceremony script.”
eMudhra also wrote that its RSA key material “was handled within the volatile memory of a Python process on the ceremony host.” After assessing that material, it revoked eight RSA issuing CAs on November 7.
One option NIST describes for stateful keys is a distributed multi-tree, HSS for LMS and XMSS^MT for XMSS, in which each module generates and keeps its own subtrees under one top-level tree. NIST wrote that “all of the bottom-level keys should be generated up front as part of the initial key generation ceremony” in that design.
NSA ruled out that option for national security systems. “From NIST SP 800-208, NSA has only approved LMS and XMSS for use in NSS. The multi-tree algorithms HSS and XMSSMT are not allowed,” it wrote. In NSA’s words, one “should implement signing and state management in hardware, such as an HSM,” and “Backup flows, which may involve transferring keys between modules, must prevent state re-use” for these keys.
The remaining options have to be designed into the first ceremony. The authors of RFC 10033 described several, among them provisioning devices to accept signatures from more than one public key, dividing one tree’s signing space into sectors on different devices, and reserving intervals of one-time keys. They also described a two-step export and import, checked with hashes, that goes “beyond what [SP.800-208] allows,” in their words.
Under each option, the team must decide at key generation how many keys devices will trust and how many signatures each key can make. The RFC’s authors wrote that “careful attention during the design phase is essential” for these keys. They also listed “M-of-N controls, least-privileges amongst participants, and a separation of duties” as safeguards, all of them familiar from classical ceremonies.
Composite certificates and parallel hierarchies
In November 2026, the IETF published RFC 10073, a Proposed Standard for composite ML-DSA, which combines an ML-DSA key with a traditional signature key in one certificate. Apple said in September that it plans to accept composite S/MIME root certificates that pair ML-DSA with ECDSA or RSA. As of November 2026, Apple had not added that change to the published Apple Root Program Policy, version 2.0 of August 1, 2026.
NSA took the other path for national security systems. It wrote that “NSS systems using PKI should not use novel mechanisms to support multiple algorithms within a single certificate” and described past algorithm transitions as “standing up a parallel PKI using the new cryptographic algorithm” instead. NSA also warned that “something marketed as hybrid or composite does not necessarily make it quantum resistant” for national security systems.
Either path means more keys. A composite key consists of two private keys generated and bound together, and a parallel hierarchy requires a second set of ceremonies. At eMudhra, by the company’s own account, the team certified truncated copies of its keys, under labels almost identical to those of the originals. Each added key is another public-key fingerprint that the team has to compare with every certificate request.
More frequent ceremonies
Google plans shorter terms for post-quantum CA keys than for classical roots. Under its draft policy, a CA cosigner key is trusted for at most 2,280 days, about six years, once included in the Chrome Quantum-resistant Root Store. Google also asks operators not to issue with one key for more than 1,550 days. It accepts only keys “generated no more than 4 years prior to the request submission date” into the store.
A classical root can stay in Chrome’s store until 15 years after its key was generated. A CA that generates a new root key once a decade would, under the draft, generate post-quantum keys every few years. Each time, Google requires “written evidence from a Qualified Auditor” that identifies “the date(s) and approximate location(s) of the key generation ceremony” and that the operator hosts in its repository.
Google’s draft also takes away the intermediate tier. “MTC CAs MUST NOT issue Subordinate CA certificates of any kind,” Google wrote. A classical CA can issue through its own intermediates, for which a script and a witness are only a “SHOULD” under the Baseline Requirements. An MTC CA operator cannot, so it needs a ceremony with written evidence from a Qualified Auditor for each CA cosigner key it adds, as Chrome’s draft requires.
CNSA 2.0 dates for software and firmware signing
NSA approves two kinds of algorithm for signing firmware and software in national security systems. Under CNSA 2.0, ML-DSA-87 is approved for “digital signatures in any use case, including signing firmware and software,” at all classification levels. LMS and XMSS are approved for “digitally signing firmware and software,” with all parameter sets allowed and LMS with SHA-256/192 recommended. NSA excluded SLH-DSA from CNSA 2.0 and from any use in national security systems, even though it is also hash-based.
| Date | NSA wording in the CNSA 2.0 FAQ, version 2.2 | Source |
|---|---|---|
| January 1, 2027 | Under CNSSP 15, “CNSA 2.0 algorithms will be required in all new acquisitions for NSS” | FAQ, p. 17 |
| From 2027 | “no new product for NSS should have a burned-in root of trust relying on a non-QR primitive” | FAQ, p. 24 |
| 2027 | “NIAP will no longer accept products for certification that have not started their quantum transition” | FAQ, p. 10 |
| December 31, 2030 | “all NSS equipment and services that cannot support CNSA 2.0 must be phased out unless otherwise granted an exception” | FAQ, p. 17 |
| December 31, 2031 | “CNSA 2.0 algorithms are mandated for use, unless otherwise noted, to achieve full QR for NSS” | FAQ, p. 17 |
NSA set out an earlier timetable in its September 2022 advisory on CNSA 2.0, which predates the FAQ. For software and firmware signing, NSA anticipated that national security systems would “support and prefer CNSA 2.0 by 2025, and exclusively use CNSA 2.0 by 2030.” NSA gave no such timetable by product category in version 2.2 of the FAQ. It wrote there that it does not mandate its requirements outside national security systems, though they “may serve as guidance for entities outside of NSS.”
NSA wrote that some components, “like firmware update options, likely cannot be transitioned after purchase.” It urged customers to make sure such services are quantum-resistant when they buy them, or risk having to buy new products in 2030.
The case for avoiding stateful keys
Signing teams can sidestep state by choosing ML-DSA, which NSA approves for all signing. NSA wrote that ML-DSA “may be the most appropriate choice for some software/firmware signing use cases,” such as a signing strategy that needs more signatures than one LMS or XMSS key can make, or a distributed signing system. In its final transition plan, NIST described LMS and XMSS as not intended for general use, though possibly useful for software and firmware signing.
NSA also judged the burden of state to be small. It wrote that the requirement for keeping track of state, and for ensuring that “certain private data is not used more than once in signing software or firmware,” has “minimal impact” in that use. The authors of RFC 10033 recommended “dedicated cryptographic hardware” to enforce the state requirements. On this view, state management becomes an HSM feature, and a ceremony for an LMS key differs little from any other once the HSM enforces its counter.
The choice between those paths is itself a decision for the first ceremony, made on NSA’s own criteria of signature volume and distributed signing. Teams that pick LMS or XMSS lose the classical pattern of backing up a key and restoring it later, since NIST bans export and NSA excludes the multi-tree variants. NSA paired its judgment of minimal impact with the requirement that backup flows “must prevent state re-use.” Teams still have to decide how many keys their products trust and what happens when an HSM fails.
SLH-DSA needs no state, but its signatures run from 7,856 to 49,856 bytes. NSA does not approve it for national security systems.
What to settle before the first post-quantum ceremony
- Which algorithm and parameter set each key will use, and which policy, such as CNSA 2.0 or Google’s draft, constrains that choice.
- Whether the HSM’s CMVP certificate lists key generation and signing for that algorithm, at which level and on which firmware version.
- For an LMS or XMSS key, how the HSM tracks state, what happens on failover, and how many signatures the key can make over its life.
- How many public keys the products will trust, so that losing one HSM does not leave devices without a usable signing key.
- For an ML-DSA key, whether the HSM stores the seed, the expanded key, or both, and how the team checks a restored key against the generated one.
- Whether the ceremony record identifies each key by its public-key fingerprint and names the HSM model and firmware version.
What would change this assessment
Two developments would make post-quantum ceremonies look more like classical ones. One is a validated way to move stateful keys between HSMs, such as the two-step export and import that RFC 10033’s authors described as going beyond SP 800-208. The other is a broad move by firmware signers to ML-DSA, which NSA permits and which needs no state.
Evidence in the other direction would include a published case of a reused one-time key in a signing HSM, or root programs and NIAP adding checks of signing-side state management to their requirements. The next fixed dates are January 1, 2027, for CNSA 2.0 algorithms in new national security acquisitions and January 1, 2029, for CMVP-validated ML-DSA HSMs under Google’s draft policy.
