Notifications
Clear all
Topic starter
10/06/2026 11:27 pm
TL;DR: Publicly trusted TLS certificate validity has dropped from 398 days to 200 days, with further reductions to 100 days in 2027 and 47 days in 2029, according to Riptides and the CA/Browser Forum context it cites. The shift makes manual certificate management a scaling problem, while pushing infrastructure teams toward automation and identity-native workload trust.
NHIMG editorial — based on content published by Riptides: The 200-Day TLS Era Has Begun
By the numbers:
- Any certificate issued on or after March 15, 2026 must comply with the new 200-day maximum.
Questions worth separating out
Q: How should security teams prepare for shorter TLS certificate lifetimes?
A: Security teams should inventory every public certificate, identify each renewal owner, and automate issuance and deployment before the shorter cadence collides with manual workflows.
Q: Why do shorter certificate lifetimes matter for workload identity governance?
A: Shorter lifetimes matter because they force teams to manage trust as a continuous identity lifecycle rather than a periodic admin task.
Q: What breaks when certificate rotation is still handled manually?
A: Manual rotation breaks when teams cannot reliably keep up with validation, deployment, testing, and rollback across every endpoint.
Practitioner guidance
- Audit the full certificate estate Map every public TLS certificate across load balancers, APIs, ingress controllers, edge services, and legacy applications.
- Eliminate manual renewal paths Replace spreadsheet, email, and ticket-based renewals with ACME automation or certificate lifecycle management workflows.
- Separate public TLS from internal workload identity Use CLM for public trust and workload identity controls for east-west traffic.
What's in the full article
Riptides's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step view of how the 200-day rule changes renewal scheduling across public-facing services.
- The vendor's explanation of SPIFFE-based identity and how it maps to internal workload authentication.
- Implementation detail on how the platform handles rotation and federated trust domains across environments.
- A practical comparison of public certificate lifecycle management and identity-native east-west traffic controls.
👉 Read Riptides's analysis of the 200-day TLS certificate change →
200-day TLS certificates: are your rotation controls ready?
Explore further
12/06/2026 5:25 am
Shorter certificate lifetimes expose an identity governance gap, not just a renewal problem. Public TLS now depends on an inventory, ownership, and automation discipline that many infrastructure teams still treat as secondary to deployment. The CA/Browser Forum mandate has simply made that weakness visible sooner. Practitioners should read this as a lifecycle control failure, not a certificate policy change.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 13% of security leaders feel extremely prepared for the reality of agentic AI, which means governance maturity is lagging behind deployment ambition.
A question worth separating out:
Q: What is the difference between certificate lifecycle management and workload identity?
A: Certificate lifecycle management controls how credentials are issued, renewed, and retired. Workload identity changes the trust model so services are authenticated as identities rather than as long-lived certificate artifacts. They are related, but not interchangeable. One manages certificates better, while the other reduces reliance on static credentials in the first place.
👉 Read our full editorial: The 200-day TLS era is forcing identity-native rotation
