PKIaaS RFP Template: Requirements for Security, Compliance, Automation, and Support

Selecting a PKI as a Service provider is a consequential, long-term decision. The provider will hold or operate the infrastructure that underpins every certificate your organization issues. Getting that selection right requires a structured evaluation process with specific, written requirements, not a comparison of marketing pages and demo calls.

This RFP template gives procurement teams, security architects, and compliance leads a complete set of requirements across ten functional and governance areas. Each section includes the specific questions vendors must answer in writing, the evaluation criteria to apply to those answers, and the signals that indicate a strong versus a weak response. Use it as a scored evaluation framework for any PKIaaS shortlist, or adapt it as a formal RFP document sent to vendors for written response.

The template is organized around the dimensions that matter most in production: CA hierarchy design, HSM infrastructure and key custody, enrollment protocols and MDM integration, API and DevOps access, certificate profiles and lifecycle management, role-based access control, audit logging and reporting, availability and incident response, compliance certifications and CP/CPS governance, and data residency, PQC readiness, migration support, and exit terms.

Quick Answer: What Does a PKIaaS RFP Cover?

A PKIaaS RFP should require written, verifiable vendor responses across ten areas: CA hierarchy design, HSM infrastructure and key custody, enrollment protocols and MDM integration, API and DevOps access, certificate profiles and lifecycle management, role-based access control, audit logging and reporting, service availability and incident response, compliance certifications and CP/CPS governance, and data residency, PQC readiness, migration support, and exit terms. The four disqualifying gaps that should end evaluation immediately regardless of total score are: inability to provide a NIST CMVP certificate number for the HSMs in use, absence of customer-controlled key escrow with independent recovery, no current SOC 2 Type II report, and no documented exit procedure.

Key Takeaways

• A structured RFP with written, scored vendor responses separates providers on the dimensions that marketing pages obscure: key custody terms, HSM validation depth, audit log isolation, CP/CPS ownership, PQC migration roadmap specificity, and exit rights. These are the areas where providers differ most and where gaps cause the most expensive problems after contract.
• Key custody and HSM infrastructure (Section 2) carry the highest individual weight in the evaluation at 20%, because they determine the actual security posture of the deployment. A vendor who cannot provide a NIST CMVP certificate number or describe an independent key recovery procedure is not operating an enterprise-grade PKI service regardless of what else they offer.
• ACME protocol support (Section 3.1) with External Account Binding is non-optional for any new PKIaaS deployment. The CA/Browser Forum’s Ballot SC-081v3 (approved April 2025) reduces maximum public TLS certificate validity to 47 days by March 15, 2029, making automated renewal a functional requirement for any meaningful TLS certificate estate.
• CP/CPS governance (Section 9.4) is the most commonly underspecified requirement in PKIaaS procurement. Whether the CP/CPS is a generic provider document or a customer-specific governance instrument, who owns it, and who maintains it when regulatory requirements change are questions that should be answered in writing before contract.
• Exit terms (Section 10.5) are the clearest signal of provider confidence. A provider who specifies exit terms clearly and without deflection is not relying on switching cost as a retention mechanism. Independent key recovery, certificate validity continuity after termination, and a 90-day migration support period should be non-negotiable contract requirements.

How to Use This Template

Send this template to each shortlisted vendor and require written responses to every requirement. Score each response on a 0-2 scale: 2 for a complete, documented, and independently verifiable answer; 1 for a partial answer with gaps or evidence gaps; 0 for no answer, deflection, or an answer that cannot be verified. Section weights are suggested below based on the criticality of each area to long-term PKI program success. Any score of 0 on a requirement marked as a disqualifier ends evaluation for that vendor regardless of total score.

Section	Area	Suggested Weight
1	CA Hierarchy Design and Flexibility	10%
2	HSM Infrastructure and Key Custody	20%
3	Enrollment Protocols and MDM Integration	15%
4	API, DevOps, and Third-Party Integration	10%
5	Certificate Profiles and Lifecycle Management	10%
6	Role-Based Access Control and Identity Provider Integration	5%
7	Audit Logging, Monitoring, and Reporting	10%
8	Service Availability, SLA, and Incident Response	10%
9	Compliance Certifications and CP/CPS Governance	15%
10	Data Residency, PQC Readiness, Migration, and Exit Terms	15%
	Total	100%

Section 1: CA Hierarchy Design and Flexibility

CA hierarchy design determines how certificate trust flows through the organization, how different certificate types are governed independently, and whether the PKI can scale to meet future requirements without a rebuild.

Requirements

• 1.1 Two-tier hierarchy support: The service must support a two-tier CA hierarchy consisting of an offline root CA and one or more online issuing CAs. The root CA must be physically air-gapped (not merely logically offline by policy) with documented access procedures.
• 1.2 Three-tier hierarchy support: The service must support a three-tier CA hierarchy consisting of an offline root CA, one or more intermediate or policy CAs, and one or more issuing CAs for organizations requiring policy separation between issuing contexts.
• 1.3 Multiple issuing CAs: The service must support the creation of multiple issuing CAs under the same root, configurable per certificate type (TLS, S/MIME, code signing, smart card, device), per organizational unit, or per geographic region without architectural rebuilds.
• 1.4 External root CA import: The service must support import of an external root CA to subordinate an existing customer-owned root CA into the managed service, preserving the existing chain of trust for already-issued certificates.
• 1.5 OCSP infrastructure: The service must operate dedicated OCSP responders for each CA that requires online certificate status. OCSP responder availability must be covered by the service SLA. Vendors must specify whether OCSP infrastructure is shared across customers or dedicated.
• 1.6 CRL distribution points: The service must publish CRLs to customer-accessible distribution points on a defined schedule. Vendors must specify the maximum CRL publication interval and what happens if a scheduled publication fails.
• 1.7 CA certificate validity periods: Vendors must document the supported validity periods for root CA certificates (typically 10 to 25 years), intermediate CA certificates (typically 5 to 10 years), and issuing CA certificates (typically 3 to 5 years). Vendors must also document the process for CA certificate renewal and whether it requires a new key ceremony.

Disqualifiers: Vendor cannot support a genuinely offline root CA; root CA key is generated and stored online without a documented offline storage procedure; vendor cannot import an external root CA.

Section 2: HSM Infrastructure and Key Custody

HSM architecture and key custody terms are the most consequential technical decisions in PKIaaS selection. They determine your real security posture, your blast radius if something goes wrong, and your ability to exit the relationship without losing your PKI hierarchy.

Requirements

• 2.1 FIPS validation: HSMs used for CA key storage must be validated to FIPS 140-2 Level 3 at minimum, or FIPS 140-3 Level 3 for new deployments. Vendors must provide the NIST CMVP certificate number for the specific HSM model in use so that validation status can be independently verified at nist.gov.
• 2.2 HSM tenancy model: Vendors must clearly state whether customer CA keys are stored in dedicated physical HSM appliances or in logical partitions within a shared appliance. If shared, vendors must describe the partition isolation mechanism and confirm that a security event affecting one partition cannot affect another partition’s key material.
• 2.3 Dedicated HSM option: For customers with data sovereignty, regulatory, or security policy requirements that demand physical key isolation, vendors must specify whether dedicated HSM appliances (not shared-appliance partitions) are available and at what additional cost.
• 2.4 M-of-N control for root CA operations: Vendors must describe the M-of-N (quorum authentication) configuration applied to root CA key generation, root CA signing operations, and other high-privilege HSM operations. Vendors must specify the default M and N values, whether customers can nominate their own custodians as part of the quorum, and how M-of-N authentication events are logged.
• 2.5 Customer-controlled key escrow: Vendors must describe the key escrow arrangement for root CA cryptographic materials. Specifically: where is the escrowed material held (provider, trusted third party, or customer-accessible storage); what format is it in; can the customer recover the root CA and re-establish their hierarchy independently without provider cooperation; and has this recovery procedure been tested in the last 12 months.
• 2.6 BYOK support: Vendors must state whether Bring Your Own Key is supported, under which the customer generates CA key material in their own controlled environment and imports it into the managed service. If supported, vendors must provide the documented key import procedure and confirm whether a key wrapping ceremony with customer witnesses is supported.
• 2.7 Customer-hosted HSM option: Vendors must state whether a customer-hosted HSM (Bring Your Own HSM) model is supported, under which the vendor’s CA software and management layer operates on top of customer-owned and customer-operated HSM hardware.
• 2.8 HSM firmware and maintenance: Vendors must describe how HSM firmware updates are managed, whether customers are notified before updates are applied to hardware storing their CA keys, and whether customer approval is required before firmware changes are applied.
• 2.9 Root CA ceremony documentation: Vendors must confirm that a formal root CA key ceremony was conducted for each customer engagement, with a witness list, ceremony script, HSM audit log, and evidence package. Vendors must confirm whether the ceremony evidence package is available to the customer and to the customer’s auditors.

Disqualifiers: Vendor cannot provide NIST CMVP certificate number; vendor cannot describe customer-controlled key escrow with independent recovery; vendor cannot confirm M-of-N controls on root CA operations; HSMs are below FIPS 140-2 Level 3 validation.

Section 3: Enrollment Protocols and MDM Integration

Enrollment protocol coverage determines whether the service can reach every certificate consumer in the environment without custom connector development. With the CA/Browser Forum’s Ballot SC-081v3 (approved April 2025) reducing maximum public TLS certificate validity to 47 days by March 15, 2029, ACME protocol support and automation capability are non-optional.

Requirements

• 3.1 ACME protocol (RFC 8555): The service must support ACME with External Account Binding (EAB) for enterprise authentication to the ACME server. Vendors must confirm that ACME support is production-ready (not in roadmap status), document the EAB configuration process, and confirm support for ACME renewal automation at high certificate volumes. Vendors must specify any per-certificate or per-renewal volume limits that could affect ACME automation at scale.
• 3.2 EST protocol (RFC 7030): The service must support EST for network device and IoT certificate enrollment. Vendors must document which EST operations are supported (SimpleEnroll, SimpleReenroll, CACerts, CSRAttrs) and confirm compatibility with standard EST clients.
• 3.3 SCEP protocol: The service must support SCEP for MDM-managed device enrollment and legacy infrastructure. Vendors must confirm the SCEP challenge password model and document SCEP compatibility with major MDM platforms.
• 3.4 WSTEP protocol: For organizations with Windows Active Directory environments, vendors must support WSTEP (Windows Simple Certificate Enrollment Protocol) with on-premises agent deployment for Active Directory integration. Vendors must document the agent deployment requirements (network, Azure, VMware) and the Active Directory forest preparation steps.
• 3.5 CMP protocol (RFC 4210): For organizations with constrained IoT or industrial OT devices, vendors must confirm CMP support. CMP is required for certain industrial automation, eSIM, and V2G (Vehicle-to-Grid) certificate use cases.
• 3.6 Microsoft Intune integration: Vendors must confirm native Microsoft Intune MDM integration (not SCEP-only workaround) for Windows, macOS, iOS/iPadOS, and Android device enrollment. Vendors must document the Intune enrollment workflow configuration and confirm support for certificate renewal and revocation through Intune.
• 3.7 Jamf integration: Vendors must confirm native Jamf Pro MDM integration for macOS and iOS device enrollment. Vendors must document the Jamf enrollment workflow, the supported SCEP challenge configuration, and whether Jamf audit events are captured in the service’s audit log.
• 3.8 VMware Workspace ONE integration: Vendors must confirm support for VMware Workspace ONE MDM enrollment via SCEP and PKI profiles, document the CA and request template configuration requirements, and confirm support for trusted certificate distribution through Workspace ONE profiles.
• 3.9 Additional MDM platforms: Vendors must list all additional MDM platforms for which native integration (not manual SCEP configuration) is supported, including Ivanti Neurons MDM and IBM MaaS360 where applicable.
• 3.10 Legacy protocol migration: Vendors must describe the migration path for customers transitioning from legacy enrollment protocols (SCEP, WSTEP) to ACME or EST automation, including whether on-premises enrollment workflow migration tooling or documentation is provided.

Disqualifiers: ACME support is on roadmap only and not production-ready; vendor cannot support WSTEP where the customer’s environment requires Active Directory integration; no documentation exists for MDM platform integrations the customer requires.

Section 4: API, DevOps, and Third-Party Integration

Requirements

• 4.1 REST API coverage: The service must expose a REST API covering: certificate issuance and renewal from a CSR; certificate issuance in PKCS#12 format; certificate status changes (revocation, suspension); bulk revocation operations; CA hierarchy management (CA creation, CA certificate download); certificate profile management; and audit log export. Vendors must provide full API reference documentation before contract.
• 4.2 API authentication: The service API must support OAuth 2.0 or mutual TLS (mTLS) for API authentication. Vendors must document the credential management model (how API credentials are created, rotated, and revoked) and confirm that all API authentication events are captured in the audit log.
• 4.3 API rate limits: Vendors must document API rate limits per endpoint category and confirm that rate limits can be adjusted for customers with high-volume automated certificate issuance workflows (for example, ACME-driven renewal at 47-day validity).
• 4.4 HashiCorp Vault integration: Vendors must confirm whether a native HashiCorp Vault PKI Secrets Engine integration or CA Gateway API integration exists for Vault-based certificate automation in DevOps pipelines. Integration should be documented and supported, not a community-maintained connector.
• 4.5 Ansible integration: Vendors must confirm whether an Ansible module or playbook integration exists for automated certificate management in infrastructure-as-code workflows.
• 4.6 CI/CD pipeline integration: Vendors must describe how the service integrates with common CI/CD platforms (GitHub Actions, Jenkins, GitLab CI) for code signing certificate automation and TLS certificate provisioning in pipeline-deployed environments.
• 4.7 SIEM and monitoring integration: Vendors must confirm whether audit logs and service health metrics can be exported to a customer SIEM in real time via a supported integration (syslog, webhook, API export, or native connector). Vendors must list the SIEM platforms for which native connectors exist.

Section 5: Certificate Profiles and Lifecycle Management

Requirements

• 5.1 Certificate profile types: Vendors must confirm which certificate profile types are available as standard in the service. Required profiles include: TLS/SSL (private trust), S/MIME (email security), code signing, smart card logon, device/machine identity, mobile device certificates, and multiuse profiles. Specialized profiles (eSIM, V2G, CMP-based IoT) should be declared where applicable.
• 5.2 Certificate profile customization: Vendors must describe the degree to which certificate profiles can be customized per customer, including: Subject DN fields and their sources; Subject Alternative Name types and allowlists (DNS, IP, email, UPN, custom OID); Key usage and Extended Key Usage extensions; Certificate validity period; and custom OID extensions for proprietary attributes.
• 5.3 SAN allowlist management: Vendors must describe how Subject Alternative Name (SAN) allowlists are managed, including how allowlists are created and updated, whether SAN validation is enforced at issuance, and who can modify SAN allowlists (role requirement).
• 5.4 Certificate lifecycle automation: Vendors must describe whether certificate lifecycle management (CLM) is included in the base PKIaaS subscription or is a separately priced module. CLM scope must include: certificate discovery across CA sources; expiration monitoring and alerting; automated renewal via ACME, EST, and SCEP; policy enforcement (blocking issuance outside defined profile constraints); and certificate inventory reporting.
• 5.5 Bulk revocation: The service must support bulk revocation of certificates by CA, by certificate profile, by SAN, or by issuance date range. Vendors must document the bulk revocation workflow and the expected time to CRL publication following a bulk revocation event.
• 5.6 Certificate issuance from CSR: The service must support certificate issuance from a customer-provided PKCS#10 CSR for environments where the private key is generated locally and must not be transmitted to the provider. Vendors must confirm that CSR-based issuance is supported for all certificate profile types.
• 5.7 PKCS#12 issuance: Where organizationally appropriate (for example, S/MIME or smart card certificates where the provider generates the key pair), vendors must confirm support for PKCS#12 certificate package issuance with the private key included.

Section 6: Role-Based Access Control and Identity Provider Integration

Requirements

• 6.1 Role-based access control model: Vendors must describe the RBAC model with specific named roles and their permissions. At minimum the service must support distinct roles for: Owner (full administrative access); CA Administrator (CA creation and configuration, not certificate issuance); Certificate Administrator (certificate issuance, renewal, and revocation, not CA configuration); CA Auditor (read-only access to CA configuration and audit logs, no issuance or configuration capability); and Enrollment Workflow Administrator (enrollment workflow configuration, no CA administration). Segregation of duties between CA administration and certificate issuance is a requirement.
• 6.2 External identity provider integration: The service must support integration with an external Identity Provider (IdP) using SAML 2.0 or OIDC for federated authentication. Vendors must confirm that SSO (Single Sign-On) is supported and that the customer’s IdP (Azure AD/Entra ID, Okta, Ping Identity, Google Workspace, or similar) can be configured as the authentication authority for the PKIaaS management console.
• 6.3 Multi-factor authentication: Access to the PKIaaS management console must require multi-factor authentication (MFA) for all users, regardless of role. Vendors must confirm whether MFA is enforced at the platform level (always on) or is optional per-user configuration.
• 6.4 IP allowlisting: The service must support IP address allowlisting to restrict management console and API access to customer-defined network ranges. Vendors must document how IP allowlists are configured and updated.
• 6.5 User audit trail: All user authentication events, role assignments, and administrative actions must be captured in the audit log with the specific user identity, timestamp, source IP, and action performed. Vendor support staff access to customer environments must also be captured in the customer-accessible audit log.

Section 7: Audit Logging, Monitoring, and Reporting

Requirements

• 7.1 Audit log scope: The service audit log must capture: every certificate issuance, renewal, revocation, and suspension event with certificate serial number, subject DN, SAN, issuing CA, requestor identity, and timestamp; every CA configuration change; every certificate profile creation or modification; every enrollment workflow creation or modification; every user authentication and role change; every HSM operation on the customer’s partition; and every instance of vendor staff access to the customer environment.
• 7.2 Audit log isolation: Each customer’s audit log must be isolated from other customers’ logs. Vendors must confirm that operations from other customers’ partitions or environments do not appear in the customer’s audit log stream.
• 7.3 Customer audit log access: Customers must be able to access their own audit logs through a self-service interface (dashboard or API export) without requiring a support ticket. Vendors must confirm the access mechanism, the query and filter capabilities, and the log format (JSON, CSV, syslog).
• 7.4 Audit log retention: Vendors must specify the default audit log retention period and confirm whether extended retention is available (minimum 7 years for regulated industries). Vendors must confirm what happens to audit logs at contract termination.
• 7.5 Real-time SIEM export: The service must support real-time or near-real-time export of audit log events to the customer’s SIEM system. Vendors must document the supported export mechanisms (syslog, webhook, API pull, or native connector) and confirm the maximum latency from event occurrence to SIEM delivery.
• 7.6 Service monitoring dashboard: Vendors must confirm that a customer-accessible monitoring dashboard is available showing: CA service availability status; OCSP responder status; CRL publication status and last publication time; current certificate issuance volume; and active enrollment workflow status.
• 7.7 Certificate expiration reporting: The service must provide certificate expiration reporting with configurable advance notification (for example, alert 90, 60, 30, and 7 days before expiry). Vendors must confirm the notification delivery mechanisms (email, webhook, dashboard alert, SIEM event) and confirm whether expiration reporting covers only certificates issued through the service or also certificates discovered from external sources.
• 7.8 Compliance reporting: Vendors must confirm whether the service provides pre-built compliance reports aligned to SOC 2, PCI DSS, CMMC, or other frameworks, or whether compliance evidence must be assembled by the customer from raw audit log exports.

Section 8: Service Availability, SLA, and Incident Response

Requirements

• 8.1 CA availability SLA: The service must commit to a contractual SLA of 99.9% or higher for CA certificate issuance availability. Vendors must specify: how availability is calculated (whether scheduled maintenance counts as downtime); the measurement period (monthly); and the compensation model for SLA breaches (service credits, with defined percentages per tier of breach).
• 8.2 OCSP availability SLA: OCSP responder availability must be covered by a separate, explicitly stated SLA. Vendors must confirm whether OCSP SLA is the same as or different from the CA issuance SLA, and what the planned OCSP response time target is (typically under 2 seconds for standard enterprise use cases).
• 8.3 Scheduled maintenance windows: Vendors must document their scheduled maintenance policy, including: how far in advance customers are notified of planned maintenance; the maximum duration of scheduled maintenance windows; and whether maintenance events are published on a status page accessible to the customer without logging in.
• 8.4 Incident severity definitions and response times: Vendors must provide their incident severity classification (P1 through P4 or equivalent) with specific definitions for each severity level in the context of PKI operations (for example: P1 = CA issuance unavailable or OCSP responder offline; P2 = Degraded performance or partial enrollment protocol failure; P3 = Non-critical feature degradation). Vendors must commit to contractual initial response times for each severity level, with P1 requiring response within one hour at maximum.
• 8.5 24/7 support coverage: P1 and P2 incidents must be eligible for 24/7 response by PKI-specialist engineers, not a general helpdesk. Vendors must confirm the support staffing model for after-hours incident response and specify whether PKI-specialist escalation is included in the base subscription or requires a premium support tier.
• 8.6 HA architecture description: Vendors must describe the high availability architecture for the CA issuance layer, OCSP infrastructure, and CRL distribution infrastructure, including geographic distribution of redundant components and failover mechanisms.
• 8.7 Disaster recovery RTO and RPO: Vendors must specify the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for the CA service and confirm that DR procedures are tested on at least an annual basis. Vendors must provide evidence of the most recent DR test (summary only, under NDA) on request.
• 8.8 Incident notification obligations: Vendors must commit to notifying customers within a defined timeframe (one hour for P1) of any security incident, service degradation, or data breach affecting the customer’s CA environment, and must provide a written post-incident report within five business days of P1 resolution.

Section 9: Compliance Certifications and CP/CPS Governance

Requirements

• 9.1 SOC 2 Type II: Vendors must hold a current SOC 2 Type II report (not SOC 2 Type I) covering the PKIaaS infrastructure and operations. Vendors must share the current report under NDA before contract and confirm the audit period covered by the most recent report. The report scope must explicitly include the HSM infrastructure, CA operations, and enrollment automation systems.
• 9.2 FIPS 140 HSM certification: As noted in Section 2.1, vendors must provide the NIST CMVP certificate number for each HSM model in use for customer CA key storage. This requirement is listed again here as a compliance artifact requirement: the CMVP certificate must be shareable with the customer’s compliance team and auditors.
• 9.3 ISO/IEC 27001:2022: Vendors must hold ISO/IEC 27001:2022 certification covering the scope relevant to the PKIaaS service. Vendors must provide the certification and scope statement under NDA.
• 9.4 CP/CPS development and ownership: Vendors must confirm whether a Certificate Policy (CP) and Certification Practices Statement (CPS) are developed as part of the engagement. Vendors must clarify: whether the CP/CPS is a generic provider-level document or is customized to the customer’s certificate types and regulatory requirements; who owns the CP/CPS (customer or provider); who is responsible for maintaining it when certificate profiles, CA hierarchy, or regulatory requirements change; and whether legal review of the CP/CPS is included in the engagement or is the customer’s responsibility.
• 9.5 CP/CPS public availability: Vendors must confirm whether the CP/CPS for the service is publicly available (required for many compliance frameworks) or is a private document shared only with the customer and their auditors.
• 9.6 Additional certifications relevant to customer requirements: Vendors must confirm the status of the following certifications where applicable to the customer’s regulatory environment: FedRAMP Moderate or High authorization (for US federal agency use cases); Business Associate Agreement (BAA) availability (for HIPAA-covered healthcare organizations); PCI DSS assessment alignment (for cardholder data environments); CMMC Level 2 control mapping documentation (for defense contractors handling CUI); ISO/IEC 27017 (cloud security); and any sector-specific certifications required by the customer’s regulatory framework.
• 9.7 Audit evidence support: Vendors must confirm the process for providing PKI-specific audit evidence to the customer’s auditors during SOC 2, CMMC, FedRAMP, or other compliance assessment cycles, including the types of evidence available (HSM CMVP certificates, CA configuration exports, ceremony records, audit log exports, access control records) and the turnaround time for evidence requests.

Disqualifiers: Vendor cannot provide a current SOC 2 Type II report; no CP/CPS exists or vendor cannot confirm its development; vendor holds no ISO/IEC 27001:2022 certification for the relevant scope.

Section 10: Data Residency, PQC Readiness, Migration Support, and Exit Terms

Requirements

• 10.1 Data residency and geographic key restriction: Vendors must disclose the specific countries and data center locations in which customer CA key material is stored and processed. For customers with data sovereignty requirements (GDPR, FedRAMP CONUS restriction, ITAR, or national data localization mandates), vendors must confirm whether a contractual commitment to geographic key restriction is available, and at what cost if not included in the base subscription.
• 10.2 Post-quantum cryptography algorithm support: 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. Vendors must disclose: which of these algorithms the platform supports today for certificate issuance; whether the CA hierarchy itself (root CA and issuing CA signing operations) can be migrated to ML-DSA (FIPS 204) without a full rebuild; whether the HSMs in use have current firmware support for NIST PQC algorithms or whether hardware replacement will be required; and whether PQC migration will be included in the base subscription at the time it is needed or will be priced as a separate engagement.
• 10.3 Hybrid certificate support: For organizations requiring a migration bridge between classical and post-quantum algorithms, vendors must confirm whether hybrid certificates (combining RSA or ECDSA with ML-DSA or SLH-DSA in a single certificate) are supported, and what certificate profile configuration is required to issue hybrid certificates.
• 10.4 Migration from self-managed or on-premises PKI: Vendors must describe the migration path for customers transitioning from a self-managed or on-premises PKI to the managed service, including: how existing certificate inventories are migrated to the new CA source; how enrollment workflows are migrated from on-premises NDES/SCEP or ADCS environments to the managed service; what migration tooling or documentation is provided; and whether a professional services migration engagement is available and at what scope.
• 10.5 Exit and data portability terms: Vendors must describe the exit procedure in writing, covering: which cryptographic materials are exportable (root CA private key, issuing CA private keys, CA certificates, OCSP signing keys) and in what format; whether issued certificates remain valid until their natural expiry date after contract termination (they should; confirm this); what the data retention period is for CA audit logs after termination; and whether a migration support period (typically 90 days minimum) is included in the contract.
• 10.6 Pricing model transparency: Vendors must provide a written pricing schedule covering: base subscription fee and what it includes; per-certificate or per-issuance pricing if applicable; pricing for additional CA tiers, certificate profiles, or enrollment protocols beyond the base subscription; pricing for dedicated HSM options; pricing for extended audit log retention; and pricing for professional services engagements (migration, CP/CPS development, PQC migration).

Disqualifiers: Vendor cannot commit to geographic key restriction where the customer has a documented regulatory requirement for it; vendor has no PQC roadmap for ML-DSA CA signing operations; vendor cannot describe a clear, documented exit procedure with independent key recovery.

RFP Submission Instructions Template

Include the following section at the beginning of the RFP document sent to vendors.

---

PKIAAS RFP: VENDOR RESPONSE INSTRUCTIONS

Issuing Organization: [Organization Name]
Response Due Date: [Date]
Response Format: Written responses to each numbered requirement in Section order. Responses must be specific and verifiable. General capability claims without supporting documentation will be scored as partial (1) or no response (0).

Required Attachments:

• Current SOC 2 Type II report (full report under NDA, or executive summary with attestation that full report will be shared under NDA before contract)
• ISO/IEC 27001:2022 certificate and scope statement
• NIST CMVP certificate number(s) for all HSM models used for customer CA key storage
• Sample CP/CPS or table of contents demonstrating CP/CPS structure and scope
• API reference documentation (current version)
• Sample SLA agreement with breach compensation terms
• Sample exit procedure documentation
• PQC roadmap document (if available) or written statement of PQC algorithm support and timeline

Evaluation Process: Responses will be scored by the evaluation team using the weighted scoring framework in the RFP. Vendors with disqualifying findings (score of 0 on any designated disqualifier) will not advance to the demo and reference check stage regardless of total score. Top-scoring vendors will be invited to a structured technical demonstration and reference customer interviews before final selection.

---

How Encryption Consulting Can Help

Encryption Consulting helps organizations run structured PKIaaS vendor evaluations, from RFP development through vendor scoring, technical demonstration facilitation, and contract review. We also operate our own PKIaaS service and can participate in evaluations as a responding vendor where that serves the customer’s process.

• PKIaaS Vendor Evaluation Support: Encryption Consulting can facilitate the full evaluation process using this RFP framework, conduct independent technical due diligence on vendor responses, and produce a scored, documented vendor comparison. This is part of our PKI Services advisory scope. Contact us at Encryption Consulting to discuss evaluation support.
• PKI as a Service: Encryption Consulting’s own PKIaaS offering can respond to all requirements in this template. Our service includes FIPS 140-3 Level 3 HSM-backed CA keys in dedicated partitions, always-offline root CA with documented M-of-N key ceremony and evidence package, CP/CPS development and maintenance, ACME/EST/SCEP/WSTEP/CMP enrollment protocol support, Intune and Jamf native MDM integration, 24/7 monitoring, customer-accessible audit logs, customer-controlled key escrow, and documented exit procedures. Contact us at Encryption Consulting to request a formal RFP response.
• PKI Assessment Service: For organizations evaluating an existing PKIaaS provider against this framework, Encryption Consulting’s PKI Assessment Service maps the current deployment against each section’s requirements and produces a gap analysis with remediation priorities.
• CertSecure Manager: For organizations whose selected PKIaaS service does not include full CLM (Section 5.4), Encryption Consulting’s CertSecure Manager provides CA-agnostic discovery, automated renewal via ACME, EST, and SCEP, and centralized policy enforcement across the full certificate estate regardless of which CA issued the certificates.
• PQC Advisory Services: For organizations evaluating vendor PQC roadmaps against Section 10.2 requirements, Encryption Consulting’s PQC Advisory Services and PQC Center of Excellence provide structured assessments that establish the internal migration cost baseline for the business case comparison.

Conclusion

A PKIaaS RFP process that generates comparable, written, verifiable vendor responses across these ten sections will surface the differences that matter: key custody terms, HSM validation evidence, protocol coverage for your specific environment, audit log access model, compliance certification scope, PQC migration roadmap specificity, and exit terms. These are the areas where providers differ most and where gaps create the most expensive problems after contract.

The disqualifiers are the most important screening mechanism. Any provider that cannot provide the NIST CMVP certificate number for their HSMs, cannot describe a customer-controlled key escrow procedure with independent recovery, cannot provide a current SOC 2 Type II report, or cannot commit to a documented exit procedure is not ready for an enterprise PKI program regardless of what else they offer.

Use the weighted scoring framework to produce a documented, defensible vendor selection decision that your compliance team, your legal team, and your executive leadership can all review and understand. The goal is not the lowest price or the longest feature list. It is the provider who can sustain your PKI program through compliance audits, staff changes, protocol transitions, and a post-quantum migration over a five-to-ten year engagement horizon.

If you want support running this evaluation or want a formal RFP response from Encryption Consulting, reach out at Encryption Consulting.

This template 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, NIST IR 8547 PQC deprecation timelines are revised, or material changes in the PKIaaS market affect the standard evaluation criteria.

Frequently Asked Questions

What should a PKIaaS RFP include?

A PKIaaS RFP should cover ten functional and governance areas: CA hierarchy design and flexibility, HSM infrastructure and key custody, enrollment protocols and MDM integration, API and DevOps integration, certificate profiles and lifecycle management, role-based access control and identity provider integration, audit logging and reporting, service availability and incident response, compliance certifications and CP/CPS governance, and data residency, PQC readiness, migration support, and exit terms. Each area should include specific, verifiable requirements that vendors respond to in writing.

What enrollment protocols must a PKIaaS vendor support?

A PKIaaS vendor should support at minimum: ACME (RFC 8555) with External Account Binding; EST (RFC 7030) for network devices and IoT; SCEP for MDM-managed devices and legacy infrastructure; WSTEP for Windows Active Directory environments; CMP (RFC 4210) for constrained IoT and industrial devices; and a REST API for DevOps and CI/CD integration. MDM platform support (Microsoft Intune, Jamf, VMware Workspace ONE, Ivanti, IBM MaaS360) should be native rather than requiring custom connector work.

What compliance certifications should a PKIaaS vendor hold?

The minimum baseline is SOC 2 Type II, FIPS 140-2 or 140-3 Level 3 validated HSMs (verify through NIST CMVP using the specific certificate number), and ISO/IEC 27001:2022. Regulated industries should additionally confirm FedRAMP authorization for government use cases, HIPAA BAA availability for healthcare, PCI DSS alignment for payment processing environments, and CMMC assessment alignment for defense contractors.

What CA hierarchy configurations should a PKIaaS vendor support?

A PKIaaS vendor should support two-tier and three-tier CA hierarchies, multiple issuing CAs per root for certificate type separation, import of an external root CA to preserve existing trust chains, and cross-certification or linkage to existing external PKI. The root CA should be genuinely air-gapped (physically disconnected from networks), not merely logically offline by policy.

What exit and migration terms should be in a PKIaaS contract?

Before signing, confirm: which cryptographic materials are exportable and in what format; whether issued certificates remain valid until natural expiry after contract termination; what the data retention period is for CA audit logs after termination; whether a migration support period is included; and what the legacy protocol migration path is. These terms should be in the contract, not a verbal commitment.

What SLA should a PKIaaS provider commit to?

A PKIaaS provider should commit to 99.9% or higher for CA and OCSP/CRL availability, with OCSP SLA stated separately from the CA SLA. The SLA should specify how availability is calculated, the measurement period, and the compensation model for breaches. P1 incident notification should be required within one hour.