Follow the service beyond your boundary
A quantum-readiness programme should ask where its control ends. A business service may depend on a hosted application, a managed connection or another organisation's signing infrastructure. In those situations, documenting your own configuration does not establish how the external dependency is protected or when its cryptography can change.
NCSC advises enterprise system owners to communicate with IT suppliers about plans for supporting post-quantum cryptography. That conversation should be attached to a specific service and use case. A general statement of intent is a useful opening, but it does not answer whether the product configuration you rely on has an upgrade path.
Use observation for what it can establish
QUAMO applies outside-in observation to supplier domains and public-facing services, creating a comparable view of observable cryptographic posture. It can place supplier exposure alongside business dependency and harvest-now, decrypt-later context. This gives procurement and risk teams technical evidence with which to begin a more focused discussion.
Keep the boundary of that evidence explicit. An observation of a public service should not be treated as proof of the supplier's entire internal architecture, data handling or readiness. Record what was observed and when. Where the programme needs assurance about an unobserved path, seek additional evidence rather than extending the scan's conclusions beyond its scope.
Ask questions that change the plan
We recommend asking suppliers which relevant cryptographic functions they control, which product versions are affected and how customers will receive supported upgrades. Establish whether adoption requires configuration changes, new components or a service transition. Ask who will provide implementation guidance and what evidence will demonstrate compatibility with your environment.
Separate availability from deployment. A supplier may support a capability that is not enabled in your service, or an upgrade may depend on another party. Request a clear account of those dependencies. Where answers remain provisional, retain them as planning assumptions with an owner and a review point, rather than recording them as completed controls.
Prioritise the business dependency
Not every supplier requires the same depth of investigation. Start with the services whose interruption or loss of protection would matter most, then consider the information involved and how long it must remain confidential. NCSC's harvest-now, decrypt-later discussion highlights the relevance of very high-value information needing long-term protection; it does not establish equal risk across a supplier portfolio.
Use that context to decide where observation is sufficient for an initial assessment and where direct technical engagement is necessary. A critical dependency with an unclear upgrade route may deserve attention before a less consequential service with more visible findings. Prioritisation should explain that judgement, rather than turn a raw scan result into an automatic procurement decision.
Carry supplier evidence into migration waves
Supplier readiness should influence the sequence of internal work. Map prerequisite upgrades, customer responsibilities and acceptance checks into the service's migration plan. Agree how material changes will be communicated and when evidence will be refreshed. Procurement, engineering and risk teams should work from the same account of the dependency instead of maintaining incompatible versions.
QUAMO turns discovery evidence into prioritised migration waves, while Cystel supports controlled implementation. No product fully automates post-quantum cryptography migration, and external dependencies reinforce that limit. The goal is not to declare every supplier safe. It is to make uncertainty visible, secure useful commitments and build a transition plan that reflects who can actually deliver each change.