Are You Ready for 100-Day TLS Certificates? 5 Questions Every Organisation Should Be Asking Now

The shift to shorter TLS certificate lifetimes is already underway

Since March 2026, newly issued public TLS certificates have a reduced lifetime of 200 days. That reduction was only the start of a much greater change. From 15 March 2027, certificate lifetimes fall again to 100 days, meaning every public-facing certificate will need renewing around 3.7 times a year. Eventually, in 2029, certificates will be valid for a maximum of 47 days.

For organisations still relying on manual processes, spreadsheets or partial visibility, that doesn't just increase the workload. It increases the opportunities for something to be missed.

For teams that are already stretched, the next decrease will be here in no time. Before the deadline arrives, it's worth asking some honest, practical questions about how ready your organisation really is, and starting the work now rather than waiting as we’ve seen how long it can take.

1. Do you know where all your certificates are?

Most organisations think they know where all their certificates are until they run a proper discovery scan. In fact, DigiCert's 2026 Global PKI Research found that only 34% of organisations have a complete and current view of their certificate estate. Manual tracking methods, including spreadsheets, remain one of the biggest challenges teams face.

Having a certificate inventory is a good start, but the real test is whether you have continuous, automated discovery across every public-facing certificate, including those protecting legacy websites, acquired domains or applications that no longer have a clearly defined owner.

What this looks like in practice:

• Run a full external attack surface scan against every domain and subdomain you own, not just the ones sitting in your CA portal.

• Reconcile that scan against your CMDB or asset inventory. Most gaps surface here first.

• Assign a named owner to every certificate you find, not just every certificate someone remembers issuing.

• Make discovery an ongoing process rather than a one-off audit. Shorter certificate lifetimes mean your inventory will become outdated far more quickly.

2. Is your renewal process ready for shorter certificate lifetimes?

A manual renewal typically involves validating ownership, generating a new private key, creating a CSR, requesting the certificate, deploying it and testing everything is working as expected. For many organisations, that's around four hours of work for a single certificate.

With 100-day certificate lifespans, that work no longer happens once a year. It happens around 3.7 times. Across an estate of a thousands of public certificates, that's thousands of additional hours of repetitive manual work every year, all of it landing on teams that typically aren't getting any bigger to handle the increased load. I recently looked at what this means in real terms, including the impact on renewal volumes and operational effort, you can read it here: The Cost of TLS Certificate Renewals.

The question is no longer whether automation is worthwhile. It's whether you can reduce renewal time from hours to minutes before the increase in volume arrives.

What this looks like in practice:

• Time an actual renewal end to end, including CSR generation, deployment and testing. Don't estimate it.

• Multiply that figure by your certificate count and the new renewal frequency to get a real hours-per-year number.

• Compare that number honestly against the headcount you realistically have free for this work.

• Identify which certificates can move to automated, policy-driven renewals today, and which genuinely still need a human in the loop.
  

3. Would a certificate failure show up on your radar before it causes an outage?

CyberArk's 2026 PKI Modernisation Report found that 56% of organisations have experienced unplanned outages caused by expired or misconfigured certificates. While today's certificate lifetimes are still relatively generous, the transition to 100-day and eventually 47-day certificates will significantly increase the number of renewals organisations need to complete each year. Every additional renewal is another opportunity for something to be missed.

The question is whether you'll know about a failed renewal before your users do. That depends on more than expiry notifications. It means integrating certificate management with your monitoring, ticketing and operational workflows so failures are detected, escalated and resolved before they become production incidents and impact reputation and revenue.

What this looks like in practice:

• Confirm expiry alerts fire to a monitored, owned queue, not an inbox that one person happens to read.

• Test what happens when a renewal fails partway through. Does anyone find out before the certificate actually expires?

• Map your highest revenue and highest risk services, then check they have tighter alerting thresholds than lower-priority systems

• Run a tabletop exercise on an expired certificate. Time your actual detection and remediation. Don't assume it.
  

4. Are you confident every certificate on your estate is compliant?

Research from Enterprise Management Associates (EMA) found that nearly 80% of SSL/TLS certificates in use were still potentially vulnerable to man-in-the-middle attacks, largely because the associated servers were not using TLS 1.3. The same research found that up to 25% of certificates were expired or self-signed, creating further security and trust risks.

As certificate lifetimes shorten, organisations will be issuing and deploying certificates more frequently. Without automated policy checks, that creates more opportunities for weak algorithms, unapproved certificate authorities or incomplete chains of trust to make it into production. It also creates more opportunities to identify and correct those issues, provided validation is built into the renewal process.

That raises an important question: are you automatically validating certificate attributes such as key length, signing algorithms and chains of trust while restricting issuance to approved certificate authorities?

What this looks like in practice:

• Define a certificate policy covering key lengths, signing algorithms, validity periods and approved certificate authorities, then enforce it at issuance.

• Check whether any certificates on your estate are self-signed or issued by an unapproved certificate authority.

• Make sure every renewal automatically re-validates compliance, rather than assuming nothing has changed since the certificate was first issued

• Automatically generate compliance evidence for standards such as NIST, ISO 27001 or PCI DSS, rather than assembling it manually ahead of an audit.

5. Is your infrastructure built for where this is heading, not just where it is now?

The move to 100 day certificate lifetimes is a milestone, not the end point. By 15 March 2029, every public TLS certificate will need renewing almost eight times a year. That’s every 47 days.

The real test of readiness isn't whether you can meet the 100-day deadline next year. It's whether the approach you put in place today will still work as certificate lifetimes continue to shrink and cryptographic standards evolve. That means building automation that can scale with future certificate lifetime reductions, while ensuring your infrastructure is crypto-agile enough to adapt to future cryptographic changes, including post-quantum cryptography.

Only 22% of organisations say they've fully assessed their systems for future cryptographic risk (DigiCert 2026 Global PKI Research). For most organisations, the challenge extends beyond shorter certificate lifetimes. It's about building a certificate management strategy that's resilient enough to support whatever comes next.

What this looks like in practice:

• Choose tooling built for continuous automation, not a stopgap patched together to clear the 100-day deadline alone.

• Ask your certificate management vendor directly how they support crypto-agility and post-quantum algorithms, and get a specific answer.

• Build renewal automation once and apply it across every future lifespan reduction, rather than re-engineering for each new deadline.

• Put 2029 on your roadmap now as a key focus, not on your successor's to-do list.

The Bottom Line

Most organisations don't need to solve every challenge overnight. But they do need to understand what they own, where manual effort is creating unnecessary risk, and where automation will have the greatest impact. The earlier that work begins, the easier each future lifespan reduction becomes.

A practical place to start is thoroughly identifying and mapping your estate. ProofID, together with CyberArk, offers a complimentary scan of your public TLS certificates, that will give you a clear view of your external certificates and help you prioritise the work ahead.

Once you've received your results, you'll have the opportunity to book a complimentary strategy session with our certificate lifecycle management experts. They'll walk you through the findings, discuss your current approach and help you build a practical roadmap for managing shorter certificate lifecycles with confidence.

From there, the path is straightforward: