Notifications
Clear all
Topic starter
24/06/2026 7:27 pm
TL;DR: Apple’s proposed CA/Browser Forum changes would shorten TLS certificate lifetimes to 47 days by 2029 and compress validation reuse windows far faster, making manual certificate operations unsustainable according to DigiCert. The practical shift is from certificate tracking to full lifecycle automation, because outage risk rises when request, validation, and installation still depend on people.
NHIMG editorial — based on content published by DigiCert: 47 Days: The New Certificate Lifetime Proposed by Apple
By the numbers:
- The current maximum lifetime of a TLS certificate is 398 days.
- As of March 15, 2029, TLS certificate lifetime SHOULD not exceed 46 days and MUST not exceed 47 days.
- Validation reuse for domain name and IP address validation MUST not exceed 10 days as of March 15, 2029.
Questions worth separating out
Q: How should security teams prepare for shorter TLS certificate lifetimes?
A: Security teams should treat shorter TLS certificate lifetimes as an automation project, not a reminder problem.
Q: Why do shorter validation reuse windows create governance risk?
A: Shorter validation reuse windows create governance risk because they force organisations to reprove identity more often while existing records may still appear current.
Q: What breaks when certificate management stays manual?
A: Manual certificate management breaks first at scale, then at the edges.
Practitioner guidance
- Inventory every certificate and owner Build a live certificate register that includes application owner, issuing CA, installation target, expiry date, and renewal method.
- Automate request-to-install workflows Use policy-driven automation for certificate request, validation, issuance, and installation so renewals do not depend on manual ticket handling.
- Shorten validation evidence freshness checks Track the age of domain and organisational validation data alongside certificate expiry so reuse windows do not silently exceed policy.
What's in the full article
DigiCert's full article covers the operational detail this post intentionally leaves for the source:
- The phased timeline for certificate lifetime and validation reuse changes across 2026, 2027, and 2029
- The specific certificate request, validation, and installation steps that teams should automate first
- The ACME protocol and lifecycle management capabilities DigiCert cites for scaling certificate operations
- The practical impact on organizations that still rely on manual certificate tracking and renewals
👉 Read DigiCert's analysis of Apple's proposed TLS certificate lifetime changes →
47-day TLS certificates and the automation gap teams must close?
Explore further
25/06/2026 4:43 am
Certificate lifecycle is now an identity governance problem, not a renewal task. When validation reuse and certificate lifetimes compress, the programme has to treat certificates as managed identities with owners, dependencies, and revocation paths. Spreadsheets and ticket queues cannot sustain that operating model. The implication is that certificate governance has to sit inside the broader identity control plane.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity programmes operate without a complete machine identity picture.
A question worth separating out:
Q: Who is accountable when certificate expiry causes an outage?
A: Accountability should sit with the team that owns the service and its certificate lifecycle, not with an isolated operations function. Certificate expiry is a governance issue because it reflects ownership, inventory quality, and automation maturity. If no one owns those controls, the outage is a programme failure, not just an operational miss.
👉 Read our full editorial: 47-day TLS certificates force certificate lifecycle automation
