NSA, CISA and Australia's ACSC turn post-quantum readiness into a vendor checklist

Joint guidance aimed at the renewal conversation

On November 4, the NSA, CISA and the Australian Signals Directorate's Australian Cyber Security Centre jointly released a document titled "Post-quantum questions to ask your vendors: Evaluating third-party readiness for post-quantum cryptography." According to a write-up on dev.to, the 19-page document issues no directives at all — it consists of questions, and it targets one specific moment: the exchange between a buyer and a supplier when a contract comes up for renewal.

Australia's ACSC published the original version in July; the November release makes it a joint edition. As the dev.to post points out, the timing is deliberate. The document landed roughly a week after NIST published its final transition plan, under which RSA and elliptic-curve cryptography become deprecated after 2030 and disallowed after 2035.

Locate the cryptography before replacing it

The argument running through the guidance is that most organisations never build their own cryptography. They buy it embedded in products, libraries, firmware and cloud services whose source they never inspect, so their encryption amounts to layer upon layer of decisions made by others, many undocumented. The first phase of migration, on this reading, is not implementation but discovery.

The centrepiece is the cryptographic bill of materials (CBOM), an extension of the software bill of materials. It is meant to enumerate every algorithm, library, protocol, parameter set and configuration a product depends on, including components inherited from third parties. According to the dev.to summary, the guidance treats a complete, current and actively maintained inventory — spanning authentication, signing, and data protection in transit and at rest — as the baseline of a credible vendor answer.

The follow-up questions target the awkward spots: whether any cryptography is hardcoded or bound to hardware, whether firmware and the boot process can verify a post-quantum signature without the device being replaced, which product versions are covered, and exactly when a post-quantum-ready release ships — with enough lead time left to test and deploy it before the end of 2030.

Firmware and the marketing-ready cloud

Firmware receives particular attention because it is where an abstract risk turns into a hardware budget line. A device whose boot chain verifies firmware using an RSA signature has that choice built into its root of trust. If the hardware cannot validate a post-quantum signature, the remedy is new equipment rather than an update, and the guidance asks vendors to explain how their existing trust mechanism transitions — and whether older units are simply stranded.

The same logic applies to cloud services, the dev.to author notes, except the hardware belongs to someone else. A managed service can be marketed as post-quantum ready while still resting on a dependency several layers down that is not. Surfacing that kind of inherited, unaudited dependency is precisely what the CBOM is designed to do.

Questions, not a mandate

The document is vendor-neutral guidance rather than a rulebook: it sets no deadlines, names no algorithms and names no products. The 2030 date in its questions reflects Australia's domestic transition objectives, not a universal cutoff. The agencies also state that no cryptographically relevant quantum computer exists today and offer no arrival date. The risk they describe is narrower and more concrete: traffic captured now could be stored and decrypted once such machines exist, so data that must stay confidential for many years justifies moving earlier than the official timeline suggests.

Buyers are also told not to interrogate every supplier identically — a small vendor and a hyperscale cloud provider warrant different conversations. The point is that the conversation happens at renewal time, while the buyer still has leverage.

Why it matters

For the past two years, post-quantum migration has been framed as an engineering effort with a distant deadline, and NIST's 2024 standards for ML-KEM and ML-DSA have made algorithm selection the comparatively solved part of the problem. This document reframes the remainder as a purchasing decision with a near-term one. Vendors should now expect customers to arrive at contract renewal asking where the cryptography lives, who controls the upgrade path, and when the post-quantum release is dated for. The dev.to author's blunt read is that a supplier unable to produce a CBOM or commit to a schedule is effectively admitting it lacks a full picture of its own product. For anyone shipping software, the practical move is to answer these questions internally first — inventory your algorithms, find where crypto is hard to change, and treat algorithm agility as a design property — before a customer asks them across the table.