Your post-quantum cryptography (PQC) plan is only as strong as your weakest vendor. You can inventory every key you own and still miss the deadline because an HSM firmware update, a PKI platform release, or a code signing service isn’t ready when you are.
The Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), the U.S. Cybersecurity and Infrastructure Security Agency (CISA), and the U.S. National Security Agency (NSA) have now put that problem in writing. Their joint guide, Post-quantum questions to ask your vendors, gives procurement and security teams a ready-made list of questions for every product that relies on cryptography, and a list of warning signs in the answers.
Key takeaways
- The guide gives 31 vendor-neutral questions for procurement, contract renewals, and ongoing vendor assurance, organized around five transition phases: locate, assess, triage, implement, and communicate.
- Some of the most useful questions: Do you maintain a CBOM? Is any cryptography hardcoded or hardware-bound? Which products will be PQC-ready before the end of 2030? When will you move from hybrid to PQC-only? Is PQC included in base licensing?
- It names seven common concerns in vendor answers, including general assurances, deferred timelines, proprietary or opaque cryptography, and PQC sold as a premium add-on.
- If you are renewing HSM, PKI, certificate lifecycle management (CLM), or code signing contracts, this is the moment to ask. Vendors who can’t answer today will be your bottleneck in 2030.
What the NSA, CISA and ASD released
On November 4, 2026, the NSA announced that it had joined ASD’s ACSC and CISA in publishing Post-quantum questions to ask your vendors: Evaluating third-party readiness for post-quantum cryptography. ASD’s ACSC wrote the guide and first published it on July 16, 2026. The November 4 release is the joint version co-authored with CISA and NSA, and all three agencies are listed as authors.
The premise is simple. Most organizations don’t choose the cryptography inside the software, hardware, managed services and cloud platforms they buy. The vendor does. So, as the guide puts it, “weaknesses or delays within the supply chain can affect progress and introduce residual risk,” even for an organization with “strong cryptographic expertise and a refined PQC transition plan.”
The guide is built for three moments: procurement, contract renewals, and ongoing vendor assurance. Its questions follow the five phases of ASD’s LATICE framework for PQC transition:
- 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, throughout the transition.
Each question comes with a short explanation of why it matters and what a good answer looks like, which makes the guide easy to drop straight into an RFP or a security questionnaire. The guide also says something worth remembering when answers come back thin: a vendor’s “willingness to engage transparently, discuss constraints and demonstrate progress can indicate maturity in both PQC and broader cyber security practices.”
The questions that matter most
The guide has 31 questions in all. These are the ones we’d put at the top of any vendor questionnaire, with the kind of answer the agencies say you should expect.
| Phase | Question to ask | What a good answer looks like |
|---|---|---|
| Locate | Do you maintain a current inventory of cryptographic dependencies, such as a cryptographic bill of materials (CBOM)? | A complete, actively maintained inventory of algorithms, protocols, libraries, parameters and configurations, including third-party and embedded components |
| Locate | Is any cryptography hardcoded, fixed or hardware-bound? | Confirmation that none exists, or a list of affected components with a realistic fix: patching, firmware upgrade or replacement |
| Locate | Can the firmware and boot processes be updated to support PQC signature schemes? | Evidence they can be updated without replacing hardware, or a roadmap for PQC-compatible signatures |
| Assess | What assumptions does your product make about how long the data it handles must stay protected? | Clear data-lifetime assumptions and customer controls, reflected in the vendor’s PQC roadmap |
| Assess | Do you distinguish between signing, encryption and authentication risks? | Separate risk assessments, timelines and mitigations for each |
| Triage | Which products or services will be PQC-ready early enough to support customer rollout before the end of 2030? | Product-specific, versioned commitments, available early enough for testing and staged rollout |
| Triage | Do you support PQ/T hybrid modes as a temporary mechanism, and how and when will you move to PQC-only? | Hybrid described as transitional only, with a documented plan and timeline for de-hybridization |
| Implement | Which PQC algorithms will you support, and when will support be generally available? | Standards-based algorithms approved by the relevant agency, with dates |
| Implement | How will key management, certificate sizes and lifecycle processes change under PQC? | A clear explanation of size, lifecycle and process changes and how production systems will be supported |
| Implement | Is PQC included in base licensing? | PQC under standard licensing terms, with no premium add-on fees |
| Communicate | How will traditional cryptography be deprecated, including any temporary hybrid use? | Deprecation timelines with warning periods, support windows and a defined path to PQC-only |
Two of these deserve a closer look.
The hybrid question is sharper than it looks. Post-quantum/traditional (PQ/T) hybrid modes are often the first PQC feature a vendor ships, and it is tempting to treat that as the finish line. The guide says hybrids “are not recommended as a long-term solution” because a working quantum computer would make the traditional half obsolete. A vendor without a de-hybridization plan is asking you to migrate twice.
The licensing question is the one most procurement teams forget. The agencies want PQC “included under standard licensing terms, without additional licensing fees or premium add-ons,” because paywalled security “could delay adoption and lead to uneven risk across customers.” If PQC is a paid upgrade on your next renewal, that is a negotiating point, not a footnote.
Red flags in vendor answers
The guide lists seven common concerns to watch for. It is careful to say these “do not necessarily indicate unacceptable risk” and should be weighed against the vendor’s risk level, the sensitivity and lifetime of the data involved, and how openly the vendor engages. Still, each one tells you where to push next.
| Red flag | What it often sounds like | What to ask next |
|---|---|---|
| Limited visibility of cryptographic use | “We use industry-standard encryption.” | Can you share a CBOM or equivalent inventory for this product? |
| Reliance on general assurances | “We’re monitoring PQC closely and will be ready.” | Which release, and on what date? |
| Unclear or deferred timelines | “PQC is on our long-term roadmap.” | Will it be generally available early enough to test and roll out before the end of 2030? |
| Proprietary or opaque cryptography | “Our encryption is proprietary.” | Which standardized, validated libraries do you use? |
| PQC as an optional or premium function | “PQC is available in our advanced tier.” | Will it be included in base licensing at renewal? |
| Over-reliance on compensating controls | “Our network segmentation mitigates the risk.” | What is the plan to replace the vulnerable algorithms themselves? |
| Lack of governance or ownership | No named owner for the PQC program | Who is accountable for PQC delivery, and how often is progress reviewed? |
The example phrases in the middle column are ours, not the guide’s, but anyone who has sent a security questionnaire will recognize them.
Heading into a renewal? Start with these four categories
The guide is vendor-neutral, but some product categories sit on the critical path of almost every PQC migration. HSMs hold the keys, PKI issues the certificates, CLM moves them around, and code signing protects what runs on your devices. If any of these stalls, everything that depends on it stalls too. Here is how we would tailor the guide’s questions for each one.
| Category | Questions to push hardest | Why it matters here |
|---|---|---|
| Hardware security modules (HSMs) | Can firmware be updated to support PQC algorithms without replacing the hardware? Which components require hardware replacement? Which PQC algorithms are available in validated firmware, and when? | HSMs are hardware trust anchors with long lifecycles. The guide calls hardware changes “long-lead items” that affect timelines, cost and interoperability |
| Public key infrastructure (PKI) | Can the CA issue ML-DSA and hybrid or composite certificates today? How will certificate sizes and lifecycles change? What is your plan to move from hybrid to PQC-only? | Every certificate in your estate inherits the CA’s algorithm choices, and larger PQC certificates affect chains, handshakes and storage |
| Certificate lifecycle management (CLM) | Can you discover certificates by algorithm and key type? Can you re-issue at scale when algorithms change? How are customers notified of cryptographic changes? | Migration means replacing certificates in bulk. A CLM platform that only tracks expiry dates won’t tell you which certificates are quantum-vulnerable |
| Code signing | Which PQC signature schemes do you support, and are they production-ready? Can signing keys stay in HSMs? Can devices that verify your signatures be updated? | Firmware signing is “long-lived and difficult to change,” and the guide flags it as a key constraint for PQC transition |
For all four, add the licensing question. A renewal is the cheapest moment to get PQC written into the base contract.
Our take: how to actually use the guide
A list of 31 questions is only useful if it changes what you buy. Here is how we would put it to work.
- Tier your vendors first: The guide says to tailor depth by risk, so don’t send all 31 questions to every supplier. Send the full set to vendors that control your keys, certificates, signing and long-lived data, and a short version to everyone else.
- Ask for evidence, not adjectives: A CBOM, a versioned release note, a validated library name, a dated roadmap. If a vendor can only answer in sentences, score it as a gap.
- Put the answers in the contract: PQC-ready release dates, a de-hybridization plan, notification of cryptographic changes, and PQC in base licensing can all be written into renewal terms. A promise in a sales call is not a commitment.
- Line vendor dates up against your own: The guide uses the end of 2030 as its planning milestone, and U.S. federal guidance points at the same window. A vendor whose PQC release lands in late 2030 leaves you no time to test.
- Re-ask every year: PQC roadmaps will move. Make these questions part of annual vendor assurance, not a one-time exercise.
The most telling signal is not the answer itself. It is whether the vendor can answer at all. A supplier that knows where its cryptography lives, and is willing to tell you, is usually one that will get there on time.
Where Encryption Consulting fits
Encryption Consulting builds products in exactly the categories this guide asks about. Here is where each Encryption Consulting product helps you act on the guide’s questions.
| Related guide question | How we address it | Product |
|---|---|---|
| Do you maintain a CBOM or equivalent inventory? | Discovers cryptography across cloud platforms, HSMs, KMIP servers, TLS endpoints, directory services, databases, file systems, source code and binaries with 20+ production sensors, and exports CBOMs in CycloneDX 1.6 and 1.7 | CBOM Secure |
| Do third-party dependencies introduce cryptography? | Scans source code and binaries for cryptographic libraries and flags quantum-vulnerable keys, certificates and cipher suites, so you can check vendor claims against what is actually deployed | CBOM Secure |
| Which PQC algorithms do you support, and are they production-ready? | Issues hybrid and composite certificates pairing ML-DSA with RSA or ECDSA from a single-tenant private CA backed by FIPS 140-3 Level 3 HSMs, with the customer keeping ownership of the CA and its keys | PKI-as-a-Service |
| How will certificate lifecycle processes change under PQC? | Discovers certificates across Microsoft, public and private CAs, and automates issuance, renewal and revocation through ACME, SCEP, EST and REST APIs, so certificate replacement can be automated when algorithms change | CertSecure Manager |
| How is firmware and software authenticity verified, and can it move to PQC signatures? | Signs code with ML-DSA and LMS built in, keeps private keys in FIPS-certified HSMs, and plugs into CI/CD pipelines including Jenkins, GitHub Actions, GitLab and Azure DevOps | CodeSign Secure |
| Can HSM firmware support PQC without hardware replacement? | Provides FIPS 140-3 certified HSMs with ML-KEM and ML-DSA in firmware, hybrid PQC for key synchronization and backup, and managed provisioning, configuration, patching and maintenance | HSM-as-a-Service |
PKI-as-a-Service and CertSecure Manager are delivered together under one tenant, so the CA issuing your post-quantum certificates and the platform managing their lifecycle work from the same view.
If you would rather have help running the assessment itself, our PQC Advisory Services team works through cryptographic discovery, risk assessment, strategy, roadmap design, proof-of-concept testing and crypto-agility enablement, and can fold vendor readiness into your migration roadmap and governance framework.
For more context, see our breakdown of NIST IR 8547’s final deprecation timeline, our guide to the new federal quantum action plan, CISO’s Guide to PQC Migration Governance, and our own PQC Vendor Readiness Questionnaire, which adds questions on validation status, performance and rollback.
Want a quick read on where you stand first? Take our Quantum Readiness Assessment, or see CBOM Secure in action and find out what cryptography is really running in your environment.
Conclusion
The NSA, CISA and ASD’s ACSC have handed every buyer a ready-made PQC vendor questionnaire. It covers where cryptography lives, what can’t be updated, when PQC will actually ship, how hybrids will be retired, and whether PQC costs extra. The red flags are just as useful: vague assurances, deferred timelines and opaque cryptography are all signs that a vendor may not be ready when you need it.
You don’t need to wait for a formal program to start. Pick your next HSM, PKI, CLM or code signing renewal, put these questions on the table, and get the answers in writing. The vendors who can answer today are the ones you will still want in 2030.
Frequently asked questions
What is the “Post-quantum questions to ask your vendors” guide?
It is a joint publication from Australia’s ASD’s ACSC, the U.S. Cybersecurity and Infrastructure Security Agency (CISA), and the U.S. National Security Agency (NSA). It gives organizations 31 vendor-neutral questions for procurement, contract renewals and ongoing vendor assurance, plus common concerns to watch for in vendor responses. The NSA announced its participation on November 4, 2026.
What questions should I ask vendors about post-quantum readiness?
Start with whether the vendor maintains a CBOM, whether any cryptography is hardcoded or hardware-bound, which products will be PQC-ready before the end of 2030, how and when hybrid modes will move to PQC-only, and whether PQC is included in base licensing. The guide groups its questions into five phases: locate, assess, triage, implement and communicate.
What are the red flags in vendor PQC answers?
The guide lists seven common concerns: limited visibility of cryptographic use, reliance on general assurances, unclear or deferred transition timelines, proprietary or opaque cryptography, PQC treated as an optional or premium function, over-reliance on compensating controls, and lack of governance or ownership. None of these automatically means unacceptable risk, but each needs follow-up.
Why does the guide warn against relying on hybrid cryptography?
Post-quantum/traditional (PQ/T) hybrid schemes combine a classical and a post-quantum algorithm. The guide says they can help with short-term interoperability but are not recommended as a long-term solution, because a cryptographically relevant quantum computer would make the classical part obsolete. Vendors should have a documented plan and timeline to move to PQC-only.
What is a CBOM and why do vendors need one?
A cryptographic bill of materials (CBOM) is an inventory of the algorithms, protocols, libraries, parameters and configurations a product uses. The guide treats it as a current, actively maintained inventory that includes third-party and embedded components. Without one, neither the vendor nor its customers can reliably say which parts of a product are quantum-vulnerable or how hard they will be to replace.
