CISA, ASD's ACSC, and NSA recently released joint guidance and a quick-reference list for assessing vendor readiness for the transition to post-quantum cryptography (PQC). The premise is straightforward. Widely used public-key cryptography will become vulnerable to cryptographically relevant quantum computers (CRQCs), and your organization needs to move to PQC before those machines exist.
The questions below are the ones compliance teams are already asking in Slack threads and kickoff meetings. The answers align with what the guidance says and what your existing frameworks already require.
Q1: Why is this a compliance problem and not just a crypto team problem?
Because you don't own most of your cryptography. Your managed services, cloud capabilities, and other cryptography-dependent products belong to third parties. The guidance is clear that effective PQC transition depends on vendor readiness. If a vendor isn't planning, your timeline slips with theirs.
Treat it like supply chain risk. NIST SP 800-53 Rev 5 already provides guidance: the SR (Supply Chain Risk Management) family and SA-4 (Acquisition Process) govern what you can require from suppliers. If you flow down DFARS 252.204-7012 or manage CUI under NIST SP 800-171, the vendors touching that data are already in your compliance boundary. Their crypto roadmap is part of your risk picture.
Q2: What should I actually ask vendors?
The guidance frames the questions around three things: does the vendor understand quantum-related risk, does it maintain transparency over its cryptographic implementations, and does it support a secure, cost-effective, and timely transition to PQC. Build your questionnaire around those three.
For quantum risk awareness, ask whether the vendor has a documented position on CRQC risk and a named owner for the transition.
For transparency, ask what public-key algorithms are in use across the product, where they're embedded, and whether the vendor can produce a cryptographic inventory. A Software Bill of Materials is a useful complement here since you can't plan around libraries you can't see.
For transition support, ask whether upgrades will be delivered through normal updates, whether the vendor will absorb migration cost or pass it through, and what the timeline looks like.
Use CISA's quick-reference list as your baseline instead of inventing your own. A shared, vendor-neutral question set also makes answers easier to compare.
Q3: Which vendors do I prioritize? I can't send this to everyone at once.
Start where replacement is hardest. The guidance highlights systems and devices that are difficult to update, tied to long asset lifecycles, and dependent on vendor support or replacement. Industrial control systems and IoT devices are the named examples.
A reasonable triage order:
- Vendors embedded in long-lifecycle assets you can't patch easily.
- Cloud and managed service providers that handle your sensitive data, including Controlled Unclassified Information.
- Everything else, folded into normal periodic reassessment.
If you're a FedRAMP-authorized or CMMC-bound organization, prioritize vendors inside your authorization or assessment boundary first.
Q4: How do I fold this into our existing compliance program without building a new one?
Don't build a new one. Attach PQC questions to processes you already run.
- Procurement: Add the vendor questions to your RFP and renewal language, so readiness becomes a purchasing criterion.
- Supply chain risk management: Record crypto-readiness answers in the same register where you track other supplier risk under the SR controls in NIST SP 800-53 Rev 5.
- System security plans: Where your SSP documents cryptographic protections, note which components depend on vendor-managed public-key cryptography.
- Risk Management Framework activities: Feed vendor responses into your ongoing risk assessment and Risk Response decisions.
The goal is a defensible paper trail showing you asked, evaluated, and acted.
Q5: Does PQC change what I need for FIPS 140-2 or other crypto requirements today?
Nothing in the guidance suspends your current obligations. Where your contracts or authorizations require validated cryptography, such as FIPS 140-2 under the Cryptographic Module Validation Program, those requirements still apply as written. PQC planning runs alongside them.
One caution: don't let a vendor's PQC roadmap stand in for current compliance, and don't let current compliance stand in for a roadmap. They answer different questions. Validated today does not mean ready for the transition, and a promising roadmap does not mean validated today. Don't claim more than you can document in either direction.
Q6: What do I do when a vendor has no answer?
Treat a non-answer as information. A vendor that can't describe where it uses public-key cryptography is telling you something about its transparency over cryptographic implementations, one of the three areas the guidance asks you to test.
Practical steps:
- Put the question in writing and set a response date.
- Escalate through your contract or account channel, not just the technical contact.
- Log the gap as a supplier risk with an owner.
- Decide your Risk Response: accept for now with a review date, require a commitment in the next renewal, or plan an eventual replacement.
Long asset lifecycles mean replacement decisions take years to execute. A vendor you ignore this year becomes a forced migration later.
Where to go for more
Start with the joint CISA, ASD's ACSC, and NSA guidance and its accompanying quick-reference question list. CISA's PQC Initiative page collects additional resources and is the best place to watch for updates.
Then map the questions to the controls you already answer to: the SR and SA families in NIST SP 800-53 Rev 5, your DFARS 252.204-7012 flow-down obligations, and your NIST SP 800-171 scoping. Ask early, document the answers, and revisit them as your vendors' plans mature.
