PKI as a service explained: how a managed private CA works, public vs private PKI, cloud PKI models compared, evaluation criteria and an ADCS migration plan.
PKI as a service (PKIaaS) is a model in which a provider operates your certificate authority hierarchy for you: root and issuing CAs, certificate issuance, revocation (CRL and OCSP) and lifecycle management are consumed through a console and APIs instead of being run on your own servers. The CA signing keys sit in hardware security modules (HSMs) or a key management service, held either by the provider or in a vault you control.
Most organizations run a private PKI because something inside the network needs certificates: Wi-Fi and VPN authentication, device identity, service-to-service TLS, Kubernetes workloads, code and document signing. For many of them that private PKI is still a Windows Server role installed years ago and maintained by one or two people. The pressure on it is rising from three directions at once: shorter certificate lifetimes that make manual renewal impractical, attack research that keeps finding abuse paths in Active Directory Certificate Services (AD CS), and the need to issue post-quantum certificates.
This guide explains what a managed private CA is, how public and private PKI differ, how the main deployment models compare (self-hosted, cloud-provider private CA, independent PKI as a service), which criteria matter when you choose, and a phased plan to migrate from AD CS without breaking existing trust.
A PKI has four moving parts, and PKI as a service turns each of them into something you consume rather than build:
| PKI component | What you run yourself (self-hosted) | What the service provides |
|---|---|---|
| CA hierarchy | Offline root, online issuing CAs, servers, backups, OS patching | Root, intermediate and issuing CAs created and managed through a console or API |
| Issuance | Templates, enrollment endpoints, approval scripts | Certificate profiles, enrollment protocols (ACME, EST, SCEP, CMP), approval workflows |
| Revocation | CRL publishing jobs, OCSP responders, distribution points | Hosted CRL distribution points and OCSP responders per CA |
| Lifecycle | Spreadsheets, expiry alerts, manual renewals | Inventory, renewal automation, reporting and audit trail |
The most important design question is who holds the CA private keys. In a fully managed offering, the provider generates and stores CA keys in its own HSMs or cloud KMS. In a customer-controlled model, the service runs the CA logic but signs through a key vault or HSM that you own, so the provider cannot use your root or issuing keys on its own. Both are valid; they carry different risk profiles, and regulated organizations often need the second.
"Cloud PKI", "managed PKI" and "hosted PKI" are used as synonyms for PKI as a service. "Private CA as a service" is the narrower term for the case covered here: a CA whose certificates are trusted only by systems you configure.
The difference is who trusts the root.
The Baseline Requirements are shortening public TLS certificate lifetimes in steps: a maximum of 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. The full timeline and its operational impact are covered in our 47-day TLS certificate lifetime guide.
Private certificates are not legally bound by that schedule, but the same direction applies: short-lived certificates issued automatically shrink the window in which a stolen key is useful. A private CA that cannot be automated becomes the bottleneck.
| Question | Public PKI | Private PKI |
|---|---|---|
| Who trusts the root? | Browsers and operating systems by default | Only devices you configure |
| Typical uses | Public websites, public APIs | Internal TLS, mTLS, VPN, Wi-Fi (802.1X), device and workload identity, internal signing |
| Rules | CA/Browser Forum Baseline Requirements, root program policies | Your own certificate policy |
| Algorithm choice | Limited to what the ecosystem accepts | Your choice, including post-quantum where both ends support it |
| Who can issue | A publicly trusted CA | You, or a provider operating a CA for you |
The business problem is rarely "we want a new CA". It is usually one of these:
There are four common ways to run a private CA. None is right for every organization; the table shows the trade-offs.
| Model | Examples | Who operates it | Where CA keys live | Strengths | Watch-outs |
|---|---|---|---|---|---|
| Self-hosted Windows CA | Active Directory Certificate Services (AD CS) | You | Windows key storage providers, optionally an on-premises HSM | Deep Active Directory integration, auto-enrollment via Group Policy, NDES for network devices | Server operations, template misconfiguration risk, tight coupling to AD |
| Self-hosted open source | EJBCA Community, step-ca, HashiCorp Vault PKI secrets engine | You | Your servers or HSM, depending on configuration | Full control, broad protocol support in some products, no per-certificate fees | You own availability, upgrades, HSM integration, revocation infrastructure and audit |
| Cloud-provider private CA | AWS Private CA, Google Cloud Certificate Authority Service, Microsoft Cloud PKI for Intune | Cloud provider | Provider-managed | No servers to run, native integration with that provider's services | Scoped to one ecosystem; feature sets and algorithms differ per service |
| Independent PKI as a service | Specialist PKI vendors | Vendor, with options for customer-held keys | Vendor HSM or a customer-controlled vault/HSM, depending on the offering | Multi-cloud and on-premises reach, multiple enrollment protocols, central policy | Check key custody, protocol coverage and exit options carefully |
A few verified details help narrow the choice:
Use the criteria below as a scoring sheet. Ask each provider to show, not tell: a demo of the enrollment flow and a sample audit export are worth more than a feature list.
| Criterion | What to ask | Why it matters |
|---|---|---|
| CA key custody | Where are root and issuing keys generated and stored? HSM, cloud KMS, MPC? Can you bring your own HSM or vault? Can the provider sign without you? | Determines who can issue in your name and how you answer auditors |
| Hierarchy options | Root, intermediate and issuing CAs? Can you import an existing (external) CA? Cascade revocation? | Lets you mirror your current hierarchy and migrate gradually |
| Enrollment protocols | ACME (RFC 8555), EST (RFC 7030), SCEP (RFC 8894), CMP (RFC 4210, profiled by RFC 9483), REST API | Each protocol covers a different estate: servers and Kubernetes (ACME), IoT and network gear (EST, SCEP, CMP), MDM (SCEP) |
| Revocation | Per-CA CRL distribution points and OCSP (RFC 6960) responder? Revocation reasons per RFC 5280? Update frequency? | Relying parties must be able to check status reliably |
| PQC readiness | ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) CAs? Hybrid or composite chains? Are PQC signing keys held in an HSM or vault? | Lets you pilot post-quantum chains while keeping classical interoperability |
| Integrations | Kubernetes cert-manager, MDM, load balancers, network devices, deployment of issued certificates to endpoints | Issuance is only half the job; certificates must land where they are used |
| Approval and policy | CSR approval workflow, profiles, role-based access, tenant isolation | Prevents the "anyone can request anything" pattern behind many AD CS findings |
| Audit | Is every issuance, revocation and admin action logged? Is the log tamper-evident and exportable? | Evidence for DORA, NIS2 and internal audit |
| Migration from AD CS | Can the service run in parallel with AD CS? Can it import your existing CA or chain to your root? | Avoids a risky cut-over |
| Exit plan | Can you export certificates, CA certificates and audit logs? What happens to keys at contract end? | A CA is long-lived; vendor lock-in is a real risk |
On post-quantum, keep expectations grounded: not every browser, server or device understands ML-DSA or SLH-DSA yet. The practical approach is to use pure PQC chains where you control both ends and hybrid chains where classical relying parties must still validate. Our ML-DSA certificates guide covers sizes, compatibility and test plans.
A CA migration fails when trust breaks: devices stop trusting a new chain, or a revoked certificate is still accepted. A parallel-hierarchy approach avoids both.
DuoKey certificate management provides a private PKI managed from DuoKey Cockpit, the same console and API used for keys and vaults. It is designed for internal trust (servers, workloads, devices and users you control), not for publicly trusted TLS certificates. According to the DuoKey documentation:
CA hierarchy and algorithms
Key custody
Issuance and revocation
Enrollment protocols
A cert-manager ClusterIssuer points at the CA's ACME directory:
# ClusterIssuer pointing cert-manager at a DuoKey CA over ACME
server: https://{cockpit-url}/api/pki/acme/{ca-id}/directory
cert-manager renews by default at two-thirds of the certificate lifetime; you can change this with renewBefore.
The same private CA can back document signing: DuoKey PDF Sign is a server-side PDF signing API in Cockpit where the certificate never leaves the tenant keystore. To find which certificates and algorithms you have today before migrating, start with cryptographic posture management. For hosting options, pricing or anything not listed here, contact DuoKey.
Q: What is PKI as a service?
PKI as a service is a delivery model where a provider operates your certificate authority hierarchy, certificate issuance, revocation and lifecycle management, and you consume them through a console and APIs. CA keys are held in HSMs or a KMS, either by the provider or in a vault you control. It replaces the servers, scripts and manual processes of a self-hosted CA.
Q: What is the difference between public and private PKI?
A public PKI's root is pre-installed in browsers and operating systems, so anyone trusts its certificates; public TLS CAs must follow the CA/Browser Forum Baseline Requirements. A private PKI's root is trusted only by devices you configure, and you set your own certificate policy. Use public certificates for internet-facing services and private ones for internal systems, devices and workloads.
Q: What is private CA as a service?
It is PKI as a service limited to a private certificate authority: the provider runs root and issuing CAs that only your systems trust. Typical uses are internal TLS, mutual TLS between services, VPN and Wi-Fi authentication, Kubernetes workloads and device identity.
Q: Can I replace ADCS with PKI as a service?
Yes, for most use cases, provided you migrate in parallel rather than with a single cut-over. Build a new hierarchy (or chain a new issuing CA to your existing root), distribute trust, move consumers protocol by protocol (ACME, EST, SCEP, CMP) and keep AD CS CRLs published until its last certificate expires. Check AD-specific dependencies such as smart card logon and Group Policy auto-enrollment early.
Q: Is PKI as a service ready for post-quantum certificates?
Some services can already create ML-DSA (FIPS 204) CAs, and a few also support SLH-DSA (FIPS 205) and hybrid composite chains; support varies by provider, so ask. Not every client understands these algorithms yet, so use pure PQC chains where you control both ends and hybrid chains where classical systems must still validate.
Q: Who holds the CA private keys in a managed PKI?
It depends on the offering. Some providers generate and keep CA keys in their own HSMs or KMS. Others sign through a vault or HSM you control, which means the provider cannot issue in your name on its own. Ask for this in writing before you choose.
Q: How do certificates get renewed automatically with a private CA?
Through enrollment protocols. Servers and Kubernetes clusters use ACME clients such as certbot or cert-manager; network devices and IoT use EST, SCEP or CMP; managed endpoints use MDM SCEP profiles. The client renews before expiry without a ticket or manual step.
Q: What is the difference between cloud PKI and managed PKI?
The terms are mostly used interchangeably. "Cloud PKI" stresses that the CA runs as a cloud service; "managed PKI" stresses that someone else operates it. What matters is the specifics: key custody, protocols, revocation, PQC support and audit.
PKI as a service removes server operations from your CA, but the decision that matters most is who holds the CA keys and whether every consumer can enroll automatically. Before you sign:
Written by
DuoKey Team
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
