7 Factors for Choosing Enterprise PKI Services

Choosing a provider of enterprise PKI services is one of the more consequential procurement decisions a security or infrastructure leader will make. Public Key Infrastructure sits underneath authentication, encryption, code signing, device identity and machine-to-machine trust. When it is designed well, it becomes invisible and dependable. When it is designed poorly, or operated without the right expertise, the consequences surface as outages, failed audits, stalled migrations and remediation programmes that run for years.

The difficulty for buyers is that the market presents a mixture of very different propositions under a single label. Certificate authorities offer public trust services. Software vendors offer certificate lifecycle management platforms. Hardware manufacturers offer cryptographic modules. Systems integrators offer implementation capacity. Each of these is valuable, and none of them is quite the same as an enterprise PKI service, which spans architecture, policy, delivery and ongoing operation across the whole estate.

This guide sets out seven factors that consistently determine whether an enterprise PKI engagement succeeds. It is written for CTOs, CISOs, heads of infrastructure and technical authorities in defence, financial services, government and large multinational organisations, where the assurance requirements are high and the cost of getting it wrong is measured in more than licence spend.

Why PKI procurement has changed

Three developments have altered the shape of this decision over the past two years, and they are worth understanding before assessing any provider.

The first is the compression of certificate lifetimes. The CA/Browser Forum has agreed a staged reduction in the maximum validity of publicly trusted TLS certificates, moving through 200 days, then 100 days, and eventually to 47 days by 2029. Code signing certificates are following a similar direction of travel. Organisations that renew certificates manually, or that rely on spreadsheets and calendar reminders, will find those processes untenable well before the final step takes effect. Automation moves from being a maturity ambition to an operational requirement. We covered the practical implications in Reduction of Public TLS Certificate Lifetimes.

The second is the arrival of standardised post-quantum algorithms. NIST published ML-KEM, ML-DSA and SLH-DSA as finalised standards in 2024, and national authorities including the NCSC have since issued migration timelines that expect discovery activity to be substantially complete before 2028 and full migration by 2035. The practical effect is that any PKI built or refreshed today should be assessed for its ability to accommodate new algorithms without a rebuild.

The third is the growth of machine and workload identity. Containers, service meshes, IoT fleets, connected vehicles and operational technology have all increased certificate volumes by orders of magnitude, often outside the visibility of the team nominally responsible for PKI. Estates that once issued thousands of certificates a year now issue millions, with lifetimes measured in hours.

Taken together, these shifts mean that PKI vendor selection is less about who can stand up a certificate authority and more about who can help you operate a living cryptographic estate under changing conditions.

Factor 1: Assurance and the integrity of the root of trust

Everything a PKI does depends on the trustworthiness of its root. If the root private key is compromised, or if the ceremony that created it cannot be evidenced, then every certificate issued beneath it is called into question. Rebuilding a trust hierarchy across a large estate is disruptive, expensive and highly visible.

Assurance is therefore the first thing to assess, and it is more than a question of whether hardware security modules are used. The considerations that matter include:

• Key ceremony practice. Is the provider able to plan, script, witness and evidence a formal key generation ceremony, including role separation, split knowledge, dual control and independent witnessing? Can they produce an auditable record that will satisfy a regulator or an accrediting authority years later?
• HSM selection and configuration. FIPS 140-3 and Common Criteria certification levels, firmware currency, backup and restore models, and quorum policies all shape the real assurance level. Certification on a datasheet does not guarantee that the deployed configuration achieves it. Our Hardware Security Modules practice covers this in detail.
• Offline root handling. How is the offline root stored, accessed and periodically brought online for CRL signing or subordinate issuance? Who holds the material, and under what physical controls?
• Certificate policy and certification practice statement. A credible provider will draft or review CP and CPS documentation against RFC 3647 and the relevant sector requirements, rather than treating governance as an afterthought.

A useful test during evaluation is to ask a prospective provider to describe a root ceremony they have run, including what went wrong and how they handled it. Providers with genuine experience will answer readily. Our Delivery of a Highly Assured PKI Root case study illustrates the level of rigour that high-assurance environments require.

Factor 2: Architecture fit and genuine vendor neutrality

The second factor is whether the provider designs around your requirements or around their commercial arrangements. This distinction is easy to claim and harder to demonstrate.

Enterprise PKI architectures vary considerably. A defence programme with air-gapped enclaves and national accreditation requirements needs a different hierarchy from a retail bank issuing EMV and payment credentials, which in turn differs from a technology business securing Kubernetes workloads across three cloud providers. The right answer depends on trust boundaries, operational separation, regulatory scope, latency tolerance, disaster recovery expectations and the realities of the existing estate.

Questions worth asking during PKI vendor selection include:

• Which certificate authority platforms has the provider designed, deployed and operated in production? Depth across Microsoft ADCS, EJBCA, Entrust and others matters more than a long list of logos.
• Can they articulate why they would recommend one platform over another for your specific case, with trade-offs rather than assertions?
• Are they willing to recommend that you retain an incumbent platform where that is the right answer?
• How do they handle mixed estates, where public trust from a provider such as DigiCert sits alongside a private hierarchy and a cloud-native issuer?
• Do they hold commercial incentives that would be materially affected by the recommendation they make?

Unsung takes a vendor-neutral position by design. We hold partnerships with Keyfactor, Thales, Entrust, DigiCert and others because our clients run those technologies and we need deep working knowledge of each. The recommendation itself is driven by requirements. Where an existing platform is fit for purpose, the advice is to keep it and improve how it is run. That position is set out further on our PKI Consultancy page.

One further architectural consideration deserves attention. The industry is moving away from using publicly trusted certificates for mutual TLS and internal authentication, driven by changes to client authentication extended key usage in public hierarchies. Organisations that have quietly relied on public certificates for internal purposes will need a private hierarchy, and the design of that hierarchy is not a trivial exercise. We examined the implications in The End of Public TLS Certificates for mTLS.

Factor 3: Scale, discovery and certificate lifecycle automation

An enterprise PKI service is only as good as its ability to keep pace with the estate it serves. Two capabilities determine this.

Discovery. Most organisations underestimate their certificate population by a significant margin. Certificates accumulate in load balancers, application servers, developer laptops, embedded devices, cloud key stores, third-party SaaS platforms and vendor-managed appliances. An enterprise PKI service should begin with comprehensive discovery across network, cloud and endpoint sources, producing an inventory that includes issuer, expiry, key algorithm, key length, owner and location. Without that baseline, automation has nothing to automate and post-quantum planning has no starting point. We set out a practical method in Building a Cryptographic Inventory.

Automation. With shorter lifetimes and larger volumes, manual renewal becomes the primary source of operational risk. Assess how the provider approaches:

• Protocol support across ACME, EST, SCEP and CMP, and the ability to advise on which is appropriate for which population of endpoints. Our comparison of these protocols is available in Certificate Management Protocols Compared.
• Integration with the platforms that actually consume certificates, including F5, NetScaler, IIS, Apache, Kubernetes ingress controllers, service meshes and cloud-native certificate services.
• Workflow design that reflects how your organisation approves, issues and revokes, rather than a generic template.
• Handling of the awkward population, meaning legacy systems and appliances that cannot support automated enrolment and require a managed exception process.

Automation projects fail more often for organisational reasons than technical ones. Application owners resist change, ownership is unclear, and no one wants to be responsible for a renewal that breaks a production service. A capable provider will have a method for addressing that resistance, which we discuss in Overcoming Resistance to Automation in Certificate Management. Licensing models also vary considerably between CLM platforms, and the basis of charge can change the total cost of ownership significantly at scale. Our guidance on that is in How to Evaluate CLM Vendors and Licensing Models, and the delivery capability itself is described under Certificate Lifecycle Management.

Factor 4: Depth of managed service and operational cover

Many organisations reach the same conclusion after building a PKI. The design was the straightforward part. Running it for the next decade, with staff turnover, platform upgrades, expiring subordinate CAs and evolving audit requirements, is the harder commitment.

Managed PKI propositions differ widely in what they actually cover, so it is worth comparing them against a consistent set of criteria:

• Scope of responsibility. Does the service cover the certificate authority estate only, or does it extend to HSMs, CLM platforms, registration authorities, validation services and the integrations that connect them?
• Availability model. What are the response and resolution commitments, and do they distinguish between a certificate issuance failure and a full CA outage? Is cover genuinely continuous, and who provides it outside business hours?
• Proactive activity. A mature service monitors CA health, CRL and OCSP responder availability, HSM status, subordinate CA expiry horizons and certificate renewal pipelines, acting before the point of failure. Reactive ticket handling alone is a weaker proposition.
• Change and lifecycle management. Who is accountable for patching, firmware updates, platform version upgrades and the eventual renewal of issuing CA certificates? Expiring issuing CAs are a recurring cause of preventable disruption, as illustrated in our Issuing CA Expiry case study.
• Hosting model. Can the provider host the environment, operate it in your data centre, or run a hybrid arrangement that keeps key material within your sovereign boundary? Our PKI Management and Hosting service supports each of these models.
• Exit and transition. How would the service be handed back or transferred to another provider? A provider confident in its value will describe this openly.

For organisations that are uncertain where they stand today, a structured assessment is usually the most efficient starting point. A PKI Health Check establishes the current state across architecture, configuration, policy, operational practice and compliance, and produces a prioritised remediation plan. We have delivered these across healthcare, engineering and systems integration environments.

Factor 5: Post-quantum readiness and crypto-agility

Post-quantum cryptography is now a live procurement consideration rather than a horizon topic. The relevant question during evaluation is not whether a provider mentions PQC, because all of them do. The question is whether they can describe a credible, staged transition for an estate like yours.

Signals of genuine capability include:

• A discovery-first approach. Migration planning depends on knowing where cryptography is used, which algorithms are in play, which are embedded in hardware or firmware, and which are controlled by third parties. This is the purpose of a Cryptographic Bill of Materials, and it is the practical foundation of any PQC programme.
• Honest treatment of vendor claims. Support for a post-quantum algorithm in a product release note does not mean the implementation performs acceptably under load, integrates with your HSMs, or is certified for your compliance regime. Larger key and signature sizes have real consequences for handshake performance, network MTU, embedded storage and constrained devices. We examined this in PQC Support vs Performance.
• Crypto-agility as an architectural property. The objective is an estate where algorithms can be changed without redesigning applications, which requires abstraction of cryptographic functions, centralised policy, certificate automation and clear ownership. Our view of what this means in practice is set out in What Does Crypto-Agility Actually Mean in Practice.
• Awareness of the data exposure profile. Harvest now, decrypt later affects organisations whose data retains value over long periods, including defence, government, healthcare and financial services. The urgency of migration should be calibrated to data lifetime, as discussed in Harvest Now, Decrypt Later.
• Hybrid and transitional design. Most estates will run hybrid classical and post-quantum constructions for a period. A provider should be able to explain how they would sequence that, including which systems move first and how interoperability is maintained during the transition.

A provider that treats post-quantum migration as an algorithm substitution has probably not attempted one. The work is closer to an infrastructure transformation programme, touching applications, hardware, suppliers, policy and governance. Our wider view is set out in Why Post-Quantum Cryptography Is a Business Transformation.

Factor 6: Compliance, sovereignty and sector obligations

Enterprise PKI rarely exists in a purely technical context. It supports regulated processes, accredited systems and contractual obligations, and the provider needs to understand the regime you operate under.

Defence and national security. Programmes in this sector carry accreditation requirements, clearance conditions, supply chain assurance expectations and constraints on where data and personnel may be located. Evaluating PKI for national defence means confirming that a provider holds appropriately cleared staff, understands the relevant assurance frameworks, and has experience of delivering into environments where standard commercial practices do not apply. Unsung is a signatory to the Armed Forces Covenant and works across defence programmes, as described under PKI for Defence.

Financial services. PKI for financial institutions intersects with PCI DSS, EMV, PSD2 and eIDAS, operational resilience expectations under DORA and the FCA regime, and payment HSM requirements that differ materially from general purpose HSM deployments. The G7 Cyber Expert Group has additionally set a 2035 target for post-quantum transition across the sector, which brings PQC planning into supervisory scope. Our sector view is set out under PKI for Financial Services.

Government and critical national infrastructure. Procurement route matters. Availability on G-Cloud, Digital Outcomes and Specialists, and Cyber Security Services frameworks reduces friction and shortens time to contract. Data residency, sovereignty of key material and the location of operational staff are frequently non-negotiable. Unsung is listed on G-Cloud 14, DOS 6 and 7, and Cyber Security Services 3, and holds ISO 27001 and Cyber Essentials Plus certification. Further detail is available on our Frameworks page and under PKI for Central Government.

Multinational operations. Organisations operating across jurisdictions face divergent requirements on cryptographic standards, data localisation and electronic signature validity. An enterprise PKI design that works in the UK may need adaptation for EU, US or Asia-Pacific operations. Ask a prospective provider how they have handled cross-border trust hierarchies and regional issuance requirements.

Factor 7: People, knowledge transfer and continuity

The final factor is the one that most often determines whether an engagement leaves the organisation stronger. PKI expertise is scarce. Very few organisations can recruit and retain enough of it to run a large estate independently, and the specialists who do exist are usually stretched across competing priorities.

When assessing a provider, look closely at the people who will actually deliver the work:

• Team depth and specialisation. How many dedicated PKI practitioners does the provider employ, as distinct from general cybersecurity consultants who occasionally work on certificates? Unsung maintains a team of more than twenty dedicated PKI specialists, which is the basis on which we take on complex migrations and high-assurance builds.
• Continuity of personnel. Will the consultants who scoped the engagement be the ones who deliver it? High turnover between bid and delivery is a common source of disappointment.
• Knowledge transfer as a deliverable. Documentation, runbooks, handover sessions and training should be defined outputs rather than optional extras. The objective is an internal team capable of operating confidently, with external expertise available for the work that genuinely requires it.
• Willingness to disagree. A consultative provider will tell you when a proposed approach carries risk, when a requirement is unrealistic, or when a cheaper option would serve you better. That candour is worth more over a multi-year relationship than agreeable delivery of a flawed plan.
• Migration experience specifically. Building a new PKI in a greenfield environment is considerably easier than migrating a live estate without service interruption. Ask for evidence of migrations at comparable scale. Our Entrust to EJBCA Migration and Migration De-Risking case studies describe how we approach that work.

Bringing the factors together

Few providers score equally across all seven factors, and the weighting should reflect your circumstances. An organisation with a mature, well-documented PKI and a stretched operations team will weight managed service depth and continuity most heavily. An organisation facing an issuing CA expiry in nine months will prioritise delivery capability and migration experience. A defence programme will start with assurance and accreditation and work outwards.

A practical approach is to score each candidate against the seven factors, then test the two highest-scoring providers against a real scenario from your estate. Ask them to outline how they would approach a specific problem you currently face, and assess the quality of the questions they ask before answering. Providers who move straight to a solution without understanding the environment tend to deliver in the same way.

How Unsung approaches enterprise PKI services

Unsung is a UK-based consultancy that works exclusively on Public Key Infrastructure and cryptographic security. We advise, design, build and operate PKI for central government, defence, financial services, healthcare, transport and critical national infrastructure, with more than twenty dedicated PKI specialists and a vendor-neutral position that keeps our recommendations aligned to client requirements.

Engagements typically begin with an assessment of the current environment, its architecture, governance and operational practice, and the compliance obligations it carries. From there we develop options with clear trade-offs, agree a roadmap, and deliver against it, whether that means a PKI design and build programme, a certificate lifecycle automation rollout, an HSM refresh, a post-quantum readiness assessment or a fully managed service. The full range is set out on our Services page.

Organisations considering a change of provider, a platform migration or a first structured review of their cryptographic estate can contact our team to discuss the options available.

‍