CISA, NSA and Australia’s ACSC Publish Post-Quantum Questions to Ask Your Vendors

On November 5, 2026, the U.S. Cybersecurity and Infrastructure Security Agency, the National Security Agency, and the Australian Signals Directorate’s Australian Cyber Security Centre published joint guidance titled “Post-Quantum Questions to Ask Your Vendors,” with an accompanying quick-reference list. The document is not a new algorithm standard. It is a procurement and assurance playbook for organizations whose cryptography lives mostly inside someone else’s cloud, appliance, or managed service—and who cannot finish a post-quantum transition if their suppliers never ship one.

Why vendor questions, not another algorithm FAQ

A cryptographically relevant quantum computer, or CRQC, would break widely deployed public-key cryptography used for key exchange, digital signatures, and many authentication schemes. Post-quantum cryptography, or PQC, is the family of algorithms designed to resist both classical and quantum-enabled attacks. National agencies have already published migration roadmaps and algorithm selections. What still stalls programs, the new guidance argues, is the supply chain: vendors choose and implement the crypto inside products and services that customers cannot easily rewrite.

That dependency is sharpest where cryptography is embedded, hard to update, and tied to long asset lives—industrial control systems, Internet of Things devices, building management, physical access systems, on-premises legacy stacks, and network gear. Cloud software-as-a-service, managed service providers, identity platforms, and backup services create a different problem: the customer may never see the libraries at all. In both cases, an organization’s transition timeline becomes the vendor’s roadmap plus the customer’s testing window. Late surprises—discovering a critical product cannot support PQC before a required date—are exactly what the authoring agencies want early questions to prevent.

Privacy and security teams already know the pattern from other cryptographic readiness pushes, including sector warnings about the AI-era threat to encryption readiness and the technical migration work captured in NIST IR 8547 on post-quantum migration. The November guidance translates that urgency into something contract managers can paste into an RFP or a renewal questionnaire.

How the questions are organized

The authoring agencies align the questions to high-level PQC transition phases drawn from ASD’s ACSC LATICE framework, as laid out in the agencies’ post-quantum vendor questions publication: locate and inventory cryptographic dependencies; assess risk to individual systems; triage and prioritize systems for transition; implement PQC algorithms; and communicate with vendors and educate stakeholders. Depth should scale with risk, how much cryptographic control the vendor holds, data sensitivity and longevity, and how far the organization is into its own migration.

The agencies are explicit that some vendors will not have detailed answers at first. Willingness to engage transparently, discuss constraints, and show progress can itself signal maturity. Opaque hand-waving is a risk indicator, not a free pass.

Locate: inventory before you negotiate

The locate phase asks whether the vendor maintains a current inventory of cryptographic dependencies—such as a cryptographic bill of materials (CBOM) or equivalent—covering algorithms, libraries, protocols, parameters, and configurations, including third-party and embedded components. Related questions probe where cryptography is implemented across application, operating system, middleware, hardware, and firmware layers; whether any of it is hardcoded, fixed, or hardware-bound; whether third-party dependencies introduce crypto; how cryptography is updated; whether products rely on hardware roots of trust; how firmware authenticity is verified; and whether firmware and boot processes can be updated to support PQC signature schemes without hardware replacement.

For privacy teams, the CBOM point mirrors the software bill of materials conversation already underway in vendor security questionnaires: you cannot protect what you cannot name. A vendor that cannot list the algorithms protecting authentication and data in transit is asking the customer to underwrite unknown residual risk.

Assess: lifespan, harvest-now risk, and auth bottlenecks

Assessment questions ask which customer data flows rely on traditional asymmetric cryptography; what assumptions the product makes about data lifespan and whether customers can configure retention; whether the vendor has a documented, product-specific CRQC risk assessment; whether it distinguishes signing, encryption, and authentication risks; whether customers can choose stronger classical settings today; and which authentication mechanisms still depend on traditional public-key crypto.

The guidance is careful on one common misconception. Stronger classical settings, such as larger key sizes, may offer only marginal short-term risk reduction and are not a substitute for transitioning to PQC. Long-lived confidentiality requirements face “harvest now, decrypt later” exposure: adversaries can store ciphertext today and break it when a CRQC arrives. Authentication systems with long replacement cycles—certificates, smartcards, tokens—can become critical bottlenecks even when encryption paths look manageable.

Triage: 2030, hybrids, and governance

Triage questions press for product- and version-specific commitments: which offerings will be PQC-ready early enough to support customer rollout before the end of 2030; which components need hardware replacement or re-architecture; whether the vendor supports post-quantum/traditional (PQ/T) hybrid modes only as a temporary bridge and how it will move to PQC-only; how customer risk shapes prioritization; and what internal governance oversees the transition.

The end-of-2030 milestone reflects ASD planning objectives cited in the publication footnotes and is framed as a planning target for vendor discussions, not a universal legal deadline for every jurisdiction. Organizations should align dates with the guidance that applies to their sector and country. Hybrid modes get a clear warning: useful for interoperability during transition, not a long-term resting place, because a CRQC would still break the traditional half.

Implement and communicate

Implementation questions ask which standards-based PQC algorithms will be supported and when; whether implementations are production-ready rather than experimental; how cryptographic libraries are validated and maintained; how key management, certificate sizes, and lifecycles change under PQC; how customers enable PQC; and whether PQC is included in base licensing rather than sold as a premium add-on. Communication questions cover customer notification of cryptographic changes, transition guides, deprecation timelines for traditional crypto and interim hybrids, support-team training, roadmap alignment with authoritative guidance through 2030, and engagement with PQC standards bodies.

Paywalling PQC is called out as a procurement red flag. If quantum-resistant crypto is an upsell, adoption will be uneven and high-risk customers may lag for budget reasons rather than technical ones.

Common weak answers—and what they mean

The guidance lists recurring concerns in vendor responses: limited visibility of cryptographic use; reliance on general assurances; unclear or deferred transition timelines; proprietary or opaque cryptography; treatment of PQC as optional or premium; over-reliance on compensating controls; and lack of governance or ownership. None of these automatically ends a relationship. They do force a risk decision: accept, compensate, accelerate replacement, or walk. That is the same logic that underpins mature third-party risk management compliance programs, where a questionnaire answer is an input to residual-risk acceptance, not a certificate of safety.

A six-step PQC vendor checklist for renewals

Use the joint questions as a living control inside procurement, not as a one-time PDF on a SharePoint site. The following sequence fits most renewals and new RFPs.

1. Inventory your own crypto exposure first. Know which vendors protect long-lived personal data, authentication, code signing, backups, and operational technology. Prioritize those conversations.
2. Send the locate and assess questions early. Ask for a CBOM or equivalent, hardware-bound crypto disclosures, and a product-specific CRQC assessment before you negotiate term length.
3. Demand dated PQC-ready commitments. “We are monitoring NIST” is not a roadmap. Ask which versions will support customer testing and production rollout before end-2030 planning milestones.
4. Constrain hybrids in the contract. If PQ/T hybrid is offered, require a documented de-hybridisation plan and a path to PQC-only.
5. Ban premium-only PQC in high-risk scopes. Treat base-license inclusion as a security requirement for systems that process sensitive or long-retention data.
6. Wire answers into onboarding and offboarding. Store responses next to other assurance artifacts collected during third-party onboarding, and re-ask at renewal. Weak crypto answers age badly; so do ignored ones. Documented vendor failures elsewhere already show how fines for third-party non-compliance land on the customer that kept the relationship without updating controls.

Frequently asked questions

Is this guidance mandatory?

No. It is joint advisory material from CISA, NSA, and ASD’s ACSC. Binding requirements, if any, come from sector regulators, contracts, or national directives that reference related PQC timelines—not from this questionnaire alone.

Does asking these questions replace a crypto inventory?

No. Vendor answers supplement an organization’s own locate-and-inventory work. If you cannot name which systems still rely on RSA or elliptic-curve cryptography for long-lived data, vendor roadmaps will not save the migration calendar.

Should we accept PQ/T hybrid forever?

The authoring agencies treat hybrid modes as transitional. Plan for PQC-only once interoperability goals are met; a CRQC would undermine the classical component.

What is a CBOM in this context?

A cryptographic bill of materials extends software bill of materials concepts with elements that document algorithms, libraries, and configurations. The guidance cites CBOMs as one way vendors can keep a current inventory of cryptographic dependencies.

The questionnaire is the migration

Post-quantum work often stalls in the gap between a national roadmap and a purchase order. CISA, NSA, and Australia’s ACSC have tried to close that gap with questions short enough for a renewal packet and sharp enough to expose hardware locks, premium upsells, and roadmap fog. Organizations that wait for a CRQC headline before asking them will discover that the critical appliance’s boot chain was never agile—and that the contract just auto-renewed for another five years.