A quantum-safe pilot must prove rollback.

A quantum-safe pilot is not a smaller version of a transformation programme. It is a controlled way to learn what changes at one real boundary, what the business depends on and how the team will recover if the experiment exposes a compatibility problem. The strongest pilot result is not a label that says “quantum safe”. It is evidence that a specific change can be tested, monitored and reversed.

NIST's Migration to Post-Quantum Cryptography project treats cryptographic discovery and interoperability testing as complementary work. Discovery shows where public-key cryptography is used; a bounded test shows what happens when an implementation or protocol changes. CISA and its partners also describe migration as a multi-year effort that needs a roadmap, an inventory, risk assessment and vendor engagement. A pilot gives those activities a practical place to begin.

Define what the pilot must prove.

Start with one named boundary: a test endpoint, a non-critical service, a signing workflow or a supplier integration. Write the question in operational language. For example: can this service establish the required connection with the selected implementation, preserve authentication, remain observable and return safely to the current configuration if a dependency fails?

Test a path you can observe.

A pilot should make the changed path visible to the people who operate it. Use a non-production or canary boundary where possible, keep the data scope deliberately small and confirm that monitoring can distinguish a cryptographic failure from an ordinary application or network fault. If a hybrid configuration is used, document precisely what it combines and what it does not demonstrate. A hybrid result is evidence about that tested path, not proof that every client, certificate, internal service and backup is covered.

Do not measure only whether a handshake completed. Larger keys, signatures or certificates can affect packet size, latency, memory, CPU, gateway limits, logging and incident response. Record the baseline and the changed result under the same conditions so the team can explain the difference rather than relying on a subjective impression that the new path “felt fine”.

Prove the way back before you expand.

Rollback is not an admission that the pilot failed. It is part of the safety case. Before changing the boundary, confirm which configuration is authoritative, how it is restored, how certificates or keys are handled, who approves the reversal and how operators know the old path is healthy again. Test the recovery in the same environment where the change will be evaluated. A document that says “revert if needed” is not a rollback test.

The output should be a migration packet: the tested boundary, configuration and versions, observations, compatibility limits, performance impact, monitoring evidence, rollback result, unresolved questions and the next decision. Keep the packet small enough for a service owner to review and specific enough for an engineer to reproduce.

A pilot earns trust by making uncertainty smaller, not by making the claim larger. Begin with one inventory row from the decision queue, define the evidence that would change its priority and test the smallest reversible boundary. The Q-Ready Check can provide a public-signal starting point; a controlled pilot shows what the organisation can safely do next.