PQC supplier questions after G7 call

Retrospective covering 7 September 2026, written on 9 September 2026.

PQC supplier questions should now be part of renewal planning for services that protect important information. My recommendation is to ask suppliers for a product-specific transition plan and evidence of its scope. A general promise about quantum readiness does not show whether your organisation's actual connections and applications are covered.

The G7 Cybersecurity Working Group's call to action, described on a Canadian Cyber Centre page dated 3 September and covered by ITPro on 7 September, urged a phased transition to post-quantum cryptography. It highlighted uncertainty about the arrival of relevant quantum computers and the risk of encrypted information being collected for later decryption. Official publication, 7 September coverage.

Turn the warning into a procurement question

The official call includes integrating PQC into cybersecurity requirements and identifying cryptographic assets and dependencies. That makes a supplier conversation a concrete first step, rather than waiting for a complete internal migration programme. Canadian Cyber Centre summary.

Start with the services your organisation actually buys. Ask which ones protect information that needs to remain confidential for a long time, which support important authentication and which would be difficult to change quickly. Your business owners should help determine those priorities.

Use the existing post-quantum implementation checklist for the wider programme. This article concentrates on obtaining usable supplier answers at procurement and renewal, rather than repeating that technical checklist.

Ask what the roadmap covers

A useful supplier answer names the relevant product, version and configuration. Ask whether the statement concerns a released capability, a preview or future work. Keep those categories separate in your review so an aspiration does not become an assumed control.

Ask the supplier to draw the paths through the service. Which connections, interfaces and supporting components are included? Which depend on another vendor? Have them mark any part that has not yet been assessed.

Do not prescribe an answer before understanding the architecture. Your goal is to establish scope and responsibility. If the supplier cannot explain its dependencies clearly, record that as a gap in the evidence and agree a follow-up.

Separate the promise from delivery

Request the evidence appropriate to the supplier's current stage. A released feature should have documentation and a way to verify the intended configuration. A roadmap should have ownership, dependencies and an update schedule. Neither needs to be presented as more mature than it is.

Ask how customers will hear about changes. A date in a sales presentation is less useful if the service owner never receives an update when it moves. Name the contact in your own organisation who will track the issue and make sure the supplier has that contact.

Where the next renewal is approaching, include the migration dependency in the commercial review. Ask what happens if a required capability remains unavailable during the contract term. The appropriate contractual response belongs with your procurement and legal advisers; the technical team's job is to explain the dependency accurately.

The ICT supplier risk guide gives you a broader structure for recording those discussions and escalating material gaps.

Make testing part of the answer

Ask the supplier how it expects customers to validate the change in their own environment. Include older clients, external partners, specialist applications and recovery processes where they are relevant. Do not assume the newest demonstration represents every device or integration you operate.

Plan a bounded test with the service owner. Record the configuration, the expected business behaviour and the evidence needed to approve rollout. Include a way to stop or reverse the change if the service cannot complete its normal work.

Treat performance and operational support as acceptance questions. Ask who will investigate an unexplained failure and what diagnostic information they will need. A technically promising change still needs a support process that your organisation can use.

Prioritise the suppliers that matter most

Bring procurement, the application owner and the security lead into the same conversation. A roadmap can be technically credible yet unusable if its delivery depends on a renewal decision that nobody has scheduled.

Do not send an enormous questionnaire to every supplier and count replies as progress. Begin with a small set linked to important information or difficult-to-replace services. Use those conversations to improve the questions before expanding the review.

For each supplier, record the business consequence, the relevant product, the current evidence and the next decision. If the answer is incomplete, decide whether to seek clarification, require a test, adjust the renewal or accept a time-bound uncertainty. Give that decision an owner.

Bring material dependencies into the IT risk register. The entry should explain what could affect the business and what is being done, rather than simply stating that quantum computing exists.

My suggested outcome for the next review is a short list of prioritised services with credible supplier contacts and dated evidence requests. That is a manageable action for an SME and a useful foundation for a longer migration. It replaces an abstract future concern with decisions the organisation can track.