Post-Quantum Ready PKIaaS: Buyer Evaluation Checklist

Every PKIaaS provider has updated their marketing to include the words “post-quantum ready” and “crypto-agile.” These terms describe genuinely important capabilities, but they do not tell you whether the provider can actually issue ML-DSA certificates today, whether their ACME endpoint handles the larger certificate sizes that post-quantum algorithms produce, whether their HSMs have been validated for ML-DSA key operations, or whether their CA key migration service includes a formal PQC root CA key ceremony. Marketing language and production capability are not the same thing.

This checklist gives security architects, PKI program owners, and procurement teams the specific questions to ask when evaluating a PKIaaS provider for post-quantum readiness. It is organized into eight evaluation categories. For each category, the questions identify the difference between a provider that is genuinely prepared for PQC migration and one that is describing a roadmap as if it were a current capability. The NIST IR 8547 deprecation of RSA and ECC for new uses is expected around 2030. Enterprise PKI migrations take 24 to 48 months. The evaluation you are conducting now determines whether your organization completes its PQC migration comfortably before that deadline or under pressure after it.

Quick Answer: What Makes a PKIaaS Provider Post-Quantum Ready?

A post-quantum ready PKIaaS provider can do eight things in production today: discover which algorithms are currently in use across your certificate estate; issue subscriber certificates signed with ML-DSA (FIPS 204); issue hybrid/composite certificates combining ECDSA and ML-DSA in a single X.509 certificate; generate ML-DSA CA signing keys and provision a new PQC CA hierarchy; update certificate profiles to switch the signature algorithm without replacing CA infrastructure; support PQC certificate enrollment through ACME, EST, and CMP endpoints; offer a PQC root CA trust store distribution strategy for the dual-algorithm transition period; and provide relying party compatibility guidance for systems that must be updated to verify ML-DSA certificates. If a provider can do fewer than eight of these, the missing capabilities represent migration risk that your organization will absorb.

Key Takeaways

• NIST finalized three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). For PKI certificate signing, ML-DSA (FIPS 204) is the primary migration target. A PKIaaS provider that does not support ML-DSA certificate issuance in production is not post-quantum ready, regardless of what their marketing materials say.
• Cryptographic debt is the gap between the algorithms you are running and the algorithms you can account for. Before a PKI migration can be planned, the organization must know which certificates use which algorithms, which CAs issue which algorithm types, and which relying party systems are capable of verifying ML-DSA certificates. Ask every PKIaaS provider how their platform supports cryptographic inventory and CBOM generation.
• The NIST IR 8547 deprecation of RSA and ECC for new uses is expected approximately 2030; disallowance approximately 2035. Enterprise PKI migrations take 24 to 48 months. Organizations starting the evaluation now are at the right point in the timeline for a methodical migration; organizations delaying are compressing their migration window toward the emergency-mode end of the spectrum.
• Hybrid/composite certificates are the practical bridge for the transition period. They let the organization begin deploying PQC certificates before all relying parties support ML-DSA verification. Ask specifically whether the provider supports composite certificates conforming to the IETF LAMPS working group draft specifications, and whether composite support is available for CA certificates and subscriber certificates.
• Production readiness matters more than roadmap promises. Ask whether ML-DSA issuance is covered by the provider’s production SLA, whether the HSMs holding ML-DSA CA signing keys are validated for ML-DSA operations, and whether ML-DSA certificate revocation and OCSP are handled by the production infrastructure. A “beta” or “preview” label means the capability is not production-governed.

Why the Timing of This Evaluation Matters

The harvest now, decrypt later (HNDL) attack strategy, in which adversaries collect encrypted traffic today for decryption by a future quantum computer, means the PQC migration is not only about preparing for a future compliance deadline. It is about reducing retrospective decryption risk on data that is being transmitted now. Organizations handling data with long confidentiality requirements (multi-decade retained records, classified government information, long-horizon financial data) should treat PQC migration as an active risk management program rather than a future compliance project.

The NIST IR 8547 timeline (RSA and ECC deprecated for new uses approximately 2030, disallowed approximately 2035) sets the compliance deadline. The program execution timeline (24 to 48 months for enterprise-scale PKI migration across all certificate types and relying parties) sets the start-by date. For most organizations, the comfortable start date was 2026 or 2027. The PKIaaS provider evaluation is the critical first step: if the provider selected cannot actually deliver PQC certificate issuance or CA key migration when needed, the organization’s migration timeline is held hostage to the provider’s roadmap.

Category 1: Cryptographic Inventory and Discovery

A PQC migration that starts without a cryptographic inventory is a migration that will miss certificates, surprise relying parties, and fail to meet the 2030 deprecation deadline for some certificate categories. The cryptographic inventory tells the organization what it is migrating from.

• Does the PKIaaS platform include a built-in cryptographic discovery capability, or does it integrate with an external CBOM tool? Specifically, can the platform produce an inventory of all currently active certificates showing the signature algorithm, key size, issuing CA, and certificate type for each certificate in the estate? Without this data, migration prioritization is guesswork;
• Can the platform identify certificates issued by CAs outside the PKIaaS hierarchy (self-signed CAs, legacy on-premises CAs, cloud-provider CAs)? A complete cryptographic inventory covers all certificates in the environment, not just the ones the PKIaaS platform issued. Certificates from unmanaged CAs are the highest-risk items in the inventory because they have no automatic renewal or governance;
• Does the platform track algorithm usage over time so migration progress can be measured? The migration progress metrics described in NIST guidance (percentage of active certificates using classical vs. PQC algorithms, percentage of certificate types with ML-DSA-capable profiles) require longitudinal data, not just a point-in-time snapshot;
• Can the cryptographic inventory be exported in CycloneDX CBOM format? CycloneDX is the emerging standard format for Cryptographic Bills of Materials. Export in this format allows the CBOM to be consumed by downstream tooling (SIEM, vulnerability management, risk quantification) without format conversion.

Category 2: ML-DSA Certificate Issuance Support

ML-DSA (FIPS 204) is the primary post-quantum digital signature algorithm for PKI certificate signing. A provider that claims PQC readiness must support ML-DSA certificate issuance in production.

• Does the platform support issuing subscriber certificates signed with ML-DSA CA keys? This is the baseline capability. Without it, the platform cannot issue post-quantum certificates regardless of other features;
• Which ML-DSA parameter sets are supported? The three parameter sets are ML-DSA-44 (Category 2 security), ML-DSA-65 (Category 3, approximately equivalent to AES-192 security), and ML-DSA-87 (Category 5, required for TOP SECRET systems under CNSA 2.0). Organizations subject to CNSA 2.0 need ML-DSA-87; most enterprise deployments are adequately served by ML-DSA-65;
• Is ML-DSA certificate issuance covered by the provider’s production SLA, or is it labeled preview or beta? Preview or beta means the capability is not governed by the same availability, key protection, and audit logging as the provider’s classical algorithm capabilities. Do not build a migration plan on preview functionality;
• Are ML-DSA certificates supported for all certificate types the platform issues, or only for TLS subscriber certificates? The migration must eventually cover user authentication certificates, S/MIME certificates, code signing certificates, and device identity certificates, not just TLS server certificates. Ask for the provider’s production support matrix across certificate types;
• Does the provider’s CA itself sign with ML-DSA keys, or does it sign ML-DSA subscriber certificates using a classical CA signing key? An ML-DSA subscriber certificate signed by a classical (RSA or ECDSA) CA key produces a hybrid chain that is not fully post-quantum. Full PQC migration requires ML-DSA CA signing keys at every level of the hierarchy.

Category 3: Hybrid and Composite Certificate Support

Hybrid and composite certificates are the practical migration bridge for organizations that cannot simultaneously update all relying parties to support ML-DSA verification. Ask these questions to assess the provider’s composite certificate capability.

• Does the platform support issuing composite certificates combining ECDSA and ML-DSA in a single X.509 certificate? Composite certificate support requires the CA software and HSM firmware to generate and store both algorithm keys and produce both signatures in a single signing operation. Not all platforms that claim composite support have implemented this at the CA key level;
• Which IETF LAMPS working group draft specifications does the composite implementation follow? The IETF LAMPS working group is the standards body developing composite public key and signature algorithm specifications. Implementations that follow the draft specifications will be interoperable with other implementations that follow the same specifications; proprietary composite implementations may not be;
• Is composite certificate support available for CA certificates and issuing CA certificates, or only for subscriber certificates? A composite subscriber certificate under a classical-only CA still has a partially classical trust chain. Full composite migration requires composite CA certificates at the intermediate and issuing CA level as well;
• What is the provider’s guidance on composite certificate validity periods and the criteria for transitioning from composite to pure ML-DSA profiles? Composite certificates are a transitional mechanism. The provider should have a defined recommendation for when composite certificates are appropriate and when the transition to pure ML-DSA is warranted based on relying party compatibility assessment.

Category 4: CA Key Migration and Root CA Strategy

Migrating to a post-quantum CA hierarchy requires generating new ML-DSA CA signing keys, conducting a new root CA key ceremony, provisioning ML-DSA intermediate and issuing CAs, and managing the dual-trust-store period during which both the classical and PQC CA hierarchies are active. This is more complex than changing a certificate profile.

• Does the provider offer a guided ML-DSA CA key migration service, including a formal PQC root CA key ceremony? The root CA key ceremony is a security-critical event that must be conducted with appropriate controls (HSM-backed key generation, M-of-N key custody, audit witnesses). Ask whether the provider’s migration service includes ceremony planning, execution, and documentation;
• How does the provider handle the dual-hierarchy transition period during which both classical and ML-DSA CA hierarchies are active? During the transition, the organization must issue classical certificates from the classical CA hierarchy for relying parties that do not yet support ML-DSA, and ML-DSA or composite certificates from the new PQC hierarchy for relying parties that do. Ask how the provider’s management plane handles this parallel operation;
• Does the provider offer a PQC root CA that the organization can anchor to, or must the organization generate and operate its own PQC root CA? Organizations that do not have the operational capacity to run a root CA key ceremony may prefer to anchor to the provider’s PQC root CA during the transition period. Ask whether this is available and under what trust model;
• How does the provider support distributing the new ML-DSA root CA certificate to relying party trust stores? Operating system, browser, and application trust stores must include the ML-DSA root CA certificate before they can verify ML-DSA certificate chains. Ask whether the provider has a documented plan and tooling for trust store distribution to the relying party systems in your environment.

Category 5: Profile Updates and Algorithm Agility

The core test of a crypto-agile PKIaaS platform is whether migrating from a classical algorithm to ML-DSA is a profile configuration change or an infrastructure project. Ask these questions to distinguish between the two.

• Does changing the signature algorithm for a certificate type require modifying only the certificate profile configuration, or does it require CA software updates, HSM firmware upgrades, or platform redeployment? A genuinely crypto-agile platform changes algorithm selection through profile configuration. A platform that requires infrastructure changes to support each new algorithm is not crypto-agile; it is manually extensible, which is a different and slower thing;
• Can ML-DSA certificate profiles be created and modified through the standard management interface (console and REST API) by the customer’s CA Administrator, or does the provider’s support team need to enable them? Customer-managed profile creation is the correct model. Provider-enabled profiles introduce a support queue into the migration timeline;
• Does the provider support policy-as-code deployment of profile changes through the PKIaaS REST API? Organizations that manage PKIaaS configuration as code (profile definitions in version-controlled repositories, deployed via CI/CD pipeline) need a REST API that supports all profile operations. Ask whether ML-DSA profile parameters are exposed through the same REST API as classical algorithm profiles;
• How does the provider handle the transition from composite profiles to pure ML-DSA profiles? The migration from composite (ECDSA + ML-DSA) to pure ML-DSA is a second profile update that occurs after the first (classical to composite). Ask whether both transitions can be managed as profile configuration changes through the standard management interface.

Category 6: Automated PQC Enrollment

PQC certificates are larger than classical certificates. ML-DSA-65 produces a public key of 1,952 bytes and a signature of 3,309 bytes, compared to an ECDSA P-256 public key of 65 bytes and signature of 72 bytes. This size difference has implications for enrollment protocols and automation clients that may have buffer sizes or timeout configurations sized for classical certificates.

• Do the provider’s ACME, EST, CMP, and SCEP endpoints support enrolling and renewing PQC certificates without requiring protocol configuration changes on the client side? Specifically, ask whether the ACME endpoint handles CSRs containing ML-DSA public keys (which are larger than classical public keys) and returns ML-DSA-signed certificates without modification to the standard ACME client configuration;
• Has the provider tested their enrollment endpoints with common ACME clients (cert-manager, certbot, acme.sh) for ML-DSA and composite certificate enrollment? Ask for test results or customer references for each enrollment protocol the provider claims supports PQC certificates;
• Does the provider’s cert-manager ClusterIssuer or CA Gateway integration support requesting ML-DSA or composite certificates from Kubernetes-native automation? Kubernetes is the highest-volume machine certificate environment for most cloud-native organizations. If the cert-manager integration does not support PQC certificate enrollment, the Kubernetes machine identity migration cannot proceed through the standard platform automation;
• Does the provider’s CLM layer track PQC certificate renewal separately from classical certificate renewal, and can it generate migration progress metrics (percentage of active certificates that are ML-DSA or composite vs. classical-only)? Migration progress metrics require the CLM to understand and report on algorithm type, not just certificate expiry.

Category 7: Application and Relying Party Compatibility

Issuing ML-DSA certificates from a post-quantum capable PKIaaS platform is only half of the migration. The other half is ensuring that the systems which verify those certificates (RADIUS servers, VPN gateways, browser TLS stacks, email clients, smart card middleware, MDM platforms, load balancers, and application frameworks) are capable of verifying ML-DSA signatures. This is outside the PKIaaS provider’s direct control but within their knowledge to advise on.

• Does the provider maintain a published compatibility matrix for ML-DSA and composite certificate verification across commonly used relying party systems? The matrix should cover at minimum: major OS TLS stacks (OpenSSL, BoringSSL, SChannel, Secure Transport), browser TLS (as browsers update), VPN gateway products, RADIUS server products, smart card middleware, and email clients (Outlook, Apple Mail). Ask for the current version of this matrix and how frequently it is updated;
• Does the provider offer pre-migration compatibility testing services or tooling that the organization can use to test ML-DSA certificate verification in their specific environment? Generic compatibility matrix data is useful for initial assessment; environment-specific compatibility testing is required before migrating production certificate types;
• What is the provider’s recommendation for handling relying party systems that will not support ML-DSA verification within the organization’s migration timeline? Some legacy systems may never be updated to support ML-DSA. The provider should have a documented approach for these systems (continued classical certificate issuance from the classical CA hierarchy, composite certificates for partial compatibility, or planned system replacement);
• Does the provider’s HSM support ML-DSA key operations, and what is the specific HSM model and firmware version? This question applies both to the HSMs the provider uses for CA signing keys and to customer-facing HSMs that store subscriber private keys for high-assurance certificate types (smart card logon, code signing). An HSM that has not been updated to support ML-DSA cannot be used to generate or store ML-DSA private keys.

Category 8: Migration Planning and Advisory Support

PQC migration is a multi-year program. Ask these questions to assess whether the provider offers the advisory and planning support that an enterprise migration program requires, or whether they provide only the technical platform and leave migration planning to the customer.

• Does the provider offer a structured PQC migration assessment service that evaluates the customer’s current certificate estate and produces a migration prioritization and roadmap? The assessment should use the cryptographic inventory data to prioritize certificate types for migration based on relying party update readiness, certificate validity period, and data sensitivity;
• Does the provider have documented guidance on the sequence of CA key migration steps (root to intermediate to issuing CA) and the dual-hierarchy transition period? Customers migrating a multi-level CA hierarchy need guidance on the correct migration sequence. Migrating issuing CA keys before root CA keys produces an inconsistent hierarchy that cannot be verified cleanly;
• Does the provider support CNSA 2.0 migration planning for organizations operating national security systems or subject to NSA guidance? CNSA 2.0 specifies ML-DSA-87 and ML-KEM-1024 and has more aggressive timelines than general NIST IR 8547 guidance. Defense contractors and agencies operating classified systems need a provider who understands and can support CNSA 2.0 requirements;
• What is the provider’s commitment to algorithm currency? When NIST publishes updates to PQC standards, when FIPS 204 or 205 parameter set guidance is updated, or when new post-quantum algorithms are standardized, how quickly will the provider update their platform to support the changes? Ask for the provider’s track record on adding algorithm support and whether they have a published algorithm roadmap.

Using This Checklist to Score Provider Responses

When evaluating provider responses against this checklist, distinguish between three response types:

• Generally available in production: The capability is covered by the provider’s production SLA, available to all customers through the standard management interface, and backed by the same key protection, audit logging, and revocation infrastructure as classical algorithm capabilities. This is the only response type that supports building a migration plan on this capability;
• Preview, beta, or limited availability: The capability exists but is not production-governed. Building a migration plan on preview functionality means the plan depends on the provider completing their own roadmap on schedule, which introduces a dependency the customer cannot control;
• On the roadmap: The capability does not currently exist. The provider intends to build it. A roadmap commitment is not a production capability. Organizations with 2028 or 2029 migration deadlines cannot afford to select a provider whose required capabilities are promised for 2027.

For each of the eight evaluation categories, the organization should achieve “generally available in production” responses before selecting a provider for a PQC migration program. Categories where the provider responds with “preview” or “on the roadmap” represent gaps that the organization must either accept (with a documented risk decision) or address by selecting a provider with current production capability.

How Encryption Consulting Can Help

• PQC Advisory Services: Encryption Consulting’s PQC Advisory Services include PKIaaS provider evaluation for PQC readiness: structured assessment of provider responses against the checklist categories above, gap analysis identifying which capabilities are missing or in preview, and risk quantification for proceeding with a provider whose PQC support has gaps. Contact us at Encryption Consulting to conduct a structured PKIaaS PQC readiness evaluation.
• CBOM Secure: Encryption Consulting’s CBOM Secure addresses Category 1 (Cryptographic Inventory and Discovery) directly: automated cryptographic discovery across the organization’s network and infrastructure, algorithm classification for every certificate (RSA, ECDSA, algorithm family, key size), CBOM generation in CycloneDX format, and continuous inventory updates. The CBOM output is the input to the PKIaaS PQC migration planning process, providing the migration prioritization data that providers need to produce a meaningful roadmap.
• PKI as a Service: Encryption Consulting’s PKIaaS offering addresses the evaluation checklist’s production readiness requirements: ML-DSA (FIPS 204) certificate profile support, composite/hybrid certificate issuance for the transition period, CA key migration services including ML-DSA root CA key ceremony planning, ACME and EST endpoints sized for PQC certificate enrollment, and profile-level algorithm management without infrastructure replacement. Encryption Consulting can also walk through each of the eight checklist categories for our own platform during a structured evaluation session.
• PKI Services (Migration Planning): Encryption Consulting’s PKI Services include PQC CA key migration planning: migration sequence design (root to intermediate to issuing CA), dual-hierarchy transition period management, trust store distribution planning for ML-DSA root CA certificates, CNSA 2.0 alignment for organizations with national security system obligations, and composite certificate profile design for the transition period.
• PQC Center of Excellence: For organizations that need research-backed guidance on IETF LAMPS composite certificate specifications, NIST IR 8547 compliance interpretation, CNSA 2.0 requirements, or ML-DSA relying party compatibility status for specific systems, Encryption Consulting’s PQC Center of Excellence provides direct expert access to post-quantum cryptography specialists who track these standards as primary sources.

Conclusion

The difference between a post-quantum ready PKIaaS provider and a provider with a post-quantum roadmap is the difference between a migration plan that can execute and one that cannot. The checklist above makes that difference visible during the evaluation process rather than after a contract is signed.

The eight evaluation categories address every component of a functional PQC PKI migration: knowing what you are migrating from (Category 1), being able to issue the destination algorithm’s certificates in production (Category 2), bridging the relying party transition with composite certificates (Category 3), migrating the CA hierarchy itself (Category 4), updating certificate policies as configuration rather than infrastructure (Category 5), enrolling PQC certificates through standard automation (Category 6), verifying PQC certificates in the relying party systems that matter to your environment (Category 7), and having expert guidance for the 24 to 48 months of program execution that follow provider selection (Category 8).

A provider who can answer “generally available in production” to all eight categories is a provider whose platform can support your PQC migration. Use this checklist in your RFP, your proof-of-concept evaluation, and your annual PKI program review to confirm that production readiness has not degraded back to roadmap promises after initial deployment.

If your organization is conducting a PKIaaS provider evaluation for PQC readiness and wants a structured assessment against this checklist, reach out to Encryption Consulting.

This checklist is reviewed on a six-month cadence and when NIST, NSA, IETF LAMPS, or major OS and browser vendors publish updates to PQC algorithm support, composite certificate specifications, or trust store integration guidance that affect the evaluation criteria.

Frequently Asked Questions

What NIST post-quantum algorithms should a PKIaaS provider support for certificate signing?

For PKI certificate signing, the primary algorithm is ML-DSA (FIPS 204, based on CRYSTALS-Dilithium), finalized in August 2024. Its three parameter sets are ML-DSA-44 (Category 2), ML-DSA-65 (Category 3, recommended for most enterprise use), and ML-DSA-87 (Category 5, required for TOP SECRET systems under CNSA 2.0). SLH-DSA (FIPS 205) is an alternative post-quantum signature algorithm with hash-based security assumptions; it is the backup algorithm rather than the primary migration target. A post-quantum ready provider should support at minimum ML-DSA-65 in production for subscriber certificates.

Why is the harvest now, decrypt later attack relevant to PKI certificates?

HNDL (harvest now, decrypt later) is a threat strategy where adversaries collect and store encrypted traffic now, intending to decrypt it once a quantum computer is available. The threat applies primarily to TLS sessions: if the TLS key exchange uses RSA or ECDH (rather than ML-KEM, FIPS 203), a future quantum adversary may decrypt the session. PKI certificates themselves are not directly harvested by HNDL, but they authenticate the sessions that are. Organizations with long data confidentiality requirements should treat this as an active risk, not a future one.

What is a hybrid or composite PQC certificate and when is it needed?

A hybrid or composite PQC certificate contains both a classical ECDSA signature and an ML-DSA signature in a single X.509 certificate. Classical-only relying parties verify using the ECDSA component; updated relying parties verify using ML-DSA. Hybrid certificates are needed during the transition period when not all relying parties support ML-DSA verification. They allow PQC deployment to begin before every system is updated, but are a transitional mechanism: the endpoint is pure ML-DSA certificates once the relying party estate supports them.

What is NIST IR 8547 and why does it set the deadline for PKIaaS PQC readiness?

NIST IR 8547 (“Transition to Post-Quantum Cryptography Standards”) establishes that RSA and ECC will be deprecated for new uses approximately 2030 and disallowed approximately 2035. For PKIaaS, this means new CA deployments after 2030 should use ML-DSA signing keys, and all existing RSA/ECC CA hierarchies must be migrated by 2035. Since enterprise PKI migrations take 24 to 48 months, organizations that have not started inventory and planning are already behind the schedule for a comfortable migration before the 2030 deprecation date.

How do I know if my PKIaaS provider’s PQC support is production-ready versus preview?

Ask four specific questions: Is ML-DSA issuance covered by the provider’s production SLA? Are the HSMs holding ML-DSA CA signing keys validated for ML-DSA key operations (ask for the specific HSM model and firmware version)? Can ML-DSA certificate profiles be created by the customer’s CA Administrator through the standard management interface, or must the provider’s support team enable them? Are ML-DSA certificate revocation and OCSP responses handled by the production OCSP infrastructure? If any of these answers is no, the PQC support is not fully production-governed.