TLS certificate risk is the chance that a certificate failure causes an outage, a breach or a blind spot. The usual causes are unnoticed expiry, private keys that leak or are reused, and certificates nobody knows exist. Shorter public certificate lifetimes make an inventory and automated renewal mandatory rather than optional.
What are the three failure modes?
NIST's practice guide on TLS server certificate management (SP 1800-16) frames certificate problems as risks to be prevented, detected and recovered from. In plain terms they fall into three groups.
Expiry. A certificate reaches its end date and clients refuse the connection. The cause is almost never cryptography. It is a renewal reminder that went to a person who left.
Key compromise or misuse. Anyone holding a private key can impersonate the site. Keys copied into a repository, shared between services, or kept on a laptop widen that exposure.
Unknown certificates. A team issues a certificate for a test host and forgets it. You cannot renew, revoke or monitor what you have never listed.
Why are public certificate lifetimes getting shorter?
The CA/Browser Forum, which sets the baseline rules for publicly trusted TLS certificates, passed ballot SC-081v3 in 2025. It sets a schedule that reduces the maximum validity period from 398 days to 47 days, starting in March 2026 and finishing in March 2029. It also shortens how long validation data can be reused.
The Forum's background notes tie this to revocation: certificates issued under the baseline rules are expected to be managed so they can be replaced quickly. Shorter life limits how long a stolen key stays useful, and it makes replacement a routine event.
The consequence for operators is simple. A yearly manual renewal does not survive a 47 day lifetime. Automation does.
How does automation work?
ACME, defined in RFC 8555, is the protocol that lets a certificate authority and a certificate applicant automate domain validation and issuance. The same document covers revocation. A client on your server proves control of the domain, receives a certificate, and repeats the process before expiry without a human in the loop.
Automation moves the risk. Instead of a missed reminder, you now depend on the renewal job working, on DNS or web access for validation, and on the new certificate being loaded by the service. Monitor those steps.
What about internal certificates?
The browser schedule covers publicly trusted server certificates. Internal certificate authorities set their own rules, and they often hold the oldest, longest-lived certificates in the company. Treat them the same way: inventory, owner, expiry date, automated renewal.
A constructed example: a payments team has an internal API with a certificate valid for five years, issued by a private authority. The person who created it has moved teams. Four and a half years later, a service-to-service call fails on a Saturday and the team spends hours finding where the certificate lives. A shared inventory with an owner field and an expiry alert would have turned that into a ticket three weeks earlier.
How to check or apply this
- Build an inventory from three sources: your certificate authority's issuance logs, a scan of your IP ranges and hostnames, and your load balancers and ingress configs.
- Record an owner, an environment and an expiry date for each certificate.
- Alert at 30, 14 and 3 days to a shared channel, not one inbox. With shorter lifetimes, scale those windows down.
- Move public certificates to ACME renewal and test a forced renewal in staging.
- Keep private keys out of source control and generate a fresh key at each renewal where your tools allow it.
- Check configuration against NIST SP 800-52 Rev. 2, which requires TLS 1.2 support and TLS 1.3 support for US government servers as of January 1, 2024.
If you need to catch keys committed to repositories, secret scanning on pull requests catches the most common leak path before it merges.
Quick check
Is a short certificate lifetime less secure than a long one?
No. Shorter lifetimes limit how long a leaked key or wrongly issued certificate remains usable. The cost is operational: you must renew often, so renewal has to be automated.
Do the 47 day rules apply to my internal certificate authority?
The CA/Browser Forum baseline rules cover publicly trusted TLS server certificates. Internal authorities set their own policy, but the same operational risks apply.
Sources
- NIST SP 1800-16, Securing Web Transactions: TLS Server Certificate Management
- CA/Browser Forum, Ballot SC081v3
- RFC 8555, Automatic Certificate Management Environment (ACME)
- NIST SP 800-52 Rev. 2, TLS Implementation Guidelines
Last reviewed: 18 October 2026.
