Certificate lifecycle management

CA/Browser Forum Ballot SC-081v3, passed on April 11, 2025, cuts the maximum life of a publicly trusted TLS certificate in three steps: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. The 2029 step also cuts how long a certificate authority can reuse a domain validation to 10 days. A certificate you renew once a year today needs renewing about twice a year now, four times a year from 2027 and eight times a year from 2029.

Only to publicly trusted TLS certificates. Certificates from your own private CA follow whatever policy you set. In practice most estates mix the two, with public certificates on internal hostnames and appliances because it was easier at the time. The inventory sorts out which is which, and some certificates end up moving to a private CA as a result.

Common examples are firewalls and VPN gateways, older F5 or NetScaler load balancers, Windows servers running IIS, Java keystores and vendor-hosted SaaS platforms. The options are to move TLS termination to something that can automate, use the vendor's own API, push certificates from a central tool, or replace the system on a schedule. The plan names one option per system with an owner and a date, so nothing is left to a calendar reminder.

Not always. An estate with a few hundred certificates, mostly in cloud and Kubernetes, often runs well on cert-manager, Certbot or acme.sh, AWS Certificate Manager and good monitoring, with a private CA such as Smallstep or AWS Private CA for internal names. Larger or more mixed estates usually need a platform for discovery and push-based renewal, such as CyberArk Certificate Manager (formerly Venafi), Keyfactor Command, DigiCert Trust Lifecycle Manager, Sectigo Certificate Manager or AppViewX. Truvo does not resell any CLM product, so the recommendation follows your estate.

Any public CA that supports ACME, which today includes Let's Encrypt, DigiCert, Sectigo, GlobalSign and Google Trust Services, plus the CLM platform you already own if you have one. If you are paying for a commercial CA, the inventory often shows where a free ACME certificate would do the same job and where an organization-validated certificate is still worth paying for.

An expired certificate is an outage, and an outage is an availability and change-management finding. The same work produces the evidence auditors ask for: a cryptographic key and certificate inventory, a documented renewal process, and monitoring with alerts. Under ISO 27001:2022 that sits mainly under Annex A 8.24, use of cryptography, which expects a managed lifecycle for keys and certificates. Under SOC 2 it supports CC6.7, which covers protecting information in transmission, and the availability commitments in your system description.

Both, and you choose where Truvo stops. Some teams want the assessment and design and then build it themselves. Most want Truvo engineers to build it alongside their team, so the automation is in place and the team knows how it works. Teams without the people to own it after go-live can hand the running of it to Truvo as an ongoing service.

Watching renewals and fixing the ones that fail, bringing new systems, domains and acquired companies into the automation, a regular inventory review with owners, tracking CA/Browser Forum and browser policy changes before they land, and keeping the inventory, renewal records and alert history ready for your SOC 2 or ISO 27001 auditor. Scope and response times are agreed per client in the statement of work.

Before the 100-day step on March 15, 2027. At 200 days a team can still renew by hand and catch most misses. At 100 days the volume doubles and manual renewal is where outages come from. Starting now leaves time to fix the hard systems before the 47-day step and the 10-day validation window in 2029.