Executive Summary
An expired certificate takes a service down as completely as any outage, and it is the one failure that arrives on a date printed in advance. Shorter lifetimes mean that date comes round far more often.
Every encrypted connection in an enterprise depends on a certificate: public websites and APIs, internal services, devices on the network, workloads in Kubernetes, code signing. Each certificate expires, and when one expires unnoticed, whatever depended on it stops. Certificate lifecycle management is the discipline of knowing every certificate you have, who owns it, when it expires, and replacing it automatically before it does.
Two changes have moved this from an operations chore to a buying decision. The industry body that sets rules for public certificates has set out a schedule that shortens their maximum lifetime step by step, so manual renewal stops being feasible. And the move to post-quantum cryptography requires an inventory of every certificate and key before any of them can be replaced. The products in this guide approach those problems from different starting points: managing certificates from many issuers, issuing public certificates, running your own private PKI, using a cloud provider's CA, issuing identities to devices and workloads, or automating renewal in open source.
Why Certificate Management Became Urgent
The rules for public certificates are changing. The CA/Browser Forum describes a schedule for reducing public TLS certificate maximum validity periods, with an eventual reduction from 398 days to 47 days. The CA/Browser Forum states that these reductions are proposed to occur starting in March 2026 and concluding in March 2029. The validation behind a certificate is shortening too. The CA/Browser Forum describes an eventual reduction of SAN validation data reuse from 398 days to 10 days. A renewal process that relies on someone remembering will fail under that schedule; one that relies on a ticket queue will struggle.
The rules have a defined scope. The CA/Browser Forum refers to its TLS Baseline Requirements as the TBRs. The CA/Browser Forum states that the TBRs address requirements only for certificates intended to be used for authenticating servers accessible through the Internet. Certificates from your own private CA are outside them. That does not make private certificates safe to ignore: they expire too, they are often far more numerous, and they are the ones nobody remembers issuing.
Post-quantum cryptography is the second driver, and it starts with the same inventory. NIST states that in August 2024 it released its principal PQC standards as Federal Information Processing Standards, specifying key establishment and digital signature schemes. NIST states that organizations should begin migrating their systems to quantum-resistant cryptography and must identify where vulnerable algorithms are used and plan to replace or update them. A complete, current certificate inventory is the practical first step of that migration, and the automation that handles short lifetimes is the same automation that will roll out new algorithms.
Who Issues, Who Manages
Two decisions are bundled in this market and are worth separating: who issues your certificates, and what manages their lifecycle. Public certificates must come from a publicly trusted certificate authority. Private certificates can come from a CA you run, a CA run for you, or a cloud provider's CA. A management layer can sit across all of them, or you can rely on each issuer's own tools.
Running your own private PKI is a real option, and some products are built to make it easier. Keyfactor states that EJBCA Enterprise can run in the cloud or on-prem, self-managed or as a service. Cloud providers offer private CAs as metered services: Amazon Web Services states that AWS Private CA issues and manages private certificates for connected resources in one place. The trade is control against effort. A self-run PKI gives you every policy decision and every failure; a managed CA takes the infrastructure but ties issuance to that provider.
| Model | What you get | What you take on |
|---|---|---|
| Multi-CA management layer | Inventory, policy and automation across issuers | Integration with every issuer and every endpoint type |
| Public CA with its own tools | Certificates and lifecycle tools from one vendor | Dependence on that CA if you need to switch issuers |
| Self-run private PKI | Full control of the hierarchy and policy | Running, securing and auditing the CA itself |
| Cloud provider private CA | A managed CA billed by use | Per-CA and per-certificate fees, and ties to one cloud |
| Open source automation | Renewal close to the workload, at no license cost | Engineering ownership and no central inventory by default |
How do you evaluate Certificate Lifecycle Management & PKI?
Judge these products on how much renewal they take off people's hands and how complete their inventory is. A dashboard that shows expiring certificates helps only if someone acts on it. The deciding capabilities are discovery across every issuer and environment, automated renewal and installation at the endpoint, and policy that stops weak or unapproved certificates from being issued.
The schedule sets the bar for automation. The CA/Browser Forum states that it can reasonably be inferred that certificates issued in compliance with the TBRs are understood to be managed so as to allow certificate replacement within any given 24 hour period. Ask each vendor to demonstrate a forced replacement of a set of certificates across your environment, end to end, within that window. Inventory is the other half: Keyfactor states that Command continuously discovers and inventories certificates and keys, including post-quantum and hybrid certificates, from one console.
| Capability | What it does | Buyer translation |
|---|---|---|
| Discovery and inventory | Finds certificates across issuers, networks and clouds | Everything else depends on it. Ask how certificates the tool did not issue are found. |
| Multi-CA support | Manages certificates from several issuers | Avoids lock-in to one CA. AppViewX states that AppViewX CLM automates the end-to-end certificate lifecycle and that no CA lock-in is required. |
| Automated renewal and installation | Replaces certificates on the endpoint without a person | The capability shorter lifetimes require. Test it on your hardest systems. |
| ACME and enrollment protocols | Standard ways for systems to request certificates | Lets servers and devices renew themselves. Ask which protocols are supported. |
| Short-lived certificate modes | Certificates that expire in days | Amazon Web Services states that AWS Private CA has a general-purpose mode that can issue certificates with any validity period and a short-lived certificate mode limited to certificates valid for up to 7 days. |
| SSH keys and code signing | Lifecycle for keys beyond TLS certificates | AppViewX states that AppViewX SSH discovers SSH keys and certificates and automates their full lifecycle. |
| Kubernetes integration | Certificates for workloads, issued and renewed in-cluster | The cert-manager project describes cert-manager as an X.509 certificate controller for Kubernetes and OpenShift workloads that obtains certificates from public and private Issuers and attempts to renew them at a configured time before expiry. |
| Crypto-agility | Changing algorithms or issuers at scale | The post-quantum test. Ask how a fleet-wide algorithm change would be run. |
Vendors in Certificate Lifecycle Management & PKI
Representative vendors include Amazon Web Services, AppViewX, cert-manager, DigiCert, Keyfactor and Smallstep. The list is alphabetical, is not a ranking, and is not for sale. How we choose vendors
The approaches below differ by where they start: managing many issuers, being an issuer, running a private PKI, renting a cloud CA, issuing identities to devices and workloads, or automating renewal in open source. An enterprise can use more than one, and the question is which one holds the inventory.
One incumbent has changed hands. A request for venafi.com is answered by paloaltonetworks.com. Palo Alto Networks states that it has brought certificate lifecycle management, PKI and certificate automation together under Next-Generation Trust Security. If an incumbent product's ownership has changed, ask for the roadmap and support commitments in writing before renewal. Open source has a large place in this market too: Let's Encrypt describes itself as a free, automated and open Certificate Authority brought to you by the nonprofit Internet Security Research Group.
| Vendor | Approach | Where it fits |
|---|---|---|
| Amazon Web Services | Cloud provider CAs | Private certificates for AWS-centered estates, priced per CA and per certificate |
| Smallstep | Device and workload identity | Hardware-attested device identity across operating systems |
| AppViewX | Multi-CA management | Certificate, SSH key and code-signing lifecycle across issuers |
| cert-manager | Open source automation | Certificate issuance and renewal inside Kubernetes |
| Keyfactor | Private PKI platforms | Private CAs run in the cloud or on-premises, with a separate management console |
| DigiCert | Public CA with lifecycle tools | Public certificates and lifecycle automation from the same vendor |
One representative of each approach is named here; the field runs to more than twenty vendors and projects, and several span camps. Approaches were set out first and a representative selected for each, and no row in this table is for sale. Certificate and PKI vendors, named here or not, can make their case in the Spotlight below.
How much should you budget for Certificate Lifecycle Management & PKI?
Most vendors here quote rather than publish, and they meter different things: certificates under management, certificates issued, certificate authorities operated, or tiers by estate size. Count your certificates by type before the first call, including private certificates, because the count drives every quote.
Where pricing is published, the structure is as informative as the rate. Amazon Web Services states that AWS Private CA charges a monthly fee for the operation of each private CA, for the private certificates issued each month, and for the use of OCSP. Amazon Web Services lists $400 per private CA per month for general-purpose mode. Amazon Web Services lists $50 per private CA per month for short-lived certificate mode.
| Meter | You are charged for | Grows with | Where it goes wrong |
|---|---|---|---|
| Certificates under management | Each certificate tracked by the platform | Estate size, especially private certificates | Shorter lifetimes do not change the count, but discovery does |
| Certificates issued | Each certificate the CA issues | Issuance volume | Shorter lifetimes multiply issuance |
| CA operation | Each certificate authority run | Number of CAs and environments | CAs created for tests and never deleted |
| Tier by estate | A package sized to the organization | Moving between tiers | Multi-CA support only in a higher tier |
| Open source | No license; engineering time | Clusters and teams | Support and inventory added later at a cost |
How long does implementation take for Certificate Lifecycle Management & PKI?
Certificate projects succeed when the inventory is trusted, and the inventory is trusted when it has caught certificates nobody knew about. Start with discovery, then automate where it is easiest, and leave the systems that need people for last, with a plan for each.
Run discovery across networks, clouds and every CA you can query. Record each certificate's issuer, expiry, location and owner. Unowned certificates are the first finding.
Turn on automated renewal and installation where systems support it: web servers, load balancers, Kubernetes and cloud services. Measure the share of certificates renewed without a person.
For appliances and legacy systems that need manual installation, document the procedure, shorten the warning period and plan replacement or proxies. These systems set your real readiness for shorter lifetimes.
Enforce issuance policy, retire unapproved CAs, and track which algorithms each certificate uses. Run the mock distrust exercise yearly; it is your rehearsal for post-quantum migration.
What should you ask vendors about Certificate Lifecycle Management & PKI?
Ask for each answer to be shown on your environment, not on a demo estate.
-
Do you use certificates from more than one CA, or plan to?Yes Shortlist multi-CA management platforms or private PKI platforms with a CA-neutral console.No Your CA's own lifecycle tools may be enough; continue.
-
Do you need a private hierarchy for internal services or devices?Yes Compare a self-run private PKI with a cloud provider CA on control, cost and where your workloads run.No Focus on public TLS automation.
-
Is most of the estate in Kubernetes or a single cloud?Yes Open source automation or a cloud provider CA may cover it, with an inventory layer above.No Plan for a management platform that reaches on-premises systems and appliances.