up:: The Human & Organizational Side MOC
PQC for Software Vendors
PQC for software vendors is the work of being on the receiving end of the post-quantum transition rather than the buying end. Your enterprise customers are writing post-quantum requirements into their procurement and renewal language, and every one of those requirements arrives at a vendor who has to answer it. The questions look like compliance paperwork and function as a technical audit: they ask which algorithms your product uses, when it will support the standardized ones, whether the change is a configuration switch or a rebuild, and whether you can produce an inventory of your own cryptography. A vendor who can answer precisely wins procurement cycles against competitors who cannot, and a vendor who answers loosely gets caught at the technical follow-up.
The short version: your customers are about to ask you the questions in the vendor-claims checklist, because that checklist is what their advisors handed them. Answer by inventorying the cryptography you actually control, committing to dated support for ML-KEM and ML-DSA on a schedule you can hold, and publishing that answer as a page you can link. The vendors who lose these cycles are not the ones behind on migration. They are the ones who cannot describe where they are.
Why is this arriving now?
Because the buyer side finally has language. For most of the last decade an enterprise asking about post-quantum readiness had no way to make the answer binding, so the question went in a security questionnaire, got a reassuring paragraph, and stopped there. That changed when procurement language became specific: a named algorithm, a named parameter set, a date, a cryptographic bill of materials as a deliverable, and a crypto-agility clause. Those are terms a lawyer can enforce and an engineer can verify.
The structural reason it lands on you rather than on your customer’s engineering team is the one vendor-controlled crypto surfaces describes. An enterprise buys far more software than it writes, so a large part of its cryptography sits inside products it did not build, and that part of its migration timeline is set by vendors rather than by its own engineers. In Mosca’s terms, you are the migration-time variable for every customer who runs your product. They have worked that out, and the questionnaire is what they do about it.
There is a second force behind the timing, and it is worth naming because it changes who asks. Federal and regulated buyers are bound by schedules like CNSA 2.0 and NIST IR 8547, and a bound buyer propagates its obligation down its supply chain as a contract term. Once one regulated customer asks, the question tends to spread across the rest of your enterprise base within a year, because their advisors are reading the same source documents.
What will they actually ask you?
The questions vary in wording and rarely in substance. Each one tests a different thing, and knowing which is which is most of the advantage:
| What they ask | What they are testing | What a defensible answer contains |
|---|---|---|
| Which cryptographic algorithms does the product use? | Whether you have an inventory at all | Named algorithms and parameter sets, scoped to a product version |
| Do you have a dated post-quantum roadmap? | Whether their migration for your surface has a schedule | A year, a named algorithm, and the release it ships in |
| Which standardized algorithms will you support? | Whether you track the finished standards or vendor marketing | ML-KEM for key establishment, ML-DSA or SLH-DSA for signatures, by name |
| Is post-quantum support on by default, or do I enable it? | Whether they control the timing after you ship | Which release makes it available, which makes it default, and who flips it |
| Can you provide a CBOM? | Whether your cryptography is visible or opaque | A CBOM scoped to the deployed version |
| Is the architecture crypto-agile? | Whether this migration repeats in 5 years | Where the algorithm is selected, and what changing it costs |
| What is your FIPS 140-3 validation status? | Whether you clear a regulated buyer’s floor | The module, its certificate status, and what is in the boundary, per FIPS 140-3 |
| What happens when a peer cannot negotiate PQC? | Whether the fallback silently downgrades | The documented behavior, including whether it is configurable |
The last row is the one most vendors have never considered and the one a competent reviewer weights heavily. A product that supports hybrid key exchange and silently falls back to classical when the peer does not offer it has a real post-quantum capability and no guarantee, and the difference between those two is the whole question.
What do you need to know about your own product first?
You cannot answer a questionnaire about cryptography you have not located, and the location work is the part that takes real time. Your product’s cryptography sits in at least four places, and you control them to very different degrees:
- What you terminate. The TLS your service presents to clients, and the certificates behind it. This is the surface you control most directly and the one most likely already to have a path, since the major providers and browsers have been moving here first.
- What you embed. The cryptographic libraries compiled into your product, the SDKs you ship to customers, and anything running on a device outside your data center. Changing these means a release, and for embedded targets it can mean the constraints in constrained-device PQC.
- What you sign. Release signing, update signing, license tokens, and anything a customer verifies. Signature migration is a separate problem from key establishment, with its own size and performance profile, and it reaches firmware and code signing wherever you ship binaries.
- What you inherit. Your own cloud providers, payment processors, identity providers, and third-party services. You are somebody else’s customer here, and supply-chain risk runs in both directions. A customer asking about your roadmap is entitled to know which parts of it depend on vendors you do not control.
Doing this inventory once and writing it down is what turns 40 questionnaires into one document, per cryptographic discovery. Doing it per deal is how a sales cycle acquires a 2-week hold while engineering reconstructs the answer from memory.
Why won’t your competitors tell you what they actually support?
Because the market currently rewards a confident yes, and “quantum-safe” has no defined content. A vendor can say it without naming an algorithm, a parameter set, a version, or a date, and until recently nobody on the buying side had the vocabulary to press further. The phrase costs nothing to say, which is exactly why it has stopped being worth anything.
That is changing in a way that favors precision. The buyers asking now are the ones whose advisors handed them a checklist, and a checklist turns a vague yes into a follow-up question the vague vendor cannot answer. The failure mode is not being behind on migration, which is normal and expected. It is claiming a capability at the questionnaire stage and having it evaporate at the technical review, because the buyer then has to re-examine every other answer you gave them.
So the sovereign position is the specific one. “We support X25519MLKEM768 for TLS key establishment as of release N, our signature migration is scheduled for release N+2, and our SDK inherits its cryptography from library L which we track” is an answer no competitor’s marketing can beat, because it is checkable. A buyer who can verify one of your claims tends to stop verifying the rest.
What can you commit to, and what should you refuse to commit to?
Commit to dates you control and describe honestly the ones you do not. A date you can hold is worth more than a date that impresses, because the questionnaire answer becomes a contract term, and the contract term becomes a conversation with that customer’s auditor in 2 years.
Worth committing to: the release in which an algorithm becomes available, the release in which it becomes default, the delivery of a CBOM at a stated cadence, notification when you deprecate an algorithm or ship post-quantum support, and the fallback behavior your product exhibits when a peer cannot negotiate.
Worth describing rather than committing: anything gated on a dependency you do not own. If your signature path waits on a library, name the library and the constraint. A buyer who understands your dependency treats you as a credible partner with a known blocker. A buyer who discovers the dependency after you promised the date treats you as a vendor who does not know their own product.
Worth refusing outright: the word “quantum-safe” with nothing attached, a validation status you do not hold, and a claim about your product’s cryptography that is really a claim about your cloud provider’s. That last substitution is common and it is the one a technical reviewer catches fastest, because your provider’s support for post-quantum TLS says nothing about the algorithms inside your application.
What does a good answer look like operationally?
Publish it. The highest-leverage move available here is turning the questionnaire from a per-deal fire drill into a link, by writing a public post-quantum statement that covers the eight rows in the table above and keeping it versioned. A page you maintain gets read before the questionnaire arrives, shortens the security review, and lets your sales team answer without routing every question to engineering.
The second move is to make the answer survive its own success. Assign one owner for the statement, tie its review to your release cycle rather than to a calendar reminder, and version it so a customer can tell which release a claim applies to. An accurate statement about a version nobody runs anymore is a new liability rather than a retired one.
The third is to treat crypto-agility as a product property you can sell rather than a checkbox you clear. A buyer asking about agility is asking whether they will run this procurement again in 5 years. A vendor who can point to where the algorithm is selected, and describe what changing it costs, is answering a question most of the market cannot.
Common misconceptions
“We use AES-256, so we are fine.” Symmetric cryptography is the part least affected, and it is not what the question is about. The exposure is in key establishment and signatures, which is where harvested traffic and long-lived certificates live.
“Our cloud provider handles it.” Your provider’s TLS termination is one of four surfaces, and it is the one you control least and depend on most visibly. It says nothing about the libraries compiled into your product or the keys you sign releases with.
“We will answer it when a customer asks.” By then it is inside a sales cycle with a clock on it. The inventory takes weeks and the questionnaire has a due date, and those two facts meet badly.
“Nobody is really enforcing this yet.” Enforcement arrives as a contract clause rather than a regulator, and it arrives from your regulated customers first. See the mandate landscape for which obligations propagate down a supply chain.
“Saying we are quantum-safe is close enough.” It is an unverifiable claim in a document your customer’s advisor is reading specifically to find unverifiable claims.
Questions people ask
Who owns the answer inside a software company? Security owns the accuracy and engineering owns the dates, and somebody has to own the document. In practice the CISO or a security engineering lead holds the statement and negotiates the roadmap language with product, because the claim is a security claim and the schedule is a product decision.
How long does the first inventory take? Longer than a questionnaire’s due date and shorter than a migration. The work is locating cryptography across the four surfaces above, and the largest variable is how much of your product is embedded or shipped to customer environments rather than running in your own.
What if we have no post-quantum support at all yet? Say so, with the inventory and a dated plan attached. A vendor with no support and a credible schedule is a manageable finding. A vendor with no support and no schedule is the item that goes to the top of the customer’s risk register, per their own procurement guidance.
Do we need FIPS 140-3 validation to answer this? Only if your buyers are federal or in a sector that requires it, in which case the validation status of the module is the answer rather than a supporting detail. See FIPS 140-3 for what the boundary covers.
Should we support hybrid or pure post-quantum? Hybrid is where the deployed ecosystem is, and it is what your customers’ clients will negotiate. Hybrid vs Pure PQC covers the tradeoff, and the practical answer for a vendor is that supporting hybrid is what makes you interoperable today.
Is a CBOM worth producing before a customer requires it? Yes, because it is the artifact that answers most of the questionnaire at once and it is the one deliverable that improves your own engineering visibility as a side effect. See CBOM.
What do we say about our own vendors? Name the dependency and what it gates. Your customers are running the same exercise you are, and a vendor who is candid about inherited constraints reads as competent rather than exposed.
How often should the public statement be updated? On your release cadence, tied to the releases that change cryptographic behavior. A statement that drifts from the shipped product becomes a documented claim about a version you have already replaced, which is a liability your customer can point at.
Everything here is the map, given freely. When your team needs its own cryptographic surfaces inventoried and turned into a post-quantum statement your customers’ security reviewers will accept, that’s the work I do.
Last verified 2026-08-27 · Updated 2026-08-27 · Maintained by Addie LaMarr, LaMarr Labs.