Key and Certificate Rotation: Building a Cadence That Isn't Just for Emergencies

Building a practice of regular key and certificate rotation prepares the business to move quickly during emergencies

The October 2026 eMudhra incident is a perfect example of an emergency migration after certificate management went wrong. The certificate authority (CA) had eight intermediate certificates with trivially-guessable private keys. While no end-user certificates were generated by these eight, 30,000 certificates had their chains of trust to their root CAs broken.

While this incident wasn't preventable by eMudhra users, it demonstrates the importance of a strong certificate and key rotation practice. Organizations with the ability to rapidly swap out at-risk certificates are better able to address this and similar incidents.

How Key and Certificate Rotation Work

Key and certificate rotation programs involve swapping out private keys and digital certificates at regular intervals. The logic is that, if private keys are compromised, then the security impacts are limited to the window when a key or certificate is active.

Digital certificate rotation is considered best practice, and the CA/Browser Forum is imposing smaller and smaller validity windows for publicly trusted TLS certificates. In March 2027, validity windows will be 100 days, and they will decrease to 47 days two years later.

At these cadences, manual certificate rotation and migration no longer works. Organizations will need to automate certificate management to ensure websites and apps continue to function. While certificate rotation doesn't require changing an algorithm, the same cryptographic inventory, automation, deployment, and rollback infrastructure can support both as part of a broader crypto-agility strategy.

Lessons Learned from the eMudhra Incident

eMudhra exemplifies an emergency rotation of digital certificates. Once those intermediate certificates were discovered to be insecure, many web browsers and software providers blocked the root certificate. This broke the chain of trust tying the 30,000 impacted certificates to a root CA, meaning that sites and applications relying on them were untrusted by major browsers.

This incident demonstrates the importance of visibility into an organization's risk exposure and cryptographic supply chain. Key governance lessons include:

Know What Chains to What: The various digital certificates within an organization's environment may chain back to different root CAs. A complete inventory of certificates in use and their associated CAs is essential to a rapid migration if a CA distrust event occurs (and eMudhra is far from the first).
Maintain CA Agility: In the event of an incident like this one, an organization needs to be able to migrate certificates rapidly from one CA to another on short notice. This automation should be in-place and tested at scale before it's needed.
Inventory Trust Stores and Revocation: In the wake of the eMudhra incident, major browsers quickly untrusted certificates; however, embedded devices, apps with bundled CA stores, and similar systems won't do so automatically. Mapping out these secondary CA stores and trust anchors is essential to a complete migration away from an untrusted certificate.
Manage Key Generation: eMudhra claims that these certificates were the result of weak ECC key pairs being generated on an HSM alongside strong ones during a test of wrapping/unwrapping. Since their names were similar to the real ones, these weak keys were signed and issued instead of the real ones. Organizations should ensure that their key generation processes are secure and validated and that keys are properly protected within hardware security modules (HSMs) or similar secret stores.
Automate Routine and Triggered Migration: Digital certificates and keys should be automatically rotated on a regular cadence. However, the organization should have a defined, tested path for triggering an unscheduled rotation in response to a compromise or distrust event.

Defining a Rotation Cadence

Key rotation should apply to all of an organization's digital certificates and secret keys. These include:

Internal and public TLS certificates
Issuing CAs
Code signing keys
Token signing keys
Data and key encryption keys
SSH keys

The exact cadence should be determined on a case-by-case basis and might have internal or external (e.g. regulatory) drivers. For each key or certificate, the organization should define a maximum lifetime, an automated process for periodic and triggered rotation (with a defined exceptions process), and role-based ownership of each key.

Top Challenges for Automated Key Rotation

Ideally, key rotation can be easily automated using ACME, KMS-managed rotation, or centralized secrets managers. Data on certificates and keys (issuer, expiry, etc.) can be tracked within the CBOM to ensure comprehensive visibility.

In reality, automated key rotation processes can be broken by:

Certificate pinning
Hardcoded keys and certificates
Embedded and IoT devices
Manual installs
Third-party software and endpoints

Many of these can be addressed by implementing crypto-agility best practices, such as avoiding hardcoded keys or manual installs, or building changes into the automation process (such as automatic repinning). Others may require careful tracking in the CBOM to manage the potential risk.

In the case of data encryption, key rotation can be implemented using envelope encryption. Replacing the key encryption key (KEK) with the new keys effectively implements key rotation without the need to re-encrypt all of the data. However, if the data encryption key is leaked, the data must be re-encrypted with a new key.

Measuring the Success of a Rotation Program

A rotation program needs to be able to address two situations. One is that a key undergoes rotation at the specified interval. The other is that rotation occurs in response to a specific event, like the eMudhra incident.

The success of a key and certificate rotation program can be measured using a few different metrics, including:

Share of keys/certificates on automated rotation
Median time to rotate
Time required to replace all certificates from a specific issuer
Inventory coverage of issuer and expiry metadata

FAQs

Would routine key rotation have prevented the eMudhra incident?

No, the eMudhra incident stemmed from the initial key generation ceremony, where extremely weak private keys were used to generate digital certificates. eMudhra claims the root cause was a faulty key generation script, so any keys generated or rotated using the same flawed process would have had the same flaw.

How do we find every certificate that chains to a given CA?

Finding every certificate that chains to a certain CA requires using a few different techniques. Certificate Transparency highlights your organization's publicly-trusted certificates, and endpoint scans can identify those certificates that are actively deployed. Internally, organizations should also check certificate management and PKI tooling, internal and private PKI infrastructure, code signing certificates, and any certificates managed by a third party on your behalf.

Do browser protections cover our internal applications and devices?

No, many internal applications and devices have their own trust stores, which are distinct from those managed by the major browsers. Internal devices, server-to-server clients, embedded devices, and other applications with self-managed trust stores may not receive or heed the blocks that the browsers apply to their trust stores.

Do we need a second CA?

No, but it's important to have the ability to switch when needed. Automated migration and rotation infrastructure is essential, such as the ability to point ACME clients to a different CA. Additionally, this migration path should be fully tested to ensure that it's operational when needed.