Post-Quantum Readiness
Vendor PQC Questionnaire: Questions to Ask Your Software, Cloud, and Infrastructure Suppliers
Use this structured vendor PQC questionnaire to assess supplier quantum readiness. Covers crypto agility, NIST PQC algorithm support, CBOM, migration roadmaps, and compliance.
Vendor PQC Questionnaire: Questions to Ask Your Software, Cloud, and Infrastructure Suppliers
Your PQC readiness is only as strong as your vendors' cryptographic posture. Every SaaS platform, cloud provider, payment processor, and managed service that terminates TLS on your behalf or processes your encrypted data introduces a cryptographic dependency you may not control.
This structured questionnaire helps security, compliance, and vendor management teams assess whether suppliers are preparing for post-quantum cryptography — or whether they represent a hidden quantum risk.
Section 1: PQC Roadmap and Strategy
- Does your organization have a published post-quantum cryptography migration roadmap? If yes, please provide a link or document. If no, when do you expect to publish one?
- Which NIST PQC algorithms do you plan to support? Specifically: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, SLH-DSA (FIPS 205) for stateless hash-based signatures.
- What is your target timeline for PQC algorithm support in production? Please provide estimated quarters/years for: internal testing, customer-facing beta/preview, general availability.
- Which cryptographic functions in your platform are in scope for PQC migration? TLS termination, digital signatures, data encryption at rest, key exchange, certificate issuance, code signing — please be specific.
Section 2: Hybrid and Transition Support
- Will you support hybrid key exchange during the transition period? (e.g., ECDHE + ML-KEM in TLS 1.3). If yes, what is the timeline?
- Will you support hybrid certificates during the transition? (e.g., RSA-2048 + ML-DSA in X.509). If yes, what is the timeline?
- How will you manage backward compatibility during the transition? How will customers using legacy clients that do not support PQC algorithms continue to connect?
- Will algorithm selection be customer-configurable? Can customers choose which PQC algorithms to enable, or will you manage the transition transparently?
Section 3: Cryptographic Bill of Materials (CBOM)
- Can you provide a Cryptographic Bill of Materials (CBOM) for your platform? Ideally in CycloneDX 1.6 format. If not currently, when do you expect to support CBOM generation?
- What does your CBOM include? Algorithms, key sizes, certificate authorities, protocol configurations, library dependencies — please be specific.
- How often is your CBOM updated? On each release? On certificate rotation? On customer request?
- Will you provide CBOMs to customers for compliance and audit purposes? Under what terms or conditions?
Section 4: Compliance and Regulatory Alignment
- Which regulatory frameworks do you track for PQC requirements? NSM-10, OMB M-23-02, CNSA 2.0, DORA, PCI DSS 4.0, HIPAA, CMMC 2.0 — please list all applicable.
- Do you provide compliance documentation that maps your cryptographic posture to specific regulatory requirements? If yes, what format and frequency?
- Are you tracking the EU PQC transition timeline? (Member states to begin by December 2026). How does your roadmap align?
- For US federal customers: do you support CNSA 2.0 algorithm requirements? If not, what is your timeline for CNSA 2.0 compliance?
Section 5: Testing and Migration Support
- Do you offer a test or sandbox environment with PQC algorithms enabled? Can customers validate their integrations before production migration?
- How will you notify customers of cryptographic configuration changes? Advance notice period, communication channels, change management process.
- Will you assist customers with coordinated migration? Documentation, support resources, professional services, migration tooling.
- What is your rollback plan if a PQC algorithm is found to have a weakness? How quickly can you revert to classical algorithms or switch to an alternative PQC algorithm?
Section 6: Operational Security
- Do you have a vulnerability disclosure program for cryptographic issues? How should customers report suspected cryptographic weaknesses in your platform?
- How do you manage your own certificate lifecycle? Certificate authority, issuance process, rotation policy, expiry monitoring.
- What is your incident response process for cryptographic events? Certificate compromise, algorithm weakness disclosure, key material exposure.
- Do you undergo independent cryptographic review? Third-party audits, penetration testing with cryptographic scope, academic review.
How to Use This Questionnaire
Send this questionnaire to every vendor categorized as Critical or High in your vendor crypto risk assessment. Set a response deadline of 30 days. For non-responsive vendors, escalate through your vendor management or procurement channel.
Use responses to:
- Populate your vendor crypto risk register
- Identify vendors that block your PQC migration timeline
- Prioritize architectural mitigations (e.g., terminating TLS at your own proxy before vendor endpoints)
- Feed compliance evidence packages and board reporting
FAQ
Q: What if a vendor refuses to answer the questionnaire? A: Document the refusal. This is a risk signal in itself. Escalate through formal vendor management channels and consider architectural mitigations.
Q: How often should I re-send this questionnaire? A: Annually for most vendors, quarterly for Critical-tier vendors. PQC roadmaps evolve, and a vendor with no roadmap today may have one in 6 months.
Q: Should I require PQC support in new vendor contracts? A: Yes. Include PQC readiness requirements in RFPs and procurement criteria. Ask for CBOM availability and PQC roadmap as evaluation criteria.
Q: Can I use CipherReady to assess my vendors' cryptographic posture? A: CipherReady is designed for authorized defensive assessment of domains you own or manage. For vendor assessment, use this questionnaire and request CBOM documentation. Never scan vendor domains without explicit written authorization.
Start Free Readiness Scan →
View Sample Report →
Contact CipherReady →