Buyers’ Guide for PKI and Certificate Life Cycle Management
29 May 2025 - ID G00823796 - 21 min read
By Sarah Almond
PKI is used extensively, but trust management, resource overheads and incidents plague deployments. Security and risk management leaders must implement effective certificate life cycle management to address outages and future-proof for short lifetimes and the quantum computing threat.
Overview
Key Findings
- Organizations typically have multiple objectives when reconsidering their approach to public-key infrastructure (PKI) and certificate life cycle management (CLM), including elimination of certificate-related incidents and reduction of resource overheads. Triggers include costly outages, regulations, erosion of trust, the postquantum threat, reducing validity periods and scalability concerns.
- Operating models based on unclear ownership and manual processes are not sustainable as certificate use cases increase, lifetimes shorten and environments become more dynamic. Strategies to rationalize PKI use cases into one PKI hierarchy no longer work, particularly where diverse applications, latency or differing security/compliance benchmarks are a factor.
- Supplier convergence is evident across PKI, CLM and the broader identity and access management and data security landscape. As CLM tools deepen in functionality, they also widen in use case coverage as vendors diversify into or from other sectors like Secure Shell (SSH) key, encryption key and secrets management.
- CLM requirements like discovery and automation require deep integrations and can be complex to implement, making it hard to link CLM product capabilities on paper with the realities of successful operation.
- Different PKI and CLM offerings lend themselves to different customer profiles in their capabilities, implementation requirements and commercial positioning.
Recommendations
- Step 1: Specify organization-specific PKI/CLM objectives to drive prioritization of related features. Improving visibility, agility and the ability to operate at scale should be at the core of this.
- Step 2: Define PKI use cases and their respective trust boundaries, then use this information to redefine the operating model so that it aligns with objectives.
- Step 3: Evaluate PKI and CLM vendor trends, including the ongoing convergence of tools, to drive the sourcing strategy and create a long-term roadmap for reaching the desired levels of maturity within achievable timelines.
- Step 4: Develop detailed PKI and CLM requirements to support vendor evaluation or RFP that go beyond the high level, particularly for objectives relating to automation, discovery and complex use cases. Validate CLM capabilities via a proof of concept (POC).
- Step 5: Factor ease of implementation and the need for additional resources, skills and support into decision making to optimize effort. Assess cost models against certificate volume forecasts and other strategic factors like wildcard/SAN use to accurately gauge and influence the total cost of ownership (TCO).
Introduction
Digital business is often underpinned by digital certificates and, as a result, certificate use is vast and growing.
Certificates rely on robust PKI for issuance and efficient CLM for maintenance, since trust is bestowed and periodically expires by design. As numbers of certificates increase and lifetimes shorten, organizations reach a point where more strategic orchestration is required, often triggered by costly outages or mounting resource demands.1,2
Many security and risk management leaders embark on strategic PKI and CLM initiatives, looking for tooling to address challenges with managing certificates at scale and/or with limited resources. Such challenges may include:
- Discovering unmanaged certificates
- Monitoring managed certificate expiries
- Automating elements of the workflow,
- Understanding ownership
- Governing certificate maintenance and compliance
Different tools are available to address different discrete challenges, including single-pane-of-glass solutions.
Given the array of options available, security and risk management leaders may find it challenging to navigate these and determine the right tools for the organization and its requirements.
The five-step process outlined in this research is a guide to discovering and defining PKI and CLM requirements and then evaluating the PKI and CLM solutions to identify the best fit (see Figure 1).
Analysis
Step 1: Specify Objectives to Prioritize Features
When looking at a new PKI provider or considering an investment in CLM tooling, start by identifying the “why.” Are there specific challenges you are trying to overcome? Are there specific features you are lacking?
For PKI, this will link directly with requirements definition in Step 4. For CLM, there are different solutions available for different requirements and some that can satisfy a multitude of requirements in one product.
Take time to define and prioritize the objectives that are driving the activity and map them to related features. This will ensure you target the right solutions and avoid both costly scope creep and overlooking solutions already within your grasp.
Some example CLM objectives and related features are provided in Figure 2. Use this matrix as a guide for assessing individual objectives, prioritizing the key capabilities and driving your sourcing and architectural decisions.
In a broader context, certificate use cases are expanding, certificate environments are becoming more complex and dynamic,1,2 and certificate validities are shortening (see Note 1).3,4,5,6 With a growing focus on resilience and threats posed to certificates by quantum computers (see Note 2),7 regulators are starting to demand better crypto visibility and agility so that certificates can be tracked and maintained seamlessly (see Note 3).8,9
Visibility, agility and the ability to operate at scale should be at the core of Step 1.
Step 2: Define Use Cases, Trust Boundaries and the Operating Model
PKI can be used to support a vast and varied number of use cases, across which CLM capabilities and approaches can vary. Therefore, once you understand the “why,” it is important to define the “what.”
Define PKI Use Cases
PKI is used for authentication, encryption and signing across workload, device and human use cases, both publicly and privately. All PKI use cases across the organization should be considered when reassessing PKI and CLM strategies. This will ensure a PKI buying strategy that works holistically across your estate and a consistent approach to CLM across all PKIs.
If visibility of all PKIs is limited, include discovery and/or PKI posture management as a key feature in Step 1 and define the priority use cases that are driving the activity. Priority use cases will include those that cause significant challenges, incorporate the most certificates or represent the quickest wins.
Define PKI Trust Boundaries
Strike a balance between the simplicity of operating one PKI for all certificate use cases and the segregation offered by multiple PKIs. Use this process as an opportunity to reassess and redraw PKI trust boundaries and determine the strategic PKIs required across all use cases.
When completing this exercise, apply the basic principles shown in Figure 3 alongside any organization-specific requirements.
Define the Operating Model
With objectives/features, use cases and required PKIs defined, it is possible to redefine the operating model so that it aligns with the strategic direction for PKI and CLM. (See CIOs’ Reference Guide to Designing IT Operating Models to support this step.)
The new operating model should be defined in accordance with the centralized/decentralized security (CeDeSec) trend, which stipulates centralized governance and control for decentralized use. CLM tooling can support the CeDeSec operating model by providing a single policy-based orchestration framework for all CLM workflows across multiple PKIs. Orchestration enables organizations to diverge from attempts to centralize everything into one PKI hierarchy and, instead, support the PKI boundaries defined earlier in this step while still providing centralized control.
Certificate authority (CA) trust can change over time, so it is important to establish a CA-agnostic strategy. CLM tooling can support this.
As the operating model is redefined, analyze changes to ways of working and new processes that may be introduced; for example:
- Manual to automated processing
- Decentralized to single-pane-of-glass management
- On-premises to “as a service” (aaS) deployment
- Introduction of self-service capabilities
- New governance processes
- New or changed infrastructure components
- New or changed support models
- New RACI (responsible, accountable, consulted and informed) matrices
The outcome of this analysis allows the strategic direction to be challenged early on, based on any issues raised. It also allows related requirements to be built into PKI/CLM requirements in Step 4, such as automation integrations, role-based access controls, support model requirements and new aaS connectivity
Note that a PKI as a service (PKIaaS) or CLM as a service (CLMaaS) operating model is not right for everyone. Figure 4 shows the pros and cons of PKIaaS/CLMaaS across multiple categories, with related recommendations to support the final decision making during operating model definition.
Step 3: Evaluate Vendor Trends to Create a Roadmap
The vast use of certificates and the security mechanisms they underpin necessitate a long-term strategy that must account for related vendor trends. Evaluating the vendor landscape will guide your PKI and CLM sourcing strategy and roadmap to help support the “when” in terms of capability adoption.
An increasing number of vendors provide solutions for PKI and CLM with evidence of supplier convergence.10,11,12 Figure 5 shows some example vendors and an array of different capabilities that now intersect across them.
Individual vendor capabilities vary in terms of breadth and depth. Some vendors focus on broader use case coverage and branch into wider trust capabilities or asset types such as code signing, document signing, DNS trust, SMIME, SSH keys, secrets and privileged access management. Some vendors provide deeper CLM coverage; for example, providing more intelligent analytics on the certificates discovered and related vulnerabilities, or more comprehensive automation capabilities. Some vendors offer a small subset of relevant features such as certificate discovery.
Several key decisions must be made at this point to drive the sourcing strategy and roadmap definition:
- Vendor rationalization versus best in class: Targeting one vendor for multiple use cases supports a vendor rationalization strategy and, in some cases, single-pane-of-glass control. However, it risks compromising on wider features across all use cases and adds supply chain risk in the event of issues with the single supplier. Use priority features defined in Step 1 to guide this decision.
- Separating versus combining trust (PKI) and management (CLM): Opting to separate or combine trust and management is a subset of the vendor rationalization decision. Assess the impact of PKI distrust and whether this has a greater impact if the same vendor is also relied upon for wider CLM functionality. Note that vendors may provide PKI and CLM as separate services.
- Quick wins from existing vendors: In many cases, incumbent vendors may offer a quick route to new PKI/CLM capabilities (e.g., by expanding use of an existing ITSM or scanning tool to incorporate CLM capabilities). Consider both tactical and strategic use of existing vendors as part of the roadmap but use priority features defined in Step 1 to guide this decision and ensure an approach that fits your needs over the long term.
- The extent of discovery: Different discovery tools based on different scan types (e.g., network scans, endpoint scans) may find different (but intersecting) subsets of certificates within the estate. It is possible to combine the outputs of multiple scans to build certificate inventory accuracy, and many CLM tools have the capability to orchestrate this and run/ingest multiple scans. Depending on the existing and desired maturity level, consider the extent to which discovery will be implemented and, if using multiple scan outputs without orchestration tooling, how these will be subsequently collated and deduplicated.
- Buy versus build: While vendor tooling exists, you may consider the possibility of building capabilities in-house after closer inspection of desired features, use cases and vendor solutions. Potential capabilities to build might include operating a self-hosted or open-source private PKI or developing complementary CLM capabilities such as automation scripts. Consider both tactical and long-term strategic use of self-built tooling in alignment with the desired operating model.
When implementing enterprise-level certificate life cycle management at scale across multiple PKIs and use cases, purchase of CLM tooling is likely unavoidable to deliver the capabilities required. Keep in mind that CLM vendors are also working to meet the needs of smaller, less complex environments.
As you make short- and long-term sourcing strategy decisions, document these in the form of a PKI/CLM roadmap. Use Toolkit: IT Strategic Plan One-Page Summary Template and other related research as a guide. Overall, the roadmap should:
- Plan the delivery of objectives and priority features mapped in Step 1
- Support the use cases, PKI trust boundaries and operating model defined in Step 2
- Align milestones to the tactical and strategic decisions made as part of the trends evaluation here in Step 3
CLM implementation will require a phased approach, from wrestling with discovered certificates and bringing them under management, to establishing integrations and implementing automation — use case by use case.
Use the PKI Consortium’s PKI Maturity Model (PKIMM) to guide thinking on a phased approach with associated maturity levels.
Establish timelines against which progress can be tracked and regular reviews can be completed. Define outcome-driven metrics aligned with objectives from Step 1 to measure success. For example:
- Average time for certificate issuance
- Percentage of automated certificate issuance
- Rolling average of automated certificate issuance
- Percentage of systems/domains scanned for certificates
- Number of help desk calls due to unmanaged/managed certificate expiry per month/year
- Number of incidents due to unmanaged/managed certificate expiry per month/year
- Average time to resolve certificate expiry-related outages
- Rolling average of certificate policy exceptions (potentially broken down by severity if tooling allows)
- Percentage of certificate policy exceptions remediated (potentially broken down by type, e.g., key length, algorithm or lifetime, if tooling allows)
Use Tool: Catalog of Business-Aligned Outcome-Driven Metrics for Risk and Security and Four Steps to Develop Outcome-Driven Metrics for Cybersecurity to guide you.
Note that PKI and CLM initiatives are often driven by certificate visibility and agility requirements. Postquantum readiness also hinges on visibility and agility, but across all cryptography usage.
Align the strategic PKI and CLM roadmap with the broader postquantum readiness roadmap.
Step 4: Develop Detailed Requirements for RFP and POC
With the prework completed, organizations can now begin to consider which tools fit their needs.
First define the requirements for the RFP process, based on desired features, use cases, PKI trust boundaries, the operating model and the strategic roadmap.
Figure 6 shows key differentiators/requirements for PKI/CLM.
Use these key differentiators to help define key categories within which organization-specific requirements can be defined. However:
Requirements definition must go beyond the high level to be effective and to ensure strategic outcomes.
For example: Many organizations define certificate automation as a key requirement and many tools support certificate automation. However, certificate automation alone does not adequately describe the requirement in a way that will facilitate evaluation and differentiation between solutions. Therefore:
- Define the extent to which you want to automate: automated workflow only; automated renewal following manual issuance; or full automation including automated issuance on demand and last-mile provisioning to the endpoint.
- Define the use cases for which you need automation, including specific technology products/models at specific versions that you must integrate with.
- Align with expectations about where and how certificate signing requests are created, and where and how issued certificates are delivered.
Another example is requirements for discovery and inventory. Discovery and inventory are standard features in CLM tooling. However, the scope of discovery and the extent to which you need to or can understand certificate issues, ownership, related business processes and related business impacts from the inventory may vary. Related requirements should be explicitly defined to adequately assess options.
These examples also highlight the importance of a POC once you have shortlisted solutions, particularly for CLM, to validate that solutions meet expectations.
During CLM evaluation, POC is critical to align paper-based assessments with the realities of operation. Spend extra time assessing automation capabilities, discovery/inventory/assessment mechanisms and support for non-standard-based life cycle management.
Step 5: Optimize Effort and Assess Cost to Influence TCO
To complete the buying process and confirm how you will proceed, you must decide how you will staff the deployment and negotiate the deal.
Factor in the following to optimize the adoption and maintenance effort:
- Machine identity working group: Since no single team has the expertise and reach to govern and manage all certificate types, redefine the RACI model within the scope of a machine identity working group. Define policy, and enforce that policy through compliance processes spanning the applicable PKI and CLM use cases and tools.
- Ownership: As part of the RACI definition, define ownership across PKIs, CLM tooling and certificates/keys. Typically, different PKIs will be owned by either the security function (who are experts at key management, or they manage the relationship with aaS vendors who are) or the technology function who owns the related service (e.g., Active Directory team supporting Microsoft Active Directory Certificate Services). CLM will usually be owned by the security function (who understands and sets cryptography policy). Certificates and keys will generally be owned by the consuming service or endpoint admin (who would be impacted by expiry and/or have access to administer certificates and therefore take responsibility for life cycle management).
- Resource/skills: Adoption of new tooling will require resources and may change the skills required (e.g., if moving from a manual, process-driven model to an automated model). Any new resources or skills should be identified in Step 2 and ease of implementation should be considered in Step 4. At this final stage, factor in the necessary skills uplift as part of decision making and plan for the changes required (e.g., training, recruitment).
- Support provided: Vendors may differ in the level of support they provide as standard (e.g., allocation of customer success managers) and the support available at extra cost (e.g., professional services for customised automation). Assess your unique needs in successfully deploying and managing new products and factor vendor support for these into buying decisions.
- New processes: The adoption of new tooling may facilitate or require new processes (e.g., a new governance process for certificate compliance or a service to monitor local/low latency business unit-owned or cloud-native PKIs). Factor this in ahead of time and ensure that all processes related to the new tooling are defined, since a well-established process is key for success and ensuring the tooling is used as intended. Then, evaluate tools based on their support for these processes.
As you evaluate the deal, consider the following:
- Cost models: Vendors may differ in the cost models they apply (ELAs, per certificate, per action, etc.). PKI vendors may also have different charging models for things like SAN and wildcard certificate usage. Evaluate the best deal based on your unique certificate usage. Look out for licensing models that allow for cost overrun or could impact cost control to avoid future issues.
- Customer profile: Vendors differ in terms of customer profile “fit.” Some vendors might lend themselves to large organizations with high complexity or high certificate volumes, while others might be aimed more toward standard use cases and lower complexity. Some vendors may also have specific offerings for small and midsize businesses (sometimes called “lite” offerings) to provide a tiered service. Factor this into decision making to ensure the right fit.
- Vendor lock-in: Assess the deal for any clauses that might impact vendor lock-n; for example, certificate revocation in the event of PKI contract termination (this is to be avoided) or use of proprietary integrations. For both PKI/CLM, factor into contract lengths and future contract renegotiation timescales the potential requirement for — or impact of — future migration.
Finally, don’t expect ROI to be achieved overnight. Existing systems may need to run alongside new systems as you make the transition (e.g., operating existing and new PKIs as you transition from one to the other, or operating manual processes alongside automation). Factor this into financial planning. However, you can also factor in cost avoidance (e.g., certificate outage costs).
1 2024 State of Digital Trust Report, DigiCert.
2 State of Machine Identity Management, 2023, Ponemon Institute and Keyfactor.
3 Minutes of the F2F 59 Meeting in Redmond, Washington, 6–7 June 2023, CA/Browser Forum.
4 Moving Forward, Together, GitHub.
5 Chrome Root Program Policy, Version 1.6, GitHub.
7 Quantum Threat Timeline Report 2024, Global Risk Institute.
8 Delegated regulation - EU - 2024/1774 - EN - EUR-Lex (Section 4, Article 6, point 4 and Section 4. Article 7, point 4)
9 PCI SECURITY STANDARDS COUNCIL, PCI SSC (v4.0.1 requirement 12.3.3).
11 DigiCert Completes Acquisition of Vercara, DigiCert.
12 Keyfactor’s InfoSec Global/CipherInsights Acquisition, Keyfactor.
Note 1: Reducing Certificate Validity Periods
In September 2020, the CA/Browser Forum reduced public certificate validity periods to 398 days, in response to restrictions imposed by Apple. Google later proposed a further shortening to 90 days. Most recently, Apple proposed a limit of 47 days to be achieved in a phased approach, by 15 March 2029. This was formally passed under CA/Browser Forum ballot SC-081 in May 2025. The shorter the validity period, the more frequent the renewal tasks and the more important agile renewal becomes.
Note 2: The Threat of Quantum Computers
Sufficiently strong quantum computers will break the asymmetric cryptography used to create and validate certificates. Gartner expects this to become a real threat by 2029 (see Justify, Build and Launch a Postquantum Response). In preparation for this, the U.S.-based National Institute of Standards and Technology (NIST), whose cryptographic standards influence many geographies, are proposing the deprecation of related algorithms by 2030 (see NIST IR 8547 initial public draft, Transition to Post-Quantum Cryptography Standards). If we are to migrate from vulnerable algorithms, visibility of affected cryptographic usage and seamless migration to new postquantum alternatives are critical (see NIST CSWP 39 initial public draft, Considerations for Achieving Crypto Agility: Strategies and Practices).
Responding to this threat also brings three key considerations in the PKI and CLM context:
- PKI uplift: New CA certificates based on postquantum cryptography (PQC) will be required for issuing postquantum safe certificates. For public PKI this is not yet supported by the CA/Browser Forum and so the status of this and related roadmaps should be monitored through public CA partners/prospects. Many private PKI providers already support postquantum safe certificate issuance, the roadmap for which should be validated in Step 4. New CAs will need to be provisioned to relevant trust stores, making trust store management a key consideration.
- Endpoint certificate uplift: All endpoint certificates will ultimately need to be reissued from quantum safe roots using new quantum safe keys and algorithms. PKI and CLM roadmaps should take this into account including the required visibility and agility to support such a migration.
- Hybrid certificates: Classical signature algorithms (like RSA and ECDSA) are well known and, prior to quantum computers, have stood up to decades of scrutiny. However, they are weak in the postquantum world, the exact date of which is unknown. PQC, by definition, remains secure in the postquantum world. However, postquantum algorithms are relatively new and have not been subjected to the same years of scrutiny. As we transition from classical to postquantum cryptography and we enjoy a time when both are considered secure, there is an argument to apply both classic and postquantum techniques for defence in depth (i.e., to mitigate the risk that quantum computers mature and break the classical algorithms or that new vulnerabilities are found in the new postquantum alternatives). It may also prove useful for interoperability between systems that do and don’t support PQC. In the PKI and CLM context, this means considering hybrid certificates, which are certificates (or certificate structures) containing both classical and postquantum signatures. Various types of hybrid certificates have been proposed, including Catalyst (see Multiple Public-Key Algorithm X.509 Certificates, Datatracker, IETF), Chameleons (see A Mechanism for Encoding Differences in Paired Certificates, Datatracker, IETF), Composites (see Composite Public and Private Keys For Use In Internet PKI, Datatracker, IETF, and Merkle Trees (see Merkle Tree Certificates for TLS, Datatracker, IETF). No clear single standard approach has been adopted by the industry as yet. Where concerns over new algorithms exist, consider your strategy for hybrid certificate use and manage roadmaps accordingly. See also PQC Capabilities Matrix (PQCCM), PKI Consortium, and Note 3 in How to Mitigate the Cryptography Risks Posed by Quantum Computing.
Note 3: Regulations Citing Crypto Visibility and Agility
In January 2025, the Digital Operational Resilience Act (DORA) became applicable to financial entities and critical third-party service providers in the European Union. The supporting Commission Delegated Regulation (EU) 2024/1774 specifies two requirements (Articles 6.4 and 7.4) for “updating or changing…cryptographic technology on the basis of developments in cryptanalysis” (crypto agility) and for maintaining “a register for all certificates and certificate-storing devices” (crypto visibility). PCI DSS v4.0.1, a global standard applicable to the payment card industry, has similar requirements (12.3.3) that became mandatory from 31 March 2025. These two examples highlight an industry trend toward improved cryptographic visibility and agility.