Why Vendor-Agnostic Quantum Security Advice Matters for Procurement Decisions

Most organisations entering the PQC migration cycle receive their migration roadmap from a vendor with a direct financial interest in one particular path through it. This is not a question of vendor ethics. It is a structural problem built into how quantum security advisory services are currently delivered. The consultant assessing your cryptographic estate and the salesperson proposing your replacement hardware may sit in different departments of the same company. The advice is structurally compromised before the engagement letter is signed.

The procurement decisions being made in 2025 and 2026 will lock in cryptographic architectures for five to ten years. NIST published FIPS 203, FIPS 204, and FIPS 205 in August 2024, establishing the migration targets. NIST IR 8547, the Initial Public Draft published in November 2024, sets the deprecation timeline for classical public-key algorithms: when RSA, ECDSA, ECDH, DH, and DSA transition from legacy-only use to outright prohibition. An organisation that selects the wrong migration path in 2026 because its advisory relationship carried undisclosed bias may not discover the problem until a rearchitecture is required in 2029 or 2031. The cost is measured in programme cycles and operational disruption, not purchase prices.

This article identifies the three structural conflict patterns that appear most frequently in quantum security procurement, explains why a vendor cannot reliably resolve them even with good intentions, and provides a framework for maintaining procurement objectivity throughout a PQC migration cycle.

Three Structural Conflict Patterns

HSM Vendors and the Hardware Replacement Framing

Hardware Security Module vendors have a structural incentive to frame PQC migration as a hardware replacement problem. An HSM at £20,000 to £100,000 per unit produces more revenue than a firmware update or a software library integration. The objective question, whether a given HSM installation actually requires hardware replacement for ML-KEM support, cannot be answered neutrally by a vendor whose primary revenue comes from selling new HSMs.

The technical reality is that PKCS#11 v3.1 (OASIS Standard, approved 23 July 2023) added hash-based signature schemes (LMS, HSS) to the interface. ML-KEM and ML-DSA interface-level support is being addressed in the PKCS#11 v3.2 draft (Committee Specification Draft, April 2025). HSM vendors implementing ML-KEM and ML-DSA today do so via vendor-specific firmware extensions or SDK mechanisms, not via PKCS#11 standard mandate. HSM vendors including Thales, Utimaco, and Entrust have published firmware and SDK updates enabling ML-KEM (FIPS 203) and ML-DSA (FIPS 204) support on current-generation hardware through those proprietary mechanisms. Whether a specific installation requires new hardware depends on the HSM model, firmware version, and integration architecture. That is precisely the question a vendor-neutral assessment starts with and a vendor assessment may not.

QKD Vendors and the Complementary Positioning

Quantum Key Distribution vendors occupy a distinct but equally well-defined conflict position. Their commercial model depends on positioning QKD as a necessary complement to, or in some framings a superior alternative to, post-quantum algorithm migration. The NSA stated its position directly in its August 2021 FAQ on QKD: NSA does not support QKD for securing National Security Systems, citing concerns about maturity, authentication requirements, limited deployment options, and lack of applicable standards. The ANSSI, BSI, NLNCSA, and Swedish NCSA issued a joint position paper in January 2024 recommending that QKD be treated as a complement to post-quantum algorithm migration, not a substitute.

Four of Europe's leading national security agencies, approaching this question from their own national interests, reached the same conclusion. QSECDEF's QKD versus PQC migration analysis explains in detail why QKD does not discharge the PQC migration obligation. A vendor whose revenue depends on QKD hardware sales cannot reliably reproduce that analysis for a client it is simultaneously trying to sell to.

PQC Library Vendors and Algorithm Selection Bias

Software vendors selling PQC cryptographic libraries have a subtler but equally real conflict at the algorithm selection stage. The choice between ML-KEM-768 and ML-KEM-1024, between ML-DSA (FIPS 204, the standardised successor to CRYSTALS-Dilithium) and SLH-DSA (FIPS 205), or between FN-DSA (the standardised FALCON-based scheme) and SLH-DSA for signing workloads should be driven by the application's security requirements, performance profile, and FIPS compliance obligations. A vendor library that implements ML-KEM-768 efficiently but SLH-DSA poorly has an interest in the algorithm selection process that a neutral assessor does not.

To be precise on terminology: ML-DSA is the NIST FIPS 204 standardised designation for what was previously called CRYSTALS-Dilithium. SLH-DSA (FIPS 205) uses hash-based constructions with different security assumptions. FN-DSA is the FIPS-designated name for the FALCON lattice-based signature scheme. Library vendors whose implementations favour certain algorithms within these families should not be the primary influence on which algorithm a client selects.

NIST IR 8547 as the Objective Baseline

NIST IR 8547, published as an Initial Public Draft in November 2024, provides the only widely accepted algorithmically objective baseline for classical public-key algorithm deprecation. It specifies when RSA, ECDSA, ECDH, DH, and DSA transition to deprecated status (use restricted to legacy interoperability) and to disallowed status (must not be used), with timelines extending to 2030 and beyond.

An objective procurement framework treats NIST IR 8547 as a non-negotiable gate. Any migration recommendation that defers action beyond NIST IR 8547's disallowance dates is not giving advice consistent with regulatory requirements. It may be giving advice consistent with the vendor's sales cycle. These are not the same thing.

The document also establishes a useful test for vendor advice: if a recommended migration path requires using algorithms that NIST IR 8547 classifies as disallowed after a certain date, the client should ask the direct question of whether the vendor's recommendation aligns with the NIST timeline and, if not, why not. The answer reveals whether the advice is client-serving or vendor-serving.

Crypto-Agility as a Structural Procurement Requirement

Crypto-agility is the architectural principle that cryptographic implementations should be modular: the algorithm, key size, and protocol should be replaceable without requiring a full system redesign. It is also the most effective structural countermeasure against vendor lock-in in PQC migration.

NCSC guidance and NIST SP 800-52 Rev 2 ("Guidelines for the Selection, Configuration, and Use of TLS Implementations") explicitly endorse crypto-agility as a design principle for quantum-ready systems. A system built with crypto-agility accepts ML-KEM today, a hybrid ML-KEM plus X25519 scheme during the transition period, and whatever the next generation of NIST-standardised algorithms specifies after 2030. It does not require a full procurement cycle every time an algorithm is updated or deprecated.

Mandating crypto-agility in every procurement specification creates an objective evaluation criterion independent of vendor recommendation. A vendor whose product architecture builds algorithm dependencies deep into its implementation, as some HSM and secure enclave products do, fails an objective crypto-agility assessment. That failure is visible in the evaluation before any advisory relationship can obscure it.

A Four-Stage Procurement Separation Model

QSECDEF's recommended approach separates four functions that should not be combined in a single vendor relationship.

Stage 1: Strategic assessment. What does the current cryptographic estate look like, and what are the regulatory obligations? This stage requires no product interest. The assessor identifies where RSA, ECDSA, ECDH, and related algorithms are used, maps those uses against NIST IR 8547 deprecation timelines and NCSC milestones, and produces a prioritised migration scope. No vendor with a product interest in the outcome of that scope definition should conduct this stage.

Stage 2: Architecture design. Which quantum-safe architectures are appropriate for this environment? This stage requires no product interest in the designed architecture. The designer specifies algorithm choices, hybrid transition approaches, key management requirements, and crypto-agility standards. Their recommendation should be producible by any qualified architect regardless of which vendors they subsequently evaluate.

Stage 3: Product evaluation. Which vendors and products best meet the architecture designed in stage 2? Vendors participate here and their commercial interests are known and managed through competitive evaluation. The scope is fixed; the conflict is bounded.

Stage 4: Implementation. Vendor-delivered. The conflict is acceptable at this stage because the strategic scope and architecture are already defined independently. The vendor implements within a constrained scope they did not define.

Allowing a vendor to participate in stages 1 or 2 while also competing in stage 3 creates a structural conflict that no vendor can be expected to resolve in the client's favour. The incentive to shape stages 1 and 2 in ways that advantage stage 3 performance is real regardless of individual intentions.

UK Public Sector: Crown Commercial Service Framework Considerations

Public sector organisations have additional structural support for this separation. The Crown Commercial Service Cyber Security Services 3 framework (RM3764.3) allows public sector buyers to procure cyber security advisory services independently from product supply. The framework structure supports maintaining separation between strategic advice and product selection. Public sector organisations planning quantum security procurements should ensure that advisory engagements under CSS3 are structured to exclude product vendors from influencing strategic or architecture stages where those vendors will also compete in the product evaluation stage.

Anyone relying on CSS3 or its successors should verify current framework availability and scope against the CCS website before committing to a procurement structure, as CCS frameworks are regularly updated and renewed.

Library Selection: The Technical Evaluation Process

When selecting a PQC cryptographic library, a procurement process should include at minimum four technical checks independent of vendor recommendation.

First, benchmarking across the target hardware profile using standard metrics: key generation latency, encapsulation and decapsulation throughput for ML-KEM, and signature generation and verification throughput for ML-DSA, SLH-DSA, and FN-DSA. Performance profiles differ materially across parameter sets and hardware architectures. A library that performs well on a high-core-count server may perform poorly on a constrained device.

Second, FIPS 140-3 validation status. For systems requiring FIPS compliance, only CMVP-validated modules (Cryptographic Module Validation Programme, NIST's validation programme) should be considered. Vendor claims about pending validation are not the same as completed validation. Check the NIST CMVP list directly.

Third, known-answer test vector verification. FIPS 203, 204, and 205 each include published test vectors. Verify that the candidate library correctly implements them using NIST's ACVP automated testing infrastructure where available.

Fourth, interoperability testing against other implementations in the target environment. A library that correctly implements FIPS 203 in isolation but fails to interoperate with a different FIPS 203 implementation at the TLS handshake layer has a problem that laboratory benchmarks will not reveal.

The Practical Test

QSECDEF's position is that vendor-agnostic assessment is the prerequisite for any meaningful PQC migration, not an optional quality measure. The organisations that manage this migration most effectively will be those that structured their advisory relationships before the procurement window opened, not those that structured them after.

Use QSECDEF's Q-Day timeline risk calculator to establish your migration urgency profile before engaging any vendor. The PQC vendor selection guide provides an independent evaluation framework for the product selection stage. For a broader view of the cryptographic estate that any assessment must start with, the cryptographic inventory methodology covers the first prerequisite step.

QSECDEF membership provides access to practitioner methodology for each stage of the four-stage separation model, developed independently of any product vendor. Individual and company membership includes access to the migration methodology documentation and the practitioner community working through these decisions across sectors.