Post-Quantum Cryptography (PQC) Crypto-Agility Selling to the CISO and Chief Cryptographer — 60-Min Training

Two ways to sell PQC: the algorithm sale versus the agility sale

Every deal in this category resolves into one of two postures, and reps who cannot name which one they are running lose to the one they aren't.

The algorithm sale leads with FIPS 203, 204, and 205 — ML-KEM (formerly CRYSTALS-Kyber), ML-DSA (formerly CRYSTALS-Dilithium), SLH-DSA (formerly SPHINCS+), plus FN-DSA/FALCON for compact signatures. The pitch is coverage: we support the standardized set, hybrid modes included. It demos well to a Chief Cryptographer because it speaks their language, and it fails at the CISO layer because "we support the algorithms" answers a question nobody funds. Algorithm coverage is table stakes now that NIST has published; every serious vendor claims it. When your differentiation is a checklist the whole market can print, procurement will commoditize you and buy on price.

The agility sale leads with the swap. The claim is not *which* algorithms — it is *how fast can you change them, and what does changing them cost you in engineering hours and downtime*. This posture assumes the standardized set will move again: parameters get revised, an implementation gets broken, a regulator adds a deadline, a hardware root of trust turns out not to support what you deployed. The buyer isn't purchasing an endpoint; they're purchasing the ability to move without a rewrite.

The reason the agility posture wins the larger deal is that it maps to the customer's actual pain, which is not cryptographic — it is architectural debt. Most enterprises have crypto hard-coded across decades of applications: cipher suites pinned in config files, key sizes baked into libraries that nobody owns, certificate logic embedded in application code by developers who left. The migration cost is not the math. It is the archaeology.

There's a third posture worth naming because reps drift into it by accident: the compliance sale, where the whole pitch is the deadline. It closes small, fast deals and caps your ACV, because a deadline-driven buyer buys the cheapest thing that produces a document. Use compliance to create urgency; never use it as the value case.

How to pick your posture in the first call. If the customer has not completed a cryptographic inventory, you are selling discovery and inventory first — the agility conversation is premature and will sound abstract. If they have an inventory and are debating which algorithms to deploy where, you are in the agility sale and should be talking about swap mechanics. If they have a regulator date and no budget, you are in a compliance sale and should qualify hard on whether real money exists before spending a quarter on it.

How to decide which posture the account is actually in

Run the decision live on the whiteboard during the training. The gate is inventory completeness, because everything downstream depends on whether the customer knows what they have.

Two coaching notes on this flow. First, "inventory complete" almost never means complete. Teams routinely find substantially more cryptographic assets than their initial inventory captured, because scanning tends to catch certificates and miss embedded libraries, firmware signing keys, hard-coded cipher suites, and anything living in OT or IoT segments. Ask the Chief Cryptographer directly: *did your scan cover code-signing, firmware, and non-IP-network segments, or just TLS?* The answer tells you whether their timeline is real.

Second, the budget-owner question separates the two-quarter deal from the two-year one. A funded migration program has a named owner, a board-visible milestone, and usually a headcount attached. A compliance-only motion has a date and a spreadsheet. Both are real; they are not the same deal, and pricing them identically is how reps lose forecast credibility.

The adjacent read. This same decision tree ports almost intact to other architecture-debt sales — certificate lifecycle management, secrets management, key management migrations off a legacy HSM fleet. In each, the gate is "do you know what you have," the buyer split is "who funds versus who approves," and the trap is selling the endpoint feature instead of the change mechanism. Reps who learn the shape here transfer it.

The numbers that actually move each conversation

Refuse to run this training on invented benchmarks. Use the numbers the customer can verify and the ones they generate themselves.

The regulatory clock is public. U.S. federal direction on post-quantum migration is set by National Security Memorandum 10 and OMB Memorandum M-23-02, which drove agency cryptographic inventories and a migration horizon out to 2035. NIST published the first standardized algorithms as FIPS 203, 204, and 205 in 2024. CISA, NSA, and NIST have jointly published quantum-readiness guidance aimed at getting organizations to inventory first. Those are checkable facts; cite them by name and let the customer pull the documents. Federal contractors inherit the pressure through flow-down, which is why defense supply chain, aerospace, and federal systems integrators are the ripest segments.

The exposure math is the customer's own. Harvest-now-decrypt-later risk is a function of how long the data stays sensitive, not of any vendor's roadmap. Build the calculation live in discovery:

• Ask for their data classification tiers and the retention or sensitivity window on each.
• Anything with a sensitivity horizon longer than the customer's own migration timeline is exposed by definition — data captured today under classical key exchange, decrypted later.
• Defense and intelligence material, long-lived intellectual property, pharmaceutical trial data, patient records under lifetime-of-patient obligations, and long-dated financial contracts all sit at the high end.

That produces a number the customer owns: *X terabytes of category-A data currently protected by classical key exchange, with a sensitivity window exceeding the migration date.* No vendor benchmark required, and it survives procurement scrutiny because it came from their own classification scheme.

The operational math is where deals size themselves. Certificate counts are the proxy for migration labor. Ask for total certificates under management, average lifetime, and how many renewals per quarter the team handles today. Then ask what fraction are automated versus ticket-driven. PQC migration does not merely re-issue those certificates once — it typically means running hybrid classical-plus-PQC certificates during a transition, testing interoperability at every endpoint, and re-issuing again as parameters or profiles settle. A team doing manual renewals at scale has a labor problem before any quantum computer exists, and that problem is fundable today.

Signature sizes are the technical constraint reps forget. ML-DSA and SLH-DSA signatures and ML-KEM public keys are substantially larger than the ECC equivalents they replace. That has real downstream consequences: handshake sizes grow, some embedded and constrained devices cannot accommodate the payloads, protocol implementations that assumed small signatures need adjustment, and certificate chains inflate. When the Chief Cryptographer raises this, do not deflect — it is the most legitimate objection in the category. The honest answer is that agility exists precisely because these trade-offs will keep shifting, and a stack that can swap without a rewrite is how you absorb them.

Pricing structure, not price points. Do not quote market list pricing you cannot substantiate. Teach the structural argument instead: per-certificate pricing punishes the customer exactly when migration succeeds and volume grows, which turns your success into their cost overrun and poisons renewal. Per-platform or per-environment pricing aligns with the migration curve. Multi-year terms are worth real discount because the migration is multi-year by regulation — a one-year contract for a decade-long architectural program is a mismatch both sides should reject. Anchor discount to term length and to case-study or reference rights, and put the actual percentages in your own approved pricing guidance rather than in a training deck.

Sequencing the engagement from first call to renewal

The order of operations matters more than any single play, because each step earns the right to the next.

Discovery, run jointly. Never sequence the three buyers. A CISO briefed alone will ask the Chief Cryptographer to sanity-check you and you will not be in the room for that conversation. Send a one-page scorecard 48 hours ahead listing exactly what you'll ask, so the cryptographer arrives with inventory data instead of promising to send it later. The seven questions worth the time: current inventory scope and method; highest-sensitivity data classes and their windows; which standardized algorithms they intend to deploy and where; whether the application stack can swap without code change; certificate volume and automation rate; PKI, KMS, and HSM estate; and current contract end dates.

POC, installed by them. Insist the customer's platform team does the install. An AE-installed proof of concept proves nothing about their environment and produces no internal champion. Ban three failure modes outright: algorithm-coverage demos with no swap shown, single-application scope with no integration surface, and any POC that skips the exposure assessment — the last one is what turns a technical win into a deal with no business case attached. What to prove instead: hybrid classical-plus-PQC operating on a real workload, a genuine runtime algorithm change with no application redeploy, and interoperability against their existing PKI, key management, and hardware security modules.

The integration question is a close, not a threat. When they ask whether you work with their existing certificate authority, cloud KMS, secrets manager, and HSM fleet, that is a buying signal. Demonstrate it live in the POC rather than answering in a slide. The customer is checking whether adopting you means abandoning a seven-figure investment; showing that it doesn't removes the largest single objection in the room.

Displacement against an incumbent. Most accounts already own certificate lifecycle or PKI tooling from an established vendor, and the honest position is usually complementary at entry. Three questions that open the wedge, all asked of the Chief Cryptographer rather than the CISO, because the cryptographer will answer them truthfully: can your current platform change an algorithm at runtime without an application rewrite; does it issue and validate hybrid certificates through the transition; and what happens to your renewal throughput when certificate operations multiply during migration. You are not attacking the incumbent's breadth — you are testing the depth of the one capability the migration actually requires.

Renewal is written at signature. Put the milestones in the agreement: inventory completed within a defined window, agility layer deployed on a named set of applications, hybrid pilot live by a stated date, and a coverage dashboard reviewed each quarter with the Chief Cryptographer present. By month 18, that dashboard is the renewal conversation — the customer is not evaluating whether to keep you, they're reading their own progress report. A joint quarterly cryptography review also surfaces expansion naturally, because every quarter reveals another segment of estate that the original scope didn't cover.

Where this training transfers. The same sixty-minute structure works for hardware security module refreshes, certificate lifecycle consolidation, and secrets management migrations. Swap the regulatory anchor and the technical proof point; keep the three-buyer qualification, the customer-generated exposure math, the customer-installed POC, and the milestone-driven renewal. Sales teams that build one strong architecture-sale motion tend to reuse it across the entire security infrastructure portfolio.

Related questions

Who actually signs a PQC deal?

The CISO usually holds budget, the Chief Cryptographer holds technical veto, and Compliance holds the regulatory narrative. Deals die when a rep single-threads to whichever one answered the email first. Qualify all three in the first call or reschedule.

Is harvest-now-decrypt-later a real risk or a sales device?

It's a real structural risk for long-lived data: encrypted traffic captured today can be decrypted later if the underlying key exchange becomes breakable. The honest framing ties it to the customer's own data sensitivity windows, not to any predicted timeline for quantum hardware.

Should we lead with inventory or migration?

Inventory, in nearly every account. Migration planning built on an incomplete inventory produces a timeline the customer can't defend to a regulator, and scans routinely miss code-signing, firmware, and embedded crypto that the eventual project must cover.

What makes a PQC POC credible to a Chief Cryptographer?

A live runtime algorithm swap on a real application with no code redeploy, hybrid certificate validation across their actual endpoints, and interoperability tested against their existing PKI, KMS, and HSM estate. Coverage checklists impress nobody at that level.

How does this differ from selling ordinary security software?

The clock is regulatory and the pain is architectural. You're not displacing a tool; you're funding a multi-year re-plumbing of cryptography across an estate nobody has fully mapped. That changes the deal shape, the buying committee, and the contract term.

FAQ

Do we need to know the cryptography deeply to sell this?

Reps need working fluency, not research-level depth. Know what ML-KEM, ML-DSA, and SLH-DSA are for, why hybrid mode exists, why signature and key sizes matter operationally, and what crypto-agility means architecturally. Bring the SE for anything past that — a rep who bluffs in front of a Chief Cryptographer loses the account permanently.

What if the customer says the quantum threat is decades away?

Agree, then reframe. The threat timeline is genuinely uncertain; the migration timeline is not. Cryptographic transitions across a large enterprise estate historically take many years, and the regulatory dates are already published. Data with a twenty-year sensitivity window is exposed today regardless of when capable hardware arrives.

How do we handle a customer mid-contract with an incumbent PKI vendor?

Deploy complementary in a non-overlapping area — an agility layer on applications the incumbent doesn't cover, or a hybrid pilot in a segment outside their scope. Accumulate evidence through the term. The displacement conversation belongs at their renewal, with your own performance data in hand.

Is per-certificate or per-platform pricing better for us?

Per-platform, in almost every case. Per-certificate pricing means the customer's cost spikes exactly as the migration succeeds, which turns your win into their budget crisis and gives procurement a reason to cap deployment. Per-platform aligns your revenue with their coverage and makes expansion a non-event.

What's the fastest way to disqualify a bad PQC opportunity?

Ask who owns the migration budget line and when it was funded. A named owner with a board-visible milestone is real. A compliance officer with a deadline, no headcount, and no funded line is a document-buying motion — time-box it or walk, and reallocate the quarter.

Does this sales motion work outside regulated industries?

It works wherever data sensitivity outlives the migration window — long-lived intellectual property, pharmaceutical research, financial contracts, critical infrastructure. Outside those, urgency is genuinely lower and the deal will be smaller and slower. Qualify on data longevity rather than on industry label.

Sources

• NIST — Post-Quantum Cryptography Project: https://csrc.nist.gov/projects/post-quantum-cryptography
• NIST — FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard: https://csrc.nist.gov/pubs/fips/203/final
• NIST — FIPS 204, Module-Lattice-Based Digital Signature Standard: https://csrc.nist.gov/pubs/fips/204/final
• NIST — FIPS 205, Stateless Hash-Based Digital Signature Standard: https://csrc.nist.gov/pubs/fips/205/final
• CISA — Quantum Readiness: Migration to Post-Quantum Cryptography: https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography
• The White House — National Security Memorandum on Promoting United States Leadership in Quantum Computing (NSM-10): https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/
• NSA — Commercial National Security Algorithm Suite 2.0: https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-sec/
• NIST NCCoE — Migration to Post-Quantum Cryptography Project: https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms
• ENISA — Post-Quantum Cryptography: Current State and Quantum Mitigation: https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation
• IETF — Datatracker, Post-Quantum Use In Protocols (pquip) Working Group: https://datatracker.ietf.org/wg/pquip/about/

Related on PULSE

• [Hardware Security Module (HSM) Selling to the CISO and Cryptography Lead — 60-Min Training](/knowledge/st405)
• [GRC Platform Selling to the CISO and Chief Compliance Officer — 60-Min Training](/knowledge/st398)
• [Data Loss Prevention (DLP) Selling to the CISO and Chief Privacy Officer — 60-Min Training](/knowledge/st393)
• [AI Safety / Red Team Services Selling to the CISO — 60-Min Training](/knowledge/st412)
• [OT/ICS Security Selling to the Plant Manager and CISO — 60-Min Training](/knowledge/st404)
• [Mobile Threat Defense (MTD) Selling to the CISO and Endpoint Management Lead — 60-Min Training](/knowledge/st403)