Why vendors are the bottleneck
Most organizations don't choose their own cryptography. Vendors pick and implement the cryptographic mechanisms in the products, managed services and cloud services customers use, so an organization's PQC transition depends on its vendors' readiness, transparency and roadmaps.
The agencies' core concern is the cryptographically relevant quantum computer (CRQC). Such a machine could break widely used public-key cryptography. Organizations are urged to plan before one exists. The guidance does not say a CRQC exists today and does not give an arrival date.
The "harvest now, decrypt later" risk is part of the argument. An attacker can collect encrypted data today and try to decrypt it later. Data that must stay confidential for many years is therefore the most exposed.
The guidance also points to systems that are hard to patch. Examples include industrial control systems, IoT devices, building-management and physical-access systems, and legacy on-premises kit. Embedded cryptography and long equipment lifecycles can make a software update impossible and force a hardware replacement. Raising this before you sign a long contract is cheaper than discovering it during a late migration.
How the question set is organized
The questions follow the five phases of ASD's LATICE framework:
- Locate and inventory cryptographic dependencies.
- Assess risk to individual systems.
- Triage and prioritize systems for transition.
- Implement PQC algorithms.
- Communicate with vendors and educate stakeholders.
The guidance says not to ask every question of every vendor. Organisations are not expected to ask every question of every vendor. The depth should reflect the product's risk, how much control the vendor has over its cryptography, how sensitive and long-lived the data is, and how far along your own planning is. Not all vendors may be able to provide detailed responses initially. A vendor's willingness to engage and explain its constraints is itself informative.
1. Locate and inventory
This phase asks where the vendor uses cryptography for authentication, key exchange, signing, and data in transit or at rest. Questions include:
- Does the vendor keep a current cryptographic bill of materials (CBOM) or equivalent inventory?
- At which layers is cryptography implemented: application, operating system, middleware, hardware or firmware?
- Is any cryptography hardcoded, fixed or hardware-bound?
- Does cryptography enter through third-party components?
- Do the vendor's products rely on hardware roots of trust?
- How is firmware authenticity verified, and can firmware and boot processes be updated for PQC signature schemes?
Secure Boot and UEFI are cited as examples relevant to firmware-signing discussions. This is where PC fleet owners should pay attention, because boot-chain signing is usually locked in at the OEM level.
Good answers include a maintained inventory of algorithms, libraries, protocols and parameters. They also include disclosure of inherited cryptography, supported patches with long-term support commitments, and a remediation roadmap where updates are constrained. The guidance prefers standardized libraries over bespoke or proprietary implementations.
2. Assess risk
These questions focus on which customer data flows depend on traditional asymmetric cryptography. They also ask what data lifetime assumptions the product makes and how customers can configure or manage those lifetimes. Retention defaults matter here, because long-lived data raises the harvest-now-decrypt-later risk.
Other prompts ask for:
- A documented, product-specific CRQC risk assessment.
- Separate treatment of signing, encryption and authentication risks.
- Stronger cryptographic settings customers can configure today.
- Identification of authentication mechanisms such as certificates, smartcards and tokens, with their replacement lifecycles.
The guidance warns that larger key sizes or stronger traditional settings may offer only marginal, short-term risk reduction. They don't replace migrating to PQC.
3. Triage and prioritize
Here you compare the vendor's schedule with your own milestones. One question asks whether the vendor's roadmap aligns with ASD guidance and supports PQC transition by the end of 2030. The publication frames 2030 as a planning milestone drawn from ASD's Information Security Manual objectives. It is not a universal deadline. Follow the guidance that applies to your jurisdiction, sector and risk environment.
Other questions in this phase:
- Which components need hardware replacement or re-architecture, and what are the timing, cost and interoperability implications?
- If the vendor supports post-quantum/traditional (PQ/T) hybrid modes, how and when will it move to PQC-only? The guidance treats hybrid as a temporary bridge and expects a documented de-hybridization plan.
- Is prioritization based on customer exposure, data sensitivity and technical complexity, rather than customer size or revenue?
- What internal governance arrangements oversee the vendor's PQC transitions?
4. Implement
Before deployment, confirm which standardized PQC algorithms the vendor will support and when they will be generally available. The guidance asks whether the implementation is production-ready and available for customer use. That separates a shipping feature from a preview or experimental one.
Further questions cover:
- How cryptographic libraries are validated and maintained.
- How key and certificate sizes and lifecycle processes will change.
- How customers enable PQC in the product or service.
- Whether PQC is included in base licensing. The guidance warns that premium add-ons could delay adoption and leave protection uneven.
5. Communicate and educate
The last phase covers predictable notice of cryptographic changes, migration and testing guides, and clear deprecation schedules for traditional cryptography, including any hybrid period. It also asks whether the vendor's support and engineering teams are trained to support PQC. It further asks whether the vendor follows or contributes to relevant standards bodies, and whether its roadmap leaves time for customer testing before production rollout.
Red flags the guidance names
The publication lists warning signs rather than automatic disqualifiers:
- Limited visibility into the vendor's own cryptographic use.
- Generic assurances.
- Unclear or deferred timelines.
- Proprietary or opaque cryptography.
- PQC treated as a paid option.
- Overreliance on compensating controls.
- No clear governance or ownership.
These should be weighed against vendor risk, data sensitivity and lifespan, and how openly the supplier engages.
What Windows and enterprise admins can do with it
The following is general analysis, not a requirement set by the agencies.
- Start with a shortlist. Prioritize vendors that protect long-lived sensitive data, authenticate users or devices, sign software or firmware, or ship embedded cryptography that is hard to replace. Identity providers, VPN and network gear, backup services, and PC and server firmware suppliers are obvious candidates.
- Fold the questions into existing cycles. Procurement, contract renewals and routine vendor-assurance reviews are the natural places. The guidance describes the questions as vendor-neutral and suited to these activities.
- Ask for evidence and versions. "Quantum ready" is a marketing phrase. Request a named algorithm, a product version, a general-availability date and deployment instructions.
- Separate roadmap from reality. A promised feature differs from PQC that is supported and production-ready today.
- Watch for pricing games. If PQC is a premium tier, ask about it now, before renewal.
- Treat hybrid as temporary. Ask for the exit plan from hybrid to PQC-only.
- Keep the 2030 caveat. Use it as a planning anchor, but check your own regulator's or sector's timelines.
Other coverage notes that CISA's Secure by Demand guidance for operational technology can be used alongside these questions, according to the threat-intelligence aggregator Mallory. Readers who run OT or industrial environments may want to combine the two.
Bottom line
The guidance does not name an algorithm or a product, and it does not impose deadlines. Its value is in turning a vague worry about quantum computers into specific questions that a vendor either can answer or can't. For IT teams, the useful step is to ask now, ask for documents, and treat a vague answer as a finding in itself.