From 200 to 47 days: How can businesses manage shorter TLS certificate lifetimes efficiently?
TLS certificates are used in virtually every business. They provide the basis of trust for encrypted connections to websites, applications, APIs and digital services. At the same time, the conditions governing their use are changing: the CA/Browser Forum has decided to gradually reduce the maximum permitted lifetime of publicly trusted TLS certificates. Since 15 March 2026, the maximum lifetime has been 200 days. From 15 March 2027, it will be reduced to 100 days, and from 15 March 2029 to just 47 days.
As a result, businesses will need to request certificates, validate domains, deploy new certificates and update existing installations much more often. As lifetimes become shorter, reliably managing certificates using calendar reminders, Excel spreadsheets or manual tickets becomes increasingly difficult. The shorter the lifetimes, the more important end-to-end Certificate Lifecycle Management becomes, combining transparency, clear responsibilities and automated processes.
Why shorter TLS certificate lifetimes increase operational risk
Certificates have always had an expiry date. What has changed is the frequency at which the entire process needs to be repeated. With longer lifetimes, renewing publicly trusted TLS certificates could be treated as a relatively infrequent administrative task in most organisations. The new CA/Browser Forum requirements change this situation: since 15 March 2026, the maximum lifetime has been 200 days, falling to 100 days from 15 March 2027 and just 47 days from 15 March 2029.
Each reduction increases the number of renewal processes, and every single renewal must also work reliably. If a certificate expires unnoticed, it can result in warnings, connection failures or a service becoming unavailable. Certificate management therefore has a direct impact on stable IT operations and affects far more than PKI administrators alone. Depending on the infrastructure, operations, network, platform and application teams may all be involved. They need to ensure that certificates on web servers, load balancers, cloud resources, APIs and applications are replaced correctly and at the right time.
The new limits apply to publicly trusted TLS server certificates. Internal certificates issued by a private enterprise PKI are not directly affected. Nevertheless, it makes sense to include both public and private certificates in an overarching certificate lifecycle strategy. This enables businesses to centrally manage inventories, responsibilities and processes. PKI should also be incorporated into the broader security architecture as a technical component of Identity & Access Management.
Why manual TLS certificate management no longer works
Many organisations still manage certificates manually or with only partial automation. Expiry dates are recorded in spreadsheets, monitoring systems or calendar entries generate reminders, and new certificates are requested via tickets. Administrators then download the certificates and install them on the relevant target systems.
As long as the number of certificates is small and lifetimes are long, this approach can work. With a maximum validity of 47 days, however, certificates will need to be renewed approximately every six to seven weeks from 2029 onwards. An organisation with a larger certificate inventory will therefore need to coordinate a significantly higher number of renewal processes at the same time.
Domain or IP address validation will also become more demanding. From 15 March 2029, previous validation can only be reused for ten days. This means that it is not only the number of certificate renewals that will increase. Validation processes will also need to run reliably at much shorter intervals, because the renewal process does not end when the certificate is issued.
The new certificate must reach the correct target system, be activated together with the complete certificate chain and subsequently undergo technical verification. The existing certificate must be replaced in a controlled manner or revoked where necessary. Without a complete inventory, certificates installed on cloud resources, applications managed on a decentralised basis or poorly documented systems can be overlooked. The more manual handovers there are within this process, the greater the administrative workload and the potential for errors. This also creates a strong dependency on individual employees and their knowledge of the infrastructure.
How to automate TLS certificate renewal with certificate lifecycle management
A robust solution starts by treating certificate renewal as an end-to-end lifecycle. This extends from inventory and issuance to deployment, renewal, monitoring and revocation.
1. Create transparency across the certificate inventory
The first question is: which certificates actually exist?
For every certificate, businesses should have a central overview of at least its lifetime, issuer, location, status and owner. Only then is it possible to identify which systems are affected by shorter lifetimes and where action is required.
2. Standardise rules and certificate processes
The inventory provides the basis for consistent rules governing issuance, renewal and revocation. Certificate profiles and policies reduce individual exceptions and create repeatable processes.
This also requires responsibilities to be defined: Who owns the certificate? Who is responsible for the associated service? And what happens if an automated renewal fails?
3. Automate issuance and renewal
Where supported by the systems involved, standardised protocols such as ACME or APIs can be used. This allows recurring steps to be automated while reducing manual intervention.
Automation should go beyond issuance alone. Creating a new certificate record within a CA provides little value if the certificate subsequently has to be installed manually across multiple target systems.
4. Automatically deploy and validate certificates
Once issued, the certificate needs to be installed and activated on the designated systems. A technical check should then confirm that the service is actually presenting the new certificate with the correct certificate chain.
Errors at this stage need to be visible and trigger a defined escalation process.
5. Integrate monitoring and revocation
A centralised lifecycle provides continuous transparency regarding status, expiry dates and failed processes. If a certificate is compromised, a system is decommissioned or a certificate can no longer be used for another reason, revocation is also part of the controlled process.
This shifts certificate management from a reactive task shortly before expiry to a continuously controlled operational process.
Benefits of Automated Certificate Lifecycle Management
The benefits range from increased availability to improved auditability. They can be summarised as follows:
| Benefit | How is it achieved? | Benefit for businesses |
|---|---|---|
| Higher availability | Automated renewals, configurable lead times, monitoring and escalation | Reduces the risk of unplanned service outages caused by expired certificates. |
| Less manual operational effort | Rule-based workflows, ACME, APIs and the integration of certificate authorities and target systems | Larger certificate inventories can be managed without staffing requirements increasing in proportion to renewal frequency. |
| Centralised transparency | Inventory, search functionality, monitoring, dashboards and reports | Critical certificates can be identified early and prioritised accordingly. |
| Consistent security policies | Central certificate profiles, policies, role-based processes and defined security levels | Reduces misconfigurations and uncontrolled exceptions. |
| Improved auditability | Documented issuance, renewal, revocation and administrative interventions | Internal and external auditors receive traceable information about certificate processes and risk controls. |
Certificate Lifecycle Management use cases
The challenges vary depending on the infrastructure. Three scenarios illustrate how Certificate Lifecycle Management can be applied in practice.
Publicly accessible websites, customer portals and APIs
A business operates several public web applications and APIs via web servers and load balancers. The publicly trusted TLS certificates used for these services will need to be replaced at much shorter intervals in future.
An automated process identifies upcoming expiry dates, requests a new certificate, performs the required domain validation and distributes the certificate to the affected systems. After deployment, the process verifies that the service is accessible and uses the correct certificate.
Hybrid IT and cloud infrastructure
In hybrid environments, certificates can be located in on-premises data centres, cloud platforms, reverse proxies and containerised applications. Without a shared overview, entries may be recorded twice or overlooked entirely.
A centralised lifecycle consolidates inventories, assigns responsibilities and connects different target systems via appropriate interfaces. This creates a common management layer across technically diverse environments.
Public administration and critical infrastructure
Business-critical services combine stringent requirements for availability and traceability. With manual management, short certificate lifetimes would require repeated operational intervention. Automated renewals, documented approvals and reporting reduce manual touchpoints while ensuring transparent processes.
How to implement automated TLS certificate renewal
The process should begin with a structured inventory. Automating individual certificates immediately without first understanding the certificate landscape, responsibilities and processes only solves part of the problem.
1. Define the scope
The first step is to establish which certificate types and environments will be included. A clear distinction between publicly trusted TLS certificates and internal certificates issued by the enterprise PKI is useful.
2. Create a Certificate Inventory
Known certificate sources, CAs and target systems should be consolidated in an inventory. Companies should also actively search for certificates that have been created outside documented processes.
3. Define owners and criticality
Every certificate needs a technical owner and, where appropriate, a business owner. The associated services should also be assessed according to criticality, public accessibility and the potential impact of an outage.
4. Standardise the entire lifecycle
Request, approval, issuance, distribution, renewal and revocation should be defined as a connected process. Any necessary exceptions require documented procedures with clearly defined time limits.
5. Prioritise automation
Publicly accessible, business-critical certificates or those requiring regular renewal are suitable starting points. Systems without an appropriate interface require an alternative controlled process.
6. Pilot, test failure scenarios and roll out
Rather than moving the entire environment at once, businesses should start with a pilot project involving a manageable number of representative systems. Testing should not be limited to successful renewal. Failed validation, an unavailable target system or an incorrect certificate chain should also be covered.
How to choose a Certificate Lifecycle Management solution
A suitable platform should do more than issue warnings about upcoming expiry dates. What matters is how much of the entire lifecycle it can actually manage and automate.
The following questions can help when evaluating a solution:
- Can the solution centrally identify and manage the existing certificate inventory?
- Which certificate authorities and existing PKI systems can be integrated?
- Which lifecycle stages can be automated?
- Does the platform support standardised interfaces and protocols such as ACME?
- Can different policies, certificate profiles and security requirements be implemented?
- Which monitoring and reporting capabilities are available?
- Can the solution operate effectively across large IT environments?
In distributed environments in particular, businesses should assess how target systems can be integrated and which manual steps remain after automated issuance. An automated CA request alone does not constitute an automated certificate lifecycle.
Certificate Lifecycle Management with SITS and keyon true-Xtender
SITS supports businesses in analysing their existing PKI and certificate processes and developing them further. With keyon true-Xtender, existing PKI environments can be enhanced with automated issuance and renewal, policy-based revocation, and centralised monitoring and reporting capabilities. The focus is on building on the existing environment: established PKI structures can continue to be used while certificate processes are gradually automated.
Conclusion: Shorter TLS certificate lifetimes require new renewal processes
The new lifetimes do not fundamentally change what businesses need to do with publicly trusted TLS certificates. Above all, they change how often these steps need to be carried out.
What was once an occasional administrative task is becoming a continuous operational process. As renewal frequency increases, spreadsheets, calendars and manual tickets reach their practical limits and increase the risk of individual certificates being overlooked or replaced incorrectly.
Centralised Certificate Lifecycle Management therefore combines inventory, responsibilities, policies, automated renewal, technical validation and monitoring. Businesses do not need to automate every process at once. However, they should identify at an early stage where publicly trusted TLS certificates are being used and which systems need to be moved into a controlled lifecycle first.
Ready for shorter certificate lifetimes?
The countdown has already begun: the first reduction in TLS certificate lifetimes has been in effect since March 2026, with the next stage following in March 2027. Prepare your PKI for the new requirements now. Our experts can help you analyse existing certificate processes and automate certificate renewal step by step.
Certificate Lifecycle Management (CLM) is the process of managing digital certificates throughout their lifecycle, including discovery, issuance, deployment, renewal, monitoring and revocation.
An expired TLS certificate can cause browser warnings, failed connections, API disruptions and application outages. Automated renewal processes help reduce this risk.
The applicable limit depends on the certificate's issue date. Certificates that were issued in compliance with the rules before a new phase comes into effect do not automatically become invalid when the next phase begins. The current maximum lifetime will, however, apply to subsequent issuance or renewal.
The most important first step is to establish an overview of certificates, their deployment locations, expiry dates and owners. Without this transparency, it is difficult to reliably determine which certificates should be automated first.
The first reduction to a maximum of 200 days has already been in effect since 15 March 2026. The next stage, reducing the maximum lifetime to 100 days, takes effect on 15 March 2027. Businesses should therefore review their existing renewal processes now and, particularly for publicly trusted TLS certificates, determine which steps are still performed manually.
Under the CA/Browser Forum roadmap, publicly trusted TLS certificate lifetimes will be reduced to 47 days by March 2029. This means organisations may need to renew certificates roughly every six to seven weeks.
