Standing up a post-quantum test environment

Post-quantum deployment does not fail cryptographically. It fails on buffer sizes, fragmentation, appliances that reject oversized certificate chains and credentials that no longer fit on a smartcard. A test environment finds those problems for a small fixed cost, before they become production incidents.

Why testing matters more here than in a normal upgrade

The algorithms work. ML-KEM and ML-DSA are computationally efficient, widely implemented and well analysed. The difficulty is that they are one to two orders of magnitude larger than what they replace, and infrastructure built around classical sizes has assumptions embedded in it that nobody documented.

The failures encountered in practice are consistent. Fixed field lengths and static buffers sized for ECDSA. Certificate chains exceeding what an appliance will accept, usually with an undocumented limit. ClientHello messages crossing the maximum transmission unit and fragmenting, which some middleboxes handle by dropping the connection. Smartcards and secure elements without the capacity for a post-quantum credential. Applications that validate certificates through their own logic rather than the platform's.

None of those is discoverable from a datasheet. All are discoverable in a lab in a matter of days.

What to build

The lab does not need to mirror production. It needs to represent the constraints that differ from production defaults.

A minimum viable environment has four components. A certificate authority capable of issuing post-quantum certificates, which for testing purposes can be OpenSSL 3.5 or an evaluation instance of the platform under consideration. A client and server pair using the same library versions deployed in the estate, not the latest available. At least one representative network appliance, load balancer or gateway from the production estate, since these are where size limits bite. And a representative constrained device or credential, typically a smartcard or embedded module, where those exist in the estate.

Vendor sandboxes are a reasonable starting point for familiarisation. Several vendors offer hosted post-quantum PKI environments, and the Open Quantum Safe project provides tooling for experimentation. They are useful for learning behaviour and useless for finding estate-specific limits, because they contain none of your equipment.

What to test, in priority order

Certificate chain acceptance

Issue certificates with realistic chain depth using ML-DSA, and present them to every class of relying party in the estate: load balancers, reverse proxies, API gateways, application servers, mobile clients and any appliance performing TLS inspection. Record the size at which each fails. This produces the single most useful output of the exercise, which is a maximum viable chain size for the estate.

Handshake behaviour on real network paths

Test hybrid key exchange across the paths users actually traverse, including mobile, satellite and international links where those apply. The additional round trip caused by exceeding the initial congestion window is invisible on a local network and material on a high-latency one.

Fragmentation and middlebox behaviour

Establish whether large ClientHello messages survive the network path intact. Failures here present as intermittent connectivity faults rather than performance problems, which makes them expensive to diagnose in production.

Credential storage capacity

Attempt to load a post-quantum credential onto the smartcards, tokens and secure elements in use. Capacity cannot be increased after purchase, so a failure here converts a software migration into a procurement programme and needs to be known early.

Signing performance and HSM behaviour

Confirm the deployed hardware security module firmware supports the required algorithms, including LMS and XMSS if firmware signing is in scope, and measure signing throughput against expected volume. Larger signatures and shorter certificate lifetimes both increase load.

Certificate lifecycle integration

Verify that issuance, renewal and revocation work end to end through the certificate management platform with post-quantum certificates, rather than only through command-line issuance. This is where the difference between an algorithm working and an estate working becomes visible.

Observability

Establish whether you can tell, from logs or telemetry, which key exchange group and signature algorithm a connection actually used. Without that, there is no way to measure migration progress or to detect silent fallback to classical algorithms.

What not to test

Do not benchmark the algorithms themselves. Published performance characteristics are reliable, and reproducing them consumes time that should go into interoperability.

Do not test against the latest library versions unless those are what you run. The purpose is to characterise the estate as deployed, and testing against newer versions produces optimistic results.

Do not attempt to test public trust certificate paths. No post-quantum roots have been accepted into the major browser trust stores and the Baseline Requirements have not been amended, so there is nothing to validate against, as covered in choosing between hybrid and composite certificates.

Turning results into requirements

The lab output is not a report. It is three inputs to decisions being made elsewhere.

A maximum viable certificate chain size, which constrains hierarchy design and parameter selection. Where an appliance rejects chains above a given size, that determines whether ML-DSA-44 or ML-DSA-65 is viable, and how many intermediates the hierarchy can carry.

A list of assets requiring replacement rather than upgrade, which enters capital planning with a lead time rather than arriving as a surprise during rollout.

A set of procurement requirements, derived from what failed. Each failure becomes a specification line for the next refresh, which is how most of the migration cost is avoided, as set out in funding post-quantum migration through refresh cycles.

Scope and sequencing

A proportionate lab is small. For most organisations a focused environment covering the four component types, run over a period of weeks rather than months, produces the findings that matter. Extending it into a permanent capability is worthwhile only where the organisation expects continuous cryptographic change, which larger and more regulated estates generally do.

The sequencing that works is to run the lab after discovery and before platform selection. Running it before discovery means testing the wrong things, because the estate's composition is unknown. Running it after platform selection means the findings arrive too late to influence the decision they should have informed.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We design and run post-quantum test environments scoped to the constraints of the estate rather than to a vendor's demonstration path, building on the findings from our PKI health check so that the lab represents what is actually deployed. We then translate the results into hierarchy design through our PKI design and build practice, and into the certificate lifecycle management configuration required to operate it.

Because we are vendor-neutral, the lab is scoped to test the estate rather than to demonstrate a product, and a legitimate outcome is that a purchase is deferred.