Two suppliers can both advertise post-quantum capabilities while their products still fail to connect in your environment. One may support a key-establishment mechanism in a particular client library. The other may expose it only behind a managed gateway. Your application also depends on proxies, certificates, monitoring and operational ownership.
For a UK organisation buying a long-lived system, this makes interoperability a useful near-term investment. A small pilot can test one important connection and identify which supplier must change what. It turns a broad future-readiness statement into an engineering decision that can influence today's contract.
A migration timeline is a planning tool
The NCSC's migration guidance sets indicative milestones: discovery and an initial plan by 2028, highest-priority migration activities by 2031, and completion by 2035. The guidance recognises differences between sectors and technologies. These milestones should inform a UK organisation's planning; they are not a claim that every business has an identical statutory deadline.
A procurement decision made now may affect systems operating across those dates. Buyers can ask for documented upgrade dependencies and support commitments without pretending that every component is ready for immediate replacement. The first useful question is which business connection would be expensive or slow to change later.
An algorithm is only one layer of a connection
NIST published FIPS 203, the ML-KEM standard, on 13 August 2024. It specifies a mechanism for establishing a shared secret. It does not specify your application's complete transport protocol, certificate deployment or upgrade process. The publication page also records a potential-update notice, which is another reason to track implementation versions and maintenance.
Separate three questions when reviewing a supplier's answer. Which cryptographic mechanism is implemented? How is it used within the selected protocol? Which product versions and operating modes support that combination? A slide listing an algorithm answers only part of this discussion.
Authentication and key establishment also deserve separate entries in the design. Improving one does not automatically replace every cryptographic dependency in the other. Ask the supplier to identify the remaining dependencies rather than presenting the entire connection as a single green status.
Pick the awkward connection, not the easiest demonstration
Consider an illustrative UK engineering business sending confidential design packages to a specialist analysis service. Its outbound traffic passes through a corporate proxy, and the receiving service sits behind a gateway operated by another supplier. A successful direct connection between two developer laptops says little about that route.
The pilot should reproduce the actual chain using non-sensitive data. Record the client library, proxy, gateway, server and relevant configuration. Establish which party can update each component. If the gateway terminates a connection, distinguish the external segment from any separate connection to the application behind it.
This boundary drawing often produces the most valuable result. It may reveal that your application team cannot enable the advertised capability until a managed service changes its supported configuration. That is a supplier coordination issue to resolve before committing to a delivery date.
Compare a feature demonstration with an integration experiment
A demonstration asks whether a vendor can make its preferred setup work. An integration experiment asks where your intended setup stops working and what evidence explains the failure.
Begin with a known working baseline, then change one part of the connection. Capture the negotiated configuration and observable errors through approved diagnostic methods. Measure resource use, latency and failure behaviour using your workload rather than importing a vendor's performance percentage.
Include older supported clients and the intermediary devices your business still needs. Establish whether a failure is explicit or whether the system quietly uses another mode. Any permitted fallback should have a named owner, a visibility mechanism and conditions for removal. Availability and confidentiality decisions belong in the risk discussion; they should not be hidden in a library default.
Ask for evidence that survives the sales cycle
The useful output is a compact compatibility record attached to tested versions. It should identify successful combinations, unsuccessful combinations, open dependencies and the person responsible for each next action. Keep enough configuration detail to reproduce the result without including production keys or customer information.
Request a description of how future updates affect that evidence. A new proxy version, certificate service or software library can change the result. Decide which changes trigger another connection test and which can use a narrower regression check.
Our cryptographic inventory guide covers discovering dependencies. The interoperability pilot starts after selecting one of those dependencies and follows its behaviour across organisational boundaries. It should remain small enough to produce a decision instead of becoming an unbounded replacement programme.
Put support and reversibility into the commercial scope
Ask each supplier who investigates a failed connection when both ends pass their own tests. Agree the evidence they need, the supported diagnostic tools and the escalation path between organisations. A shared issue owner matters when remote teams work across different support windows.
Keep a controlled route back to the previously approved configuration where your risk assessment permits it. Reversibility does not justify leaving an indefinite exception. Define the event that ends the pilot, the conditions for wider deployment and the unresolved questions that prevent expansion.
When comparing bids, separate discovery, the connection experiment and later implementation. A proposal can be useful even if the pilot concludes that a dependency is not ready. Finding that limitation before a large purchase is a concrete outcome.
Turn one tested connection into a buying decision
A good pilot ends with a choice: proceed on the tested path, negotiate a dependency change, defer a particular connection or replace an unsuitable component. It should not claim that the whole organisation is quantum-safe because one experiment succeeded.
TuniCyberLabs can discuss remote integration and security engineering work with UK teams. Explore our cybersecurity services, then send the connection, suppliers and upgrade constraints you need to assess. The initial scope should establish a reproducible experiment and the decision it needs to support.