PQC Supplier Readiness Questionnaire Template

Most of the cryptography an organisation depends on sits inside products and services it does not build, so a post-quantum migration plan is only as credible as the answers its suppliers give. The UK NCSC asks organisations to identify supplier dependencies in their initial migration plan by 2028, to communicate their needs to suppliers and to track supplier roadmaps as they change. This template is a ready-to-send questionnaire for that work: numbered question sections with IDs, the evidence to request, what a good answer looks like and a scoring scheme. It is for third-party risk, procurement and PQC programme teams. It feeds section 5 of the PQC Migration Plan Template and extends the short supplier question list in the Post-Quantum Cryptography Migration Guide. Status statements are as of November 2026; standards and timelines in this area change, so check the sources before you send.

How to use this template

Customise: replace [Organisation], [Supplier], [Product] and dates. Keep the question IDs so answers can be compared across suppliers and years.
Tier the depth: section 2 says which sections each supplier tier receives. Do not send all sections to every supplier; a short, relevant questionnaire gets better answers.
Ask for evidence, not adjectives: "quantum-safe" or "quantum-ready" without named algorithms, parameter sets and versions scores zero.
Record answers in one place: copy scores and committed dates into your migration plan's supplier table and your third-party risk register.
Repeat yearly: roadmaps move. Re-send to critical suppliers every 12 months (our recommendation) and when a supplier announces a major release.
Pair with contracts: answers are not commitments. Use section 9 to turn the important ones into contract terms. See the Third-Party Security Contract Clauses Template.

1. Purpose and scope

1.1 [Organisation] is migrating its use of public-key cryptography to post-quantum algorithms in line with [NCSC PQC migration timelines / NIST IR 8547 / sector requirement]. This questionnaire asks [Supplier] to describe the cryptography in [Product or service] and its plan to support the NIST post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA).

1.2 Scope: [Product, versions and modules in use], [interfaces in use: customer-facing, management, API, inter-service], [services the Supplier operates for Organisation].

1.3 Please answer by [date]. Where an answer is "not yet decided", give the date by which you expect to decide.

1.4 Answers are treated as [confidential supplier information] and used for migration planning and risk assessment only.

2. Supplier tiers and sections to send

Tier	Typical suppliers	Sections to send
A: Cryptographic infrastructure	HSMs, key management services, certificate authorities, PKI and certificate lifecycle platforms, VPN and network encryption appliances	3 to 10
B: Platforms that hold your keys or identities	Cloud and SaaS platforms, identity providers, secrets managers, CI/CD and code signing services, managed service providers	3, 4, 5, 6, 8, 9, 10
C: Embedded and long-lived products	OT and IoT devices, medical and industrial equipment, firmware-signed hardware	3, 4, 6, 7, 9, 10
D: Commodity software and services	Standard business SaaS and packaged software with no special cryptographic role	3, 4, 9, 10

The NCSC notes that commodity products usually receive PQC through vendor updates, while bespoke and specialised software needs its own route. Tier C deserves early attention because devices bought now may still be in service after 2035.

3. Supplier and product profile

ID	Question	Evidence to request
P-01	Name the product versions and service components in scope, and their support end dates.	Version list, lifecycle policy
P-02	Who owns your post-quantum programme, and is there a published statement of intent or roadmap?	Named role, public or NDA roadmap document
P-03	Which cryptographic libraries, modules or hardware does the product rely on, and who supplies them?	Library and module list with versions
P-04	Which of your own suppliers' PQC readiness does your roadmap depend on?	Dependency list (fourth parties)

4. Algorithm and standards support

ID	Question	Good answer
A-01	Which quantum-vulnerable algorithms (RSA, Diffie-Hellman, ECDH, ECDSA, EdDSA) does the product use, and where (data in transit, data at rest, signing, authentication)?	Per-function list, not a single statement
A-02	Which FIPS 203, 204 and 205 parameter sets are supported or planned (for example ML-KEM-768, ML-KEM-1024, ML-DSA-65, ML-DSA-87), in which release, by what date?	Named parameter sets, version numbers, dates
A-03	Do you support hybrid key exchange (a classical and a post-quantum algorithm combined, for example X25519MLKEM768 in TLS 1.3) on every interface, including management interfaces and APIs?	Per-interface answer, default setting, how to enable
A-04	Do you use any pre-standard or draft algorithm versions or code points (for example early Kyber implementations), and how will you move off them?	Yes or no, with retirement date
A-05	Is your PQC implementation inside a FIPS 140-3 validated boundary, or when do you expect validation?	CMVP certificate number or submitted status with date
A-06	Do you use stateful hash-based signatures (LMS, XMSS) anywhere, for example firmware signing? How is state protected?	Hardware-enforced state, backup procedure
A-07	What symmetric algorithms and key lengths are used for data at rest and session encryption?	AES-256 or equivalent, with modes

Background on the signature families is in the ML-DSA and SLH-DSA Post-Quantum Signatures Guide and on hybrid TLS in the Hybrid Post-Quantum TLS Key Exchange Guide.

5. Cryptographic inventory and CBOM

ID	Question	Good answer
C-01	Can you provide a cryptography bill of materials (CBOM) for the product, listing algorithms, keys, certificates and protocols and the components that use them?	CycloneDX CBOM per release, or a dated plan to produce one
C-02	Is the CBOM generated automatically in your build, or assembled by hand?	Generated per build, versioned with the release
C-03	Does the CBOM cover third-party libraries and firmware, not only your own code?	Yes, with method described
C-04	How will you tell us when the cryptography in a release changes?	Release notes section or updated CBOM with each release

For how a CBOM fits your own inventory, see the Cryptographic Inventory and CBOM Guide.

6. Crypto agility

ID	Question	Good answer
G-01	Can algorithms, parameter sets and key sizes be changed by configuration, without a code change or firmware replacement?	Yes, with the configuration setting named
G-02	Which algorithms are fixed in hardware, ROM or bootloaders?	Named list with replacement route
G-03	Can the product handle larger keys, signatures and certificates (protocol message sizes, storage fields, database columns, packet sizes)?	Tested limits stated
G-04	Can customers disable a classical algorithm once the post-quantum option is in use, and can they roll back if interoperability fails?	Both documented
G-05	How did you test interoperability with other PQC implementations?	Named test programme or interoperability results

Score agility consistently with your internal systems using the Crypto-Agility Assessment Template.

7. Keys, HSMs and firmware

ID	Question	Good answer
K-01	Does current firmware support ML-KEM and ML-DSA key generation, signing and key encapsulation inside the HSM boundary? If not, from which firmware version?	Firmware version and date
K-02	Can PQC keys be wrapped, backed up and replicated between devices and partitions with the same controls as classical keys?	Yes, documented procedure
K-03	What is the effect of larger PQC keys on partition capacity and signing throughput?	Published or measured figures
K-04	Does a firmware upgrade to add PQC require hardware replacement or re-validation, and what is the upgrade path for devices already deployed?	Upgrade path, re-validation status
K-05	How is your firmware and update signing protected, and when will it move to a post-quantum or hybrid signature?	Named algorithm and date

See the HSM Deployment and Operations Guide for how these answers affect capacity planning.

8. Machine identities and credentials

Non-human identities rely heavily on public-key cryptography: workload certificates, signed tokens, SSH keys and code signing. Ask these questions of any supplier that issues, stores, validates or uses such credentials for you.

ID	Question	Good answer
N-01	Which credential types does the product issue or accept for machines and workloads (X.509 certificates for mTLS, signed JWT access tokens, SAML assertions, SSH keys, API keys), and with which signature algorithms?	Per-credential list with algorithms
N-02	When will token signing (for example JWT signing keys published in a JWKS) support ML-DSA or composite signatures, and how will relying parties be told?	Dated plan, key rollover notice process
N-03	Will your certificate issuance support post-quantum or composite certificates, and for which certificate types first?	Dated plan tied to published standards
N-04	Do any credentials you issue have lifetimes beyond 2030, and can they be shortened?	Lifetimes stated, shorter options available
N-05	Do API keys or shared secrets you issue rely on symmetric algorithms only, and of what length?	Named algorithm and length
N-06	Can customers rotate machine credentials to new algorithms without re-provisioning every client?	Rotation process that supports both algorithms during transition

The Post-Quantum Migration for NHIs Guide explains which machine credentials to prioritise.

9. Roadmap, dates and contract commitments

ID	Question	Good answer
R-01	Give your dated roadmap for general availability of PQC in the in-scope product, by interface.	Dates per interface, not a single year
R-02	How does your roadmap align with NIST IR 8547 and, where relevant, NCSC and EU timelines?	Explicit mapping
R-03	Will PQC support be included in the current licence, or require a new edition, module or hardware purchase?	Stated commercial position
R-04	Will you commit contractually to a PQC support date, CBOM delivery and notification of cryptographic changes?	Yes, with proposed wording
R-05	For services you operate for us, have you completed your own discovery and assessment, and by when will you migrate them?	Assessment completed, dated plan

Clause to adapt: "[Supplier] shall provide by [date] a dated roadmap for supporting [ML-KEM and ML-DSA as specified in FIPS 203 and FIPS 204] in [Product], shall provide a cryptography bill of materials with each major release, and shall notify [Organisation] at least [90] days before changing the cryptographic algorithms used in [Product]."

10. Scoring and follow-up

10.1 Score each answered question with these anchors (ours):

Score	Meaning
0	No answer, or a marketing claim with no named algorithm, version or date
1	Plan described but undated, or dated beyond [Organisation]'s migration milestone for the affected system
2	Dated plan within the milestone, with named algorithms and versions
3	Available now, documented, with evidence (release notes, CBOM, validation certificate)

10.2 Readiness band: average the scores for the sections sent. Below 1.5 is red: raise as a programme risk and agree mitigations (compensating controls, contract terms or replacement planning). From 1.5 to 2.4 is amber: track committed dates quarterly. 2.5 and above is green: re-send yearly.

10.3 Record for each supplier: tier, sections sent, date sent, date answered, band, committed dates, follow-up owner and next review date.

10.4 Sign-off: [Third-party risk owner], [PQC programme lead], [System owner for affected systems].

Implementation guidance

Rollout

Start from the inventory: list suppliers behind the systems in your first migration wave and tier them using section 2.
Pilot: send to three to five tier A and B suppliers first, refine wording from their questions, then send to the rest.
Load answers: transfer scores and dates into the migration plan and risk register within two weeks of receipt (ours).
Escalate: red-band suppliers behind high-priority systems go to the programme board with options.
Repeat: re-send yearly and after major releases; compare answers with the previous year.

Decision guidance

Small organisations using mostly commodity SaaS can send sections 3, 4 and 9 to their top ten suppliers and rely on vendor updates elsewhere, as the NCSC suggests for commodity IT.
Large organisations should embed the questions in standard third-party onboarding and renewal so readiness is captured without separate campaigns. See the Third-Party Risk Management Guide.
Procurement of new products should treat a score of 0 on A-02, C-01 or G-01 as a material gap for any product expected to be in service after 2030 (ours).

Metrics

Share of tier A and B suppliers with a returned questionnaire.
Share of critical suppliers with a dated, written PQC roadmap.
Number of red-band suppliers behind first-wave systems.
Share of tier A and B suppliers delivering a CBOM.

Reference frameworks

The questionnaire supports NIST CSF 2.0 GV.SC-05 (supply chain requirements in contracts) and GV.SC-07 (supplier risks understood and monitored), and NIST SP 800-53 Rev 5 SR-6 (supplier assessments and reviews) and SA-4 (acquisition process).

PQC Supplier Readiness Questionnaire Template: Questions to Ask Vendors About Post-Quantum Roadmaps, CBOMs and Crypto Agility