Knowing what to migrate is the easy half.
A sandbox where a post-quantum change is made and proved before it goes anywhere near production: a standalone ML-DSA certificate authority, sixteen migration templates covering the flows that actually break, and a harness that asserts against a captured handshake rather than a vendor's claim.
Discovery tells you where the problem is. This is where you find out what the fix costs before you commit to it.
The migration fails in the places nobody tested.
Post-quantum algorithms are standardised and the libraries exist. What is missing is the answer to a much more boring question: what happens to your actual stack when you turn them on.
Vendor support is a claim
A release note saying a product supports ML-KEM is not the same as your build of it, on your platform, negotiating it with your peer. The only proof is a handshake you captured yourself.
Certificates get much bigger
ML-DSA keys and signatures dwarf their classical equivalents. Things that never had a size limit worth thinking about — packet buffers, header limits, embedded stores — start failing in ways that look like anything but a crypto problem.
Middleboxes have opinions
Inspection proxies, load balancers and firewalls sit between the two ends you tested. A handshake that works on a bench can be silently downgraded or dropped in the path that matters.
There is nowhere to test against
Post-quantum mutual TLS needs a post-quantum CA to issue both ends. Public CAs do not issue ML-DSA certificates, so without your own hierarchy the test cannot be run at all.
It negotiated ≠ it works ≠ it works at your volume
Three different tests. The kit runs all three and keeps the evidence.
Change it, capture it, assert on it.
Every template is the same shape, so the output is comparable across sixteen very different technologies.
Stand up
A compose foundation brings up the private post-quantum CA, the peers and the capture harness. Self-tests confirm the environment before any template runs.
Run
A template configures one real flow — edge TLS, an SSH key exchange, an IPsec tunnel — with the hybrid or post-quantum change applied to both ends.
Assert
The handshake is captured and the assertions run against the packet capture. What was negotiated is read off the wire, not off a log line that says it should have been.
Translate
Each result names the production-equivalent configuration on a supported stack. The sandbox proves the mechanism; the result tells you what to actually deploy.
What is in it.
Assembled because each piece turned out to be a prerequisite for the next, not because a kit needed filling out.
A standalone post-quantum PKI
ML-DSA-87 root, ML-DSA-65 issuing
A full EJBCA hierarchy on a hardware-backed token, with certificate profiles, CRL distribution and enrolment. You cannot test post-quantum mutual authentication without a CA that will issue post-quantum certificates, and no public one will.
Sixteen migration templates
Eight hybrid KEM, eight ML-DSA
One per flow that realistically breaks: edge TLS, service-to-service by runtime, application-to-database, SSH, IPsec, MQTT and QUIC, key wrapping, code signing, AS2 and CMS, OpenPGP, enrolment protocols and mutual TLS.
An evidence harness
Capture, assert, load
Each run captures the handshake and asserts against the capture, then measures under load. A result is a packet capture plus a pass or fail, not somebody's recollection of a successful test.
A capacity template
What breaks when things grow
A dedicated run for the size problem: what larger keys and certificates do to handshake latency, throughput and the buffers in between. Usually the finding that changes the migration plan.
A middlebox pass
The path, not the endpoints
Edge TLS is additionally run with an inspection device in the path, because a change that works end-to-end and fails through the proxy is the failure mode that reaches production.
A pinned reference stack
Reproducible, not approximately
Versions are locked and recorded, so a result from three months ago can be reproduced and a regression can be attributed to a specific change rather than argued about.
The rule of the kit: the test peers are reference and harness only. Every result names the production-equivalent configuration separately, so nothing in the sandbox is ever mistaken for deployment advice.
The templates.
Phase one applies hybrid key exchange with classical authentication. Phase two puts ML-DSA at both ends on the private hierarchy.
| Template | Flow | Phase |
|---|---|---|
| T1 | Edge TLS termination, including a middlebox pass | Hybrid KEM |
| T2 | Service-to-service TLS, per language runtime | Hybrid KEM |
| T3 | Application-to-database TLS | Hybrid KEM |
| T4 | SSH and SFTP key exchange | Hybrid KEM |
| T5 | IPsec and IKEv2 | Hybrid KEM |
| T6 | TLS-VPN and machine-to-machine — MQTT, QUIC | Hybrid KEM |
| T7 | Data at rest and key wrapping | Hybrid KEM |
| T8 | Symmetric and hash uplift | Hybrid KEM |
| T1 | Private ML-DSA hierarchy | ML-DSA |
| T2 | Enrolment protocols with ML-DSA | ML-DSA |
| T3 | Private-CA mutual TLS, ML-DSA both ends | ML-DSA |
| T4 | AS2 and CMS-signed payloads | ML-DSA |
| T5 | OpenPGP-signed file flows | ML-DSA |
| T6 | Code and firmware signing | ML-DSA |
| T7 | SSH signatures | ML-DSA · pilot |
| T8 | Capacity — what breaks as keys and certificates grow | ML-DSA |
Each template ships as a compose overlay, a run script and a guide, and produces a results file in the same format as every other.
Where it is, honestly.
This is the newest thing we build and the one with the most still in front of it. Stated plainly rather than dressed up.
In development
The post-quantum PKI is standing and issuing. The template suite is built and being worked through; the full dry-run across all sixteen is not finished.
It is a sandbox, not a production PKI
The certificate authority exists so post-quantum flows can be tested end to end. It is not an offer to run your PKI, and it is not intended to issue anything you depend on.
Hardware support is uneven
Post-quantum signing works on some token configurations and not others, which is a property of the HSM ecosystem in 2026 rather than of the kit. Where a limitation exists it is recorded against the run, not worked around quietly.
Reference peers are not recommendations
The open-source test peers exist to make a flow testable. What you should actually deploy is named separately in every result, on a stack with support behind it.
It informs a migration, it does not perform one
The output is evidence and a costed configuration. Changing your estate is still an engineering programme, which is what the advisory practice is for.
Delivered with an engagement
Today this runs as part of our work with you rather than as software you licence and operate yourselves.
The cheapest place to discover the migration does not work is here.
One flow, one template, one captured handshake. It is usually enough to turn an argument about whether post-quantum is ready into a specific, costed piece of engineering.