Crypto-Agility & Compliance

Three separate clocks are converging on the same overloaded team. Here is what changes on September 21, what changes again in March, and how to automate your way out before an expired certificate takes down a payment rail.

ibm/SEIMless Communications Technologies, Inc.

For most enterprises, certificate lifecycle management has never been a strategic conversation. It was a spreadsheet, a shared mailbox, and a calendar reminder that someone set three years ago and nobody has looked at since. That arrangement is about to fail — not gradually, but on specific, published dates that are already on the federal record.

At the same time, the maximum lifetime of a public TLS certificate has already dropped to 200 days, on its way to 100 days in March 2027 and 47 days in March 2029. And NIST has formally scheduled the retirement of the RSA and elliptic-curve cryptography that virtually every certificate in your estate depends on today.

Individually, each of these is a project. Together, they are a structural change in how networks have to be built. This post explains all three, shows which one hits your industry first, and lays out the certificate lifecycle management playbook we use at ibm/SEIMless to get enterprises from manual renewal to genuine crypto-agility.

What Is Certificate Lifecycle Management?

The critical word in that definition is algorithm-agnostic. Historically, certificate lifecycle management was about not letting things expire. In 2026, it is about being able to change what your certificates are made of — quickly, at scale, and more than once. NIST’s National Cybersecurity Center of Excellence calls this property crypto-agility, and it now drives every serious network design conversation we have.

Deadline One: FIPS 140-2 Validation Sunsets This Month

The Cryptographic Module Validation Program, jointly run by NIST and Canada’s cyber centre, is the arbiter of whether a cryptographic module can be used in U.S. federal systems. Its transition schedule has been public for years, and it lands this month.

• April 1, 2022: CMVP stopped accepting new FIPS 140-2 validation submissions. Everything issued since has been FIPS 140-3.
• September 21–22, 2026: All remaining FIPS 140-2 certificates move to the Historical List. Per the CMVP program page, agencies may continue using those modules for existing systems only. The FIPS 140-3 Transition Effort page documents the same milestone.
• After that date: New procurements, FedRAMP packages, CMMC assessments, and downstream vendor questionnaires increasingly require FIPS 140-3 validated modules.

Here is the part that catches people out: this is not only a government problem. FIPS validation is written into commercial contracts across banking, insurance, and healthcare because it is the cheapest available shorthand for “this crypto was independently tested.” When your module drops to the Historical List, your customer’s procurement team sees it in their next vendor review — and the burden of proof lands on you.

The practical question is not “are we compliant today.” It is: can you produce, on request, a list of every module in your environment and its current validation status? Most organizations cannot, which is precisely the certificate lifecycle management gap. Federal agencies have been under an explicit cryptographic inventory mandate since the White House issued OMB Memorandum M-23-02; the private sector is simply arriving at the same requirement through contracts instead of memos. If your organization sells into the defense supply chain, the same evidence is expected under CMMC and, for cloud services, under FedRAMP.

Deadline Two: TLS Certificate Lifetimes Are Collapsing Toward 47 Days

In April 2025, the CA/Browser Forum passed Ballot SC-081v3, which sets a staged reduction in the maximum validity of publicly trusted TLS certificates. The schedule is not a proposal. It is in force.

Read the right-hand column again. An enterprise that renews 400 public certificates once a year today will be executing roughly 3,200 renewal events per year by 2029 — plus domain revalidation every ten days. No staffing model absorbs that. This is the single clearest argument for automated certificate lifecycle management ever put in front of a CFO, because the labor math stops working long before the security math does.

It also changes the blast radius of a mistake. When certificates lasted over a year, a missed renewal was an embarrassment. When they last 47 days, a broken automation pipeline silently expires your entire estate inside two months. NIST’s TLS Server Certificate Management project (SP 1800-16) documents exactly this failure pattern, and NIST SP 800-52 Rev. 2 remains the federal baseline for TLS configuration itself.

Deadline Three: NIST Has Scheduled the Retirement of RSA and ECC

The third clock is the one this company was built around. In NIST IR 8547, NIST published a transition timeline for the classical algorithms underpinning today’s certificates:

• After 2030: RSA, ECDSA, ECDH, and finite-field Diffie-Hellman at 112-bit security strength are deprecated
• After 2035: those algorithms — including their 128-bit-and-above variants — are disallowed

Replacements are already standardized: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures, finalized by NIST in August 2024. The NSA’s Commercial National Security Algorithm Suite 2.0 sets an even more aggressive posture for national security systems — see the CNSA 2.0 FAQ and the broader NSA cybersecurity guidance library.

Post-quantum certificates are also structurally different: ML-DSA signatures and public keys are substantially larger than their ECC equivalents. That changes handshake sizes, MTU behavior, load balancer buffers, and embedded device storage. You do not discover those problems in a policy document — you discover them the first time you try to deploy a real certificate through your real network. Which is why the inventory has to come first, and why we cover the underlying mathematics in our explainer on quantum computing and encryption.

Why Certificate Lifecycle Management Is Really a Quantum-Resistance Problem

Treat these as three unrelated compliance chores and you will run three unrelated projects, three times, over the next decade. Treat them as one problem and the answer is singular: build a network that can change its cryptography on demand.

That is the whole thesis of crypto-agility, and every U.S. authority now converges on it. CISA’s Post-Quantum Cryptography Initiative makes cryptographic discovery and inventory the first step in its migration model; its Strategy for Migrating to Automated PQC Discovery and Inventory Tools is explicit that manual inventories do not scale. The NIST Cybersecurity Framework 2.0 puts asset identification ahead of protection for the same reason. Automated certificate lifecycle management is how that identification stays true from one week to the next.

And the urgency is not theoretical. Adversaries are already capturing encrypted traffic today to decrypt once a cryptographically relevant quantum computer exists — the pattern we covered in Harvest Now, Decrypt Later. Data with a ten-year confidentiality requirement is already exposed. Certificates are simply the control plane you use to fix it.

What Breaks First, by Industry

Financial Services and Insurance

Payment rails, trading systems, and claims platforms carry the highest density of machine identities and the lowest tolerance for downtime. Examiners are already asking. The FFIEC IT Examination Handbook covers encryption and key management directly; New York institutions face NYDFS Part 500, which mandates encryption controls and annual review; and public companies must disclose material incidents under the SEC’s cybersecurity disclosure rules. An outage caused by an expired certificate is an operational event you will be explaining in writing.

Healthcare

Medical records carry decades-long confidentiality obligations, which makes healthcare the most exposed vertical to harvest-now-decrypt-later. The HIPAA Security Rule requires encryption of ePHI in transit and at rest, and clinical environments are dense with long-lived embedded devices that were never designed for 47-day certificate rotation. Those devices are where certificate lifecycle management programs quietly fail.

Carriers, MSPs, and Multi-Nationals

Providers inherit their customers’ obligations. If you operate infrastructure on behalf of regulated clients, every one of these three deadlines arrives as a contractual question from a client procurement team — often all three in the same questionnaire. Consumer-facing firms should also review the FTC Safeguards Rule, which sets encryption expectations for non-bank financial institutions.

The ibm/SEIMless Certificate Lifecycle Management Playbook

This is the sequence we run with clients. It is deliberately ordered — each step makes the next one cheaper.

1. Build a cryptographic bill of materials

Discover every certificate, key, algorithm, key length, module, and expiry across data centers, cloud, branch, and remote endpoints. Include internal PKI, not just public certificates — internal estates are typically three to ten times larger and far less governed. Correlate findings against the National Vulnerability Database and the CISA Known Exploited Vulnerabilities Catalog so cryptographic debt and exploitable debt are ranked on one list.

2. Automate issuance and renewal — with no exceptions

Any certificate that a human renews by hand is a certificate that will expire. At 200 days it is a risk; at 47 days it is a certainty. ACME-based automation should be the default path, and every exception should carry a named owner and a documented reason.

3. Re-validate every module against FIPS 140-3

Map each cryptographic module to its validation certificate and its status after this month’s Historical List transition. Where a vendor has no FIPS 140-3 path, that is a procurement decision, not an engineering one — escalate it now, while you still have runway.

4. Test hybrid and post-quantum certificates in a real lab

Deploy ML-KEM hybrid key exchange and ML-DSA certificates against representative load balancers, firewalls, and clients. Measure handshake size, latency, and failure modes. Our data in motion and data at rest practices exist for exactly this validation work.

5. Centralize key custody

Certificate lifecycle management fails when keys live in a dozen places under a dozen policies. Consolidate custody, rotation, and escrow under a single governed service — the role our Exodus key management platform plays.

6. Rehearse the emergency rotation

Assume a certificate authority is compromised, or an algorithm is broken, on a Friday afternoon. How many hours to rotate everything? If the answer is unknown, it is too long. Run the drill, measure it, shorten it, repeat annually.

7. Write crypto-agility into contracts

Every renewal from here forward should require FIPS 140-3 validation, a published post-quantum roadmap, and automated certificate lifecycle management support. Buying it into the estate is cheaper than retrofitting it.

How Exodus QRN Makes This Operational

ibm/SEIMless has spent more than twenty years as a vendor-agnostic integrator, which is how we saw the flaw in SD-WAN and SASE early enough to build past it. Exodus QRN was designed on the assumption that cryptographic standards will keep changing — so certificate and algorithm changes are configuration, not reconstruction.

• Quantum-resistant networking built on NIST-standardized post-quantum algorithms with hybrid transition modes
• Transparent encryption that protects traffic without rewriting applications
• NxTGen firewall and zero trust content security so certificate identity and access policy are enforced together
• Exodus Aria ADR and endpoint detection and response for the machine identities the network cannot see on its own
• SD-WAN and managed network services that carry quantum-safe policy consistently to every branch and remote site

Because we manufacture as an OEM and remain carrier- and cloud-agnostic, we can rebuild the cryptographic layer without forcing a wholesale hardware refresh — the difference between a migration and a rip-and-replace. Our earlier post-quantum cryptography migration playbook covers the algorithm-selection layer that sits beneath this certificate work.

Frequently Asked Questions

What is certificate lifecycle management in simple terms?

It is the end-to-end process of finding, issuing, deploying, renewing, rotating, and revoking every digital certificate and key in an organization. Modern certificate lifecycle management is automated and algorithm-agnostic so cryptography can be replaced without redesigning the network.

What happens to FIPS 140-2 certificates on September 21, 2026?

They move to the CMVP Historical List. Per NIST, agencies may continue using those modules for existing systems only. New procurements and most compliance attestations will expect FIPS 140-3 validated modules.

Are TLS certificates really dropping to 47 days?

Yes, on a staged schedule set by CA/Browser Forum Ballot SC-081v3: 200 days as of March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029, with domain validation reuse falling to 10 days.

When do RSA and ECC actually stop being allowed?

NIST IR 8547 deprecates 112-bit RSA and elliptic-curve algorithms after 2030 and disallows RSA, ECDSA, ECDH, and Diffie-Hellman after 2035. Systems holding data with long confidentiality lifetimes should migrate well ahead of those dates.

Can we handle 47-day certificates without automation?

Realistically, no. A 400-certificate estate moves from roughly 400 renewal events per year to roughly 3,200, plus domain revalidation every ten days. Automated certificate lifecycle management is the only model that scales.

Should we wait for post-quantum standards to settle before starting?

No. The three primary standards — FIPS 203, 204, and 205 — were finalized in August 2024. Inventory and automation work is valuable regardless of which algorithms you eventually deploy, and it is the long pole in every migration we have run.

The Bottom Line

Certificate lifecycle management stopped being a maintenance task the moment the renewal cadence outgrew the people doing it. Between the FIPS 140-2 sunset this month, TLS validity shrinking toward 47 days, and NIST’s deprecation of RSA and ECC, the enterprises that automate now will absorb every one of these changes as a configuration update. The ones that wait will absorb them as outages, failed audits, and emergency projects priced at three times the cost.

The work is knowable and the deadlines are published. What separates the two outcomes is whether you start before or after something breaks.