Post-quantum security depends on your suppliers

A standard does not upgrade a service

On 5 November 2026, Australia's cyber security agency announced updated guidance on evaluating suppliers' readiness for post-quantum cryptography, developed with CISA and NSA. It is intended for procurement, contract renewal and ongoing supplier assessment. The practical question is whether an organisation can replace vulnerable cryptographic mechanisms across the products it actually uses, including components controlled by other companies.

Our reading is that this creates a purchasing problem as much as a mathematical one. A customer can approve a migration budget without controlling the software library, appliance firmware or managed identity service that determines whether the migration can happen. A supplier's public commitment therefore needs a defined product scope and evidence of delivery. Neither an attractive roadmap nor a security badge establishes that an installed service has changed.

NIST's announcement of 13 August 2024 provides the technical starting point: it finalised standards for a key-encapsulation mechanism and digital signatures. ML-KEM supports establishing shared secrets; ML-DSA and SLH-DSA address signatures. These are distinct functions. Naming an algorithm in a product announcement does not show which connections use it, whether it is enabled, or what happens when a peer cannot support it. [2][3]

Dependencies determine the migration bill

The joint guidance asks suppliers about cryptographic inventories, third-party components, hardware-bound mechanisms and update paths. It also distinguishes risks to confidentiality from signing and authentication. Those questions matter because the same commercial product can contain several layers with different owners and replacement cycles. A software update may change one layer while leaving a hardware trust anchor untouched.

Consider a hypothetical financial service buying a managed platform. Its supplier says post-quantum support is available, but the commitment covers only a connection between selected servers. Customer applications, device firmware and a separate signing service are outside that statement. This is an illustrative procurement scenario, not an allegation about a named provider. The useful comparison is between the promised boundary and the customer's real dependency map.

In that scenario, the purchase price understates the transition cost. Testing, integration, support contracts and equipment replacement can sit in different budgets. Our inference is that a cheaper renewal can become expensive if it extends dependence on a component whose update path is uncertain. Conversely, replacing everything immediately can waste money when a supported upgrade is available. The evidence needed to choose is product-specific, not a general prediction about quantum computing. [1]

Three promises that require different evidence

A research demonstration answers whether something can work under specified conditions. A supported release answers what customers can deploy and maintain. A completed customer migration answers what is running in a particular environment. Treating these as interchangeable obscures the remaining work. The following comparison is our editorial assessment framework, not an official certification scheme.

• A roadmap should identify the product, responsible team, dependencies and delivery conditions. A date without those boundaries is difficult to enforce.
• A released capability should have documentation, supported configurations and a testable deployment path. A feature name alone is insufficient.
• An operational migration should have an inventory of the systems changed, test results and recorded exceptions. A successful pilot does not establish complete coverage.

This framework also gives a fairer interpretation of incomplete answers. A supplier that identifies an unresolved dependency and provides a credible plan may offer more useful information than one claiming universal readiness without boundaries. Lack of a detailed answer is a reason to investigate and manage exposure, not evidence that the company has been breached or is intentionally misleading customers. [1]

Confidentiality and availability need separate decisions

The guidance highlights the relevance of data lifetime, including the possibility that encrypted information collected today could be decrypted in the future. That concern does not mean every stored file or every cryptocurrency transaction is already exposed. The organisation must establish which cryptographic mechanisms protect the relevant information and how long its confidentiality matters. An agency questionnaire cannot answer those questions for an individual wallet or exchange.

Operational reliability needs its own acceptance criteria. In our hypothetical platform, a migration that interrupts access to customer records creates a separate business risk, even if the cryptographic design is appropriate. A sensible procurement discussion therefore includes who tests compatibility, who authorises the change and how service is restored if the deployment fails. These are our practical implications of supplier dependence, not guarantees supplied by the document.

For readers evaluating custody or financial technology, the defensible conclusion is narrower than a claim that a product is quantum-safe. Ask what part of the service has changed, what remains dependent on another supplier and what evidence supports the answer. The reviewed publications do not establish a date when a cryptographically relevant quantum computer will arrive, certify a specific provider, or predict the price of a digital asset. Their immediate value is making a long-term transition measurable before a purchasing decision locks in the wrong assumptions. [1]