Certificate lifecycle management has moved from housekeeping to a hard requirement. The CA/Browser Forum has voted to cut the maximum lifetime of public TLS certificates in stages, to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. Manual renewal will not keep up, and a missed renewal is an outage. At the same time, private certificates for mTLS, devices, workloads and code signing are multiplying, and post-quantum migration will require changing algorithms across all of them. This vendor-neutral buyer's guide helps you evaluate certificate lifecycle management (CLM) and wider machine identity management platforms.
Key takeaways
- Automation is the core requirement. Every renewal path should run without a person.
- Discovery must find certificates you did not issue, across networks, clouds, load balancers and Kubernetes.
- Cover public and private PKI, including mTLS, device, SSH and code signing certificates where you need them.
- Evaluate key protection and crypto-agility, including post-quantum readiness.
- Check integration breadth: ACME, cloud certificate services, secrets managers, service meshes and CI/CD.
Define requirements
- How many certificates, of which types, and where do they live today?
- Which public CAs do you use, and do you run private CAs?
- Which platforms must be automated: load balancers, web servers, CDNs, Kubernetes, cloud services, appliances, devices?
- Who owns certificates today, and how are renewals requested?
- Regulatory or sector requirements for key storage and cryptography.
The Machine Identity, PKI and Certificate Lifecycle Guide covers the underlying practices.
Capability areas
| Area | What to look for |
|---|---|
| Discovery and inventory | Network and cloud scanning, CT log monitoring, integration with load balancers and Kubernetes; owner assignment |
| Automated issuance and renewal | ACME server and client support, agents where ACME is not possible, renewal well ahead of expiry, deployment and verification |
| CA agility | Support for multiple public CAs and private CAs, with the ability to switch CA quickly after a distrust event |
| Private PKI | Managed or integrated private CA for mTLS, devices and workloads; short-lived certificates |
| Key protection | HSM and KMS integration, non-exportable keys, key generation location |
| Policy | Allowed CAs, algorithms, key sizes, lifetimes and domains, with enforcement |
| Other machine identities | SSH certificates, code signing, device identities and workload identity integration where needed |
| Crypto-agility and PQC | Algorithm inventory, ability to reissue at scale, post-quantum roadmap. See the Post-Quantum Readiness Guide |
| Monitoring and reporting | Expiry alerts, failed renewal alerts, compliance reports, API and SIEM integration |
Questions to ask vendors
- Show us discovery finding certificates on a load balancer, a Kubernetes ingress and a cloud service we have not told you about.
- Show a full automated renewal, deployment and verification for a certificate that cannot use ACME natively.
- How quickly could we replace every certificate from one CA with another after a distrust event?
- How are private keys generated and stored, and can they be non-exportable?
- What is your roadmap for post-quantum certificates and hybrid algorithms?
- How do you handle ownership, so every certificate has an accountable team?
Red flags
- Discovery that relies only on certificates issued through the platform.
- "Automation" that stops at issuance and leaves deployment to people.
- Lock-in to a single public CA.
- No answer on 47-day lifetimes or post-quantum algorithms.
- Private keys generated centrally and distributed without justification.
Proof of concept
- Run discovery on a representative network segment and cloud account; compare with your known inventory.
- Automate renewal end to end for a web server, a load balancer, a Kubernetes ingress and one legacy appliance.
- Issue short-lived private certificates for a service-to-service mTLS use case.
- Simulate a CA replacement for a batch of certificates and time it.
- Test alerting for a failed renewal and confirm the owner is notified.
How NHI Mgmt Group can help
We provide independent requirements and evaluation support for machine identity, PKI and NHI programmes. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Machine Identity and PKI Guide · Cryptographic Key Management Guide · NHI Security Platform Buyer's Guide · Secrets Management Buyer's Guide
