The 100-Day Deadline Lands March 2027. Most Teams Are Still Planning for 2029.

Announcing PKI Insights 7.3 — built-in CLM for FortiWeb, ADFS, Microsoft SQL Server, Exchange and RDP, a pluggable CLM module for any server, and PQC Readiness across your entire certificate estate.

The wrong deadline is getting all the attention

Ask a security team about shortened certificate lifetimes and you will almost always hear the same number: 47 days. It is the headline figure from CA/Browser Forum Ballot SC-081v3, and it is genuinely disruptive.

It is also 2029.

Here is the schedule that ballot actually set for publicly-trusted TLS certificates:

Two things stand out.

• First, the 200-day cap is already in force. It went live in March 2026. If your renewal runbook still assumes an annual cycle, it is already out of date.
• Second, the next step down — 100 days, on 15 March 2027 — is less than seven months away. That is not a strategic planning horizon. That is inside the current budget year, inside most change-freeze calendars, and inside the lead time for a procurement cycle at almost any regulated enterprise.

Teams that build for 100 days now will arrive at 47 days in 2029 with a working automation platform and a tuning exercise ahead of them. Teams that wait for 2029 will do an emergency project in 2027, and then do it again.

One clarification before the numbers: SC-081 binds publicly-trusted certificates, so the certificates your internal ADCS or EJBCA instance issues are not governed by it. That is not a reprieve — enterprises are already shortening internal lifetimes voluntarily for the same reasons, so the arithmetic below applies to the internal estate too, with nobody outside your organisation enforcing the deadline.

The arithmetic that decides this for you

At a 100-day maximum validity, you cannot renew on the last day. Real operations need a buffer — most teams will settle on roughly a 90-day cadence, which means four renewals per endpoint per year.

Assume one hour of engineer time per renewal. That is a generous assumption: it covers requesting the certificate, retrieving it, installing it on the endpoint, updating the chain, restarting or reloading the service, and confirming the new certificate is actually being served. It assumes nothing goes wrong.

* Based on ~1,800 productive engineering hours per person per year.

Even a small environment of 20 certificates loses two full working weeks a year to a task that produces no business value when it succeeds and produces an outage when it fails.

At 1,000 certificates you are funding two full-time engineers to do nothing but renew certificates. At 5,000 you are funding a team of eleven.

Now apply the 2029 numbers. At 47 days you renew roughly every 45 days — eight times a year. Every figure above doubles. A 5,000-certificate estate becomes 40,000 hours, or around 22 FTE.

And these numbers still describe the happy path. They exclude:

• Renewals that fail because a private key was not accessible where the cert had to be installed
• Certificates installed correctly but never picked up because the service was not reloaded
• Chain and intermediate mismatches discovered only when a client fails to validate
• Out-of-hours change windows for production endpoints
• The incident bridge that opens when a certificate does expire

Manual renewal was defensible at 398 days. At 100 days it is a staffing problem. At 47 days it is not a strategy at all.

What’s new in PKI Insights 7.3

Built-in CLM for five more endpoint types

PKI Insights already ships native certificate lifecycle automation for IIS, NGINX, HashiCorp Vault, Citrix NetScaler, Citrix StoreFront and F5. Version 7.3 adds:

• FortiWeb

• Active Directory Federation Services (ADFS)

• Microsoft SQL Server

• Microsoft Exchange

• Remote Desktop Protocol (RDP)

These additions are deliberate. ADFS, Exchange and SQL Server are the endpoints where a certificate expiry does not degrade a service — it stops authentication, stops mail flow, or stops an application tier. RDP certificates are the ones nobody inventories until an auditor asks. They are exactly the endpoints where manual renewal survives longest and fails hardest.

Discovery, enrolment, installation, service reload and post-renewal validation are handled end to end, on premises.

Pluggable CLM: integrate any server, with any CA

The built-in connectors cover the common estate. They will never cover all of it. Every enterprise has an appliance, a bespoke application, a legacy load balancer or a vendor product that no CLM vendor has a connector for — and that is usually the endpoint that causes the outage.

PKI Insights 7.3 introduces a pluggable CLM module. You can extend the platform to manage certificates on effectively any server, on Windows or Linux, without waiting on a vendor roadmap.

The practical requirement is simple. If the target server offers either of the following, it can be automated:

• An API that accepts a key and certificate, or

• A file location where a key and certificate can be placed, plus a way to reload the service

Where one of those exists, a working module can quickly be implemented. Where neither does, the picture is usually still workable. Appliances with only a management console, systems reachable over SSH or WinRM, and applications with certificates buried in a keystore all have automation paths — they just need scoping rather than a connector off the shelf. If you have an endpoint you assume cannot be automated, it is worth a conversation before you accept that as permanent.

Combined with PKI Insights’ existing CA support, this means the platform now works with any CA and any server. No connector gap, no vendor lock-in on either end of the certificate’s life.

PQC Readiness across your whole estate

Version 7.3 introduces PQC Readiness — a cryptographic health view that pinpoints post-quantum posture across your certificates and SSL/TLS endpoints, spanning:

• Discoveries — machine and network scans
• Network Monitors — live SSL/TLS endpoints
• PKI Posture — your issuing infrastructure itself

This matters for two reasons that have nothing to do with quantum computers existing yet.

• The first is harvest-now-decrypt-later. Encrypted traffic captured today can be stored and decrypted once a cryptographically relevant quantum computer exists. Any data with a confidentiality lifetime measured in years — health records, financial records, government and defence material, long-lived IP — is already exposed if it is protected only by classical key exchange.
• The second is that migration timelines are being set now. NIST standardised ML-KEM, ML-DSA and SLH-DSA in 2024, and government guidance in multiple jurisdictions now carries dated deprecation milestones for RSA and ECC. Answering “which of our endpoints, certificates and CAs are quantum-vulnerable, and where are they” is the first task of any migration plan — and it is a discovery problem before it is a cryptography problem.

PKI Insights 7.3 answers that question against your live estate rather than a spreadsheet.

UI improvements

General interface refinements throughout, focused on faster navigation across large estates and clearer surfacing of the findings that need action first.

Automation is not the whole answer — and this is where most CLM tools stop

There is a comfortable assumption in the market that certificate automation solves certificate risk. It does not.

Consider what an expired certificate did to Equifax in 2017. A certificate on a device inspecting encrypted network traffic lapsed, and for roughly 76 days that traffic passed uninspected. The expiry caused no outage. Nothing went down, no user complained, no alert fired. What it caused was the silent failure of a security control — and the exfiltration underway during that window went undetected until the certificate was renewed and the monitoring came back to life.

That is the failure mode worth sitting with. A certificate problem does not always announce itself as downtime. Sometimes it announces itself as a control that has quietly stopped working, in an environment where every dashboard still reads green.

Automating renewal on top of a misconfigured PKI does not fix the misconfiguration. It industrialises it. You now issue certificates from a compromised trust foundation four times faster than you did before, with less human review at each step, and with more confidence that everything is fine because the dashboard is green.

Automation keeps certificates alive. Posture keeps trust intact.

We made the full case for this in What Should Enterprises Prioritize First: PKI CLM or PKI Posture?

This is why PKI Insights was never a CLM-only product. PKI Posture continuously assesses the health and security configuration of your issuing infrastructure — including Microsoft ADCS, EJBCA, Microsoft Cloud PKI and HashiCorp Vault.

For ADCS specifically, that means evaluating your environment against the full family of ESC misconfigurations — the template, enrolment agent, CA configuration and access control weaknesses that turn an internal CA into a domain-wide privilege escalation path. ESC1 through ESC16 are not theoretical. They are the standard opening move in Active Directory compromise, they are trivially discoverable with freely available tooling, and the vast majority of ADCS deployments have at least one.

Recent research into ADCS attack paths — including the technique circulating as CertiGhost — has reinforced how little standing an attacker needs to abuse a certificate authority that has been configured to defaults. An ADCS instance that has never been posture-assessed is not a supporting service. It is a domain compromise waiting for someone to notice it.

If you are a CISO, the question is not “are our certificates renewing.” It is:

• Can any authenticated user in our domain request a certificate that authenticates as someone else?

• Do we know every template that permits requester-supplied subjects?

• Are our CA audit settings capturing what an investigation would need?

• Would we detect abuse of our own CA, or would we find out from the incident?

PKI Insights answers those questions continuously, on premises, in an architecture where keys are never transmitted — which is why it deploys cleanly in air-gapped, regulated and government environments where SaaS-based tooling is not an option.

Three time horizons, one platform

What makes 7.3 a meaningful release is not any single feature. It is that the three certificate risks enterprises face sit on three different clocks — and most teams are only resourced for one.

Buying a point tool for each of those means three procurements, three deployments, three inventories that disagree with each other, and three vendors to argue with when they do.

Where to start

If you take one action from this post, make it this: count your endpoints, multiply by four, and multiply by one hour. If the answer is more engineering time than you have, you have a 2026 project, not a 2029 one.

Then ask a harder question: when was your ADCS environment last assessed against ESC checks? If the answer is “never” or “at deployment,” automation is not your most urgent problem.

PKI Insights 7.3 is available now!

PKI Insights is Codegic’s on-premises PKI observability platform, covering Discovery, Network Monitor, Certificate Lifecycle Management, PKI Posture and HSM Monitor. Fully on-premises and air-gap capable — your keys never leave your infrastructure.