Digital certificates are a key foundation for secure digital communication. They enable websites, applications, devices, and services to verify identities and establish encrypted connections. As long as a certificate is valid and trustworthy, this process usually runs invisibly in the background.
But trust can change. If, for example, a private key is compromised or a certificate is issued incorrectly or without authorization, it must be revoked. And in that case, the regular expiration date no longer matters: depending on the cause, the deadline for revocation may be as short as 24 hours.
For companies, this means that, in addition to ever-shorter certificate validity periods, a second factor is becoming increasingly relevant: the ability to replace certificates very quickly and in a controlled manner in the event of an emergency. Without transparency and automated processes, a certificate issue can quickly turn into an availability and business risk.
This article explains the current requirements for certificate revocation, when the 24-hour deadline applies, and why automated certificate lifecycle management plays a crucial role in this process.
A digital certificate verifies a system’s identity and lays the foundation for encrypted and trustworthy communication. However, this trust is valid only as long as the conditions for issuing the certificate are met.
For example, if the associated private key is compromised or it turns out that a certificate was not issued properly, the certification authority (CA) must respond by revoking the certificate.
The currently valid TLS Baseline Requirements of the CA/Browser Forum essentially distinguish between two timeframes for regular, publicly trusted TLS certificates: revocation within 24 hours, and situations in which a certificate must be revoked within five days at the latest.
Revocation within 24 hours is required, among other things, when:
In addition, there are other scenarios in which a revocation must take place within 24 hours if possible, but no later than five days. These include, for example, misuse of the certificate, incorrect certificate information, or issuance in violation of applicable requirements.
What initially sounds like a regulatory requirement for certificate authorities has direct implications for their customers: If a certificate is revoked, the affected company must be able to issue a new certificate at very short notice, distribute it, and put it into production on all affected systems.
With just a few certificates, replacement can still be handled manually under certain circumstances. However, modern enterprise environments often include hundreds or thousands of certificates—spread across web servers, load balancers, firewalls, cloud platforms, APIs, Kubernetes environments, network components, and other systems.
Without a complete overview of this certificate landscape, critical questions arise in the event of an emergency:
Where is the affected certificate installed?
Which applications and services depend on it?
Who is responsible for it? How is a replacement issued?
This is precisely where the real risk lies. If a certificate that has already been revoked continues to be used, or if a replacement cannot be rolled out in time, there is a risk of connection failures, inaccessible applications, and disruptions to business-critical processes.
Legacy systems or infrastructures where certificates can only be replaced with significant manual effort pose a particular challenge. The CA/Browser Forum and DigiCert therefore emphasize that publicly trusted TLS certificates should not be used on systems that are technically unable to handle timely revocation and replacement. Depending on the use case, private trust architectures may offer a suitable alternative.
Speaking of which: The white paper from our partner DigiCert shows you how to sustainably optimize your certificate management—from complete transparency regarding your certificate inventory to automated issuance and renewal. You’ll receive a field-tested framework to reduce risks and streamline your processes. Interested? Download the white paper now and future-proof your own certificate management:
The situation becomes even more challenging in the case of a so-called mass revocation. In such cases, a large number of certificates may need to be replaced simultaneously due to a vulnerability, an issuance error, or another widespread incident.
The CA/Browser Forum has therefore significantly tightened the requirements for Certificate Authorities. Starting in December 2025, CAs must have a comprehensive and actionable mass revocation plan in place. Among other things, this plan must define responsibilities, communication channels, automation options, and specific procedures for revocation and replacement, and it must be tested at least once a year.
Mozilla also requires Certificate Authorities to actively prepare for such scenarios and mandates early communication with customers regarding applicable revocation deadlines.
For companies, this has a simple implication: Certificate revocation should also be an integral part of cyber and operational resilience on the customer side.
Even the gradual reduction of maximum TLS certificate validity periods to 47 days in the future makes automated certificate lifecycle management indispensable. An unplanned revocation further exacerbates this challenge: In such cases, there may be only a few hours left, rather than weeks.
A modern Certificate Lifecycle Management (CLM) system creates the necessary conditions for this:
With the DigiCert Trust Lifecycle Manager, you can centrally manage certificates and automate lifecycle processes. DigiCert supports, among other things, Managed Automation, ACME, and REST APIs for integration into existing infrastructures and DevOps processes.
Don’t Just Automate Renewals—Be Prepared for Emergencies
Automated certificate management must therefore not be limited to renewing certificates in a timely manner before they expire.
Companies should also assess how quickly they can respond to an unplanned revocation. This includes, for example, regularly testing whether critical certificates can be reissued on short notice and automatically distributed to all relevant systems.
The crucial question is no longer just: “When does our certificate expire?”
But also: “Can we replace it within 24 hours?”
The requirements for TLS certificates show that certificate lifecycle management has long been more than just a matter of timely renewal. Companies must not only know which certificates are in use and when they expire; they must also be able to act quickly and in a controlled manner in the event of an emergency.
This includes transparency regarding their own certificate landscape, clearly defined responsibilities, and automated processes for issuance, distribution, and replacement. It is equally important to regularly review these processes and test them in the event of an unplanned revocation.
Together with DigiCert, InfoGuard helps companies meet these requirements—from analyzing existing certificates and processes to designing suitable PKI and CLM architectures and implementing automated lifecycle processes.
After all, digital trust doesn’t end with the issuance of a certificate. It is crucial to securely manage trust throughout the entire lifecycle—and to remain capable of taking action even if a certificate must be revoked on short notice.
Would you like to know how well your certificate landscape is prepared for shorter validity periods and an unplanned certificate revocation scenario? Download our TLS Best Practices white paper now or speak directly with our experts about your certificate lifecycle management strategy. We look forward to hearing from you!
Image caption: AI-generated image