Post-Quantum Cryptography RFP Template and Checklist (2026)

This post-quantum cryptography RFP template gives you a vendor-neutral set of requirements, a weighted scoring model, vendor questions, a proof-of-concept plan and contract clauses that you can paste into your own request for proposal. It covers ten requirement groups: discovery and inventory (CBOM), risk assessment, algorithm support (ML-KEM, ML-DSA, SLH-DSA, hybrid and composite), PQC certificates and PKI, TLS and protocol readiness, key management impact, migration orchestration, reporting and compliance, deployment, and the vendor itself. The tables can be copied straight into a spreadsheet.

Every requirement is something a serious product in the category can satisfy and be asked to evidence. Items that only some architectures provide are labelled Advanced, so the RFP does not exclude good vendors by accident. For the market picture before you write, read the buyer's guide to cryptographic posture management.

---

Table of Contents

1. Who this is for and how to use it
2. Before you write the RFP
3. The requirements checklist
4. Weighted scoring model
5. Vendor questions to ask
6. Red flags in vendor answers
7. Proof-of-concept plan
8. Contract and exit clauses
9. Copy-ready RFP introduction
10. FAQ
11. References

---

Who this is for and how to use it

Use this checklist if you are a CISO, security architect, PKI or crypto owner, or procurement lead buying one or more of: a cryptographic discovery and posture management platform, post-quantum certificate and PKI capability, or key management that must hold post-quantum keys. It works as a full RFP, as the technical annex of a larger one, or as the criteria sheet for a short-list review.

How to use it:

1. Delete groups that are out of scope. Do not keep requirements you will not score.
2. Set each priority for your context. Must means a bid that fails it is disqualified or heavily penalised. Should is scored. Advanced is a differentiator scored as a bonus, never a gate.
3. Keep the "Evidence to request" column; it is what turns a claim into something you can verify.
4. Copy each table into a spreadsheet, add columns for each bidder's response and score, and use the weights in the scoring section.

Requirement IDs use a group prefix, such as DI for discovery and inventory. Standards are named precisely so that vendors answer the same question: ML-KEM is NIST FIPS 203, ML-DSA is FIPS 204 and SLH-DSA is FIPS 205.

---

Before you write the RFP

A good RFP starts with answers you already hold. Without them, bidders write generic responses and you cannot compare them.

Scope questions

• Which environments are in scope: data centres, public clouds, SaaS, OT and IoT, developer pipelines, third-party products?
• Which cryptographic surfaces matter most: external TLS, internal TLS, VPN and IPsec, SSH, code signing, document signing, data-at-rest keys, database encryption, firmware?
• Which data has a long confidentiality life? Data that must stay secret for many years is exposed to "store now, decrypt later" (background).
• Are there isolated or air-gapped networks, and which data-residency rules apply?

Inventory you can bring

• Counts, even rough ones: certificates, internal CAs, load balancers, HSMs, cloud accounts, repositories, languages.
• Known constraints: constrained devices, legacy protocols, vendor appliances you cannot change.

Stakeholders

• Security architecture, PKI and key management, application owners, network and infrastructure, risk and compliance, procurement and legal. Name an owner for each requirement group.

Decision criteria and timeline

• Write the weights before you read the bids. See the scoring section. Decide the proof-of-concept scope and dates in the RFP itself so bidders can resource it.
• Anchor the timeline to regulatory dates that apply to you, for example NIST's draft IR 8547 (deprecation of 112-bit quantum-vulnerable algorithms after 2030, disallowance after 2035), CNSA 2.0 if you serve US national security systems, or national guidance such as Switzerland's NCSC and FINMA and Germany's BSI TR-02102. NIST IR 8547 is a draft; treat the dates as planning baselines.

---

The requirements checklist

Priority key: M = Must, S = Should, A = Advanced.

Group 1: Discovery and inventory (CBOM)

Group 2: Risk assessment and prioritisation

Group 3: Algorithm support

Group 4: PQC certificates and PKI

Group 5: TLS and protocol readiness

Group 6: Key management impact

Group 7: Migration orchestration

Group 8: Reporting and compliance

Group 9: Deployment

Group 10: Vendor

---

Weighted scoring model

Use a 0 to 5 scale for every scored requirement and multiply by the group weight. Decide the weights before you read responses.

Scale

Suggested weights (adjust to your context; they must total 100)

Any Must requirement scoring below 3 is a gate: the bidder is excluded or must supply a written remediation plan with dates. Advanced items add up to 5 bonus points in total and never cause exclusion.

Worked example (made-up numbers, for illustration only). Suppose the average score for Group 1 is 3.5 for Vendor A and 4.0 for Vendor B. Group 1 contributes 3.5 / 5 x 20 = 14.0 points for A and 4.0 / 5 x 20 = 16.0 for B. Repeat for each group and add up. If A reaches 74 and B reaches 71 across all ten groups, A ranks higher overall even though B is stronger on discovery. Then check the gates and the PoC results before you decide: a lower paper score that passes the PoC is better than a higher one that fails it.

---

Vendor questions to ask

Ask these in the written response. Require specific, dated, verifiable answers.

1. Which asset types does discovery cover today, and which are on the roadmap? Give release dates for roadmap items.
2. What exactly is analysed in binaries and container images: dependencies only, or the compiled code?
3. Which CycloneDX version does your CBOM export use, and can you share a sample that validates against the schema?
4. How do you detect hybrid key exchange, and which groups are recognised?
5. How is the risk score calculated, and can we see the formula and weighting?
6. How do you represent the confidentiality lifetime of data in scoring?
7. Which regulations and standards are mapped in the product itself, and which only in marketing material?
8. Which cloud KMS and HSM products are supported in production, and which are beta?
9. Can discovery run in an isolated network? How are updates delivered?
10. What is the minimum privilege needed on each scanned system, and what runs on our infrastructure?
11. Where is customer data stored and processed, and who are your sub-processors?
12. Which post-quantum certificate profiles can you issue, which RFC or draft versions do they follow, and what has been tested for interoperability?
13. How do you handle certificate and chain size growth in your issuance and delivery?
14. How are post-quantum keys protected, and which HSM firmware versions are supported?
15. What is the process when NIST or the IETF changes a specification after we deploy?
16. How do you integrate with our ITSM, CMDB, SIEM and CI/CD tools? Show an example of each.
17. What can be automated end to end, and where is human approval required?
18. How do you detect and report configuration drift back to disallowed algorithms?
19. What happens to our data, CBOM and reports if we terminate?
20. Which independent certifications cover the service, and what is their scope?
21. How many customers of our size and sector run the product in production?
22. What professional services do you offer for migration, and who delivers them?

---

Red flags in vendor answers

• "Quantum-safe" claims with no mention of which standard (FIPS 203, 204 or 205) or which parameter set.
• A CBOM described as "supported" without a format, version or sample file.
• Readiness scores whose method is not shared, or a "100% ready" score with no scope statement.
• Compliance mapping shown only in marketing material, not in the product or documentation.
• Scanning claims that quietly depend on you installing agents everywhere, or on outbound internet access you cannot allow.
• Roadmap items presented in the present tense.
• Inability to run a proof of concept on your own data in a reasonable time.
• No clear statement of what the vendor does not do. Every product has limits; a vendor that names none is not being straight.
• Post-quantum certificates described as ready for public websites. The public web PKI does not accept ML-DSA certificates yet.
• Lock-in: proprietary data formats with no export, or termination terms that delete your data immediately.

---

Proof-of-concept plan

Run the same PoC with every short-listed bidder, on the same slice of your estate, for two to four weeks.

Record time to first result, number of manual steps and false-positive rate for each bidder. Add measured numbers to the scoring sheet.

---

Contract and exit clauses

• Data ownership. All inventory data, CBOMs, scan results and reports are your data. The vendor may use anonymised telemetry only with your written consent.
• Export and exit. Full export in open formats (CycloneDX for the CBOM, standard formats for reports) at any time and for a defined period after termination, at no extra charge.
• Deletion. Certified deletion of your data within a stated number of days after termination.
• Service levels. Availability, support response times and credits for breach.
• Security obligations. Maintain the certifications offered in the response, notify you of incidents within a stated number of hours, and allow audit rights proportionate to the risk.
• Roadmap commitments. Features promised in the response are listed in an annex with delivery dates and remedies if missed.
• Standards change. The vendor will implement final versions of relevant standards (for example, the final IETF specification for composite signatures) within an agreed period, at no additional licence cost.
• Sub-processors. Prior notice and a right to object to changes.
• Regulatory support. Cooperation with your regulator's information requests where applicable (for example under DORA for financial entities).
• Price protection. Caps on renewal increases, and clear metrics for what drives price (assets, scans, users).

---

Copy-ready RFP introduction

[Organisation] invites proposals for a platform and services to inventory, assess and migrate its cryptography ahead of the transition to post-quantum standards. The scope covers [environments]. Bidders must demonstrate discovery of cryptographic assets across network endpoints, certificates and keystores, source code, cloud key management services and hardware security modules; export of a Cryptography Bill of Materials in CycloneDX; documented risk scoring that accounts for data confidentiality lifetime; support for the NIST standards ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) in detection and, where applicable, in certificate issuance and key management; and migration planning with hybrid-first guidance. Responses must provide verifiable evidence for each requirement in Annex A, distinguish production capability from roadmap, and support a proof of concept on a representative portion of our environment. Evaluation will use the weighted model in Annex B, with Must requirements acting as gates. Responses are due [date]; proofs of concept will run [dates].

---

FAQ

What should a post-quantum cryptography RFP include?

It should include scope and constraints, requirements grouped by discovery and CBOM, risk assessment, algorithm support, PQC certificates and PKI, TLS and protocols, key management, migration orchestration, reporting and compliance, deployment and vendor qualifications. It should also include a scoring model, a proof-of-concept plan and contract clauses for data export and standards changes.

Which NIST standards should I name in the RFP?

Name FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for signatures and FIPS 205 (SLH-DSA) for hash-based signatures. Ask vendors which parameter sets they support and how they handle hybrid and composite constructions that combine them with classical algorithms.

Do I need a CBOM requirement?

Yes. A CBOM in an open format such as CycloneDX lets you share evidence with auditors, feed other tools and leave a vendor without losing your inventory. Ask for the specification version and a sample file that validates against the schema.

Should the RFP require post-quantum certificates from the public web PKI?

No. At the time of writing, ML-DSA certificates are not accepted in the public web PKI, and the CA/Browser Forum work on them is not final. Limit PQC certificate requirements to private PKI and test environments, and require a written statement of what is supported for each trust domain.

Is a proof of concept necessary?

For this category, yes. Discovery tools differ in what they can see in your environment, and risk scores differ in how they are calculated. A two to four week proof of concept on the same slice for each finalist is the most reliable way to compare.

How do I avoid an RFP that favours one vendor?

Write requirements around outcomes and evidence, mark architecture-specific capabilities as Advanced and score them as bonuses, and fix the weights before you read the bids. If a requirement is met by only one vendor, ask whether it is essential to your use case.

Can I start without an internal scan?

You can get a first view of your external exposure without internal access. DuoKey's free Quantum Risk Score is computed from public signals and needs nothing installed; it is a starting point, and the inventory itself comes from an internal scan, for example with cryptographic posture management.

---

References

• NIST FIPS 203: ML-KEM
• NIST FIPS 204: ML-DSA
• NIST FIPS 205: SLH-DSA
• NIST IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards
• RFC 9881: Algorithm Identifiers for ML-DSA in X.509
• RFC 9909: Algorithm Identifiers for SLH-DSA in X.509
• IETF Datatracker: draft-ietf-lamps-pq-composite-sigs
• IETF Datatracker: draft-ietf-tls-ecdhe-mlkem
• CycloneDX Cryptography Bill of Materials
• DuoKey Docs: CPM (PQC Scanner) overview
• DuoKey Docs: migration planning