PKI as a service explained: how a managed private CA works, providers compared, CA key custody, post-quantum readiness and an AD CS 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, what PKI as a service changes compared with an on-premises PKI, how public and private PKI differ, how the main deployment models and providers compare, which criteria matter when you choose, how to run a post-quantum PKI as a service, 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 choice is less about technology than about who carries the operational work and who controls the keys.
| Topic | On-premises PKI | PKI as a service |
|---|---|---|
| Infrastructure | CA servers, HSMs, databases, backups and patching run by your team | Run by the provider; you configure CAs, profiles and policies |
| Availability of CRL and OCSP | Your web servers and responders, your uptime | Hosted distribution points and responders |
| Enrollment protocols | Whatever your CA product supports, often only native Windows enrollment | Usually ACME, EST, SCEP and a REST API; check CMP if you run industrial or telecom PKI |
| CA key custody | Your HSM, or a software key store | Provider HSM or KMS, or a vault or HSM you control, depending on the offering |
| Skills | PKI specialists in-house to design, run and recover the CA | Policy and integration skills in-house; CA operations delegated |
| Cost model | Hardware, licences and staff time, mostly fixed | Subscription; models vary (per CA, per certificate volume, pay as you go) |
| Change speed | New CA or profile is a project | New CA or profile is a configuration change |
The benefits most teams look for are the ones in the right-hand column: no CA servers to patch, hosted revocation services, standard enrollment protocols for automation, and a faster path to new algorithms. What stays your responsibility in every model is the certificate policy, the list of relying parties that trust your root, and the decision on who may hold the CA keys.
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:
The PKI as a service market splits into specialist PKI vendors, publicly trusted CAs that also sell private CAs, and cloud providers. The table summarises what each vendor states in its own public material (reviewed November 2026); confirm details such as regions, protocols and algorithms with the vendor before you shortlist.
| Provider | Offering | Delivery and hosting (as stated by the vendor) | Points to check |
|---|---|---|---|
| DigiCert | DigiCert Private CA, part of DigiCert ONE | "Run PKI in DigiCert cloud, on-prem, or hybrid environments"; FIPS 140-2 Level 3 HSMs | US company; public and private certificates from one vendor |
| Keyfactor | EJBCA SaaS | Hosted EJBCA Enterprise through the AWS and Azure marketplaces, in US, EU and AP regions; dedicated offline root CA; ACME, SCEP, CMP, Microsoft autoenrollment and REST | US company; HSM or KMS options depend on the cloud chosen |
| Sectigo | Sectigo Certificate Manager | Cloud-based certificate lifecycle platform covering public and private certificates | Publicly trusted CA; check private CA options and protocols |
| Entrust | Entrust PKI as a Service | Managed PKI from a publicly trusted CA | Ask for hosting regions, key custody and protocol coverage |
| AWS, Google Cloud, Microsoft | AWS Private CA, Google Cloud CAS, Microsoft Cloud PKI for Intune | Provider-managed, within each cloud (see the list above) | Scoped to one ecosystem |
| DuoKey | PKI and certificate management in DuoKey Cockpit | Operated by DuoKey (Swiss company, Swiss law) or on your premises; CA keys in an HSM, cloud KMS or MPC cluster you choose | Private PKI only, not a publicly trusted CA; details below |
For a feature-by-feature view with a source for every cell, see the comparisons of DuoKey with Keyfactor, DigiCert and Microsoft AD CS, or the broader PKI solution buyer's guide.
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 |
A post-quantum PKI is a certificate hierarchy whose CAs and certificates are signed with quantum-resistant algorithms, ML-DSA (FIPS 204) or SLH-DSA (FIPS 205), or with hybrid composites that pair one of them with RSA or ECDSA. A PKI service is a practical place to build one, because creating a new root and issuing CAs becomes a configuration step rather than a hardware project.
What to check with a provider:
Keep expectations grounded: not every browser, server or device understands ML-DSA or SLH-DSA yet, and no CA/Browser Forum ballot allows ML-DSA in publicly trusted TLS certificates. Use pure PQC chains where you control both ends and hybrid chains where classical relying parties must still validate. Our guide to post-quantum PKI and ML-DSA certificates covers sizes, standards, compatibility and a step-by-step migration path.
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 available as a service operated by DuoKey (a Swiss company, under Swiss law) or installed on your premises. 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, governance 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: Which companies offer PKI as a service?
Specialist PKI vendors such as Keyfactor (EJBCA SaaS) and DuoKey, publicly trusted CAs such as DigiCert, Sectigo and Entrust, and cloud providers with AWS Private CA, Google Cloud Certificate Authority Service and Microsoft Cloud PKI for Intune. They differ most on CA key custody, enrollment protocols, hosting jurisdiction and post-quantum support.
Q: What are the benefits of PKI as a service?
No CA servers, HSMs or revocation infrastructure to run, standard enrollment protocols for automated renewal, faster creation of new CAs and profiles (including post-quantum ones), and a central audit trail. The trade-off is dependence on the provider, so check key custody and exit options.
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.
