If your public-facing TLS certificates still live on a spreadsheet, brace yourself. The way most teams handle certificates is about to break.
The CA/Browser Forum has set an aggressive schedule for shrinking how long TLS certificates stay valid. By March 2027, newly issued certificates max out at 100 days. By March 2029, that drops to just 47.
Here’s what that means in practice. Under the old 398-day model, you’d buy a certificate, install it, and forget about it until next year. By 2027, you’ll touch each certificate about four times as often. By 2029, renewals become roughly monthly — more than eight times the old workload.
Why the industry is doing this
Think of a certificate as a snapshot. At the moment it’s issued, the CA confirms that you control the domain or IP and that everything checks out. The longer that snapshot stays valid, the more time reality has to drift away from it. Domains change hands, DNS gets updated, cloud assets get reassigned, services get retired, and keys occasionally leak. The CA/B Forum’s SC-081 rationale points to exactly these problems: stale certificate data, misissuance risk, revocation limits, and the need to stay nimble as cryptography evolves.
Shorter lifetimes aren’t a magic fix, though. Reissuing certificates with the same old private key doesn’t buy you much. The real value shows up when short certificates are paired with automated issuance, repeatable deployment, key rotation, reliable ownership records, and the ability to swap a certificate out fast.
There’s a forward-looking reason to care, too. When NIST approved its first post-quantum cryptography standards in 2024, the migration guidance leaned hard on discovery, inventory, roadmaps, vendor engagement, and agility. A 47-day world won’t make you quantum-safe on its own, but it builds the exact operational muscles the next big crypto transition will demand.
Who this applies to
This roadmap covers publicly trusted TLS server certificates — the ones chained to roots that browsers and common software trust. The Baseline Requirements say plainly that they don’t govern certificates from an organization’s own internal PKI used purely for internal purposes.
That’s some comfort, but don’t get complacent. Internal PKI will still feel the pull. Cloud platforms, service meshes, Kubernetes controllers, load balancers, and DevOps pipelines increasingly assume automated certificate lifecycles. Modernize your public TLS and leave private PKI as a manual exception, and you’ll end up running two systems: one fast and resilient, one slow and fragile.
The impact will be uneven — but broad
Large, regulated enterprises may already have lifecycle programs, ownership models, and change windows. They’ll still feel it. Swapping a certificate is easy; producing documented proof that the change was planned, approved, tested, and compliant is not. Treat every renewal as a one-off and the costs pile up fast.
Smaller teams face the same squeeze from a different angle. Certificate management is usually one job among many. When renewals get more frequent, nobody gets more hours in the day. The predictable result: more context switching, skipped steps, last-minute scrambles, and a higher chance of an outage.
The piece everyone overlooks: validation reuse is shrinking too
Most teams focus on expiration dates. That’s no longer enough. The CA/B Forum is also compressing how long a CA can reuse your domain and IP validation data — down to 200 days in 2026, and just 10 days by 2029.
Why it matters: renewal isn’t always as simple as issuing a new certificate. Some workflows lean on pre-validated domains, manual DNS edits, email-based validation, central or outsourced DNS teams, or fragile CA account setups. As reuse windows shrink, your domain control validation needs to become automated, API-driven, observable, and clearly owned.
What "good" looks like
The goal is simple to state: be able to replace any public TLS certificate safely, repeatedly, and with almost no manual effort. A mature program can discover certificates, identify their owners, validate domain control, issue and renew, deploy, verify, alert, revoke, and report — without heroics.
Automation should be the default for standard infrastructure. ACME is the protocol to know here; it was built to automate issuance, validation, deployment, renewal, and revocation, and RFC 8555 calls out reduced manual intervention as a core benefit.
If subscribing to an enterprise CLM platform is cost-prohibitive, you still have options. Linux and web-server teams can use ACME clients where they fit. Private PKI teams can explore internal ACME patterns, including ACME support in private CA tooling. Just remember these are building blocks, not substitutes for governance. You still need ownership, monitoring, approved patterns, exception handling, and evidence.
Change management must evolve
In a lot of organizations, a certificate renewal still goes through the same heavyweight process as a risky app release. That won’t survive 47-day certificates at scale.
Routine renewals should become standard changes — pre-authorized, low-risk, repeatable, and documented, with no trip to the Change Advisory Board each time. To earn that status, you need credible runbooks. Each major infrastructure pattern deserves its own concise procedure covering prerequisites, validation, deployment, health checks, rollback, evidence capture, and escalation. Load balancers, CDNs, ingress controllers, API gateways, web servers, SaaS portals, HSM-backed systems, and legacy appliances may each need their own.
Don’t skip your lower environments. If non-production mirrors production certificate flows, you can test automation, refine your docs, and prove repeatability before asking the CAB to ease up.
The bottom line
The move to 47-day TLS certificates will be tough maturity test for most organizations.
Treat certificates as static assets and the new cadence will feel like endless toil, risk, and disruption. Treat them as dynamic machine identities — with owners, automation, telemetry, policy, and lifecycle controls — and you’ll be ready not just for shorter certificates, but for the bigger cryptographic shifts already on the way.
