Everything You Need To Know About PKI-as-a-Service (PKIaaS)

On July 21, 2024, an expired certificate inside the Bank of England’s own infrastructure knocked its CHAPS and retail settlement systems offline for 91 minutes, by the Bank’s own account. That’s not a minor IT hiccup. It’s a reminder that expired or mismanaged certificates can stop a payment system cold. PKI-as-a-service exists to prevent exactly that scenario by moving the entire certificate lifecycle, from setting up a Certificate Authority (CA) to issuing, renewing, and revoking end-entity certificates, onto a managed cloud platform.

Instead of buying hardware, standing up software, and hiring dedicated PKI staff, you get the same trust infrastructure delivered as a service, with automated procedures and lower overhead handling the certificate lifecycle for you.

Executive Summary

PKI-as-a-Service (PKIaaS) hosts an organization’s Root and Issuing Certificate Authorities in the cloud and automates certificate issuance, renewal, and revocation. Here’s what matters most for a PKI or security team evaluating it:

• PKIaaS hosts your Root and Issuing CAs in the cloud and manages the full certificate lifecycle on your behalf.
• It uses the same PKI building blocks as an on-premises deployment: public/private key pairs, digital certificates, and a chain of trust rooted in a CA.
• CA/Browser Forum Ballot SC-081v3 cut the maximum public TLS certificate lifespan to 200 days as of March 15, 2026, heading to 47 days by March 2029, making manual certificate management increasingly impractical.
• Automated enrollment protocols (ACME, SCEP, EST, WSTEP) are what let PKIaaS issue and renew certificates without a human clicking “renew” every time.
• PKIaaS trades upfront hardware and staffing costs for a subscription model, while still letting you control certificate policy and, in Encryption Consulting’s model, your own private keys.

Now that you know what PKIaaS is at a glance, let’s look at how it relates to Public Key Infrastructure itself, since PKIaaS doesn’t replace PKI concepts, it just changes who operates them.

How PKI-as-a-Service Relates to Public Key Infrastructure (PKI)

PKI issues digital certificates (such as SSL/TLS certificates) to authenticate data communication using asymmetric encryption, generating X.509 certificates from public and private key pairs. Whether you run this in-house or buy it as PKIaaS, the same four components make up the trust chain.

Public and private keys

Public and private keys carry out asymmetric encryption. When a client needs to receive sensitive information, it shares its public key with the sender to encrypt the data. Only the holder of the matching private key can decrypt and read it.

Digital certificates

The CA’s private key signs the digital certificate. This signature confirms both the identity of the certificate holder and their ownership of the associated public key.

Certificate Authority: Root CA and Issuing CA

The Certificate Authority signs and issues the digital certificate with its own private key. There are two tiers:

• Root CA: the top-level authority that establishes the foundation of trust in the PKI hierarchy. It issues and signs certificates for intermediate CAs and is typically kept offline in a highly secure environment to protect long-term trust.
• Issuing CA: processes and signs end-entity certificate requests (for example, SSL/TLS certificates), whether they arrive through a Microsoft CA proxy or another enrollment path. It operates online and handles day-to-day issuance, renewal, and revocation.

Registration Authority

The Registration Authority sits between users and the CA. It verifies the identity of anyone requesting a certificate, then forwards validated requests to the CA for issuance.

PKI-as-a-Service vs. Self-Managed (Traditional) PKI: Which Is Right for You?

The components above are the same whether you deploy PKI on-premises (self-managed) or buy it as PKIaaS. What changes is who operates them, and that difference drives cost, speed, and scalability.

Factor	PKI-as-a-Service	Self-Managed (Traditional) PKI
Deployment	Quick, managed setup with minimal infrastructure required from your organization.	Significant time, expertise, and resources needed for hardware, software, and network configuration.
Management	Certificate issuance, renewal, and revocation are handled by the service provider, reducing operational overhead.	Managed in-house, requiring dedicated personnel for ongoing certificate tasks and maintenance.
Scalability	Cloud infrastructure adjusts automatically as certificate volume grows or fluctuates.	Scaling requires additional hardware, software licenses, and configuration changes.
Cost	Subscription model eliminates hardware, software, and ongoing maintenance costs, reducing upfront investment.	Requires high upfront investment in hardware, software installation, and ongoing management.
Renewal cadence at 47-day validity	Automated issuance protocols (ACME, SCEP, EST) absorb the renewal frequency without added headcount.	Manual renewal processes break down well before certificates reach 100-day, let alone 47-day, lifespans.

PKI-as-a-Service is the stronger fit for organizations prioritizing ease of use, cost savings, and faster deployment, especially as certificate lifespans keep shrinking. Organizations with strict data residency requirements or highly specialized CA configurations may still have valid reasons to keep PKI self-managed, but that list is getting shorter as automation protocols mature.

Buyer Decision Table: Which PKI Deployment Model Fits Your Organization?

Use this table to match your organization’s constraints to a deployment model before evaluating providers.

Criterion	On-Prem PKI	SaaS PKI	PKIaaS
Dedicated PKI staff available	Required	Reduced, but still needed for policy	Not required
Certificate volume growth	Scaling requires new hardware	Scales within your cloud tenant	Scales automatically, provider-managed
Time to first certificate	Weeks to months	Days to weeks	Days
Budget model	High upfront capital investment	Cloud consumption plus internal staff time	Subscription, minimal upfront cost
Private key control	Full, in your own HSMs	Full, in your own cloud tenant	Full, in provider-hosted HSMs (in Encryption Consulting’s model)
Best fit for	Strict data residency or highly specialized CA configurations	Organizations already standardized on a cloud platform	Organizations prioritizing speed, automation, and reduced overhead

How PKI-as-a-Service Works: The Certificate Request Workflow

From the moment a device submits a certificate signing request to the moment it receives a signed certificate, a PKIaaS platform moves the request through five steps:

1. Certificate request initiation. A client requests a certificate using a protocol such as ACME, SCEP, or Intune. The request goes to the Certificate Enrollment Gateway (CEG), which builds a secure connection to the Certificate Authority Gateway (CAGW) using its own client certificate.
2. Request processing. The CAGW, hosted on a containerized system, receives the request and forwards it to the appropriate Managed CA through a secure proxy.
3. Connection to the Issuing CA. The proxy bridges the CAGW and the designated Issuing CA, with the connection secured by mutual client and server certificates.
4. Certificate issuance. The Issuing CA issues the end-entity certificate, often through Active Directory Certificate Services (AD CS).
5. Certificate delivery. The signed certificate returns through the proxy to the CAGW, which sends it to the CEG for delivery to the requesting client.

Every step in this chain is secured by mutual certificate authentication, so the entire round trip, from request to delivery, happens without a person manually approving each certificate.

Key Features of PKI-as-a-Service

PKI-as-a-Service provides a comprehensive set of capabilities for managing digital certificates and key pairs. The core features fall into four groups:

• PKI infrastructure management: centralized configuration of managed PKI, including optional Root CA separation, with the full CA lifecycle following industry best practices such as FIPS 140-3 Level 3 HSMs to secure CA private keys with high availability. NIST retires FIPS 140-2 validation certificates to Historical status on September 21, 2026, so new HSM deployments should specify FIPS 140-3.
• Certificate Authority security: Root CA keys are generated securely and transparently, with auto-enrollment protocols like SCEP, EST, and ACME plus REST APIs automating issuance and renewal.
• Policy and compliance management: certificate profiles, validity periods, and key usage constraints are defined to meet your organization’s security requirements while adhering to standards such as NIST, FIPS, and GDPR.
• Integration and automation: RESTful APIs connect PKI services to other applications and systems, with scripts and tools automating issuance and management end to end.

PKI-as-a-Service Use Cases and Supported Protocols

PKIaaS earns its value through automation, and automation runs on standardized enrollment protocols. Here’s what each one does and where it fits.

Automated Certificate Management Environment (ACME)

• Automates communication between CAs and clients requesting server certificates for a domain, defined in RFC 8555.
• Validates domain ownership through HTTP-01 (placing a file on the web server) or DNS-01 (creating a DNS record) challenges.
• Communicates over HTTPS, keeping the certificate management process secure and tamper-resistant.
• Is the protocol the Chrome Root Program has required CA applicants to support since February 2024, and the one the CA/Browser Forum’s shortened certificate lifetimes reward most directly, since it’s built for full automation with no manual renewal step.

Simple Certificate Enrollment Protocol (SCEP)

• Automates certificate enrollment for devices such as routers and switches, reducing manual effort in device-heavy environments.
• Uses PKCS#10 (Public Key Cryptography Standards) for certificate requests, standardized in RFC 8894 (2020) after decades as a de facto standard.
• Verifies the identity of the requesting device or user via a shared challenge password before issuing a certificate.
• Remains widely deployed in mobile device management (MDM) and legacy network hardware, though EST is its modern, more secure successor.

Enrollment over Secure Transport (EST)

• Defined in RFC 7030 as the modern replacement for SCEP, running over HTTPS with mutual TLS authentication.
• Both client and server authenticate each other, closing a trust gap that SCEP’s shared-password model leaves open.
• Fits enterprise PKI and IoT deployments that already run TLS infrastructure and need stronger mutual authentication than SCEP provides.

WSTEP (Windows enrollment)

• Lets a Windows enrollment client connect to a Domain Controller through the Certificate Enrollment Policy Web Service and request certificates from multiple CAs.
• Restricts certificate access to authorized devices, improving overall network security.
• Protects certificate enrollment data in transit with secure channels and encryption.

Microsoft Intune integration

• The Certificate Enrollment Gateway can receive SCEP requests with a CSR from Windows clients and forward them to Intune for validation, streamlining device management across mobile devices, desktops, and virtual endpoints.
• Cryptographic policies and algorithms stay aligned with regulatory and compliance requirements.
• Automatic revocation in Intune speeds up certificate invalidation, supporting a stronger disaster recovery plan.

Endpoint authentication (UEM/MDM)

• Verifies that certificates are issued with strong security settings, giving visibility into certificate usage and validity.
• Requires Mobile Device Management (MDM) clients to authenticate to the Certificate Enrollment Gateway with valid login credentials, with at least one username/password pair defined per client.
• Enforces granular access control and role-based permissions, a compliance requirement under NIST and FIPS 140-3, so only authorized personnel manage sensitive certificate functions.
• Issues certificates only after assessing both integrity checks and security patch levels on the requesting device.

S/MIME

• Provides end-to-end encryption of email messages.
• Separates signing and encryption functionality, allowing S/MIME certificates to deliver non-repudiation alongside confidentiality.
• Uses key history management and automated backup to keep cryptographic keys available without interruption.
• Works across Windows, macOS, iOS, and Android.

Managed PKI

• Secures Root CA infrastructure to ISO/IEC 27001 standards, protecting cryptographic assets.
• Keeps you in full control of your private keys, with complete oversight of certificates and cryptographic operations.
• Stores private keys in FIPS 140-3 Level 3 certified Hardware Security Modules (HSMs) to prevent unauthorized access or tampering.
• Verifies certificate validity and status through CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol) services.

SLA and Security Control Checklist for Evaluating a PKIaaS Provider

Before signing a PKIaaS contract, confirm the provider meets these SLA and security-control baselines:

• Published uptime SLA (99.9% or higher) for issuance, renewal, and revocation endpoints, with documented incident response times.
• Root and Issuing CA private keys generated and stored in FIPS 140-3 Level 3 validated HSMs, not general-purpose servers.
• CRL and OCSP responder availability commitments, published separately from the core issuance SLA.
• Documented key ceremony procedures and audit rights for Root CA key generation.
• A stated certificate revocation turnaround time following a reported key compromise.
• Role-based access control and multi-person authorization for sensitive CA operations.
• Clear disclosure of where certificate metadata and audit logs are stored, to confirm data residency.
• Documented disaster recovery and failover architecture at the Issuing CA layer.
• Current compliance certifications (ISO/IEC 27001, SOC 2, PCI-DSS, HIPAA, GDPR) with recent audit dates.
• Contract terms confirming private key ownership and portability if you change providers later.

HSM and Compliance Requirements for PKI-as-a-Service

A PKIaaS platform is only as trustworthy as the hardware protecting its CA private keys and the compliance framework governing its operation.

• FIPS 140-3 Level 3 HSMs: Root and Issuing CA private keys should be generated and stored in FIPS 140-3 Level 3 validated Hardware Security Modules. NIST retires FIPS 140-2 validation certificates to Historical status on September 21, 2026, so confirm any HSM your provider uses is FIPS 140-3 validated, not relying on an expiring FIPS 140-2 certificate.
• ISO/IEC 27001: the provider’s information security management system should carry current ISO/IEC 27001 certification covering the systems that host your CA infrastructure.
• HIPAA, PCI-DSS, and GDPR: if your certificates protect PHI, cardholder data, or EU personal data, confirm the provider’s PKIaaS environment is explicitly scoped into their HIPAA, PCI-DSS, or GDPR compliance program, not just the parent company’s general compliance posture.
• Key custody model: clarify upfront whether your organization or the provider holds ultimate control of the Root CA private key. Encryption Consulting’s PKIaaS model keeps that control with the customer, which not every provider offers.

Why Certificate Automation Matters Now: The 47-Day Deadline

Here’s the part most PKI explainers gloss over: the case for PKIaaS got a lot stronger in 2026, and it isn’t just about convenience anymore.

In April 2025, the CA/Browser Forum approved Ballot SC-081v3, which sets a phased reduction of the maximum public TLS certificate validity period: 200 days starting March 15, 2026 (already in effect), 100 days starting March 15, 2027, and 47 days starting March 15, 2029. That’s a drop from the old 398-day standard to renewals every 47 days, roughly eight times a year, within three years.

The operational math doesn’t work with manual renewal at that frequency, and the industry data backs that up. CyberArk’s 2025 State of Machine Identity Security Report, based on a survey of more than 1,200 security leaders, found that 72% of organizations experienced at least one certificate-related outage in the past year, and 50% reported a security incident or breach linked to compromised machine identities. Automation has also become a condition of entry for public CAs: the Chrome Root Program has required CA applicants to support at least one automated issuance and renewal solution for each certificate policy they issue since February 2024, and as of June 15, 2026 it additionally requires publicly trusted TLS certificates to carry only the server-authentication EKU, pushing any organization still using public certificates for client authentication or mTLS onto a private CA.

Our take: if your team is still renewing certificates by hand, or tracking them in a spreadsheet, the 100-day phase in March 2027 is the point where that process breaks, not the 47-day phase in 2029. Treat 2026-2027 as the window to move onto ACME, SCEP, or EST-driven automation, whether that’s through an in-house platform or a PKIaaS provider, before renewal frequency outpaces your team’s ability to keep up manually.

Why Encryption Consulting for PKI-as-a-Service?

Deploy PKI-as-a-Service in your environment

Encryption Consulting offers a flexible, high-assurance PKIaaS solution with scalable support that manages the full digital certificate lifecycle for your organization. Two areas stand out:

• Customizable and scalable solutions: a framework tailored to your organization’s security requirements, with broad CA support and the ability to scale certificate and user volume without hampering performance.
• Consistent support: strong security features aligned with HIPAA, PCI-DSS, and GDPR, plus day-to-day operational support to keep certificate policies under control.

Deployment models: on-prem, SaaS PKI, and PKIaaS

Encryption Consulting supports three deployment approaches, so you can match the model to your environment:

• On-prem PKI: Managed PKI deployed within your own infrastructure, with Root and Issuing CAs hosted on-premises.
• SaaS PKI: Certificate lifecycle management configured within your organization’s own cloud platform.
• PKIaaS: Automated certificate lifecycle management and custom Managed PKI hosted entirely in Encryption Consulting’s cloud environment, customized to your domain and security requirements.

Conclusion

PKIaaS is the cloud-hosted evolution of the same PKI trust model organizations have relied on for decades, just without the hardware, staffing, and manual renewal overhead. Every organization handling sensitive data, whether that’s Personally Identifiable Information (PII) or Protected Health Information (PHI), needs the authentication and encryption a PKI provides. PKIaaS delivers that as a managed cloud service instead of an internal infrastructure project.

With the CA/Browser Forum’s certificate lifespan reductions already underway, the timing question isn’t whether to automate certificate management, but how soon. A PKIaaS platform built on ACME, SCEP, and EST gives you that automation without adding headcount, while still letting you control certificate policy and, depending on the provider, your own private keys.

Frequently Asked Questions About PKI-as-a-Service

What is the main takeaway from this guide to PKI-as-a-Service?

PKIaaS moves Root and Issuing CA operations, HSM management, and the full certificate lifecycle onto a managed cloud platform, letting an enterprise trade the capital cost and staffing burden of self-managed PKI for a subscription that scales automatically and keeps pace with shrinking certificate validity periods.

Why does PKI-as-a-Service matter for enterprise PKI teams specifically?

Enterprise PKI teams authenticate every server, device, and service on the network, and as public TLS certificate validity drops from 398 days toward 47 days by 2029, manual issuance and renewal become operationally unsustainable at enterprise scale. PKIaaS gives these teams automated enrollment protocols (ACME, SCEP, EST) so certificate volume can grow without adding headcount.

What risks increase if PKI is handled manually instead of through PKIaaS?

Manual PKI management increases the risk of expired-certificate outages, like the Bank of England’s 91-minute CHAPS outage, missed renewals buried in spreadsheets, inconsistent key protection outside FIPS-validated HSMs, and delayed revocation after a compromise. CyberArk’s 2025 survey found risks like these already affect the majority of enterprises.

Which teams should own PKI-as-a-Service adoption and ongoing operations?

Security architecture and identity/PKI teams should own CA hierarchy design and policy decisions, while IT operations or platform engineering teams typically own day-to-day enrollment integration across Intune, DevOps pipelines, and network devices. Compliance teams need visibility into audit logging and key-custody terms, since HSM and regulatory requirements ultimately sit with them.

How does PKIaaS connect to certificate lifecycle management (CLM)?

PKIaaS is the infrastructure layer, the Root and Issuing CAs themselves, while certificate lifecycle management is the operational layer that tracks issuance, renewal, revocation, and expiry across every certificate the CA issues. Pairing a PKIaaS deployment with a CLM platform like CertSecure Manager gives full visibility from the CA down to individual certificates, which manual tracking cannot match at scale.

How should organizations measure the success of a PKIaaS deployment?

Track certificate-related outage count (target: zero), average time from CSR submission to issued certificate, the percentage of certificates issued through automated protocols versus manual request, HSM and CA audit findings per cycle, and adherence to the CA/Browser Forum’s shrinking validity windows without manual intervention. A drop in unplanned renewal incidents is the clearest success signal.

What should be audited or monitored regularly in a PKIaaS environment?

Audit CA private key custody and HSM access logs, certificate issuance and revocation logs, CRL/OCSP responder uptime, enrollment protocol authentication events (ACME challenge validation, SCEP shared secrets, EST mutual TLS), and compliance alignment against ISO/IEC 27001, HIPAA, PCI-DSS, or GDPR, depending on which apply to your organization.

How does PKIaaS affect cloud, hybrid, or multi-CA PKI environments?

PKIaaS is built to operate across cloud, hybrid, and multi-CA environments by design. The Certificate Authority Gateway routes requests to the appropriate Managed CA through a secure proxy, so an organization running multiple CAs, for example separate CAs for internal devices and public-facing TLS, gets a single automated enrollment layer instead of managing each CA’s renewal process independently.

What common mistakes should teams avoid when adopting PKI-as-a-Service?

The most common mistakes are treating PKIaaS as a lift-and-shift of existing manual processes instead of redesigning around automation, failing to confirm exactly where the provider generates and stores private keys before signing a contract, skipping FIPS 140-3 validation requirements for HSMs, and not testing failover to a redundant Issuing CA before it’s needed during an outage.

What should be refreshed quarterly in a PKI-as-a-Service program?

Review CA certificate profiles and validity periods against the current CA/Browser Forum schedule, re-validate HSM FIPS certification status, especially with FIPS 140-2 certificates moving to Historical status on September 21, 2026, refresh the inventory of enrollment protocols in use per device type, and re-confirm SLA and security-control commitments with your PKIaaS provider.