Vendor Selection for PQC Migration: How to Evaluate Cryptographic Library and Platform Providers

A cryptographic library is not a commodity procurement. The library your TLS stacks, PKI infrastructure, and application layer use determines which algorithms are available across your entire estate. Choose a library without ML-KEM (FIPS 203) support today and you face a choice between deferring migration or replacing the library mid-programme. Neither outcome is cheap. The vendor selection decision belongs at the beginning of migration planning, not after the migration roadmap is already committed to delivery dates.

This article is written for security architects, PKI engineers, and CISOs who have completed or are completing a cryptographic inventory and are now choosing the platforms that will carry the migration. If you need the methodology for building that inventory, the cryptographic inventory guide covers discovery and classification. If you are working in an NSS-adjacent environment with CNSA 2.0 obligations, see the CNSA 2.0 versus 1.0 comparison for the specific parameter requirements that affect your vendor shortlist.

Why Library Choice Is a Migration Dependency, Not an Afterthought

Software cryptographic libraries and hardware security modules form the cryptographic substrate of an organisation's infrastructure. Every application, TLS stack, PKI system, and storage encryption service is constrained by what the underlying library supports and what its FIPS validation covers. Algorithm support decisions made at the library layer propagate upward through the entire stack. A library that supports ML-KEM but not ML-DSA (FIPS 204) means the application layer can migrate key exchange but not signatures without swapping libraries. A library with partial parameter set support means NSS-adjacent organisations cannot satisfy CNSA 2.0 requirements without a library change.

FIPS 140-3 validation is the procurement gateway for US federal use cases and many regulated commercial environments. As of mid-2025, no HSM had achieved combined FIPS 140-3 Level 3 validation with post-quantum algorithm support in a single certificate. Entrust nShield HSMs (firmware 13.8.0, released August 2025) and Thales Luna HSMs (firmware 7.9.0) both support ML-KEM, ML-DSA, and SLH-DSA, and both have submitted for FIPS 140-3 Level 3 re-validation. That validation gap is temporary, but procurement timelines must account for it. A deployment that requires FIPS-validated PQC support cannot go live until the validation certificate exists.

CNSA 2.0 sets the highest public parameter specification. US National Security Systems and their vendors must use ML-KEM-1024 for key encapsulation and ML-DSA-87 for signatures. Enterprise use cases outside the NSS perimeter can use ML-KEM-768 and ML-DSA-65. A library that implements only the 768/65 parameter sets does not satisfy CNSA 2.0 requirements and should fail the NSS-adjacent shortlist gate before any other evaluation begins.

Software Libraries: ML-KEM and ML-DSA Support Status

OpenSSL is the most widely deployed open-source cryptographic library and the integration target for most enterprise and infrastructure stacks. OpenSSL 3.x includes ML-KEM and ML-DSA support through the Open Quantum Safe (OQS) provider integration. Full native support, without a separate provider module, is in development; the integration trajectory points toward native availability in OpenSSL 3.5 and later releases, though the exact version should be confirmed against current release notes rather than taken from this article. Organisations evaluating OpenSSL today should test the OQS-OpenSSL provider in their environments and monitor the upstream merge schedule. The OQS provider is production-usable; the question is operational overhead of the separate provider module versus native integration.

BoringSSL, Google's library used in Chrome and Android, has supported hybrid X25519+ML-KEM-768 key exchange in TLS 1.3 since 2023 and is the basis for Chrome's production PQC deployment. BoringSSL is not distributed as a standalone library for general enterprise adoption; it is embedded in products under Google's control. Its production deployment at browser scale is the most significant real-world validation that X25519+ML-KEM hybrid TLS works, which makes it a useful reference even if it is not a direct procurement option.

AWS Libcrypto (AWS-LC) is a production-hardened fork of BoringSSL maintained by AWS and used internally across AWS services including KMS, ACM, S3, Secrets Manager, and Load Balancers. AWS-LC was the first open-source cryptographic module to include ML-KEM in a FIPS validation submission. For organisations running significant workloads on AWS infrastructure, AWS-LC provides consistency with the underlying platform cryptographic layer. It is publicly available as a standalone library for organisations outside AWS who want a FIPS-validation-tracked library with confirmed production PQC deployment.

wolfSSL is optimised for constrained environments: embedded systems, IoT devices, automotive platforms, and RTOS. It implements ML-KEM, ML-DSA, LMS, XMSS, and SLH-DSA, with Rust bindings in its 2026 roadmap. wolfSSL holds FIPS 140-2 Level 1 certification for its software module; FIPS 140-3 re-certification is in progress. For organisations with OT/ICS, industrial control, or IoT use cases where memory footprint and RTOS compatibility matter, wolfSSL is the primary candidate. Enterprise server and cloud environments are not its primary target.

LibreSSL, maintained by the OpenBSD project, added ML-KEM-768 and ML-KEM-1024 via BoringSSL import in version 4.1.0 (April 2025), X25519MLKEM768 public API in version 4.2.0 (October 2025), and MLKEM768_X25519 TLS keyshare in version 4.3.0 (April 2026). LibreSSL is directly relevant for organisations running OpenBSD or BSD-derived systems; it is not a primary evaluation target for most enterprise environments.

HSM Platforms: Hardware Key Protection During the PQC Transition

Hardware security modules protect the keys that matter most: root CA private keys, code signing keys, high-value encryption keys. An HSM that cannot perform ML-DSA key operations cannot be used as the root of trust for a PQC PKI hierarchy, regardless of what the software layer does. HSM selection is therefore a blocking dependency for PKI migration specifically, not just a general migration consideration. The PKI migration planning framework in the PKI migration planning article covers the sequencing logic in detail.

Thales Luna Network HSM at firmware 7.9.0 and above supports ML-DSA and ML-KEM at all standardised parameter sets. Luna HSMs hold FIPS 140-2 Level 3 certification; FIPS 140-3 certification is pending. Luna is the dominant HSM family in financial services, government PKI, and large enterprise key management. Organisations with existing Luna infrastructure should apply firmware 7.9.0 as a priority update. This firmware migration extends the hardware lifecycle for PQC without requiring hardware replacement, which is the most operationally efficient path for environments already invested in the Luna platform.

Entrust nShield Connect HSMs at firmware 13.8.0 (released August 2025) support ML-DSA, ML-KEM, and SLH-DSA natively. Entrust has submitted for FIPS 140-3 Level 3 re-validation. The nShield family is widely deployed in PKI root CA environments and code signing infrastructures. For organisations running nShield-based PKI hierarchies, firmware 13.8.0 enables ML-DSA signing operations on the same hardware that currently handles RSA and ECDSA operations, making the dual-algorithm transition period operationally manageable.

AWS CloudHSM had ML-DSA key pair generation and signing in preview as of late 2025. ML-KEM support status for CloudHSM at general availability should be confirmed against current AWS documentation. AWS KMS, the managed key service layer above CloudHSM, supports ML-KEM hybrid TLS and ML-DSA signing at general availability across multiple regions. Organisations using AWS for key management should distinguish between CloudHSM (dedicated hardware, preview PQC at last verification) and KMS (shared managed service, GA PQC operations). These are different products with different capability timelines.

Microsoft Azure Key Vault and Azure HSM had not published a general availability date for ML-KEM or ML-DSA key operations as of knowledge cutoff August 2025. Azure has deployed hybrid ML-KEM in TLS for Azure service endpoints. Organisations with Azure-native key management should verify current roadmap timelines with Microsoft and build a gap period into their migration schedule during which Azure-hosted keys may not yet support native ML-KEM operations. Do not assume Azure's TLS-layer PQC deployment implies Key Vault parity.

Seven Evaluation Criteria for Procurement

Vendor evaluation across any cryptographic library or HSM platform should address seven specific dimensions.

Algorithm completeness. Does the library support all four NIST-finalised algorithms: ML-KEM (FIPS 203) at all three parameter sets (512/768/1024), ML-DSA (FIPS 204) at parameter sets 44/65/87, SLH-DSA (FIPS 205), and FN-DSA (FIPS 206)? Partial support constrains migration scope. A library with ML-KEM but no ML-DSA cannot support PKI certificate migration.

FIPS 140-3 validation status. What is the CMVP certificate number? Is PQC support within the validated boundary, or outside it? For HSMs specifically: does the firmware update that adds PQC support trigger a delta validation, a full re-validation, or neither? A vendor who says their HSM "supports PQC" should be asked whether that support is inside or outside the current FIPS validation scope. The answer determines whether it satisfies federal procurement requirements.

Hybrid scheme support. Does the library support X25519+ML-KEM-768 hybrid key exchange for TLS 1.3 migration, and hybrid signature schemes for the transition period? The NCSC recommends hybrid as the interim standard. A library that implements PQC-only but not hybrid forces a hard cutover rather than a phased transition and increases operational risk during migration.

Integration ecosystem. Does the library have tested integrations with the TLS stacks, PKI software, and key management systems already in your environment? ML-KEM support in a library that is not compatible with your certificate authority platform or VPN appliance creates integration risk that vendor documentation may not surface until you are mid-deployment.

Performance at operational load. ML-KEM key generation and encapsulation are computationally cheaper than RSA key exchange at equivalent security levels. ML-DSA signatures are larger: approximately 3.3 kilobytes for ML-DSA-65 versus 72 bytes for ECDSA P-256 (3,309 bytes per FIPS 204 Table 2). Applications or protocols that carry signatures in constrained headers need profiling. The performance question is not "is ML-KEM slower than RSA" (it is not) but "do any of our protocols hit size or latency constraints from ML-DSA signatures specifically?"

Vendor update frequency and PQC programme maturity. How quickly did the vendor ship support after NIST published final FIPS 203/204/205 in August 2024? A vendor who took more than twelve months to update is demonstrably slow on PQC responsiveness. This is observable data, not a prediction, and it is a reasonable signal of how quickly the vendor will respond to future algorithm updates, of which there will be more.

CNSA 2.0 parameter alignment. For NSS-adjacent organisations and their suppliers: does the vendor explicitly support ML-KEM-1024 and ML-DSA-87? This is a pass/fail gate for that procurement context, not a weighting factor in a balanced scorecard.

How to Sequence the Selection Decision

Library selection should precede migration roadmap finalisation. The migration plan commits phase delivery dates to specific systems; those dates depend on the library being available, tested, and validated before execution begins. Running library evaluation in parallel with migration execution creates a dependency risk that surfaces as schedule failures when the library evaluation takes longer than expected.

Two reference sources are worth consulting before issuing an RFP or shortlist. The PKI Consortium's PQC Capabilities Matrix (PQCCM) is a regularly updated, vendor-submitted capability register across libraries, HSM platforms, and protocol implementations. It is the most current publicly available cross-vendor comparison and should be the first document any procurement team reads. NIST NCCoE SP 1800-38, the migration guide series, describes integration patterns for PQC libraries into TLS, PKI, and key management infrastructures. Volume B covers cryptographic discovery; subsequent volumes cover migration execution. These are preliminary drafts, but they remain the canonical technical reference for the migration layer above library selection.

The library selection decision is a dependencies map as much as a capability evaluation. Start with the systems in scope for Phase 1 of your migration programme, identify what cryptographic library each of them uses or can use, and evaluate vendors against the constraints those systems impose. A library that scores well in abstract evaluation but does not integrate with your Phase 1 systems is a Phase 2 or Phase 3 option at best.

Quantum technologies are evolving quickly and new developments emerge regularly. This page was last updated on 18/05/2026. For the most current information, we recommend contacting us directly.