up:: The Human & Organizational Side MOC
PQC Procurement and RFP Language
PQC procurement and RFP language is the specific set of questions, requirements, and contractual commitments an organization writes into its purchasing process so that post-quantum readiness becomes an obligation the vendor signs, rather than a hope. It’s the operational answer to the problem that vendor-controlled crypto surfaces name: most of your cryptography lives inside products a vendor controls, changing those algorithms yourself is impossible, and the only real leverage you hold sits at procurement and contract renewal. Procurement language is how you spend that leverage before you’ve spent your budget, while the vendor still wants your signature.
The short version:
- You can’t migrate a vendor’s cryptography for them. You can require, in writing and before you sign, that they migrate it on a schedule you can hold them to.
- Renewal and new procurement are the two moments your leverage is highest, so the questions belong in the RFP and the commitments belong in the contract, not in a support ticket after the deal closes.
- The load-bearing clauses are a dated post-quantum roadmap, crypto-agility as a design requirement, a cryptographic bill of materials for what you’re buying, and a notification obligation when a post-quantum-capable version ships.
- A vendor’s verbal “we’re working on it” is a comfort. The enforceable version is a named algorithm, a named year, and a remedy if they miss.
- Align the language to the mandate that binds you, so the requirement reads as a compliance obligation rather than a preference, and a regulated vendor moves faster because the compliance risk is now shared.
Think of it like a renovation contract for a building you’re about to lease for 10 years. Once you’ve signed, the landlord decides when the wiring gets upgraded and you live with whatever they choose. Before you sign, you can write into the lease that the wiring will meet a named code by a named date, that they’ll tell you the moment they upgrade it, and that they’ll hand over the as-built diagrams. The leverage is entirely in the timing. You use it before the ink dries or you don’t use it at all.
Why does PQC belong in procurement rather than engineering?
Because for most of your estate the cryptographic decision was made by someone you’re paying, and the only place you touch that decision is the contract. Vendor-controlled surfaces are usually the majority of an enterprise’s cryptographic footprint by count, and you can’t compress a vendor’s migration timeline with internal engineering effort. If a SaaS platform won’t ship post-quantum support until 2029, your migration for that surface waits until 2029 no matter how capable your own team is. In Mosca’s terms, the vendor sets your migration-time variable for everything they control.
That reframes the whole problem. The engineering work of a migration is real, but it only reaches the systems you build yourself. Everything else moves through purchasing, and purchasing has a rhythm the engineering calendar lacks: an RFP cycle, a renewal date, a contract up for renegotiation. Each of those is a forcing function, and any forcing function that passes without a requirement written into it is leverage let expire. The reason PQC procurement language exists as a discipline is that the biggest lever in the whole migration is a document the security team often never sees.
What questions belong in the RFP?
The RFP is where you find out whether a vendor can even be held to a post-quantum commitment before you’re committed to them. These are the questions that separate a vendor with a real plan from one improvising an answer, and each one maps to a decision you’ll have to make later:
| Ask the vendor | What the answer decides |
|---|---|
| Do you have a published, dated post-quantum roadmap? | Whether migration planning against this product is possible at all |
| Which post-quantum algorithms will you support, and by which date? | Alignment with the ML-KEM / ML-DSA timeline and the NIST IR 8547 schedule |
| Is post-quantum support something I switch on, or something you decide for me? | Whether you control the timing once they ship it |
| Will you provide a cryptographic bill of materials for this product? | Whether you can see the cryptography you’re buying, per CBOM |
| Is the upgrade covered by my proposed tier, or does it require a new contract? | Whether the migration is already paid for or is a future upsell |
| What’s your FIPS 140-3 validation status for the new algorithms? | Compliance readiness against federal and regulated-sector baselines |
| Is your architecture crypto-agile, so the next change is a configuration swap? | Whether you’re buying a one-time fix or a system that survives the transition after this one, per Crypto-Agility |
The last question is the one vendors least expect and the one that matters most for the long horizon. A product that can move from RSA to ML-KEM but hardcodes the result is a product that will make you do this again from scratch in 5 years. Asking for crypto-agility in the RFP is asking whether your next migration is a setting or a construction project.
What clauses belong in the contract?
An RFP answer is marketing until it’s a term. The contract is where the vendor’s roadmap becomes something you can enforce, and the difference between a comfortable answer and a defensible one is entirely in whether it’s written down with a consequence attached. The clauses worth insisting on:
- A dated post-quantum roadmap as a contractual commitment. Not “we intend to support PQC” but “the product will support ML-KEM for key establishment and ML-DSA for signatures by [date],” with the algorithms and the date both named. A roadmap with no date is a brochure.
- A crypto-agility requirement. Require that the product’s cryptography be changeable through configuration rather than a rebuild, so that when the algorithm needs to move again the vendor can do it without a multi-year re-platforming. This is architectural agility written as an obligation.
- A cryptographic bill of materials. Require the vendor to deliver and maintain a CBOM for the product, so the cryptography inside it stops being opaque and you can fold it into your own inventory.
- A notification obligation. Require the vendor to notify you when a post-quantum-capable version ships and when any algorithm they use is deprecated or broken, so the timing of your own migration isn’t something you have to keep chasing.
- A validation commitment. Where compliance demands it, require that the post-quantum implementation be FIPS 140-3 validated rather than merely FIPS-approved in principle, because a validated module is the difference between a claim and an artifact an auditor accepts.
- A remedy. Tie a consequence to a missed commitment, whether that’s a termination right, a service credit, or a renewal renegotiation trigger. A commitment with no remedy is a preference the vendor can quietly drop.
Every one of these is easier to obtain during a competitive RFP or a renewal than at any other time, which is exactly why the language has to be ready before those windows open.
How do you make the requirement stick to a reluctant vendor?
By making the requirement the market’s requirement rather than yours alone, so refusing it costs the vendor more than meeting it. A vendor’s default incentive is to keep its roadmap flexible and to avoid committing to a date it might miss, so the move is to remove the option of vagueness and to raise the cost of a “no.”
- Point to the mandate that binds you. If you operate under OMB M-23-02, the CRA, or a sector regulator that references NIST, cite it in the requirement. A vendor that serves regulated customers moves faster when your compliance obligation becomes a shared one, and the mandates in the mandate landscape were written partly to propagate exactly this way, through procurement into the supply chain.
- Route it above the support desk. Send the roadmap question through your vendor relationship manager to the product strategy team, because the people who can commit to a date are not the people who answer tickets.
- Use the renewal as the deadline. A contract up for renewal is the one moment a vendor has to say yes to keep the revenue. Treat every renewal date as a forcing function and put the post-quantum terms on the table before the vendor assumes the renewal is automatic.
- Make FIPS 140-3 the floor for regulated work. Where your own compliance turns on validated cryptography, require the validation rather than the promise, because “we use approved algorithms” and “we ship a validated module” are different assurances and only the second survives an audit.
The federal government models this at scale. OMB M-26-15 tells agencies to consult CISA’s product-categories list and build PQC integration into their requirements for products in those categories, which is procurement language operating as national policy: the mandate reaches product makers who never read the memo because their buyers wrote the requirement into the purchase.
Where does this connect to the rest of the migration?
Procurement language is the leverage arm of the whole vendor problem, and it only works when it’s wired to the artifacts around it. The inventory is where each vendor surface gets recorded with its roadmap answer and its contract-renewal date, so procurement knows which contracts to target and when. crypto-agility is the property you’re buying, so the RFP question and the contract clause are how an architectural goal becomes a purchasing requirement. And ownership is the reason any of it happens: chasing a vendor’s roadmap through an RFP is nobody’s default job, so unless the migration has a named owner who can task procurement, the leverage sits unused while the renewal date passes. The language in this note is the tool. An owner who reaches for it at the right moment is what makes it work.
Common misconceptions
- “Our vendors will handle their own post-quantum migration.” They will migrate on their own schedule, which may not be yours, and they won’t volunteer their exposure. The commitment you can enforce is the one you wrote into the contract before you signed.
- “A vendor saying they support PQC is enough.” A verbal or marketing claim isn’t a date, an algorithm, or a remedy. Only the contractual version, with the algorithm named and a consequence for missing the date, is real.
- “We can add the requirement after we sign.” Your leverage is highest before signature and at renewal. After you’ve signed, the vendor sets the timeline and you live with it until the next renewal window opens.
- “This is the security team’s job, not procurement’s.” It’s both, and the leverage lives in procurement’s hands. Security defines the requirement; procurement is the only function that can attach it to a contract at the moment the vendor has to agree.
- “FIPS-approved and FIPS-validated are the same thing.” Approved means the algorithm is on NIST’s list; validated means the specific module passed testing. Regulated work usually needs the validated module, so require it explicitly rather than accepting the general claim.
Questions people ask
What’s the single most important thing to put in a PQC RFP? A requirement for a published, dated post-quantum roadmap naming the algorithms and the years. Everything else follows from whether the vendor can produce one, because a vendor with no dated roadmap is telling you your migration for that surface has no schedule you can plan against.
When is the best time to add post-quantum terms to a vendor relationship? New procurement and contract renewal, because those are the only two moments the vendor needs your signature and your leverage is real. A live contract with no renewal in sight is the hardest place to introduce a new requirement.
Do I need my vendors to be crypto-agile, or only post-quantum-capable? Both, and agility is the one that protects you past this migration. A vendor that ships ML-KEM but hardcodes it has solved today’s problem and rebuilt tomorrow’s, so require crypto-agility as a design property alongside the specific algorithm.
How do I get a vendor to give me a cryptographic bill of materials? Make it a contractual deliverable in the RFP and the renewal, the same way you’d require an SBOM. Framed as a purchase condition it’s routine; requested after the fact it’s a favor the vendor can decline.
What if the vendor refuses to commit to a date? Treat the refusal as a finding. A vendor-controlled surface with no dated roadmap and no contractual commitment is one of the highest-priority items in your inventory, because it’s the part of your migration you cannot fix yourself and cannot yet schedule.
Does the mandate that binds me help with procurement leverage? Yes, directly. Citing OMB M-23-02, the CRA, or a sector rule that references NIST turns your requirement into a compliance obligation the vendor shares, and a regulated vendor moves faster when the compliance risk is on both sides of the table. See the mandate landscape for which one reaches you.
Everything here is the map, given freely. When your team needs its vendor surfaces turned into RFP requirements and enforceable contract clauses sequenced against your renewals, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.