Below is an objective explanation of what a complete post-quantum cryptography conversion actually involves — the NIST standards, the inventory work, the hybrid period, the hardware impact, the typical timelines, the typical costs, and the honest limitations. Then: what H33 is covering, what we're not, and how to claim a slot.
Post-quantum conversion (sometimes called PQ migration) is the work of upgrading cryptographic systems from classical algorithms — RSA, ECC, Diffie-Hellman — to algorithms that resist attack from a cryptographically-relevant quantum computer (CRQC). Shor's algorithm breaks every widely-deployed public-key system today. The replacement set is standardized by NIST. The conversion itself is multi-year, structural, and touches every layer of an organization's stack.
A complete PQ conversion typically covers eight distinct workstreams. Few organizations have all of them in flight; almost none can shortcut any of them.
Identify every use of public-key cryptography across the organization: keys, certificates, protocols (TLS, IKE, SSH), code signing, applications, networks, hardware (HSMs, TPMs, smart cards), embedded/IoT/OT systems, and data at rest and in transit. Discovery is the longest single phase in most enterprise programs.
Rank systems by data sensitivity, shelf-life of secrets (HNDL exposure), business criticality, regulatory exposure, and upstream/downstream dependencies. Long-lived sensitive data (PHI, classified intel, IP, identity records) goes first.
Run classical + post-quantum algorithms side-by-side during transition. Hybrid TLS, hybrid signing, hybrid KEMs. This buys compatibility with existing peers while adding PQ resistance. Most organizations operate in hybrid for years.
Adopt NIST-standardized algorithms: ML-KEM (FIPS 203, from Kyber), ML-DSA (FIPS 204, from Dilithium), SLH-DSA (FIPS 205, from SPHINCS+). FALCON and HQC in development. Configuration, parameter selection, and library updates are non-trivial.
TLS 1.3 with PQ key exchange. VPN suites (IKEv2/IPsec, WireGuard) updated. X.509 certificates expanded for larger keys/signatures. Secure boot, code signing, software supply chain attestation. Each protocol is its own conformance exercise.
PQ keys and signatures are 10 – 50× larger than classical. Many HSMs, accelerators, smart cards, TPMs, and embedded devices need firmware updates — or physical replacement. Hardware refresh cycles dominate large-enterprise PQ timelines.
The 2026 standards will not be the last. Crypto-agility is the discipline of building systems that can swap algorithms without redesign. The single most strategic engineering decision in a PQ program: agility-first or single-algorithm migration.
Performance benchmarking, interoperability conformance, security validation (FIPS 140-3 module updates), and ongoing compliance. Vendors, customers, and third parties must align — supply chain coordination is itself a workstream.
Structured roadmaps from NIST/NCCoE, NCSC, and major consultancies converge on a five-phase model. Phases overlap.
Define goals. Assign leadership. Understand HNDL exposure. Engage internal stakeholders + vendors. Align with CNSA 2.0 / NCSC / sector regulator deadlines.
Full cryptographic inventory (scanners + manual). Risk & priority assessment. Dependency mapping. 1 – 3 years at enterprise scale.
Detailed roadmap. Hybrid vs. cutover approach. Budget. Pilot designs. Vendor coordination. Crypto-agility framework selection.
Start with high-priority / low-risk systems. Test hybrids. Deploy updates. Replace hardware. Migrate data and protocols in staged waves.
Ongoing verification. Performance tuning. Compliance audits. Crypto-agility maintenance for the next standard transition.
Highly dependent on starting maturity, regulatory exposure, and legacy footprint. These are industry-synthesized ranges, not promises — quote them as planning starting points only.
| Organization scale | Typical window | Dominant cost driver |
|---|---|---|
| Small enterprise | 5 – 7 years | Software stack + identity/SSO/code-signing migration |
| Mid-size enterprise | 8 – 12 years | Inventory discovery + HSM/TPM refresh + vendor coordination |
| Large enterprise (global, legacy, OT) | 12 – 15+ years | Hardware refresh cycles + supply chain + legacy systems with no PQ path |
| Critical infrastructure / national | 15+ years | Sovereign supply chain + cleared-environment HSMs + regulator alignment |
| Tech-platform leaders (Google, Cloudflare) | ~2029 internal target | Vertical integration + crypto-agility-first architecture |
Major regulator milestones in scope: ~2028 (discovery + inventory complete) · ~2031 (high-priority migrations complete) · ~2035 (full migration, NIST deprecation target, CNSA 2.0 alignment).
Highly variable. The numbers below are industry-synthesized estimates that assume PQ work piggybacks on normal infrastructure refresh cycles. Standalone PQ programs run higher; delayed starts run higher still.
| Organization scale | Estimated investment | Largest line items |
|---|---|---|
| Small organizations | $100K – $500K initial | Discovery tooling + consulting + library updates |
| Mid-size enterprises | $500K – $3M+ | + HSM refresh, integration, hybrid deployment, pilot testing |
| Large enterprises | $5M – $20M+ over years | + global rollout, supply chain coordination, performance mitigation |
| Critical infrastructure / national | Tens of millions – billions | US federal civilian systems estimated ~$7B+ over a decade |
Line items not always counted: training, performance mitigation (larger keys/signatures impact bandwidth, storage, latency), opportunity cost of pulled engineering resources, and the cost of delay — rushed work or post-CRQC breach response.
All three of these are the current FIPS-finalized standards as of 2024-2026. FALCON and HQC are advancing.
Module-Lattice Key Encapsulation Mechanism. The replacement for RSA / Diffie-Hellman key exchange. Modest performance impact, modest size impact.
Module-Lattice Digital Signature Algorithm. The primary replacement for ECDSA / RSA signatures. ~2 – 3 KB signatures (vs. 64 – 256 bytes for classical).
Stateless Hash-Based Signatures. Hash-based, no lattice assumption — survives lattice attacks. Larger and slower than ML-DSA, used as a backup family.
NTRU-lattice signature standard, complementary to ML-DSA. Smaller signatures, harder to implement constant-time. Expected to formalize as FN-DSA.
Code-based key encapsulation, recently selected as a backup to ML-KEM. Different hardness assumption — important for cryptographic diversity.
Generally NOT impacted by Shor's algorithm. Grover's algorithm halves effective key length — moving to AES-256 / SHA3-256 is sufficient for symmetric primitives.
No marketing inflation. Below is what the 1,000-company program includes at no cost, and what remains your responsibility. We will not over-promise scope; the credibility of the offer depends on this being honest.
Even with H33 covering the work, these structural constraints don't go away. Going in eyes-open beats discovery mid-pilot.
Cryptography is everywhere. Discovery in legacy systems is genuinely hard — undocumented dependencies, forgotten keys, embedded credentials.
PQ artifacts are 10 – 50× larger than classical. Affects bandwidth, storage, protocol packet sizes, and any system with hard byte budgets.
Many devices require physical replacement, not firmware updates. Refresh cycles span years.
Your vendors, customers, and partners must align on PQ adoption simultaneously. Some won't be ready.
PQC expertise is scarce. Most existing crypto-engineering teams have never deployed lattice or hash-based signatures in production.
Some PQ algorithms are slower than classical for certain operations. Selection and parameter tuning matter.
HQC was just selected. FALCON is finalizing. Future standards will follow. Crypto-agility is not optional.
CRQC arrival estimates span 2028 – 2033. HNDL means sensitive long-lived data should be assumed to be at risk now.
Email support@h33.ai with your organization name, industry, approximate scale, and the three highest-priority cryptographic surfaces you'd start with. We screen for genuine production scope — not pre-revenue exploration.