Vendor RFP Evaluation Rubric.
A scored framework for evaluating vendor PQC readiness — fourteen criteria, three hard pass/fail gates, weighted aggregate.
CISA's January 2026 product-category list identifies which product families are PQC-capable. This rubric is what you use to evaluate a specific vendor response inside one of those categories — and what auto-disqualifies a vendor who is not actually ready to sell into a CNSA 2.0-shaped procurement.
- Gate 01 — Standards commitmentVendor cannot confirm FIPS 203 or FIPS 204 implementation on a stated, dated, public timeline.
- Gate 02 — Negotiation observabilityVendor has no cipher-suite negotiation logging — a silent downgrade attack would be invisible in production.
- Gate 03 — Rollback pathVendor offers no documented rollback to classical-only mode for production incident recovery.
Score, weight, gate.
Run the three hard pass/fail gates first. Any single gate failure auto-rejects the vendor regardless of how strong the rest of the response is — there is no scoring path that compensates for "we don't know what FIPS standard we implement" or "we have no rollback." If the vendor clears all three gates, score the fourteen criteria on the 0/1/2 scale, multiply by category weight, and compare against other shortlisted vendors.
Scoring scale: 0 = not supported, 1 = on roadmap with a stated date, 2 = available now or fully validated. Weights are High (×3), Medium (×2), and Low (×1). Maximum possible weighted score is 76 across the fourteen criteria; a vendor scoring below 50% (38) after passing the gates is generally not yet ready for a P1 procurement decision.
Across seven categories.
Each criterion has a category, a weight, and a scoring guidance line. The XLSX has the full scoring template with auto-totals; the table below is the operator-level summary you can read in one sitting.
| Category | Criterion | Weight | Scoring guidance (0 / 1 / 2) |
|---|---|---|---|
| Algorithm Standards | Implements ML-KEM (FIPS 203) | High | 0 = no · 1 = roadmap · 2 = available now |
| Algorithm Standards | Implements ML-DSA (FIPS 204) | High | Same scale as above |
| Algorithm Standards | Implements SLH-DSA (FIPS 205) | Medium | Same scale; required only where conservative long-lived signing is in scope |
| Algorithm Standards | Algorithm validation (NIST ACVTS) | High | 0 = none · 1 = in process · 2 = validated |
| Hybrid Operation | Hybrid key exchange (classical + PQC) | High | 0 = no · 1 = proprietary combiner · 2 = IETF-standard combiner |
| Hybrid Operation | Configurable fallback policy | High | Can disable classical-only fallback; integrity-protect negotiation |
| PKI / Certificate | CA infrastructure PQC-ready | High | Certificate issuance, OCSP, CRL all support PQC structures |
| PKI / Certificate | Dual-cert or composite-cert support | Medium | Transition-phase need; required only if relying parties are mixed |
| Operational | MTU / fragmentation tested at >1,500 bytes | Medium | Vendor provides test evidence with realistic certificate chains |
| Operational | Latency / throughput baseline data | Medium | Quantified regression vs. classical mode; published, not "comparable" |
| Observability | Cipher-suite negotiation logging | High | Detects downgrade attempts in production · also Gate 02 |
| Rollback | Classical rollback path documented | High | Production incident recovery · also Gate 03 |
| Roadmap | PQC release version and date committed | High | Specific product version + ship date — not "coming soon" |
| Support | Future-algorithm update process | High | Crypto-agility principle; ML-KEM is not the last algorithm change |
Procurement cycles. Renewals. Architecture review.
The rubric is built for three moments in the procurement cycle. First: any new vendor going into a CISA-identified product category — cloud services, web software, networking, endpoint security. Second: any contract renewal where the renewal window overlaps the CNSA 2.0 inflection (Jan 2027 preferred · 2030 disallowed). Third: any architecture-review escalation where the architecture team has flagged "crypto unclear" against a candidate vendor.
Use one workbook per vendor per evaluation cycle. Save the evidence column references; the workbook becomes audit-grade documentation of the procurement decision. If you have to defend the choice to compliance or counsel two years from now, the rubric is the artifact you cite.
How to attach evidence
- Algorithm Standards. Cite the FIPS validation certificate number (or absence of one). NIST publishes the validated-module list publicly.
- Hybrid Operation. Cite the IETF draft the vendor implements (
draft-ietf-tls-mlkem-XX). "Proprietary combiner" is a Gate 02 risk. - Operational. Require packet captures and latency reports as part of the RFP response, not "available on request."
- Observability. Require a sample log line showing cipher-suite negotiation. If the vendor cannot produce one, fail Gate 02.
- Rollback. Require a runbook section from the vendor's production-incident playbook. If they don't have one, fail Gate 03.
The rubric is the procurement-side companion to the Inventory Worksheet (Tool 01). Use the worksheet to identify which systems need vendor evaluation; use this rubric to score the responses. For the architectural reasoning behind the criteria, see the Security Architects briefing. For the procurement framing for the board, see the Executives briefing and the Executive One-Pager.