PKI and Managed PKI Buyer's Guide

Every private certificate your organisation trusts is only as safe as the certificate authority that issued it, and many enterprise CAs still run on unpatched servers with software-protected keys and no documented policy. Organisations replacing an ageing in-house CA now choose between self-managed CA software, CA software backed by their own hardware security modules, and managed PKI where a provider runs the CA hierarchy as a service. This vendor-neutral buyer's guide covers that CA layer: hierarchy, key protection, issuance protocols, revocation, policy and audit. Automating discovery, renewal and deployment of certificates across your estate is a separate purchase, covered in the CLM Buyer's Guide. It is written for PKI owners, identity architects and security teams running an evaluation.

Key takeaways

Decide who holds the CA keys. The main choice is between keys in your own validated HSMs and keys in a provider's HSMs; everything else follows from that.
Buy the operating model, not only the software. A CA needs a certificate policy, a certification practice statement, ceremonies, audit and a recovery plan, whoever hosts it.
Short-lived certificates change the load. Public TLS lifetimes fall to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029 under the CA/Browser Forum Baseline Requirements, and private PKIs usually follow, so issuance capacity and automation protocols matter more than ever.
Revocation must actually work. Test CRL publication, OCSP availability and how quickly a revoked certificate stops being accepted by relying parties.
Plan for crypto-agility. You will need to reissue on new algorithms, including post-quantum ones, so ask how a hierarchy is re-keyed and how fast.

Define requirements

Use cases: Which certificate types will the CA issue: TLS for internal services, mutual TLS between workloads, device and Wi-Fi (802.1X) certificates, user authentication and smart card logon, S/MIME, code signing, VPN, and IoT device identity?
Volume and lifetime: Certificates issued per day today and in three years, and target lifetimes per use case. Workload certificates measured in hours or days multiply issuance volume.
Enrolment protocols: ACME (RFC 8555) for servers, EST (RFC 7030) and SCEP for devices and mobile management, Windows auto-enrolment for domain machines, REST APIs and Kubernetes integrations.
Trust distribution: How the root certificate reaches every relying party: Windows and macOS trust stores, Linux CA bundles, Java keystores, containers, mobile devices and appliances. See Certificate trust stores and root CA management.
Assurance level: Whether CA keys must sit in modules validated to FIPS 140-3 (FIPS 140-2 validations remained acceptable until 21 September 2026, when CMVP said they would move to the Historical list), at which security level, and whether an external audit is required by a sector rule or a customer.
Existing estate: The current CA (often Active Directory Certificate Services), its templates, the relying parties that pin to it, and how long the old and new hierarchies must coexist.
Residency and sovereignty: Where CA keys, logs and certificate databases may be located.

Deployment models compared

Model	Who holds CA keys	Best fit	Trade-offs to test
Self-managed CA software, software keys	You, on the CA server disk	Labs and low-assurance internal use only	Key theft from the server gives an attacker a trusted CA; not suitable for production roots
Self-managed CA software with your HSMs	You, in your validated HSMs	Regulated sectors, sovereignty requirements, high volume	You run ceremonies, patching, backup and HSM operations. See the HSM and Key Management Buyer's Guide.
Hybrid: offline root on premises, managed issuing CAs	You hold the root; provider holds issuing CA keys	Organisations that want root control without running issuing infrastructure	Clear split of responsibilities; how subordinate CAs are signed and revoked
Managed PKI (PKI as a service)	Provider, in provider HSMs	Teams without PKI specialists, cloud-native workloads	Provider security and audit evidence, export of the hierarchy, cost per certificate at high volume, concentration risk
Cloud provider private CA	Cloud provider, in its HSMs	Workloads concentrated in one cloud	Cross-cloud and on-premises reach, per-certificate pricing. See the AWS Certificate Manager and Private CA Guide.

Small vs large organisations: a small organisation with a few hundred internal certificates rarely benefits from running its own HSM-backed hierarchy; managed PKI with a clean exit path is usually simpler and safer. A large or regulated organisation with tens of thousands of devices, sovereignty rules or code signing often needs the root under its own control, with issuing CAs wherever the volume is. See the Enterprise PKI Design and CA Hierarchy Guide for hierarchy design.

Capability areas

Area	What to look for
Hierarchy and key ceremonies	Offline root support, multiple issuing CAs per use case, scripted and witnessed key ceremonies, M-of-N quorum for root operations, cross-signing for migration
Key protection	CA keys generated and kept in HSMs validated to FIPS 140-3 at the level you require, non-exportable keys, documented key backup and escrow, key usage logging
Issuance protocols	ACME with http-01 and dns-01 challenges or external account binding for internal use, EST with /simpleenroll and /simplereenroll, SCEP, Windows auto-enrolment, REST API, Kubernetes issuer integration
Certificate profiles	Template control over key usage, extended key usage, subject and SAN rules, lifetimes and key types; blocking requester-supplied subjects where they are not needed
Validation and approval	How the CA verifies the requester is entitled to the name: directory lookup, device attestation, workload identity, manual approval for high-value profiles
Revocation	CRL publication frequency and size management, delta CRLs, highly available OCSP responders, revocation by API, short-lived certificates where revocation is impractical. See the Certificate Revocation Guide.
Policy documentation	A certificate policy and certification practice statement structured to RFC 3647, kept current and mapped to actual configuration
Audit and logging	Immutable logs of every issuance, revocation and administrative action, exportable to SIEM; independent audit reports for managed services
Crypto-agility	Support for RSA and ECDSA today, a documented roadmap for post-quantum and hybrid algorithms, and tooling to stand up a new hierarchy and reissue at scale. See the Post-Quantum Readiness Guide.
Availability and recovery	Geographic redundancy for issuing CAs and OCSP, tested CA restore, and a plan for CA compromise

Evaluation criteria

The weights are an NHI Mgmt Group suggestion for a mid-sized organisation replacing an in-house CA, not a sourced benchmark.

Criterion	Suggested weight	Evidence to request
CA key protection and ceremony controls	20%	HSM validation certificate numbers, ceremony scripts, quorum design
Issuance protocol coverage for your use cases	20%	Working ACME, EST or SCEP and auto-enrolment in the pilot
Profile and validation controls	15%	Template export, test of a request with a forbidden subject
Revocation performance	15%	Measured time from revocation to updated CRL and OCSP answer
Audit, logging and policy documentation	15%	Sample CP/CPS, audit report, SIEM log sample
Crypto-agility and exit	10%	Re-key plan, algorithm roadmap, export of certificate database
Cost at projected volume	5%	Pricing at three times today's volume with short lifetimes

Where identity fits

A private CA is a machine identity issuer: most certificates it signs authenticate workloads, devices and services rather than people. That makes the CA and its templates a direct path to impersonation. Attackers steal or forge authentication certificates (ATT&CK T1649), for example by abusing misconfigured Active Directory Certificate Services templates that let a low-privileged user request a certificate for an administrator, and steal private keys from hosts (T1552.004). Code signing keys outside hardware protection are a recurring failure: the NVIDIA code-signing certificate theft led to leaked keys being used to sign malware. Require the candidate to show which identities can request which profiles, and to log every issuance with the requesting identity. See the AD CS Security Guide and the Machine Identity and PKI Guide.

Questions to ask vendors

Where are root and issuing CA private keys generated and stored, in which HSM model, and what is its FIPS 140 validation certificate and security level?
Who can perform root operations, what quorum is required, and can we attend or witness the key ceremony?
For managed PKI: is our hierarchy cryptographically separate from other customers, and who on your staff can use our CA keys?
Show us a certificate profile rejecting a request for a subject or SAN the requester is not entitled to.
Which enrolment protocols are supported natively (ACME, EST, SCEP, auto-enrolment), and which need extra components?
How often is the CRL published, how is OCSP made highly available, and what is the measured time from revocation to relying parties seeing it?
Can you provide your current certificate policy and certification practice statement, and the most recent independent audit report?
How would we stand up a new hierarchy with a different algorithm and migrate all subscribers, and how long would it take at our volume?
If we leave, can we take the CA keys (for a hierarchy we own), the certificate database and the revocation service with us?
What happens to OCSP and CRL availability, and therefore to relying parties, if your service has an outage?

Red flags

Root or issuing CA keys held in software on an online server, or no clear answer on HSM validation.
No certificate policy or practice statement, or one that does not match the actual templates.
Templates that allow requesters to set any subject alternative name by default.
Revocation that depends on a single OCSP responder or a CRL published weekly.
Managed PKI with no export path for the hierarchy, or pricing that makes short-lived certificates unaffordable.
No roadmap for post-quantum algorithms and no tested re-key procedure.

Proof of concept

Inventory first: list the current CA's templates, issued certificate counts per template, and every relying party that trusts the old root.
Build a test hierarchy with an offline or HSM-protected root and one issuing CA per use case, following a written ceremony script with quorum.
Issue through each protocol you need: ACME for a web server, EST or SCEP for a managed device, auto-enrolment for a domain machine, and an API call for a workload certificate with a lifetime of one day or less.
Test policy enforcement: submit requests with forbidden subjects, weak keys and excessive lifetimes, and confirm they are rejected and logged.
Test revocation: revoke a certificate and measure when the CRL and OCSP reflect it and when a relying party rejects the certificate.
Test logging: confirm every issuance, revocation and admin action reaches the SIEM with requester identity.
Test recovery and compromise: restore an issuing CA from backup, then simulate an issuing CA compromise and time the reissue of a test batch. See the CA Compromise and Mass Certificate Replacement Playbook.
Plan coexistence and rollback: distribute the new root alongside the old one, migrate relying parties in rings, and keep the old CA issuing until each ring is proven.

Measuring success after go-live

Percentage of certificates issued through automated protocols rather than manual requests.
Median and maximum certificate lifetime per profile, against policy.
OCSP availability and time from revocation to relying-party rejection.
Number of templates that allow requester-supplied subjects, trending to zero.
Days since the last tested CA restore and re-key exercise.

Framework mapping

Framework	Reference	How the PKI supports it
NIST SP 800-53 Rev. 5	SC-12, SC-13, SC-17, IA-5(2), IA-3	Key establishment and management, cryptographic protection, PKI certificates, public key-based authentication, device authentication
NIST SP 800-57 Part 1 Rev. 5	Key management guidance	Key types, protection requirements, cryptoperiods and key inventory
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.DS-01	Credentials for services and hardware, authentication, protection of data at rest
CIS Controls v8.1	Control 3 (Data Protection)	Encryption of data in transit and at rest relies on trusted certificates
MITRE ATT&CK	T1649, T1552.004, T1588.004	Certificate theft and forgery, private key theft, adversary acquisition of certificates

Standards and references

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support for PKI, certificate and machine identity programmes. Browse vendors in our NHI and AI products directory or contact us.

PKI and Managed PKI Buyer’s Guide: evaluation criteria, questions and proof of concept tests