The Change Is Already Underway
The industry is not waiting for 2029 to make certificate operations harder. Under the CA/Browser Forum Baseline Requirements, publicly trusted TLS certificates issued from 15 March 2026 are limited to 200 days. That maximum falls to 100 days from 15 March 2027 and to 47 days from 15 March 2029. Domain and IP validation reuse also tightens over the same period, ultimately reaching 10 days.
For infrastructure teams, the operational consequence is more important than the headline number. A certificate estate that was tolerable with annual manual renewals becomes a continuous lifecycle problem when the same systems need attention several times a year. The answer is not a bigger renewal calendar. It is removing humans from the repetitive parts of issuance, deployment and verification.
Inventory Before Automation
The first risk is not renewal itself; it is not knowing what exists. Public endpoints, internal services, appliances, lab systems, vendor-managed applications and forgotten load balancers often sit in different ownership domains. Start by building a certificate inventory that records the certificate, its deployment target, issuing CA, renewal policy, technical owner and live endpoint.
Discovery should feed that inventory rather than create a separate spreadsheet. A certificate seen on the network but not yet under lifecycle control should remain visibly unmanaged until an operator deliberately adopts it. That distinction is critical when the renewal window becomes shorter.
Automate The Whole Lifecycle
Issuing a replacement certificate is only one step. The operational loop is request or renew, deploy, reload the consuming service where required, verify the live endpoint, record the result and alert when any stage fails. Automating only the CA request still leaves the most failure-prone step—deployment—on a person.
This is why agentless orchestration matters. Linux systems can be managed over SSH, Windows estates over WinRM and infrastructure platforms through their native management APIs. The certificate control plane can stay central while each target keeps its normal operating model.
Design For Failure, Not Just Success
Shorter validity periods increase the frequency of change, which increases the number of opportunities for a reload failure, blocked firewall path, expired service account or changed application configuration to interrupt renewal. Every automated path should therefore have independent connection testing, post-deployment certificate verification and an auditable failure state.
Maintenance windows and approval policies still matter. Automation should respect production change controls rather than bypass them, while emergency revocation should remain available when a certificate or key must be removed immediately.
What To Do Now
Treat 47 days as the end state, not the starting gun. Prove automation now while the maximum is still 200 days. Pick representative systems from Linux, Windows and network infrastructure, automate their renewal path, test a failed deployment and confirm that alerts reach the right team.
By the time 100-day certificates arrive in 2027, the process should already be boring. By 2029, routine public TLS renewal should be infrastructure automation—not ticket work.
See SSL Nexus In Your Environment
SSL Nexus brings discovery, multi-CA lifecycle management, agentless deployment, vendor delegation and policy into one self-hosted control plane.
Request A Demo Read The Documentation