PKIaaS Buyer’s Guide: 20 Questions to Ask Before Selecting a Vendor

Selecting a PKI as a Service provider is not the same as selecting a SaaS tool. The provider will hold or operate the cryptographic root of trust that underpins every certificate your organization issues: authentication, encryption, code signing, device identity, and service-to-service communication. If that root is compromised, misconfigured, or locked behind a vendor relationship you cannot exit, the consequences run deep and are expensive to reverse.

Most PKIaaS solution pages describe what the service does. They say less about the commitments, the constraints, and the fine print that determine whether the service can actually sustain an enterprise CA program through compliance audits, staff changes, regulatory updates, and a post-quantum migration. That is the gap this guide addresses.

The 20 questions below are organized by category. Each one identifies what to ask, what a strong answer looks like, and what an evasive or incomplete answer signals. Use this as a structured evaluation framework. Take it into every vendor conversation and score against it before you sign anything.

Quick Answer: The Questions That Matter Most

If you only ask five questions before selecting a PKIaaS vendor, make them: (1) who holds the root CA key and how do you recover it without the provider; (2) what FIPS HSM validation level are your keys stored at; (3) what compliance certifications cover the infrastructure and operations; (4) what enrollment protocols and APIs are included; and (5) what happens to your PKI when you leave. Every other question in this guide layers depth on top of those five.

Key Takeaways

• Key custody is the first and most important question. Any provider that cannot give you a documented, independently verifiable path to recover your root CA materials without their cooperation is not running a PKI service. They are renting you a certificate machine with no exit.
• HSM validation level, tenancy model, and audit logging depth are the three infrastructure questions that separate enterprise-grade PKIaaS from basic managed CA offerings. Ask for the NIST CMVP certificate number, confirm dedicated partitions, and request a sample audit log before committing.
• Protocol support, specifically ACME, EST, SCEP, REST API, and WSTEP, determines whether the service can actually automate certificate lifecycle across your environment. The CA/Browser Forum’s 47-day certificate validity schedule (effective March 2029 under Ballot SC-081v3) makes ACME automation a functional requirement, not a nice-to-have.
• PQC readiness is a procurement question now, not an upgrade conversation for later. NIST finalized FIPS 203, 204, and 205 in August 2024. NIST IR 8547 guidance points toward deprecating RSA and ECC around 2030. Providers that cannot articulate a migration path for your CA hierarchy to ML-DSA (FIPS 204) are not positioned to sustain your PKI program through the transition window.
• Exit rights, data portability, and migration support terms should be in the contract before you sign. A provider with nothing to hide will specify these terms clearly. A provider that deflects this question deserves careful scrutiny.

Category 1: Key Custody and Root CA Control

Question 1: Who physically holds the root CA private key, and under what conditions can the provider access it?

This is the foundational question. In a PKIaaS service, the provider operates the infrastructure that holds your CA keys. The critical distinction is between a provider that operates HSMs you cannot independently access (highest operational risk) and one that operates with documented controls restricting their own access to your keys (standard for well-run PKIaaS).

A strong answer specifies: the keys are stored in FIPS-validated HSMs in dedicated partitions for your organization; provider staff access to your partition is restricted by role-based controls, requires dual authorization, and is logged with full audit trails; and provider staff cannot issue certificates under your hierarchy without your authorization workflows being triggered. A weak answer is a general statement that keys are “secure” or “encrypted” without addressing the access control model.

Question 2: Does the service include customer-controlled key escrow, and how do I recover my root CA materials independently?

Customer-controlled key escrow means that a copy of your root CA cryptographic materials is held by a trusted third party or is recoverable by you under documented procedures that do not require provider cooperation. This is your exit right and your protection against provider insolvency, acquisition, or contract dispute.

Ask the provider to walk you through the specific recovery procedure in writing. How does the escrow work? Who is the escrow party? What format are the materials in? What is the turnaround time? Has this procedure been tested? A provider that cannot answer all of these or that describes recovery as a support ticket to them is not offering true key escrow.

Question 3: Was the root CA established with a documented, witnessed, and logged key ceremony?

A root CA ceremony is the formal, audited procedure for generating the CA root key pair, signing the root certificate, and establishing the chain of trust. A proper ceremony requires a formal script, multiple independent witnesses, full HSM audit logging, and a documented evidence package that becomes part of the CP/CPS record.

Ask to see or review the ceremony procedure. Ask whether a ceremony evidence package exists for your specific CA hierarchy and whether it is available to your auditors. A provider running a PKIaaS without a documented root CA ceremony is operating a certificate machine, not a PKI. This directly affects whether your certificates will survive a compliance audit.

Category 2: HSM Infrastructure and Tenancy Model

Question 4: What FIPS validation level do the HSMs meet, and can you provide the NIST CMVP certificate number?

FIPS 140-2 Level 3 is the minimum acceptable standard for storing CA private keys. FIPS 140-3 Level 3 is the current standard as NIST completes the transition from 140-2 to 140-3. Level 3 requires physical tamper resistance that renders the module inoperable or zeroizes keys if the enclosure is breached, a hard requirement for CA key storage.

Asking for the NIST CMVP certificate number lets you verify the claim directly against NIST’s public database. A provider that references FIPS compliance without being able to give you the certificate number, the specific HSM model validated, and the validation date is citing marketing language, not a verified technical control.

Question 5: Are my CA keys stored in dedicated HSM partitions, or shared with other customers?

Multi-tenant HSM deployments use partitioned keys within a shared appliance. Dedicated partitions for each customer are standard in well-designed PKIaaS services; they ensure that a security incident, misconfiguration, or operational failure affecting another customer’s partition cannot affect yours.

Some providers use entirely separate physical HSMs per customer. Others use partitioned virtual HSMs within a shared appliance. Both can be acceptable, but the architecture should be explicit and documented. Also ask what happens if the HSM hardware fails: is there a hot standby, and what is the failover procedure for an active issuing CA?

Question 6: Where are the HSMs physically located, and does that meet my data sovereignty requirements?

Data sovereignty matters for organizations subject to GDPR, FedRAMP, CMMC, or jurisdiction-specific data residency laws that require CA keys to remain within specific geographic boundaries or to be operated by nationals of specific countries. Some PKIaaS providers operate globally distributed infrastructure; others offer region-specific deployments.

Ask for the specific data center locations, the countries in which CA keys are stored, and whether the provider can commit contractually to keeping your keys within a defined jurisdiction. If your regulatory environment includes data residency requirements, get this in writing before any other conversation proceeds.

Category 3: Compliance Certifications and CP/CPS

Question 7: What compliance certifications does the service hold, and can I see current copies?

The minimum certification baseline for an enterprise PKIaaS service is SOC 2 Type II (not Type I, which covers design only, not operating effectiveness), FIPS 140-2 or 140-3 Level 3 HSM validation, and ISO/IEC 27001:2022. For regulated industries, ask specifically whether the provider’s certification scope covers CMMC Level 2, FedRAMP Moderate, HIPAA, PCI DSS, DORA Article 9, or NIS2 as applicable.

Ask to receive current copies of each certification under NDA. A SOC 2 Type II report covers a specific audit period. Verify that the most recent report covers the last 12 months and that the infrastructure scope matches what you are buying. A provider with outdated or narrowly scoped certifications may still claim compliance; the report scope tells you what is actually covered.

Question 8: Does the service include CP/CPS development for my organization, or is it a generic provider document?

A Certificate Policy (CP) defines what your PKI is authorized to issue and under what conditions. The Certification Practices Statement (CPS) defines how the provider implements those requirements operationally. Together they are the governance and audit backbone of your PKI program. Without a CP/CPS that reflects your specific certificate types, your regulatory requirements, and your organizational policies, your PKI cannot be audited to a recognized standard.

Ask whether CP/CPS development is included in the engagement or priced separately. Ask whether it is customized to your organization or is a generic provider-level document that you are expected to adopt. Ask who owns the CP/CPS and who is responsible for maintaining it when your certificate profiles, regulatory requirements, or CA hierarchy changes. Encryption Consulting includes CP/CPS development and maintenance as part of its PKIaaS service.

Question 9: What audit logs does the service generate, and can I access them independently?

Enterprise PKI audit logs must capture every certificate issuance, renewal, and revocation event; every administrative action on the CA configuration; every HSM operation; and every access event by provider staff. These logs are required for SOC 2, CMMC, FedRAMP, and most other compliance frameworks, and they are evidence you need if an audit finding or a certificate incident requires investigation.

Ask whether you can access your audit logs independently through a dashboard or API export, or whether you must request them as support tickets. Ask what the log retention period is and whether logs can be forwarded to your SIEM in real time. A provider that makes audit log access a support process rather than a self-service capability is creating compliance friction at exactly the wrong moment.

Category 4: Enrollment Protocols, APIs, and Integration

Question 10: Which enrollment protocols are supported, and are they all included in the base service?

The enrollment protocols supported determine whether the service can reach every certificate consumer in your environment. The relevant protocols are ACME (RFC 8555, standard for web servers and automated TLS), EST (RFC 7030, for network devices and IoT), SCEP (for MDM-managed devices and legacy infrastructure), REST API (for DevOps and CI/CD pipelines), WSTEP (for Windows Active Directory environments), and CMP (RFC 4210, for industrial and IoT applications).

The CA/Browser Forum’s Ballot SC-081v3 (approved April 2025) reduces maximum public TLS certificate validity to 47 days by March 15, 2029. At that renewal frequency, ACME automation is not optional. It is the only operationally sustainable path for a TLS certificate estate of any meaningful size. Confirm that ACME support is production-ready, not roadmap, and that it supports External Account Binding (EAB) for enterprise authentication to the ACME server.

Question 11: Which MDM and DevOps integrations are native versus requiring custom connector work?

Enterprise environments typically include MDM platforms (Microsoft Intune, Jamf, VMware Workspace ONE, Ivanti) for device certificate enrollment, and DevOps platforms (Jenkins, GitHub Actions, HashiCorp Vault, Ansible) for automated certificate provisioning in pipelines. The difference between native integration and custom connector work is measured in weeks of engineering effort and ongoing maintenance burden.

For each platform in your environment, ask whether the integration is documented, tested, and supported by the provider, or whether you will be building and maintaining it yourself using the REST API. Ask for the specific documentation for each integration you need. Some providers offer deep MDM integration from day one; others treat everything beyond ACME as a customer-led integration effort.

Question 12: What REST API does the service expose, and what operations are available through it?

A REST API for certificate operations is the integration surface for DevOps workflows, CI/CD pipelines, custom applications, and any certificate consumer that does not use a standard enrollment protocol. Ask for the API reference documentation before purchase. Key capabilities to confirm: certificate issuance and renewal, revocation, CA hierarchy management, certificate profile management, and audit log export. Also confirm API authentication mechanisms (OAuth 2.0, API keys, mutual TLS) and rate limits that could affect high-volume automated workflows.

Question 13: Does the service include certificate lifecycle management, or is that a separate product?

The CA issues certificates. CLM tracks where those certificates are deployed, monitors expiration, triggers automated renewal, enforces policy, and provides inventory visibility across the certificate estate. These are functionally distinct, and many PKIaaS services include the CA layer but treat CLM as a separately priced module or a separate product entirely.

At 47-day certificate validity by March 2029, a certificate estate of 1,000 TLS certificates generates more than 8,000 renewal events per year. That volume is unmanageable without CLM automation. Confirm whether CLM is included, what the certificate volume limit is, and which CA sources the CLM layer can manage: your own, the provider’s, and third-party CAs. Encryption Consulting’s CertSecure Manager provides CA-agnostic CLM that integrates with PKIaaS deployments, self-managed CAs, and public CAs in a single inventory and automation layer.

Category 5: CA Hierarchy, Customization, and Multi-Tenancy

Question 14: What CA hierarchy configurations does the service support?

Enterprise PKI requirements vary significantly. A two-tier hierarchy (offline root CA, online issuing CA) is standard for many deployments. Three-tier hierarchies (offline root, policy CA, issuing CA) are common in regulated environments and large organizations that need policy separation between issuing contexts. Some organizations also need cross-certified hierarchies or the ability to subordinate an external root CA.

Ask whether the service supports the CA hierarchy your specific requirements need, not just the most common configuration. Ask whether issuing CAs are single-purpose (one CA per certificate type or department) or general-purpose. Ask whether you can create and manage multiple issuing CAs under the same root without pricing them separately. The Entrust PKIaaS documentation, for instance, distinguishes root, intermediate, issuing, and external CA types with separate profiles for each. This is the kind of hierarchy flexibility that matters in practice.

Question 15: Is my PKI environment single-tenant or does it share infrastructure with other customers?

This question covers two related concerns: blast radius and compliance evidence. If your CA environment shares a multi-tenant platform with other customers, a security incident, misconfiguration, or revocation event affecting another tenant could have operational or reputational impact on your environment. For some compliance frameworks, multi-tenancy at the application layer is acceptable; for others (particularly defense-related requirements), logical isolation is not sufficient.

Ask the provider to describe the tenancy model at each layer: application, HSM, network, and data. Confirm what the isolation boundary is and what the blast radius would be if another tenant’s environment had a certificate compromise requiring mass revocation. The answer will determine whether the architecture is compatible with your compliance and risk requirements.

Category 6: High Availability and Disaster Recovery

Question 16: What is the service’s HA architecture, and what is the contractual SLA?

A CA outage means new certificate requests fail, OCSP responders may become unreachable triggering certificate validation failures across your environment, and CRL publishing may stall. These cascading effects can cause authentication failures enterprise-wide within minutes of a CA going offline. The availability SLA for the CA and OCSP infrastructure should be contractually committed and include clear remediation terms for SLA breaches.

Ask for the specific SLA percentage (99.9% minimum, with 99.99% standard for enterprise-grade services), how availability is calculated (does scheduled maintenance count as downtime), and what the compensation model is for SLA breaches. Also ask about OCSP and CRL infrastructure availability separately. These are often not included in the headline CA SLA even though they are critical to certificate trust validation.

Question 17: What is the disaster recovery procedure, what is the RTO, and has it been tested?

A documented and tested DR procedure is required evidence for SOC 2, CMMC, FedRAMP, and most enterprise security frameworks. An untested DR plan is not a DR plan; it is a statement of intent that has never been validated against reality.

Ask for the specific DR recovery time objective (RTO) for the CA service, the geographic distribution of backup infrastructure, and whether DR testing has been conducted in the last 12 months. Ask for evidence of the most recent DR test that you can share with your auditors. A provider that cannot produce DR test evidence should be treated as a provider without a functioning DR program, regardless of what their documentation states.

Category 7: Post-Quantum Cryptography Readiness

Question 18: Which NIST post-quantum algorithms does the platform support today, and what is the migration roadmap?

NIST finalized three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a stateless hash-based signature scheme). NIST IR 8547 guidance points toward deprecating RSA and ECC around 2030, with full disallowance by 2035. For PKI, the most operationally significant algorithm is ML-DSA (FIPS 204), which would be used for CA signing operations and end-entity certificate signatures.

Ask which of these algorithms the platform supports today for certificate issuance. Ask whether the CA hierarchy itself can be migrated to ML-DSA without a full rebuild. Ask whether the HSMs in use have firmware support for NIST PQC algorithms and whether hardware replacement will be required. Ask whether PQC migration will be included in the subscription at the time it is needed or priced as a separate upgrade. A provider with no PQC roadmap cannot sustain your PKI program through the transition window that is now underway.

For organizations that want to assess their current PKI’s quantum exposure now, Encryption Consulting’s PQC Readiness service and PQC Center of Excellence provide structured assessments and migration planning regardless of which PKIaaS provider you use.

Category 8: Support, Migration, and Exit Rights

Question 19: What does support cover, what are the response time commitments, and how are incidents handled?

PKI incidents do not wait for business hours. A CA certificate expiry that causes an authentication outage at 2 AM on a weekend is still a high-severity incident requiring an immediate response. The support model for a PKIaaS service must include 24/7 coverage for production incidents, not just business-hours coverage with an after-hours emergency line.

Ask for the specific support tiers, the response time SLAs for each severity level (P1 through P4), and what constitutes a P1 incident in the provider’s definition. Ask whether PKI-specialist engineers are available for incident response or whether the support tier routes to a general helpdesk. Ask for examples of incident response procedures for specific scenarios: a compromised issuing CA, a failed CRL update, an OCSP responder outage. Ask whether PKI advisory support (for architecture questions, compliance questions, and root CA ceremony planning) is included or billed separately.

Question 20: What are the exit terms: what can I take with me, in what format, and with what migration support?

Exit terms are the clearest test of whether a PKIaaS provider is confident in their service or relies on switching cost as a retention mechanism. A provider with a strong service defines exit terms clearly and does not view them as a threat. A provider that deflects this question or buries exit terms in unfavorable contract language is telling you something important about how they expect the relationship to go.

The specific terms to confirm before signing: what cryptographic materials are exportable (root CA key, issuing CA key, CA certificates, CRL signing keys); in what format and under what conditions; what happens to issued certificates that are still valid at contract termination (they remain valid until their natural expiry in most deployments, but confirm this); what the data retention period is after termination; and whether there is a migration support period and what it covers. For organizations moving from a self-managed PKI to PKIaaS, also ask about migration support for existing on-premises enrollment workflows and legacy protocol migration. Some providers document this explicitly.

Encryption Consulting’s PKI as a Service includes customer-controlled key escrow, documented exit procedures, and migration support as part of the engagement. We also provide independent advisory engagements to help organizations evaluate and migrate between PKIaaS providers. See our PKI Services for the full scope.

Scoring Your Evaluation

Use the table below to score each vendor across the 20 questions. For each question, score 2 (strong answer, documented and verifiable), 1 (partial answer, some evidence but gaps), or 0 (no answer, deflected, or cannot be confirmed). A total score below 28 out of 40 should prompt a serious reconsideration. Any score of 0 on Questions 1, 2, 7, or 20 is a disqualifying finding regardless of the total.

Category	Question	Disqualifying if 0?
Key Custody	Q1: Who holds the root CA key and under what access controls?	Yes
Key Custody	Q2: Customer-controlled key escrow and independent recovery path	Yes
Key Custody	Q3: Documented, witnessed, logged root CA ceremony	No
HSM Infrastructure	Q4: FIPS validation level and NIST CMVP certificate number	No
HSM Infrastructure	Q5: Dedicated HSM partitions vs. shared tenancy	No
HSM Infrastructure	Q6: Physical HSM location and data sovereignty coverage	Depends on regulatory requirements
Compliance	Q7: Compliance certifications with current copies available	Yes
Compliance	Q8: CP/CPS included and customized to your organization	No
Compliance	Q9: Audit log access, retention, and SIEM integration	No
Protocols	Q10: Enrollment protocol coverage (ACME, EST, SCEP, REST, WSTEP)	No
Protocols	Q11: Native MDM and DevOps integrations vs. custom connector work	No
Protocols	Q12: REST API capabilities and authentication model	No
Protocols	Q13: CLM included or separate product	No
CA Hierarchy	Q14: CA hierarchy configurations supported	No
CA Hierarchy	Q15: Single-tenant vs. multi-tenant isolation model	Depends on requirements
HA and DR	Q16: HA architecture and contractual SLA	No
HA and DR	Q17: DR procedure, RTO, and evidence of testing	No
PQC Readiness	Q18: NIST PQC algorithm support and migration roadmap	No
Support and Exit	Q19: 24/7 support coverage, response SLAs, and PKI specialist access	No
Support and Exit	Q20: Exit terms, data portability, and migration support	Yes

How Encryption Consulting Can Help

Encryption Consulting is a vendor-neutral PKI and applied cryptography firm. We help organizations evaluate PKIaaS providers against this checklist, negotiate contract terms for the areas where gaps are found, and select the model that fits their specific compliance requirements, technical environment, and operational posture. We also operate our own PKIaaS service for organizations where the evaluation points toward a managed engagement.

• PKIaaS Vendor Evaluation: Encryption Consulting can facilitate the 20-question evaluation framework with your team, run technical due diligence on shortlisted providers, and produce a scored comparison with documented findings. This is part of our PKI Services advisory scope. Contact us at Encryption Consulting to discuss an evaluation engagement.
• PKI as a Service: Encryption Consulting’s own PKIaaS offering provides FIPS 140-3 HSM-backed CA keys in dedicated partitions, always-offline root CA with documented ceremony, CP/CPS development and maintenance, ACME/EST/SCEP/REST/WSTEP enrollment support, 24/7 monitoring, customer-controlled key escrow, and documented exit procedures. Every question in this guide has a verifiable answer for our service.
• PKI Assessment Service: For organizations with an existing PKIaaS contract that want to verify their current provider meets these standards, Encryption Consulting’s PKI Assessment Service evaluates your current environment against the same criteria and produces a gap analysis with prioritized remediation guidance.
• CertSecure Manager: For organizations whose PKIaaS service does not include CLM, or that need CA-agnostic certificate visibility across multiple CA sources, Encryption Consulting’s CertSecure Manager provides unified discovery, automated renewal, and policy enforcement regardless of which CA issued the certificate.
• PQC Readiness: For organizations evaluating vendor PQC roadmaps against their own migration timeline, Encryption Consulting’s PQC Readiness service and PQC Center of Excellence assess your current quantum exposure and produce a migration roadmap aligned to the NIST IR 8547 timeline.

Conclusion

PKIaaS vendor selection is one of the few infrastructure decisions where the wrong answer creates a problem you cannot quickly undo. Migrating off a PKIaaS provider means re-establishing a CA hierarchy, re-issuing certificates to trust the new chain, and managing the transition across every system that validates certificates from the old hierarchy. That is a multi-month program, not a configuration change.

The 20 questions in this guide are designed to surface the gaps and commitments that marketing pages obscure. Key custody terms, HSM validation evidence, CP/CPS ownership, audit log access, PQC roadmap specificity, and exit rights are not secondary concerns to address after signing. They are the primary evaluation criteria for any organization treating PKIaaS as a long-term program rather than a short-term convenience.

Take this checklist into every vendor conversation. Ask for written answers to Questions 1, 2, 7, and 20 before any other discussion proceeds. Score the field before you make a shortlist. The providers who answer these questions completely and without deflection are the ones worth your time.

If you want support running this evaluation, reach out to Encryption Consulting. We have run this process for organizations across regulated industries and can help you get to a documented, defensible decision faster than running it internally.

This post is reviewed on a six-month cadence and immediately when NIST updates FIPS 140-3 transition guidance, the CA/Browser Forum updates the Ballot SC-081v3 schedule, or NIST IR 8547 PQC deprecation timelines are revised.

Frequently Asked Questions

What is the most important question to ask a PKIaaS vendor?

Key custody is the single most consequential question. Specifically: who holds the root CA private key, where does it live physically, under what conditions can the vendor access it, and how do you recover it independently if the relationship ends? A PKIaaS provider that cannot answer all four parts of that question clearly and in writing should not advance to due diligence.

What HSM standard should a PKIaaS vendor meet?

PKIaaS vendors should use hardware security modules validated to FIPS 140-2 Level 3 at minimum. FIPS 140-3 Level 3 is the current standard as NIST transitions fully from 140-2 to 140-3. Ask for the NIST CMVP validation certificate number for the specific HSM model in use and confirm it is current. Also confirm whether your CA keys live in dedicated HSM partitions or are shared with other customers.

What enrollment protocols should a PKIaaS service support?

At minimum: ACME (for automated TLS certificate renewal and the CA/Browser Forum 47-day schedule compliance), EST (for network devices and IoT), SCEP (for MDM and legacy device environments), and a REST API for DevOps and CI/CD integration. WSTEP support matters for Windows Active Directory environments. If your environment includes Intune, Jamf, Workspace ONE, or similar MDM platforms, confirm native integration with those systems before contract.

Does a PKIaaS vendor need to provide a CP/CPS?

Yes. A Certificate Policy (CP) and Certification Practices Statement (CPS) are required for any PKIaaS deployment operated to an auditable standard. The CP defines what certificates the PKI is authorized to issue and under what conditions. The CPS describes how the provider implements those requirements operationally, including HSM controls, key ceremony procedures, access controls, audit logging, and revocation practices. Ask whether CP/CPS development is included in the engagement or billed separately, and whether the document is customized to your organization or is a generic provider document.

What compliance certifications should a PKIaaS vendor hold?

At minimum: SOC 2 Type II (not Type I) for infrastructure and operations, FIPS 140-2 or 140-3 Level 3 validation for HSMs, and ISO/IEC 27001:2022 for information security management. For regulated industries, verify whether the provider’s framework covers CMMC, FedRAMP, HIPAA, PCI DSS, DORA, or NIS2 as applicable to your requirements. Ask for current copies of each certification under NDA before committing.

What happens to my PKI if I want to leave a PKIaaS provider?

Before signing, confirm: what cryptographic materials are exportable, in what format, and under what conditions; whether you can re-establish your PKI hierarchy independently without provider cooperation; what the data retention period is after contract termination; and whether there is a migration support period. A provider that cannot define a clear, documented exit path is not a provider you should trust with your root CA.

How does PKIaaS support the CA/Browser Forum 47-day certificate schedule?

The CA/Browser Forum’s Ballot SC-081v3 (approved April 2025) reduces maximum public TLS certificate validity to 200 days from March 15, 2026; 100 days from March 15, 2027; and 47 days from March 15, 2029. At 47-day validity, certificate lifecycle automation via ACME or EST is operationally required. Ask whether ACME automation is included in the PKIaaS service, what certificate volume limits apply, and whether the provider has tested high-volume automated renewal at the renewal frequency the 47-day schedule will require.

How should a PKIaaS vendor handle post-quantum cryptography?

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 guidance points toward deprecating RSA and ECC around 2030, with disallowance by 2035. Ask the vendor: which of these algorithms does the platform support today for certificate issuance; what is the roadmap for the remaining ones; can the CA hierarchy itself be migrated to ML-DSA without a full re-build; and will PQC migration be included in the subscription or priced separately.