Too much of the PQC market sells fear. Here is what practitioners should do first.

Vendors figured out that "Q-Day is coming" books more meetings than "show me your crypto inventory," so that is what they ship. The agencies that publish the clearest baseline timelines have been saying something more disciplined: start with discovery, planning, and crypto-agility, then pull dates forward where your own exposure justifies it.

Watch

The video version of this analysis is available on YouTube.

The thesis

Too much of the post-quantum cryptography market runs on fear because fear closes procurement cycles. Practitioners pay the bill: they skip cryptographic inventory, skip crypto-agility plumbing, and buy bundled products before they know what they are actually migrating from. The correction is not to ignore the threat. The correction is to anchor planning to primary-source government guidance, and only pull dates forward where your own data lifetime, exposure, or regulatory context justifies it.

CISA, the NSA, and NIST published a joint "Quantum-Readiness: Migration to Post-Quantum Cryptography" factsheet on 21 August 2023. After establishing a quantum-readiness roadmap, the first concrete technical task it names is cryptographic discovery and inventory, not algorithm selection. Many vendor PQC readiness assessments run the order in reverse: the slide that turns into a contract is algorithm selection, not an inventory handoff.

This is not an argument against using vendors. IBM, Keyfactor, and DigiCert all foreground cryptographic discovery in their PQC material; NIST's Migration to PQC project runs a discovery workstream with industry participants; the UK NCSC has launched an assured consultancy pilot whose first offering is Discovery and Migration Planning. The argument is against buying the platform before you own the discovery problem, not against outside help itself.

The fear patterns

Three patterns keep recurring across PQC marketing. Each one has an authoritative counter that practitioners can anchor to.

1. Imminent "Q-Day" marketing

The pattern is vague countdown framing ("the window is closing, buy now"), usually citing a recent resource-estimate paper with the caveats stripped.

The actual numbers tell a slower story, and they tell it about two different targets. Gidney and Ekerå's 2021 paper estimated factoring RSA-2048 at roughly 20 million noisy physical qubits over 8 hours. Google Quantum AI, writing in March 2026 with Stanford, UC Berkeley, and the Ethereum Foundation, estimated that attacking the secp256k1 elliptic-curve discrete logarithm problem (the primitive behind Bitcoin and Ethereum signatures) could run on fewer than 500,000 physical qubits under specific superconducting assumptions. These are estimates for different cryptanalytic targets, cited together to show a trend in resource cost rather than equivalent floors. Both describe requirements for future fault-tolerant machines. NIST IR 8547's own draft says there are no existing cryptographically relevant quantum computers (CRQCs) that currently threaten security, and expects the migration to take at least a decade.

The Global Risk Institute's 2025 Quantum Threat Timeline Report (March 2026) puts the probability of a cryptographically relevant quantum computer within ten years at 28 to 49 percent, a marked acceleration from prior surveys. Quite possible within a decade is a reason to plan, not a reason to buy this quarter. My walk-through of the Google paper shows why the caveats matter more than the headlines.

2. "Harvest now, decrypt later" urgency without inventory

Harvest-now-decrypt-later (HNDL, also called store-now-decrypt-later or SNDL) is a real threat category, and CISA, the NSA, and NIST all name it as motivation for migration schedules. The problem is that HNDL urgency is too often deployed in sales decks as a closer, before the practitioner has any idea what long-lived sensitive data they actually hold.

HNDL becomes actionable only when you can say what encrypted data you generate whose confidentiality lifetime is long enough that future decryption would still matter, where it sits, and what algorithms protect it. Without that, "harvest now, decrypt later" is unfalsifiable. Skipping discovery turns HNDL from a threat model into a marketing enhancer.

IR 8547 also draws a sharper line than most decks: encrypted long-lived data is exposed to HNDL risk now, while authentication stays secure until a CRQC exists. Code-signing and long-lived non-updatable devices are the edge cases that force earlier action regardless.

Even organizations that have started migrating miss whole subsystems. I wrote recently about how PQC migration plans routinely ignore zero-knowledge proof verifiers, because the inventory step never included them. That is the cost of inventory-later.

3. Bundled-product pressure dressed as readiness

The third pattern is structural: "PQC readiness assessment" delivered by a vendor whose next slide is their own migration platform. The assessment is real work, and so is the conflict of interest. A useful readiness assessment should leave you owning an inventory, a risk ranking, and a migration sequence that remain useful even if you switch supplier next month. If it cannot, it is selling the wrong thing first.

Marin Ivezic's March 2026 "Q-FUD" piece on postquantum.com already catalogued the four tactics (proprietary algorithm pitches, false authority claims, artificial urgency, stripping academic caveats). Naming the pattern is not new; what most of the critique lacks is the concrete practitioner alternative.

What practitioners need instead

The counter to each fear pattern is the same shape: a specific, standards-backed action that prevents the organization from buying the wrong thing first.

1. Cryptographic inventory, using CycloneDX CBOM

CycloneDX 1.6, released 9 April 2024, introduced Cryptography Bill of Materials support as an open standard, later standardized as Ecma International ECMA-424. Use it as a practical schema for one artifact inside a broader inventory program. Many teams can extend existing CycloneDX/SBOM pipelines rather than procure new tooling, though runtime discovery, protocol mapping, firmware visibility, and supplier engagement often still need dedicated capability. An incomplete first-pass CBOM is a feature; it shifts the conversation from "we need your platform" to "here is what we are actually running."

CBOM is not the whole inventory problem; it is one useful artifact inside it. NIST's SP 1800-38B draft treats cryptographic discovery as a multi-surface process, not a single report export, which is the right mental model.

The NCSC's March 2025 timeline guidance puts "identifying your key services and applications" and "forming a record of the data you hold (including its expected lifetime and its value to an adversary)" in Phase 1, with a 2028 deliverable. Everything else waits on it.

2. Crypto-agility before algorithm choice

NIST stood up a Crypto Agility project on 28 February 2025 and defines the capability as "the capabilities needed to replace and adapt cryptographic algorithms for protocols, applications, software, hardware, and infrastructures without interrupting the flow of a running system." The NCSC's 2025 guidance says the same in different language, and notes that classical and post-quantum cryptography will coexist during migration. Crypto-agility is not a product; it is a set of invariants you enforce: algorithms negotiated via protocol rather than compiled in, key material rotated without service redesign, hybrid modes supported natively.

Bruce Schneier, on Google's 2029 internal PQC target: the reason is not that a useful quantum computer must arrive in 2029, but that "crypto-agility is always a good thing." Google's and Cloudflare's 2029 dates are not vendor fear-selling; they are rational earlier targets from operators who have done the agility work. Earlier is defensible when the homework is done first.

Before evaluating any migration product, ask the other direction: if NIST deprecates algorithm X tomorrow, how long until your stack can swap? If the answer is "eighteen months and a re-architecture" rather than "a configuration push and a reboot," algorithm selection is not your top problem.

Algorithm selection is also more concrete than it was two years ago: NIST finalized FIPS 203, 204, and 205 in August 2024 and selected HQC as a backup KEM in March 2025. The bottleneck for most organizations is not which PQC family to pick; it is inventory, dependency mapping, and the agility to swap when choices change.

3. Government-timeline literacy

Three documents replace the vendor urgency chart. All are free, all are primary sources, and none of them require a call with an account executive.

• NIST IR 8547 (still an initial public draft as of April 2026, originally dated 12 November 2024): under NIST's current draft transition timeline, 112-bit public-key systems such as RSA-2048 and ECC P-256 are deprecated after 2030, and higher-strength RSA/ECC (for example RSA-3072, ECC P-384) are disallowed after 2035. Treat it as NIST's proposed U.S. planning anchor, not as settled rulemaking.
• NSA CNSA 2.0 (September 2022 advisory, with an updated algorithms document published 30 May 2025): for National Security Systems only, phased mandates ending with full quantum resistance by 2035. NSA's 2033 milestone applies to web browsers, web servers, and cloud services operating as NSS, not to the public internet; outside NSS, CNSA 2.0 is a timing signal, not a mandate.
• NCSC UK timelines (v1.0, 20 March 2025): 2028 for inventory and assessment, 2031 for high-priority migration, 2035 for full migration. For a broad practitioner audience, this is the clearest management timeline of the three.

These are planning anchors with overlapping but non-identical scope. The official clock is not imaginary, but neither is it a quarterly countdown: all three point to a multi-year migration that starts now with discovery and planning and moves through staged implementation into the early-to-mid 2030s.

The counterargument

The strongest objection is that fear works. Urgency moves budget, urgency gets CISO attention, and without it, PQC migration does not happen. That is true, and worth engaging with.

It is also the wrong conclusion from the right premise. Urgency aimed at the right first action is fine; urgency aimed at the wrong one is harmful. A CISO who spends 2026 budget on a migration platform before completing inventory consumes a budget line that will not return and narrows the window in which fundamentals can still be completed. Two years later the tool sits unused over a stack nobody inventoried, deadlines are closer, and the organization is behind where it started with less money.

The correction is not less urgency. It is urgency aimed correctly: at inventory, at agility, at the government timelines. The migration product, when the time is right, then plugs into an organization that can use it.

The takeaway

Three things to do this week, none of which require buying a migration platform first:

1. Pick one service you own end to end and map the three discovery surfaces the CISA/NSA/NIST factsheet names: network protocols, end-user systems and servers including applications and associated libraries, and cryptographic code in your CI/CD pipeline. A CBOM in CycloneDX 1.6 is the right artifact; a deliberately incomplete first pass is the correct starting point.
2. Write down your organization's agility story in one page: which algorithms are hard-coded, which are negotiated, how long a swap takes today, and what the single worst dependency is. That page is what a real readiness assessment looks like.
3. Read NIST IR 8547 (as a draft), the latest CNSA 2.0 advisory, and the NCSC's migration timelines side by side. Compare the dates in those three documents to the dates in the last vendor slide you saw.

If the vendor deck's dates are more aggressive than the public guidance and not tied to your own data lifetime, exposure, or regulatory context, that is not insight. That is the sales motion.

Sources:

1. CISA, NSA, and NIST, "Quantum-Readiness: Migration to Post-Quantum Cryptography", joint factsheet, 21 August 2023.
2. Gidney and Ekerå, "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits", arXiv:1905.09749, Quantum, 2021.
3. Babbush et al. (Google Quantum AI, Stanford, UC Berkeley, Ethereum Foundation), "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities", whitepaper, 31 March 2026.
4. Global Risk Institute, "Quantum Threat Timeline Report 2025", 9 March 2026.
5. Ivezic, "Q-FUD: The Quantum Panic Industry", postquantum.com, 5 March 2026.
6. NIST IR 8547 (Initial Public Draft), "Transition to Post-Quantum Cryptography Standards", 12 November 2024.
7. NSA, CNSA 2.0 Algorithms advisory, updated 30 May 2025.
8. NCSC (UK), "Timelines for migration to post-quantum cryptography", v1.0, 20 March 2025.
9. NIST, Crypto Agility project, created 28 February 2025.
10. OWASP CycloneDX, CBOM capabilities, CycloneDX v1.6 (9 April 2024); standardized as Ecma International ECMA-424.
11. NIST, "Post-Quantum Cryptography FIPS Approved", FIPS 203/204/205 issuance, 13 August 2024.
12. NIST, "NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption", 11 March 2025.
13. Schneier, "Google Wants to Transition to Post-Quantum Cryptography by 2029", Schneier on Security, April 2026.
14. NIST NCCoE, "Migration to Post-Quantum Cryptography" project; SP 1800-38B draft on cryptographic discovery.
15. 0xLoopTheory, "Google's quantum threat to Bitcoin: what the paper actually says," Encryptorium, 2 April 2026 (internal: /blog/google-quantum-threat-bitcoin).
16. 0xLoopTheory, "PQC Migration Plans Have a ZK Blind Spot," Encryptorium, 9 April 2026 (internal: /blog/pqc-zk-blind-spot).