What Is Crypto-Agility? A Guide for PKI Architects and CISOs in Regulated Industries

Inside: a precise definition of crypto-agility, the three converging deadlines that now make it an operational requirement, the architecture and discovery work that make it real, and what a forced migration costs the organizations that lack it.

In late June 2024, Google’s Chrome Security Team announced that Chrome would stop trusting publicly issued TLS certificates chaining to several Entrust roots. Mozilla followed a month later. The trigger was not a single catastrophic breach: it was a pattern of compliance failures stretching back roughly six years, with Mozilla alone documenting 22 separate incidents between March and May of 2024.

Every enterprise running an Entrust certificate that would be issued after the cutoff faced the same question with a fixed deadline attached: can we find, replace, and redeploy these certificates before browsers start throwing security warnings at our users?

That question is the whole subject of this post. Crypto-agility is the capability to answer it (for any algorithm, any key, any certificate, on any timeline an outside party imposes) without turning the answer into a multi-week emergency. This guide is written for the PKI architects, infrastructure leads, and CISOs who own that capability in regulated environments: financial services, healthcare, government, energy, telecom, and manufacturing.

It covers what crypto-agility precisely is, the three converging pressures that have moved it from a maturity aspiration to an operational requirement, the architecture and discovery work that make it real, the migration patterns that actually hold up in production, and what a forced transition costs an organization that lacks it.

Quick Answer: What Is Crypto-Agility?

Crypto-agility is the operational capability to swap cryptographic algorithms, keys, certificates, and protocols rapidly and safely, without turning each change into an emergency. It is built from five properties: continuous inventory, algorithm abstraction, automated lifecycle management, enforced governance, and validation capability. An organization is crypto-agile when it can absorb any cryptographic transition as routine operations work, not just when it finishes one migration.

Key Takeaways

• Crypto-agility is a capability, not a migration. An organization is crypto-agile when it can absorb any cryptographic transition (a CA distrust, a broken algorithm, a shortened certificate validity, a post-quantum mandate) as routine operations work. Completing one migration does not make an organization agile; the capability that makes the next migration routine is what agility means.
• Three pressures now converge on the same narrow window and require different responses. The post-quantum mandate (NIST FIPS 203/204/205, finalized August 13, 2024) is a scheduled algorithm transition with federal deprecation of RSA and ECC after 2030. The CA/Browser Forum SC-081v3 schedule is a phased operational change collapsing public TLS validity to 47 days by March 15, 2029. The unscheduled shock (CA distrust, algorithm break, vulnerable library) arrives on no calendar. No single response covers all three; only capability does.
• The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year. The 2024 Entrust distrust illustrated what that downtime looks like when it is caused by an external CA event: organizations with discovery, multi-CA orchestration, and automated lifecycle management treated it as a filtered query and a scheduled reissue campaign. Organizations without those properties treated it as a cross-team emergency measured in weeks of overtime and outage risk.
• Discovery is the prerequisite for everything. No migration can be scoped, prioritized, or validated without a trustworthy cryptographic inventory. CT logs miss all private PKI. HSMs protect keys but do not catalog certificates or their deployment endpoints. A complete CBOM requires drawing from six discovery sources simultaneously: CT logs, network scanning, CA APIs, CMDB correlation, CI/CD scanning, and HSM inventory. For automated CBOM discovery across all six sources, CBOM Secure closes the gaps each individual source leaves open.
• Short-lived certificates and automated lifecycle management are the forcing function for the muscle that post-quantum migration also requires. The 47-day validity mandate makes manual certificate management operationally impossible, which forces the automation that a post-quantum algorithm transition will also depend on. Track post-quantum migration planning through the PQC Center of Excellence and assess readiness through PQC Readiness services.

Who Should Care About Crypto-Agility

Crypto-agility is a cross-functional requirement. The technical work is distributed across PKI operations, security architecture, platform engineering, and compliance, but the strategic mandate must come from the top. Every team listed below has a specific role in building and maintaining an agile cryptographic estate.

Role	Why It Matters	Action Item
PKI Admins	Own the certificate lifecycle automation that crypto-agility depends on: automated issuance and renewal via ACME, multi-CA orchestration so issuance can be re-pointed without re-architecting, policy enforcement at the issuance gate, and continuous certificate inventory; a CA distrust, algorithm deprecation, or validity reduction lands first as a certificate operations problem, and the speed of the response depends entirely on what has been automated before the deadline	Audit the current certificate estate using CBOM Secure; confirm multi-CA orchestration is configured and tested so issuance can be re-pointed without re-architecting; enable automated renewal via ACME for all public TLS populations; set renewal alerts for private PKI populations at 30 percent of remaining validity; add all certificate populations to CertSecure Manager with policy enforcement at the issuance gate
Security Architects	Own the algorithm abstraction design: ensuring applications reference cryptographic classes through policy rather than hard-coded algorithm names, so swapping an algorithm becomes a configuration change rather than a code change; also own the CBOM architecture (which discovery sources are integrated, how findings are classified by risk and exposure, and how the CBOM is kept current as new systems are deployed); and the hybrid deployment strategy for post-quantum transition	Map every application that hard-codes algorithm names and define an abstraction layer for each; design the CBOM architecture using all six discovery sources (CT logs, network scanning, CA APIs, CMDB, CI/CD pipelines, HSM inventory); define the hybrid deployment strategy for post-quantum transition (classical plus post-quantum in parallel); conduct a PQC readiness assessment through PQC Readiness services; track algorithm deprecation timelines through the PQC Center of Excellence
Platform and DevOps Teams	Own the automation pipelines that make crypto-agility executable at machine speed: ACME enrollment for short-lived certificates, CI/CD pipeline scanning to detect cryptographic material in artifacts and images, container and workload certificate provisioning, and the operational monitoring that detects certificate anomalies before they produce outages; the 47-day TLS validity mandate makes every manual deployment process a future outage risk	Integrate ACME enrollment into all service provisioning pipelines; add certificate expiry monitoring to platform observability alerting with thresholds calibrated to 30 percent of remaining validity; scan CI/CD artifacts and container images for embedded certificates and keys using CBOM discovery tooling; confirm that certificate rotation is tested in pre-production before each new deployment pattern is added to production
Compliance Teams	Must demonstrate that the cryptographic estate is inventoried, that algorithm and validity policy is enforced, and that migration evidence meets regulatory requirements; NIST SP 800-53 Rev. 5 SC-12 (Cryptographic Key Establishment and Management) and SC-17 (Public Key Infrastructure Certificates) require cryptographic governance; CNSA 2.0 compliance for defense industrial base organizations requires documented inventory and migration timelines beginning in 2025; the $7.1 billion OMB federal migration cost estimate reflects the compliance and operational exposure that an undocumented, brittle estate creates	Include CBOM inventory completeness in the quarterly compliance evidence package; confirm that certificate validity, algorithm, and key-size policy enforcement is documented and tested; map NIST IR 8547 deprecation milestones and CA/B Forum SC-081v3 phase dates to internal compliance deadlines; document the migration roadmap for post-quantum algorithms with named owners and dated milestones for each asset class
CISOs	Three external deadlines (NIST post-quantum deprecation 2030/2035, CA/B Forum 47-day validity March 2029, and unscheduled CA distrust events) now require crypto-agility to be a funded, governed, strategic program rather than a reactive project; the 2024 Entrust distrust demonstrated that organizations with agility absorb external cryptographic shocks as routine operations, while organizations without it absorb them as emergency projects that displace planned security work for months; post-quantum algorithm migration is the largest infrastructure transition most regulated industries have faced since Y2K	Fund crypto-agility as a multi-year strategic program with C-level accountability, defined RACI, and quarterly review; mandate CBOM inventory as a board-level KPI alongside vulnerability count and patch coverage; require that every new system deployment includes a cryptographic governance requirement before go-live; evaluate PKI as a Service for organizations that need a governed, multi-CA issuance capability without building and operating the infrastructure internally; track post-quantum migration planning through the PQC Center of Excellence

Post-Quantum Migration Roadmap by Asset Class

A practical migration roadmap sequences remediation by the combination of algorithm exposure, data confidentiality horizon, and system replaceability. The table below maps each major asset class to its algorithm exposure, migration priority, applicable NIST standard, recommended owner, and the relevant regulatory or policy timeline. Organizations should use their CBOM findings to populate the actual count of assets in each row before assigning migration sequencing.

Asset Class	Algorithm Exposure	Migration Priority	NIST Standard	Owner	Timeline / Deadline
Public TLS certificates (web servers, load balancers, CDN)	RSA-2048 / ECDSA P-256 in serverAuth profile; validity already collapsing to 200 days (March 15, 2026) then 100 days (March 15, 2027) then 47 days (March 15, 2029) under SC-081v3	High (operational urgency driven by CA/B Forum schedule); automation must be in place before manual renewal becomes impossible	FIPS 204 (ML-DSA) for signature; hybrid classical + ML-KEM (FIPS 203) for key exchange during TLS 1.3 handshake	PKI Admin + Platform Team	Automation required before March 15, 2027 (100-day phase); post-quantum hybrid recommended for new deployments from 2026
Private PKI certificates (internal mTLS, device authentication, machine identity)	RSA-2048 / ECDSA P-256 in clientAuth and device profile; not bound by SC-081v3 but exposed to the same algorithm deprecation as public TLS	High (largest population in most enterprises; CNSA 2.0 deadline for NSS-adjacent systems begins 2025)	FIPS 203 (ML-KEM) for key encapsulation; FIPS 204 (ML-DSA) for signatures; hybrid deployment recommended during transition	PKI Admin + Security Architect	CNSA 2.0 systems: begin 2025; federal systems: RSA/ECC deprecated after 2030 per NIST IR 8547; commercial regulated: align with sector-specific guidance
Code-signing certificates and firmware signing keys	RSA-2048 / ECDSA; signatures verify software and firmware integrity; if a code-signing key is broken retroactively, all software signed under it loses integrity assurance	Critical for long-lived software artifacts (firmware, BIOS, OS images) where signatures must remain verifiable for decades; the harvest-now threat applies to long-lived signed artifacts as well as encrypted data	FIPS 204 (ML-DSA); FN-DSA (derived from FALCON) for size-constrained firmware signing	Security Architect + Platform Team	NSS systems: CNSA 2.0 requires ML-DSA for new code signing by 2025; commercial: align with NIST IR 8547 2030 deprecation
CA root and intermediate certificate signing keys	RSA-4096 / ECDSA P-384 typically; the root signing key is the highest-value cryptographic asset in the estate; compromise or algorithmic weakness invalidates every certificate issued under it	Critical; root key compromise or algorithmic break has the largest blast radius; hybrid root keys (classical + post-quantum) are being piloted in public PKI programs	FIPS 204 (ML-DSA) for the signing algorithm; key protection requires FIPS 140-3 Level 3 HSM regardless of algorithm	PKI Admin + Security Architect	Plan root transition before NIST IR 8547 deprecation after 2030; hybrid root pilots recommended from 2026 for new hierarchies
Long-lived encrypted data at rest (database encryption, archive keys, backup encryption)	AES-256 (symmetric, quantum-safe for key sizes 256 bits and above); RSA or ECDH key wrapping for the symmetric key (vulnerable to harvest-now attack on the wrapping key)	Highest for data with confidentiality horizon beyond 2030 (medical records, financial contracts, national security information); the harvest-now threat makes current exposure real even though quantum computers do not yet exist	FIPS 203 (ML-KEM) for key encapsulation replacing RSA/ECDH key wrapping; AES-256 for symmetric encryption remains quantum-safe at current key sizes	Security Architect + Compliance Team	Immediate re-encryption or re-keying of long-lived data recommended; do not wait for NIST 2030 deprecation for high-confidentiality-horizon data
VPN and network infrastructure (IKEv2, TLS 1.3 session keys)	RSA / ECDH for key establishment in IKEv2 and TLS 1.3; symmetric session keys (AES-256) are quantum-safe; the harvest-now threat targets the key establishment phase	High for VPNs carrying classified or long-lived sensitive traffic; CNSA 2.0 requires IKEv2 post-quantum key establishment for NSS systems beginning 2025	FIPS 203 (ML-KEM) for key encapsulation in IKEv2 and TLS 1.3; hybrid classical + ML-KEM during transition	Platform Team + Security Architect	CNSA 2.0 systems: begin 2025; commercial: hybrid deployment recommended from 2026 for new VPN deployments

What Crypto-Agility Actually Means (and What It Doesn’t)

Crypto-agility is the ability of an organization’s systems to switch between cryptographic algorithms, keys, libraries, protocols, and certificates rapidly and safely, with minimal operational disruption. The emphasis belongs on capability rather than on any single change. An organization is crypto-agile when it can absorb a cryptographic transition as routine operations work, not when it happens to have finished one migration.

This distinction matters because the events that trigger a transition are not predictable. A cryptanalytic result can weaken an algorithm overnight. A browser root program can distrust a CA on its own schedule. A regulator can shorten a compliance window. A standards body can deprecate a key length.

Even after the post-quantum algorithms are deployed, organizations may need to move between them as new analysis emerges: these algorithms are young, and some of their properties will not be fully understood until a capable quantum computer exists to attack them. Agility is the property that lets you respond to the trigger you did not see coming, not just the one on the published roadmap.

It also helps to separate crypto-agility from three narrower terms it is often confused with. Certificate agility is the ability to discover, manage, and replace digital certificates quickly; it is a critical subset of crypto-agility, because certificates are the most numerous and most visible cryptographic objects in most estates, but it is not the whole.

CA-agility (sometimes described as being CA-tolerant) is the ability to switch issuing authorities without re-architecting, which is precisely the muscle the Entrust event exercised. Key agility concerns the rotation, re-keying, and re-encryption of the key material itself. A genuinely agile estate has all three, plus the algorithm flexibility that sits underneath them.

Why the Pressure Is Compounding Now: Three Deadlines on One Calendar

Crypto-agility has been good engineering advice for two decades. What changed is that three distinct pressures now converge on the same few years, and they differ in a way that makes any one-off response inadequate. One is a scheduled algorithm transition. One is a scheduled operational change in how certificates are issued. One is unscheduled and arrives whenever it arrives. Agility is the only capability that answers all three at once.

Force One: The Post-Quantum Mandate Is No Longer Theoretical

On August 13, 2024, NIST finalized its first three post-quantum standards, concluding an eight-year selection process that began in 2016. FIPS 203 specifies ML-KEM, the key-encapsulation mechanism derived from CRYSTALS-Kyber, intended to replace RSA and elliptic-curve key exchange. FIPS 204 specifies ML-DSA, a lattice-based signature scheme derived from CRYSTALS-Dilithium.

FIPS 205 specifies SLH-DSA, a hash-based signature scheme derived from SPHINCS+ that rests on a different security assumption as a hedge. A fourth signature standard, FN-DSA, derived from FALCON, followed for size-constrained use cases such as firmware signing.

The standards exist; the deadlines now drive behavior. NIST’s draft transition guidance, IR 8547, sets the direction for federal systems: RSA and elliptic-curve cryptography are slated to be deprecated after 2030 and disallowed after 2035. The NSA’s CNSA 2.0 suite, issued in September 2022, requires national security systems to move to ML-KEM-1024 and ML-DSA-87, with timelines beginning in 2025 and running through the early 2030s, and those requirements reach into the defense industrial base, not just government agencies.

National Security Memorandum 10 (May 2022) and the Quantum Computing Cybersecurity Preparedness Act (signed at the end of 2022) already obligate federal agencies to inventory their cryptography and begin transitioning. The financial driver is real too: the U.S. Office of Management and Budget has estimated the federal migration alone at roughly $7.1 billion.

Force Two: Public Certificate Lifespans Are Collapsing on a Fixed Schedule

In April 2025, the CA/Browser Forum adopted Ballot SC-081v3 by a vote of 29 in favor and none opposed. The ballot sets a phased reduction in the maximum validity of publicly trusted TLS certificates and in the period for which domain-control validation can be reused. The schedule is unambiguous, and it is short.

Effective Date	Maximum TLS Validity	Operational Reality
Before March 15, 2026	398 days	Annual renewal; disciplined manual processes survive
March 15, 2026	200 days	First forcing function; the runway closes
March 15, 2027	100 days	Quarterly cadence breaks most manual workflows
March 15, 2029	47 days	Renewal roughly every six weeks; revalidation near-continuous

By the final phase, domain-control validation reuse shrinks to ten days, which means validation effectively repeats on each renewal. Certificate authorities are already moving ahead of the deadlines for safety margin (DigiCert began issuing a maximum 199-day certificate on February 24, 2026, and Sectigo moved to 199 days on March 12, 2026) because exceeding a validity limit by even one second is a misissuance that triggers mandatory revocation. The companion ballot SC-085v2, requiring DNSSEC validation at issuance, lands alongside the first SC-081v3 phase, raising the operational bar further.

Two precise points keep this section honest. First, SC-081v3 governs only publicly trusted TLS certificates. Private PKI (the internal CAs most enterprises run for machine identity, mutual TLS, and device authentication) is not bound by it, and neither are S/MIME or code-signing certificates.

Organizations should set their own internal validity policies based on their threat model and automation maturity, not reflexively import the public-web schedule. Second, the value of the 47-day rule to an agility program is indirect: a six-week renewal cycle makes manual certificate management operationally impossible, which forces the automation that a post-quantum transition will also require. The mandate that looks like a burden is, in practice, the lever that builds the muscle.

Force Three: The Unscheduled Shock You Can’t Put on a Roadmap

The third force has no date because it arrives on someone else’s schedule. A CA gets distrusted. An algorithm gets broken. A library ships a vulnerability that turns a deployed cipher suite into a liability. These are not hypotheticals: they are the recurring texture of the field.

The migration from SHA-1 to SHA-2, sometimes called the “Shapocalypse,” took many organizations years. Google’s distrust of Symantec’s certificate authority across 2017 and 2018 forced the reissuance of a large fraction of the web’s certificates. The 2024 Entrust distrust, examined in detail later in this post, is simply the most recent entry in a long list.

The defining feature of this force is that planning cannot eliminate it; only capability can absorb it. An organization with a trustworthy inventory, abstracted cryptography, and automated lifecycle management treats a surprise distrust as a filtered query followed by an automated reissue campaign. An organization without those things treats it as a fire drill measured in overtime and outage risk.

The Anatomy of an Agile Cryptographic Estate

An agile cryptographic estate is one where five properties hold at once: you can see your cryptography, your applications do not name their algorithms in code, your certificate lifecycle runs without humans in the loop, your changes pass through enforced policy, and you can prove a new algorithm works before you depend on it. Each property is necessary; the absence of any one of them is where agility quietly fails.

The first property is visibility: a continuously maintained, authoritative inventory of every cryptographic asset, not a spreadsheet that was accurate the day it was compiled. The second is abstraction: cryptography is referenced through policy and cryptographic classes rather than hard-coded algorithm names, an approach sometimes called bring-your-own-crypto.

When an application asks the platform for a “digital signature” rather than for “ML-DSA-44,” swapping the underlying algorithm becomes a configuration change instead of a code change. The third is automation of the full certificate and key lifecycle (issuance, renewal, revocation, provisioning, and rotation) executing at machine speed and scale.

The fourth is governance: enforced policy, defined ownership, approval workflows for sensitive changes, and a complete audit trail. The fifth is validation: the ability to test hybrid and post-quantum configurations in non-production before they become load-bearing.

The contrast between an estate that has these properties and one that does not is stark in practice.

Dimension	Brittle Estate	Agile Estate
Inventory	Partial spreadsheets, stale within weeks	Continuous automated discovery, single source of truth
Algorithm binding	Hard-coded in applications and firmware	Referenced by policy or cryptographic class
CA dependency	Single issuer, manual reissue on change	Multiple issuers, orchestrated re-pointing (CA-agility)
Certificate lifecycle	Manual issuance and renewal, calendar reminders	Automated via ACME and APIs, policy-gated
Response to a forced change	Emergency project measured in weeks	Filtered query plus automated campaign, measured in hours
Governance	Ad hoc, ownership unclear at incident time	RACI-defined, C-level accountable, audit-ready on demand

Two structural traps deserve a specific warning, because they are the hardest to undo. Cryptography embedded in secure boot loaders and hardware roots of trust cannot be swapped by updating software; if those mechanisms weaken, the fix is a redesign. And cryptography distributed across subsystems owned by different teams tends toward weaker overall protection and fragmented visibility, because no one holds the whole picture. Agility is therefore as much an organizational design problem as a technical one, which is the thread the rest of this post pulls on.

Discovery: Why You Can’t Migrate What You Can’t See

Discovery is the foundation, and it is the step most organizations underestimate. Every downstream decision (what to prioritize, what to replace first, what to test, what to prove to an auditor) depends on an inventory that reflects reality. The uncomfortable truth is that cryptographic assets hide. Keys and certificates are embedded in applications, file systems, network interfaces, hardware devices, cloud services, CI/CD pipelines, container images, and legacy systems that no current employee fully understands.

A trustworthy inventory has to draw on several discovery surfaces at once, because no single source sees the whole estate. This is where a great deal of well-intentioned discovery work goes wrong, so it is worth being precise about what each source can and cannot find.

Discovery Source	What It Surfaces	What It Misses
Certificate Transparency logs	Publicly issued TLS certificates	All private and internal PKI; any non-TLS key material
Network and endpoint scanning	Certificates active on reachable listeners	Dormant certificates, embedded keys, offline systems
CA databases and APIs	Certificates a known issuer produced	Certificates from CAs you do not query; self-signed material
CMDB and asset inventory	Ownership and system-to-asset mapping	The cryptography itself, unless explicitly linked
CI/CD and binary scanning	Keys and certificates in pipelines and artifacts	Material that exists only at runtime
HSM inventory	Keys held under management	Certificates: an HSM protects keys, it is not a certificate catalog

Two misconceptions are worth retiring directly. Certificate Transparency logs are sometimes treated as a master inventory; they are not. CT logs only capture certificates from publicly trusted CAs, which means an organization’s entire internal PKI (often its largest population of certificates) is invisible to them.

Likewise, an HSM is frequently assumed to be the place you go to enumerate certificates; it is not. An HSM safeguards private keys, but it does not maintain a searchable inventory of the certificates those keys correspond to or the endpoints where they are deployed. Endpoint scanning, network discovery, CA APIs, CMDB correlation, pipeline scanning, and a cryptographic bill of materials (CBOM) are what close the gap that CT logs and HSMs leave open.

Once assets are visible, they need to be classified by risk and exposure so remediation can be sequenced. A practical scheme sorts every asset into states (not compliant, legacy, compliant, and post-quantum-ready) and links each finding to a business owner and a system, so that prioritization aligns with enterprise risk rather than with whatever a scanner happened to find first. The harvest-now, decrypt-later threat sharpens this prioritization: data with a long confidentiality horizon moves to the front of the queue.

The Migration Patterns That Work: Hybrid, Abstraction, and Re-Encryption

When it comes to actually moving an estate, three patterns have proven durable in production: hybrid deployment during the transition, algorithm abstraction in application design, and re-encryption of long-lived data. Each addresses a different failure mode, and together they describe how a careful organization moves without betting everything on an unproven algorithm.

Hybrid deployment combines a well-established classical algorithm with a post-quantum one in a single cryptographic operation, so that the result stays secure as long as either component holds. The rationale is twofold: the post-quantum algorithms lack the decades of scrutiny that RSA and elliptic-curve cryptography have accumulated, and transitioning an entire infrastructure at once is risky. Running ML-KEM-768 in parallel with X25519 during key establishment is the canonical example, and it already has real-world endorsement:

Abstraction is the design discipline that makes every future migration cheaper than the last. When applications refer to cryptographic classes rather than specific algorithms, swapping an algorithm becomes a policy decision propagated through configuration, not a code change shipped through a release cycle. This is the same bring-your-own-crypto principle described earlier, viewed from the migration side: it reduces provider lock-in, lowers the blast radius of a future standards change, and lets a vendor ship a single product across jurisdictions with different cryptographic requirements.

Re-encryption and rotation address the failure mode the other two patterns do not. Swapping the algorithm you use going forward does nothing for data an adversary has already captured. If encrypted secrets have been exfiltrated, deploying a new algorithm tomorrow leaves yesterday’s harvested ciphertext exactly as exposed as it was. That is why re-encryption of long-lived data and rotation of key material have to be part of the migration, not an afterthought, and why short-lived, just-in-time credentials are such a powerful complement. An ephemeral token or single-use key that expires in minutes is worthless to an adversary by the time a quantum computer could break it.

What the Entrust Distrust Actually Cost Organizations

Return to the event this post opened with, because it is the clearest illustration of agility tested in the wild. When Chrome announced it would distrust TLS certificates chaining to Entrust roots with a Signed Certificate Timestamp dated after November 11, 2024, and Mozilla set its own cutoff at November 30, 2024, every affected organization inherited a hard deadline and a finite set of tasks.

Entrust arranged to keep issuing publicly trusted certificates as a delegated authority through a partnership with SSL.com, but that did not relieve customers of the work, and infrastructure providers reacted on their own timelines, with Akamai announcing it would remove Entrust and AffirmTrust roots from its origin trust store by March 1, 2025.

The work itself was not exotic. It was a sequence of concrete steps, and the gap between a brittle estate and an agile one shows up at every single one.

1. Find every Entrust-issued certificate across the estate: This is a discovery problem, and it is where organizations without a current inventory lost the most time: combing endpoints, load balancers, cloud services, and forgotten internal systems by hand.
2. Map each certificate to an owner and the systems that depend on it: Without CMDB correlation, this becomes archaeology: tracing which application, which team, and which downstream integration each certificate quietly supports.
3. Select and onboard a replacement certificate authority: An estate with CA-agility already had alternative issuers integrated; an estate locked to a single CA had to evaluate, contract, and integrate a new one under deadline pressure.
4. Reissue and redeploy at scale before the cutoff: Manual reissuance across hundreds or thousands of certificates is precisely the workload automation exists to absorb; doing it by hand is where outage risk concentrates.
5. Validate the new chains and monitor for breakage: Every replacement has to be verified end to end, with monitoring in place to catch the certificate that was missed or misconfigured before a user does.

For an organization with discovery, multi-CA orchestration, and automated lifecycle management, this sequence is a filtered query and a scheduled reissue campaign: disruptive, but bounded, and measured in hours of oversight rather than weeks of overtime. For an organization without them, the same sequence is a cross-team emergency that displaces planned work for a month and still risks a public outage. The distrust did not create that cost. The absence of agility did.

How CertSecure Manager Delivers Crypto-Agility

CertSecure Manager is Encryption Consulting’s certificate lifecycle management platform, built to turn the five properties of an agile estate into day-to-day operations rather than a project plan. Its capabilities map directly onto the pressures described above.

• Continuous discovery and inventory: Agent-based and network discovery build a continuously updated record of certificates and keys across endpoints, load balancers, and cloud workloads: the trustworthy inventory that every downstream decision depends on, and the thing a forced migration needs first.
• Multi-CA orchestration and CA-agility: The platform integrates with public and private issuers (Microsoft ADCS, HashiCorp Vault, and external CAs) so issuance can be re-pointed to a different authority without re-architecting. This is the exact capability the Entrust distrust demanded under deadline.
• Policy enforcement at the issuance gate: Allowed algorithms, key sizes, validity periods, and approved issuers are enforced centrally, so non-compliant certificates are blocked before they exist rather than discovered later in an audit.
• Automated lifecycle management: Issuance, renewal, revocation, and provisioning run through ACME and native integrations, sized for the renewal cadence that SC-081v3 makes mandatory as validity falls toward 47 days.

The throughline is that CertSecure Manager treats a cryptographic change (a CA swap, an algorithm transition, a validity reduction) as routine, governed, automated work, which is the operational definition of crypto-agility.

How Can Encryption Consulting Help?

Encryption Consulting has spent more than a decade advising regulated enterprises (across financial services, healthcare, government, energy, telecom, and manufacturing) on PKI, certificate lifecycle management, and cryptographic strategy. That experience is built into CertSecure Manager, a certificate lifecycle management platform that unifies discovery, multi-CA orchestration, policy enforcement, and automated issuance and renewal so that cryptographic change becomes routine operations rather than a recurring emergency.

The goal is simple: make your estate able to change on demand, before an outside deadline makes that change urgent.

Beyond the platform, our PKI Services design and modernize the two-tier and HSM-backed architectures that issuance depends on, our Post-Quantum Readiness assessment builds the inventory and migration roadmap that NIST’s timelines now require, and CBOM Secure delivers the cryptographic discovery and bill-of-materials visibility that turns an unknown estate into a managed one. For ongoing post-quantum algorithm migration guidance, planning resources, and regulatory timeline tracking, visit the PQC Center of Excellence. To talk through where your organization stands, reach out at [email protected] or visit www.encryptionconsulting.com.

Conclusion

Three pressures have converged on the same narrow window, and they are different enough that no single response covers them. The post-quantum mandate is a scheduled algorithm transition with deprecation in 2030 and a hard line in 2035. The collapse of public TLS validity to 47 days by March 2029 is a scheduled operational change that makes manual certificate management impossible. And the unscheduled shock (a distrust, a break, a vulnerable library) arrives whenever it arrives. Crypto-agility is the one capability that answers all three, because it is about the ability to change rather than about any particular change.

The evidence that agility is the deciding variable is not theoretical. The SHA-1 transition, the Symantec distrust, and the 2024 Entrust distrust all imposed the same finite sequence of work on every affected organization. The deadlines on the roadmap are a gift, because they give you time to build the capability before the unscheduled shock tests it.

That window is closing on a published calendar: the first SC-081v3 phase is already in effect, and the post-quantum deprecation dates are fixed. The organizations that treat the next scheduled change as the forcing function, rather than the last one, are the ones that will move through the coming transitions as a managed change instead of a crisis.

Frequently Asked Questions

What is crypto-agility?

Crypto-agility is the ability of an organization’s systems to replace cryptographic algorithms, keys, certificates, and protocols quickly and safely, without disrupting the systems that depend on them. It is an operational capability built from inventory, abstraction, automation, and governance, not a single migration or a product you switch on. NIST describes it as a practice that organizations should adopt at every layer, from the algorithms themselves up through enterprise architecture.

Why does crypto-agility matter in 2026?

Three pressures now coincide: NIST finalized its post-quantum standards in August 2024 with federal deprecation of RSA and ECC slated after 2030, the CA/Browser Forum is driving public TLS certificate validity down to 47 days by March 15, 2029, and unscheduled events like the 2024 Entrust distrust continue to force migrations on outside timelines. Agility is the only capability that addresses all three at once.

What is the difference between crypto-agility and certificate agility?

Certificate agility is the ability to discover, manage, and replace digital certificates quickly. Crypto-agility is broader: it covers algorithms, keys, libraries, and protocols in addition to certificates. Certificate agility is an essential subset of crypto-agility, because certificates are usually the most numerous cryptographic objects in an estate, but it is not the whole picture.

Does the 47-day certificate rule apply to internal PKI?

No. CA/Browser Forum Ballot SC-081v3 governs only publicly trusted TLS certificates. Internal or private PKI, S/MIME, and code-signing certificates are not bound by it. Organizations should set internal validity policies based on their own threat model and automation maturity rather than automatically adopting the public-web schedule.

What are the NIST post-quantum cryptography standards?

NIST finalized three standards on August 13, 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a hash-based signature scheme used as a hedge). A fourth signature standard, FN-DSA derived from FALCON, followed for size-constrained applications. These replace RSA and elliptic-curve cryptography in their respective roles.

What is harvest now, decrypt later?

Harvest now, decrypt later is a threat model in which an adversary captures encrypted data today and stores it, intending to decrypt it once a cryptographically relevant quantum computer exists. It makes post-quantum preparation urgent for data with long confidentiality lifetimes, because that data is already exposed the moment it is transmitted, and deploying a new algorithm later does not protect what was already captured.

Why is hybrid cryptography recommended during the transition?

Hybrid cryptography combines a classical algorithm with a post-quantum one in a single operation, so the result stays secure as long as either component holds. It is recommended because the post-quantum algorithms are relatively new and lack decades of scrutiny, and because migrating an entire infrastructure at once is risky. ENISA, ETSI, and Google’s Chrome implementation all endorse or ship hybrid approaches.

Does CertSecure Manager support crypto-agility?

Yes. CertSecure Manager is built to operationalize agility through continuous discovery and inventory, multi-CA orchestration that lets you re-point issuance without re-architecting, policy enforcement at the issuance gate, and automated certificate lifecycle management sized for short-validity environments. It also integrates with Luna, Thales, and cloud HSMs to keep private keys in hardware.

What should be inventoried before a post-quantum or crypto-agility migration?

A complete cryptographic bill of materials (CBOM) must be established before migration, drawing from multiple discovery sources simultaneously: certificate transparency logs (publicly issued TLS only), network and endpoint scanning (active listeners), CA databases and APIs (known issuers), CMDB and asset inventory (ownership mapping), CI/CD and binary scanning (pipeline and artifact material), and HSM inventory (managed key material). No single source sees the full estate. CT logs miss all private PKI; HSMs protect keys but do not catalog certificates or their deployment endpoints. CBOM Secure automates discovery across all six sources simultaneously.

How does crypto-agility support post-quantum readiness?

Crypto-agility is the enabling capability for post-quantum readiness. The NIST post-quantum migration requires replacing RSA and elliptic-curve algorithms with ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) across an entire cryptographic estate. An organization with crypto-agility (continuous CBOM inventory, algorithm abstraction, automated certificate lifecycle, multi-CA orchestration) can execute that transition as a governed, phased change. An organization without those properties faces the same transition as a multi-year emergency project. Assess your current readiness through PQC Readiness services and track migration planning through the PQC Center of Excellence.