Certificate Lifecycle Management (CLM)
Public certificate lifetimes keep shrinking:
- 200 days since March 2026
- 100 days from March 2027
- 47 days from March 2029
Websites, APIs, servers, load balancers and containers all rely on certificates to encrypt traffic and prove their identity. When a certificate expires unnoticed, services go down.
When one is issued outside policy or its private key is exposed, attackers can intercept traffic or impersonate your systems. And the maximum lifetime of public certificates keeps shrinking: from 398 days to 200 days in March 2026, and down to just 47 days by 2029.
Certificate Lifecycle Management (CLM) gives you control over every certificate, from request to retirement. It discovers certificates across your datacenter, cloud and Kubernetes, builds one inventory with a clear owner for each certificate, and automates issuance, renewal and installation.
Expired certificates take services down
A single forgotten certificate can stop a website, an API or a production process. What's more, finding the cause often takes hours, because the certificate is the last place anyone looks.
Automated renewal and installation
The platform renews certificates, installs them on the right systems and validates them automatically, well before they expire. Where a system cannot be automated yet, its owner gets an alert in time and knows exactly what to do.
Nobody knows how many certificates there are
Certificates come from different certificate authorities, cloud services and teams. Teams track them in spreadsheets and calendar reminders, if they track them at all. Nobody can say how many exist, where they are installed or who is responsible for them.
One inventory with clear ownership
Continuous discovery across networks, certificate authorities, cloud platforms and Kubernetes builds a single, up-to-date inventory. Every certificate gets an owner, so alerts, renewals and approvals always reach the right person.
Eight times more renewals ahead
Public TLS certificates have been valid for at most 200 days since March 2026. That drops to 100 days in 2027 and 47 days in 2029, which means about eight times as many renewals as under the old 398-day limit. A manual process built for yearly renewals cannot keep up.
Automation and self-service that scale
Standard protocols such as ACME, ready-made integrations and a self-service portal let teams renew certificates without tickets or manual steps. Whether a certificate lasts a year or 47 days makes no difference to your workload.
Every team does it differently
Teams request certificates in their own way, from different authorities, with weak keys, broad wildcards or private keys shared by email. When a certificate authority loses trust or an algorithm has to be replaced, nobody can say what is affected.
Central policy, ready for change
Central policies define approved certificate authorities, key types, validity periods and naming, and the platform checks every request automatically. Because you know where every certificate lives, replacing a certificate authority or moving to post-quantum algorithms becomes a planned change instead of a crisis.
What can you expect?
Every certificate across datacenter, cloud and Kubernetes has its owner, issuer, location and expiry date.
Application teams request, renew and revoke certificates through a portal or API, while approved certificate authorities, key types and validity periods are enforced on every request.
Automated renewal and installation handles shorter lifetimes without extra manual work, plus timely alerts wherever automation isn’t possible yet.
Replace a certificate authority or algorithm at scale, the foundation for a smooth move to post-quantum cryptography.
47-day certificates will challenge every business
Public TLS certificates are getting shorter lives, from 200 days today to just 47 days in 2029.
That means about eight times as many renewals, while many organizations don’t even know how many certificates they have or which applications depend on them. Find out why certificates deserve to be treated as machine identities, and why automation is the only way to keep up.
How we’re stopping attacks in their tracks
- Discover & Inventory
- Set up & Integrate
- Automate & Orchestrate
- Support
Phase 1 CLM Discover & Inventory
We start with automated scans of your certificate authorities, your Kubernetes clusters and your networks to find every certificate, including the ones nobody knew about. Together with your teams we assign owners, assess the risks and define a target architecture. You end up with a complete inventory and a prioritized roadmap.
Phase 2 CLM Set up & Integrate
We set up your certificate lifecycle management platform, as a cloud service or self-hosted, and connect it to your internal and public certificate authorities and to the rest of your IT landscape, such as single sign-on, ITSM and notification channels. We configure policies, roles and self-service so that every request follows your rules from day one.
Phase 3 CLM Automate & Orchestrate
We automate the full lifecycle in waves, from issuance and renewal to installation and revocation. We use out-of-the-box integrations wherever they exist and build custom ones where they don’t. For each environment we decide together whether the platform installs certificates centrally or teams fetch their own. We train your teams along the way, so they can run the platform with confidence.
Phase 4 CLM Support
Once the Certificate Lifecycle Management platform is live, we remain actively engaged through a comprehensive support model. Our experts provide operational assistance, proactive recommendations, and continuous improvement services to maximize platform value and resilience. This enables organizations to sustain a strong security posture while seamlessly accommodating growth and changing business needs.
Can you trust your code? Why code signing matters
Code signing proves that software comes from you and hasn’t been tampered with. But a signature is only as strong as the key behind it: if attackers get hold of a signing key, they can make malicious software look legitimate.
Find out why signing keys belong on a central, protected platform, and how this protects your software supply chain.
72%* of organisations experienced at least one certificate-related outage in the past year.
*According to a CyberArk 2025 report. Don’t let your organisation be the next in line.
