Post-quantum readiness just became a procurement question

On November 4, three government cybersecurity agencies published a document that does not tell anyone to do anything. It just lists questions. Nineteen pages of them, aimed at one specific conversation: the one between a buyer and a vendor, at contract renewal time.

The document is called "Post-quantum questions to ask your vendors: Evaluating third-party readiness for post-quantum cryptography." It comes from the NSA, CISA, and Australia's cyber security centre, ASD's ACSC. Australia published the first version in July. This November update turns it into a joint edition, and it arrives one week after NIST published its final transition plan, the one that says RSA and elliptic-curve cryptography become deprecated after 2030 and disallowed after 2035.

That timing is not a coincidence. The policy now exists. The deadlines now exist. The question this new guidance asks is different, and harder: can the people who sell you software actually get there?

The swap is not the hard part

For the last two years, most of the post-quantum conversation has sounded like a shopping list. Replace RSA with ML-KEM. Replace ECDSA with ML-DSA. NIST published the standards in 2024, the libraries are shipping, and the algorithms themselves are, by now, the solved part of the problem.

I know this from the inside, in a small way. I built my own encrypted messenger, and its protocol runs on ML-KEM-768 for key exchange and ML-DSA-65 for identity signatures. When I wrote that code, I knew exactly which algorithm sat in which place, because I put it there myself. That is the luxury of building something from scratch. Almost nobody else has it.

Most organisations do not build their cryptography. They buy it, inside products, inside libraries, inside firmware, inside cloud services they never see the source of. Their encryption is a stack of other people's decisions, and a surprising number of those decisions are undocumented. The new guidance starts from that fact. Its first phase is not "implement." It is "locate."

Know what is actually in the box

The centrepiece of the guidance is a simple idea with an unglamorous name: the cryptographic bill of materials, or CBOM. It is an extension of the software bill of materials, and it lists every algorithm, library, protocol, parameter set, and configuration a product depends on, including the ones inherited from third parties.

That sounds like paperwork. It is actually the whole migration, compressed into one artefact. You cannot plan a transition for cryptography you cannot see. A vendor that cannot produce a CBOM is a vendor that does not know its own product well enough to migrate it, and the guidance is blunt about what a good answer looks like: a complete, current inventory, actively maintained, covering authentication, signing, and data protection in transit and at rest.

The questions that follow are the ones I wish more people asked before they signed a renewal. Is any cryptography hardcoded, or bound to hardware? Can the firmware and the boot process accept a post-quantum signature without replacing the device? Which product versions are covered, and when, exactly, will a post-quantum-ready release ship, with enough time left to test and deploy it before the end of 2030?

That last question matters because of the way the guidance treats 2030. It is a planning milestone drawn from Australia's own transition objectives, not a universal deadline. The document does not impose dates, name algorithms, or name products. It is vendor-neutral guidance, not a mandate. But a vendor that cannot give you a dated release plan is telling you something, even if the guidance never says so out loud.

Firmware is where migrations go to die

The part of the guidance that stuck with me most is the firmware question, because it is where the abstract risk turns physical.

A server can be patched. A phone app can be updated. But a device whose boot chain verifies firmware with an RSA signature has that signature baked into its trust model. If the hardware cannot verify a post-quantum signature, the upgrade path is not a software update. It is a replacement. The guidance asks vendors to explain how the existing trust mechanism transitions, and whether older units simply have to go.

I think about this every time I work on Android, because I have spent enough time with rooted phones and custom modules to know how much trust lives below the operating system. The bootloader, the verified boot chain, the keys that decide whether a piece of firmware is allowed to run: all of it is cryptography, and almost none of it is visible to the person using the device. A migration plan that covers the app layer and forgets the boot chain is not a migration plan.

The same logic applies to the cloud, only the hardware is someone else's. A managed service can be post-quantum ready in its marketing and still depend on a library three layers down that is not. The CBOM is supposed to catch exactly that: the dependency you did not know you had, inherited from a supplier your supplier never audited.

What this means if you build things

There is a temptation to read a document like this as something for procurement departments and government buyers. It is, and it is also a checklist for anyone who ships software, including people building things alone.

Here is the honest version of that checklist, the one I would hand to a developer who asked me where to start:

First, write down your own cryptography. Not a formal CBOM, just a list: which algorithms, which libraries, which protocol versions, where each one lives in your system. If you cannot produce that list for your own project, you are in the same position as the vendor the guidance is warning about.

Second, look for the places where cryptography is hard to change. A signature scheme baked into a file format. A key type assumed by a database column. A protocol version pinned in a client you cannot force to update. Those are the spots that will hurt later, and they are cheaper to find now.

Third, treat crypto-agility as a design property, not a feature. When I built my messenger's protocol, the decision that mattered most was not which algorithm I picked. It was making the algorithm a parameter, so the protocol could move to a different one without being rewritten. That is the same property the guidance is asking vendors to demonstrate, at product scale.

Fourth, plan around data lifetime, not algorithm lifetime. The agencies are careful to say that no cryptographically relevant quantum computer exists today, and they give no arrival date. The risk they describe is narrower and more concrete: data intercepted now can be stored and decrypted later, so anything that must stay secret for years should be protected by post-quantum cryptography sooner than the deadlines suggest. If your data has a long shelf life, your deadline is earlier than the official one.

A question, not a mandate

The guidance ends the way it begins: with questions, not orders. Organisations are told not to ask every question of every vendor. A small supplier and a cloud provider get different conversations. The point is that the conversation happens at all, at renewal time, while there is still leverage, instead of in 2030, when there is none.

That is the real shift here. For years, post-quantum migration was framed as an engineering project with a distant deadline. This document reframes it as a purchasing decision with a near one. The next time a contract comes up for renewal, somebody on the buying side is supposed to ask where the cryptography is, who controls the upgrade, and when the post-quantum version ships. The vendors who can answer will keep the contract. The ones who cannot will have to explain why.

If you build software, do not wait for someone to ask you those questions. Ask them of yourself first, while the answers are still cheap.

---

Sources: ASD's ACSC / CISA / NSA, "Post-quantum questions to ask your vendors" (November 2026); NIST IR 8547, "Transition to Post-Quantum Cryptography Standards" (October 2026).