Key Ceremonies: What They Are, What Good Looks Like, and What PQC Changes

Since eMudhra’s broken CA keys became public on October 20, clients have kept asking me some version of the same question: how does a certificate authority end up with a private key whose value is 4? The keys for eight of eMudhra’s publicly trusted intermediate CAs came out of one key ceremony on April 30, 2025, and each private key was a number between 4 and 237, where it should have been a random value up to 384 bits long.

I covered the incident and the cleanup in my analysis of the eMudhra failure. The follow-up questions were about the ceremony itself, and about whether the CAs and HSMs my clients depend on run better ones.

A key ceremony is the scripted, witnessed event in which an organization generates a private key inside a hardware security module, or HSM, and certifies the matching public key. It is also when the organization creates most of the evidence of how the key was made. After the ceremony, a public key whose private value is 4 passes the same validity checks as one generated correctly. There is no way to tell them apart after the ceremony. Unless you run a deliberate search of small values.

For any organization that relies on a CA key, whether a public CA’s, an internal root or a firmware-signing key, the ceremony record is the main and often the only evidence it will ever have that the key was generated correctly. That record deserves the same scrutiny as the HSM’s certificate, and over the next few years every CA that wants post-quantum trust will produce a new set of them.

What a Key Ceremony Is

The CA/Browser Forum’s Baseline Requirements, the rules every publicly trusted TLS certificate authority follows, define a Key Generation Script as “a documented plan of procedures for the generation of a CA Key Pair.” The ceremony is the execution of that plan, with people in assigned roles, witnesses, a log and often a camera.

A root ceremony usually runs in a physically secured room with an access log. Participants sign in, and the team checks the serial numbers on the tamper-evident bags that hold the HSM, the smart cards and the laptop that will drive the HSM. The laptop boots from media whose hash was recorded in advance.

A quorum of key custodians then activates the HSM, each with a credential that is useless alone. The HSM generates the key pair, the team exports the public key and records its fingerprint, and the root certificate is signed. The key is backed up under split control, the team puts the equipment back into new bags and the safes, and the participants and the auditor sign the log.

Intermediate CA ceremonies follow the same pattern, with one difference. The root key stays offline, so each intermediate certificate the root signs directly, each cross-signature and each root-signed CRL needs the root’s HSM brought out of storage and activated under quorum. The intermediate’s own key can be generated in that ceremony or earlier. Its public key has to reach the root ceremony intact, as a CSR or a key file, and the root signs whatever key it is given.

Public CAs are the visible case. The same discipline applies to an enterprise’s internal root CA, to the keys that sign code and firmware, and to the key-signing key for the DNS root zone, which ICANN generates and uses in ceremonies whose scripts, logs and video it publishes.

Banks and payment processors run their own version for HSM master keys and key components, where each custodian holds one part of a key under dual control and split knowledge, as I described in my breakdown of interbank payment cryptography. The vocabulary changes between these worlds. The questions stay the same: who generated the key, on which device, following which steps, checked by whom.

Why Key Provenance Needs Evidence

A valid public key does not show that its private key was generated securely. eMudhra’s keys passed every structural check. Each was a valid point on the P-384 curve, with coordinates of the right size, and the intermediate certificates carried valid signatures from eMudhra’s roots. The flaw appears only when someone multiplies the curve’s base point by 1, 2, 3 and so on and compares each result with the public key.

An HSM’s certification does not close that gap. FIPS 140 validates the module: its algorithms, its random number generator and its physical protections. It does not validate the script an operator runs against the module, and importing a key is a normal, approved function on most HSMs. An HSM cannot tell whether a value it is asked to import was generated well. eMudhra’s HSMs were Utimaco modules, which the company describes as “FIPS 140-2 Level 3 compliant.”

Certification does not guarantee the module’s own key generation either. In 2017, Matus Nemec and colleagues showed that an RSA key generation library used in Infineon chips since at least 2012 produced primes with a structure that made the keys factorable (ROCA, CVE-2017-15361). The library ran on devices certified to FIPS 140-2 and Common Criteria EAL 5+, including electronic citizen documents. A quick test of the public key could flag a ROCA key, because the primes’ structure carried over into the modulus. eMudhra’s public keys had no such structure, and finding them took someone who thought to try small private values.

The other recurring pattern is test material reaching production. In 2011, TURKTRUST copied its certificate profiles to a test system, added two test profiles with CA extensions, and then patched production with that set during a software migration. On August 8, 2011, TURKTRUST issued two certificates from the wrong profiles, and both worked as intermediate CAs. In December 2012, one of them was installed on a firewall that was configured for TLS interception and used it to generate a certificate for *.google.com. Google alerted TURKTRUST on December 26, 2012, according to TURKTRUST’s account.

eMudhra says its weak keys came from a ceremony in which it had added steps to test key wrapping and unwrapping.

The ceremony record also serves as the key’s official birth date. Chrome’s root program policy removes roots whose key material is more than 15 years old, and it 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 is earlier. New applicants must document the date of the key generation ceremony and provide an auditor’s attestation.

Mozilla removes the website trust bit when a root’s key material reaches 15 years, under a rule it introduced in 2023, and since July 1, 2026 it has required keys submitted for inclusion to have been generated within the previous five years.

What the Rules Require, and What They Leave Out

Section 6.1.1.1 of the Baseline Requirements, now at version 2.3.1, sets two tiers. For a root CA key, and for a subordinate CA operated by someone other than the root’s operator or its affiliates, the CA “SHALL” prepare and follow a Key Generation Script and have a Qualified Auditor witness the generation or record a video of the entire process. The CA must also have a Qualified Auditor issue a report “opining that the CA followed its key ceremony.” For subordinate CAs that the root’s own operator runs, the script and the witness or video are a “SHOULD,” and no auditor report is required.

In every case, the CA must generate the key in a physically secured environment, “using personnel in Trusted Roles under the principles of multiple person control and split knowledge,” inside cryptographic modules that meet its own published policy. It must also log the activity and maintain controls that give reasonable assurance the key was generated as its documents describe. Section 6.2.7 requires CAs to protect their private keys in modules validated to FIPS 140-2 or FIPS 140-3 at Level 3, or an appropriate Common Criteria Protection Profile or Security Target at EAL 4 or higher.

A WebTrust key generation report, such as the one BDO issued for Let’s Encrypt on September 30, 2025, reports against CA Key Generation Criterion 4.1 of the WebTrust Principles and Criteria for Certification Authorities. BDO’s report covers the September 3, 2025 ceremony in Utah that created ISRG Root YE and Root YR, identifies each root by its Subject Key Identifier and the SHA-256 fingerprint of its certificate, and states that the auditor physically observed all procedures, reviewed the script against industry practice and tested the controls over the keys, backups and access credentials.

eMudhra’s report for its February 8, 2024 root ceremony in Bangalore follows the same model for ten roots, including emSign Root TLS CA – G3 and emSign Root CS CA – G3, which later issued the eight weak intermediates.

The rules leave three gaps.

The weaker tier covers a CA’s own issuing intermediates. Those are the keys that sign subscriber certificates every day. eMudhra’s eight intermediates were its own, and the Code Signing Baseline Requirements, which cover its two code-signing intermediates, use the same two tiers. Neither set of requirements obliged eMudhra to have an auditor witness, a video or a dedicated auditor report for the ceremony that created them, although its own CPS and its annual audit still applied.

The weak-key screening list applies to subscriber keys. Section 6.1.1.3 requires CAs to reject subscriber keys with known weaknesses, such as keys from the 2008 Debian random number bug, ROCA keys and RSA keys whose primes are close enough for Fermat factorization. No equivalent list applies to the CA’s own keys. Section 6.1.6 recommends that CAs validate ECDSA public keys, and a key with a private value of 4 passes, because the base point multiplied by four is a valid point on the curve.

The audit does not verify the ceremony code. The auditor reviews the script, observes its execution and tests the controls around the keys, which gives reasonable assurance over the ceremony. A defect inside the script’s code, such as a test step that creates a second key pair, can pass those checks. The ceremony section of the Baseline Requirements requires a script without saying how a change to it, such as eMudhra’s “approved deviation,” should be reviewed or rehearsed. The Forum’s separate Network and Certificate System Security Requirements require a documented, approved change management process for CA infrastructure, but they set no ceremony-specific rules such as independent code review, a rehearsal or a change freeze.

What a Good Key Ceremony Looks Like

Before the Ceremony

Treat the script as code that will run once in production. Every step should name the command, the expected output and the person who checks it. When the script calls custom code, that code needs a reviewer who did not write it, a version number and a hash recorded in the script. Let’s Encrypt’s ceremony tool is a concrete example. Each ceremony is driven by a single YAML configuration file, which its documentation says allows “for simple verification of a single file, instead of verification of a large number of independent commands.”

Rehearse the full script on non-production HSMs, more than once, with the people who will be in the room. Every test step should be exercised in the rehearsal. If a test has to run during the production ceremony, it should run on a separate HSM partition and use keys whose labels cannot be confused with production labels. Delete those test objects and record the deletion before any production key is used.

Freeze the script days before the ceremony. Give a late change the same review and a fresh rehearsal as the original. If anyone proposes a change in the room, stop the ceremony. eMudhra introduced “an approved deviation” to its usual ceremony so it could test wrapping and unwrapping keys meant for export to its US and European data centers, and it says a flaw in the ceremony code created the weak keys during that ceremony.

Publish what you can before the ceremony. In July 2025, Let’s Encrypt published preview certificates for the roots and intermediates it planned to create and asked the community to find problems “our designs and linters have missed.” A private CA can do the same internally, by circulating the planned certificate profiles and key types to reviewers outside the ceremony team.

In the Room

The room needs physical security, an access log and cameras. The Baseline Requirements accept a video of the entire process in place of an auditor witness, and ICANN publishes the audit camera footage, scripts and logs from its root key ceremonies, along with the hash of the operating system image its signing computer boots.

Activation needs a quorum. Under ICANN’s key management procedure, activating an HSM requires 3 of the 7 shares held by Crypto Officers, and its ceremonies also need a Ceremony Administrator, Internal Witnesses and Safe Security Controllers. Quorum stops a single insider from using the key, but a whole team following a broken script still satisfies it.

Every step should be read aloud, performed by one person and confirmed by another, with the result written into the log. ICANN’s procedure requires the team to “announce the generated key’s fingerprint (hash) to participating witnesses.” Each witness who hears and records that fingerprint can check every later artifact against it.

Checks on the Key and the Certificates

Bind every artifact to the key that was generated. When the HSM creates the intended key, record a fingerprint of the public key itself, usually a SHA-256 hash of its DER-encoded SubjectPublicKeyInfo, then confirm that the CSR, the issued certificate and every cross-signed certificate contain exactly that key. A certificate fingerprint cannot do this job, because a CSR, a self-signed certificate and a cross-certificate for the same key all hash differently.

Let’s Encrypt’s tool builds this into its code. The tool generates a key only under a label that no object in its HSM slot already has, and before it signs anything, it checks that the key the HSM returns matches the expected public key, taken from the issuer certificate or from the public key file written at generation. eMudhra says it built its CSRs from a second key pair with a similar label, and a public key fingerprint comparison at the CSR step would have exposed the mismatch.

Check where each key came from before using it. In PKCS#11, the interface most ceremony tools use to talk to HSMs, the attribute CKA_LOCAL is true only for a key generated on the HSM itself or copied from such a key, according to the PKCS#11 specification. A key that was imported or unwrapped reports false. The attribute shows how the key object was created, not whether the random number generator worked. A key legitimately moved between HSMs by wrapping also reports false, so an unexpected value is a reason to stop and investigate. Production CA keys should also be created non-extractable, as Let’s Encrypt’s tool creates them, unless the ceremony has a documented, separately reviewed reason to export them.

Test the CA’s own public keys for known weaknesses, the same way CAs must test subscriber keys. On October 20, three days after a researcher reported eMudhra’s keys to the root programs and the day the problem became public, Let’s Encrypt added a check to its open-source key checks that rejects ECDSA keys whose private value is 255 or less, or the negative of such a value modulo the curve order, and its ceremony tool runs those key checks. The search can go much further. Checking every private value below $$2^{40}$$ with the baby-step giant-step method takes about two million elliptic-curve operations and a table of about a million points.

Lint every certificate before the real signature, and verify every signature after it. Let’s Encrypt’s tool first signs a lint certificate with a throwaway key, runs the linters on it, then signs the real certificate and checks that the two contain identical certificate data.

After the Ceremony

Produce a report that identifies every key generated by its public key fingerprint and every certificate by its certificate fingerprint. BDO’s report for Let’s Encrypt lists each root’s Subject Key Identifier and certificate fingerprint, which is enough to match the ceremony to the certificates in use years later. Keep the log, the video and the script version with the report.

Back up the key under split control, test that a restore produces the same public key, and record the result. Stateful hash-based signing keys need a different design, covered below.

Treat the first operations of a new CA as part of the ceremony. The first certificate or CRL it signs must verify against the public key in its CA certificate, and a failure calls for an investigation of which key the CA is actually using and where that key came from.

In June 2025, Sectigo engineer Rob Stradling found that six CRLs from eMudhra’s new TLS intermediates had invalid signatures. eMudhra attributed the failure to a manual process that referenced the wrong CA key, and Mozilla closed the incident report in July 2025. In October 2026, eMudhra told Mozilla that those CRLs “were signed with the original private keys” and were then “resigned with flawed keys.”

The People and Skills a Ceremony Needs

I have overseen key ceremonies as a CISO. ICANN’s procedure for the DNSSEC root key is the most detailed public description of ceremony roles I know of.

The Ceremony Administrator is responsible for running the ceremony as written. Internal Witnesses observe and attest that it was executed as described. Crypto Officers hold the credentials that authorize HSM operations, and Safe Security Controllers hold the combinations to the equipment and credential safes. A System Administrator deals with equipment failures. Recovery Key Share Holders each keep one of seven shares of the Storage Master Key, and External Witnesses, auditors among them, observe without any access. Public CAs define comparable positions as Trusted Roles in their certification practice statements.

The roles describe who is in the room. The skills behind them decide what the room can catch:

Two properties cut across the table. The first is independence. The person who wrote the ceremony code should not be the person who certifies it, and witnesses should not report to the script’s author.

The second is the authority to stop. In February 2020, ICANN postponed its 40th root key ceremony after finding that a security mechanism protecting its safes was malfunctioning, even though the material inside was not at risk, and it kept a complete replica facility in Culpeper, Virginia, available as a fallback. A ceremony administrator who can stop the room without needing anyone’s permission, and who records why, is in my view the strongest control a ceremony can have.

The same people will run their organizations’ post-quantum ceremonies. The PKI and HSM skills I listed in the skill stack a CISO needs for crypto-agility in 2023 are the skills these ceremonies draw on.

What Probably Went Wrong at eMudhra

eMudhra has not published its full incident report. In Mozilla’s Bug 2083449, it has said that the April 30, 2025 ceremony ran on Utimaco HSMs with an approved deviation to test wrapping and unwrapping keys for export. The first key pair for each CA was generated as expected. Then, in eMudhra’s words, “a flaw in the code resulted in the second pair of keys being created onboard which were weaker,” and the CSRs were built from those pairs because the key labels were similar. Its RSA issuers took a different path through the code and were not affected.

The published keys add one clue. Scott Helme published the eight private values, 4, 56, 66, 115, 155, 156, 230 and 237. In the 48-byte form of a P-384 private key, each is 47 zero bytes followed by one byte. Mozilla’s Dennis Jackson wrote in Bug 2083449 that the eight keys “all used integers less than 256.” A correctly implemented P-384 generator picks the private value uniformly from a range of about $$2^{384}$$ values, so the chance of drawing one below 256 is about one in $$2^{376}$$ per key, and eight such keys did not come from a correct generator.

My inference is that the code passed the HSM a one-byte value where P-384 needs 48 bytes, or truncated a longer value to its last byte, perhaps while creating a test key or a copy for the wrap-and-unwrap test. eMudhra has not published enough detail to establish the exact code path.

On eMudhra’s account, a public key fingerprint comparison between the key generated first and the key in each CSR would have shown the mismatch on the day. If the weak keys were imported or unwrapped, a provenance check would also have shown that the CSR key was not generated by the HSM. A small-value test would have caught the keys at any point in the following 17 months.

The June 2025 CRL failure was the last clear signal. CRLs signed with the original keys failed to verify against certificates that contained the weak keys, and eMudhra’s fix re-signed them with the weak keys. That made the CRLs verify. I could not find a question in Bug 1970728, Mozilla’s record of that incident, about why each CA had two keys.

In Bug 2083449, eMudhra has told Mozilla that “over the next week, we will reverify every key ceremony we have done,” and it had not posted results when I checked on October 21. In the same bug, the researcher who reported the weak keys has also reported that a CRL published on October 14, 2026 for emSign Root TLS CA – G1, another root from the February 2024 ceremony, had an invalid signature. eMudhra had not addressed that report specifically. I would also want to know whether an auditor witnessed the April 2025 ceremony, what the deviation approval covered and how the second key pairs were created.

What PQC Changes in Key Ceremonies

Post-quantum cryptography does not fix ceremony failures. A script that hands the wrong key to a CSR can do the same with an ML-DSA (formerly CRYSTALS-Dilithium) key. PQC changes the hardware and firmware ceremonies run on and the formats of the keys. Chrome’s proposed policy for post-quantum certificates would also make ceremonies more frequent, and stateful hash-based signatures change whether a key can be backed up at all.

New Ceremonies on New Firmware

Chrome plans to launch its quantum-resistant root store for Merkle Tree Certificates in the third quarter of 2027, and Let’s Encrypt and Apple have committed to the same certificate format. TrustAsia became the first known CA to apply to Chrome’s test program, as I reported in August. Every CA that joins will need new post-quantum keys, generated in new ceremonies.

In its draft quantum-resistant root program policy, version 0.3.0 of August 14, 2026, Google asks more of key ceremonies than the Baseline Requirements do. CA keys, which the draft calls CA cosigner keys, must be generated and used in HSMs validated to FIPS 140-3 Level 3 or Common Criteria EAL 4+, and backups or wrapped transfers between HSMs are allowed only if “the plaintext key material never exists outside of a validated HSM boundary.” Operators must collect written evidence from a Qualified Auditor for each key generation ceremony, host it in their repository and reference the ceremony report when they disclose a key. Until an HSM’s CMVP certificate covers ML-DSA, the draft accepts a FIPS 140-3 Level 3 or EAL 4+ module whose ML-DSA and ML-KEM (formerly CRYSTALS-Kyber) implementation has CAVP validation. From January 1, 2029, the HSMs storing CA cosigner keys not already trusted by Chrome must have CMVP certificates that explicitly cover ML-DSA and ML-KEM.

Those HSMs are only now arriving. As I noted when FIPS 140-2 went historical in September, FIPS 140-3 Level 3 HSM certificates listing ML-DSA as an approved service began appearing in July and August 2026. A CA’s first post-quantum ceremony will run new HSM firmware, new PKCS#11 mechanisms and new ceremony code. eMudhra’s weak keys came out of a change to its usual ceremony, by its own account.

More Ceremonies, More Often

In Chrome’s design, MTC CAs “MUST NOT issue Subordinate CA certificates of any kind,” so a CA cosigner key does the work an issuing intermediate does in a classical hierarchy. Classical roots can stay trusted for 15 years from key generation. Chrome’s draft policy trusts a CA cosigner key for at most six years once it is included, says a key “SHOULD NOT be used for Subscriber certificate issuance for more than 4 years,” and accepts new keys only if they were generated no more than four years before the application. It also lets operators “rotate multiple Active keys during a single ceremony event.”

Under that policy, a CA that runs a root ceremony once a decade today would run post-quantum key ceremonies every few years. Each repetition of a long manual ceremony is another chance for an eMudhra-style mistake, and Let’s Encrypt’s single-file approach reduces the number of steps an operator can get wrong.

ML-DSA Keys Start as a 32-Byte Seed

An ML-DSA key pair is derived from a 32-byte random seed. RFC 9881, published in October 2025, defines three private key formats for ML-DSA in X.509 systems: the seed alone, the expanded private key, or both. It recommends the seed as the format to store and export. Expanding a seed is one-way: a key stored only in expanded form can never be converted back to its seed. When both forms are present, the RFC says the recipient “SHOULD perform a seed consistency check” and, if it runs the check and finds a mismatch, must reject the key.

For a ceremony, this creates three new decisions: which format the HSM stores, which format backups and transfers use, and how the team proves that a key restored or moved between HSMs is the key that was generated. A key exported only in expanded form cannot be imported where a seed is required.

eMudhra’s failure has a direct ML-DSA equivalent. An ML-DSA public key generated from a predictable seed looks like any other ML-DSA public key, and Wycheproof’s test vectors can confirm that an implementation derives the right key from a seed without showing that the seed was random. Evidence that the seed came from the HSM’s validated random number generator has to come from the ceremony record and the HSM’s provenance attributes.

NIST’s draft revision of SP 800-133, released in April 2026, adds methods for deriving randomness during key-pair generation and asks how its requirements fit “storing keys as seeds,” so the guidance itself is still changing.

Hybrid Designs Add Keys

A composite ML-DSA key, defined in an IETF draft now in the RFC Editor’s queue, combines an ML-DSA seed and a traditional private key in one key. A dual hierarchy runs separate classical and post-quantum CAs side by side, which can roughly double the number of issuing keys. Apple has chosen the composite path for S/MIME while backing Merkle Tree Certificates for TLS, as I covered in my analysis of Apple’s policy. eMudhra’s failure began with two key pairs per issuer and similar labels. Every additional key per issuer adds a fingerprint to bind and a label to confuse, so hybrid ceremonies need the binding checks more than classical ones do.

Stateful Signing Keys Change Backup and Recovery

Stateful hash-based signatures change ceremonies the most. For software and firmware signing in US national security systems, CNSA 2.0 expects support and preference for its algorithms by 2025 and exclusive use by 2030, and NSA recommends LMS or XMSS for that job now rather than waiting for ML-DSA. Each LMS or XMSS signature uses a one-time key, and RFC 10033, published in September 2026, states that “double-signing with the same OTS key allows forgeries.” Restoring an old backup or cloning a device can bring used one-time keys back into service.

NIST SP 800-208 requires key and signature generation in hardware modules that do not allow secret keying material to be exported, so the usual ceremony pattern of generating a key and backing it up under split control does not apply. SP 800-208’s own answer is a distributed multi-tree, with subtrees generated on separate HSMs under a root tree. RFC 10033 describes further options, such as a signing space divided into sectors stored on different devices and reserved intervals of one-time keys, and one approach that goes beyond what SP 800-208 allows. Each of these has to be designed into the first ceremony, including how many signatures the key will ever be able to make.

A classical firmware trust anchor that can never be replaced is the key most exposed to Trust Now, Forge Later, the risk I first described in 2018 as Sign Today, Forge Tomorrow. Organizations replacing those anchors with LMS or XMSS keys should get these ceremonies right first.

Crypto-Agility Includes the Ceremony

I measure crypto-agility as time-to-change, which for a CA or a PKI team includes how quickly the team can run a correct ceremony. An organization with a reviewed script, rehearsed staff, HSMs it can activate on short notice and tooling that checks fingerprints can replace a broken key quickly. One that rebuilds its ceremony from memory each time will be slower, and more likely to repeat eMudhra’s mistake under pressure.

Questions to Ask Your CA, Your HSM Vendor and Your PKI Team

Your public CA

• Can we see the key generation reports for the roots and intermediates that issue our certificates, and do they identify each key by a public key fingerprint?
• Was a Qualified Auditor present, or was video recorded, for your intermediate ceremonies, where the Baseline Requirements only recommend it?
• Do your ceremony tools compare the key in every CSR and certificate with the key generated at the ceremony?
• Do you run weak-key tests on your own CA keys, including small private values?
• When will you hold your first post-quantum key ceremony, and on which HSM firmware?

Your HSM vendor

• Which firmware versions have CMVP certificates that list ML-DSA, and SLH-DSA (formerly SPHINCS+) or LMS if you need them, as approved services?
• Do you store ML-DSA keys as seeds, expanded keys or both, and in which formats can they be backed up and moved?
• Can the HSM show that a key was generated on the device, through CKA_LOCAL or a signed key attestation?
• How do you manage LMS or XMSS state across backups and failover?

Your own PKI team

• Do we have a written, reviewed ceremony script for our internal roots and issuing CAs, and when did we last rehearse it?
• Who reviews the ceremony code, and is that person independent of its author?
• Do we record each key’s fingerprint at generation and check every later artifact against it?
• Who in the room can stop the ceremony?
• What evidence would stop a key from entering service, even if the ceremony completed and the certificate validates?
• Does our cryptographic inventory and CBOM record each CA key’s identifier, a link to its ceremony record and the trust stores that rely on it?

The Next Round of Ceremonies

On April 26, 2024, ICANN generated KSK-2024 at its facility in Culpeper, Virginia, on new HSMs, and published the scripts, logs and camera footage afterward. The key entered the DNS root zone on January 11, 2025 and became the only key-signing key the root zone uses on October 11, 2026. ICANN reported on October 15 that the rollover was completed as planned and that the previous key’s revocation remains scheduled for January 2027. It said it was still assessing whether issues affecting a limited number of systems were related to the rollover. A year after ICANN’s ceremony, eMudhra ran its own on Utimaco HSMs and produced eight intermediate keys that a laptop recovers in under a second.

Both organizations say their HSMs meet FIPS 140 requirements. Anyone can inspect ICANN’s controls in its published scripts, logs and footage, while eMudhra’s ceremony is known mainly through its own account after the fact. Every CA that wants post-quantum trust is about to write a new script for new firmware and new key formats. Before I asked a CA about its post-quantum algorithm, I would ask to see that script, the fingerprints in its last key generation report and the name of the person who can stop its next ceremony.

From the author