Post-Quantum Cryptography Migration Plan
What to Do Before 2035

The Scale of the Problem

Every public-key cryptographic operation in your infrastructure is built on mathematical problems that quantum computers will solve efficiently. RSA relies on integer factorization. ECDH and ECDSA rely on the elliptic curve discrete logarithm problem. Both fall to Shor's algorithm running on a sufficiently large quantum computer.

This is not a question of "if." NIST, the NSA, CISA, and the White House have all issued directives mandating migration. National Security Memorandum 10 (NSM-10), signed in May 2022, required federal agencies to begin inventorying cryptographic systems immediately. OMB Memorandum M-23-02 followed with specific reporting requirements and deadlines.

The government's own cost estimate for federal migration alone is $7.1 billion. For private-sector organizations, the economics are similar in proportion: enterprise migrations using internal teams typically take 2-4 years and cost $8-25 million depending on the complexity of the cryptographic footprint. The organizations that treat this as a future problem will face emergency timelines, audit failures, and contract disqualifications.

The Harvest-Now-Decrypt-Later Threat

The most dangerous misconception about post-quantum migration is that you have time until quantum computers are built. You do not. The threat is not future decryption—it is present-day data collection.

Nation-state adversaries are intercepting and storing encrypted traffic today, banking on the certainty that quantum computers will eventually break the encryption. This is called the harvest-now-decrypt-later (HNDL) attack, and it has been publicly acknowledged by the NSA, GCHQ, and ANSSI.

Consider the implications: every TLS session using ECDH key exchange, every VPN tunnel using RSA, every encrypted email using PGP with RSA keys—all of that ciphertext can be recorded today and decrypted in 5, 10, or 15 years when a cryptographically relevant quantum computer (CRQC) becomes operational. If the data you encrypted today will still be sensitive in 2035, it is already compromised in a strategic sense.

The 5-Phase Migration Plan

Phase 1: Cryptographic Inventory (Weeks 1-4)

You cannot migrate what you have not mapped. The first phase requires a complete inventory of every cryptographic algorithm, key size, protocol, and library in your production environment.

• TLS/SSL certificates: What algorithms are your certificates using? RSA-2048? ECDSA P-256? Document every certificate across every domain, load balancer, and internal service.
• Key exchange protocols: How are your services negotiating session keys? ECDH? DH? RSA key transport? Map every TLS cipher suite in use.
• Digital signatures: Where do you sign data? JWTs, API request signing, code signing, document signing, S/MIME email. Identify every signature operation.
• Data at rest: How is stored data encrypted? If you are using RSA or ECC to wrap symmetric keys, those wrapping keys are vulnerable.
• Third-party dependencies: What cryptographic libraries do your vendors use? OpenSSL, BoringSSL, libsodium, AWS KMS, Azure Key Vault—each has its own PQC support timeline.

Phase 2: Risk Assessment (Weeks 5-8)

Not all systems need to migrate simultaneously. Prioritize based on two factors: data sensitivity and data longevity.

Phase 3: Architecture Planning (Weeks 9-12)

This is where most internal migration projects stall. The architectural decisions are complex: Do you run hybrid mode (classical + PQ) or cut over directly? How do you handle backward compatibility with partners who have not migrated? What about performance impact from larger keys and signatures?

H33 eliminates these decisions by handling them at the API layer. When you call H33's cryptographic endpoints, the system automatically uses post-quantum algorithms, with optional hybrid mode for backward compatibility. There is no architectural redesign required on your side. Your application code calls an API. The API returns quantum-resistant results. That is the entire integration surface.

Phase 4: Implementation and Migration (Weeks 13-16)

With H33, implementation means replacing your cryptographic library calls with API calls. There are no new hardware security modules to procure, no firmware upgrades to schedule, no kernel patches to test. The migration is a software change:

// Before: RSA key exchange (vulnerable)
const encrypted = crypto.publicEncrypt(rsaPublicKey, data);

// After: ML-KEM key encapsulation (FIPS 203, quantum-resistant)
const { ciphertext, sharedSecret } = await h33.kem.encapsulate(publicKey);
const encrypted = await h33.encrypt(data, sharedSecret);

// Before: ECDSA signature (vulnerable)
const sig = crypto.sign('sha256', data, ecdsaPrivateKey);

// After: ML-DSA signature (FIPS 204, quantum-resistant)
const sig = await h33.sign(data, privateKey);

Each endpoint swap takes minutes, not months. A team of two engineers can migrate an entire production cryptographic stack in a sprint.

Phase 5: Validation and Continuous Compliance (Ongoing)

Migration is not a one-time event. Post-quantum compliance requires ongoing validation:

• Automated algorithm auditing: Continuously scan your codebase and runtime for any remaining classical algorithm usage.
• Key rotation: Establish rotation schedules for post-quantum keys. H33's API supports automated key rotation with zero-downtime cutover.
• Compliance evidence generation: Maintain audit trails showing when each system was migrated, which algorithms are in use, and what security levels are deployed.
• Interoperability testing: As your partners and vendors migrate, test cross-system PQC interoperability regularly.
• Standard updates: Monitor NIST for algorithm updates, parameter changes, and new standards (FIPS 206 for SLH-DSA is forthcoming).

Common Migration Pitfalls

Organizations that attempt PQC migration without specialized infrastructure consistently encounter the same failure modes:

• Incomplete inventory: Missing cryptographic usage in embedded systems, IoT devices, legacy applications, or third-party integrations. Every missed system is a vulnerability.
• Ignoring ECDH: Teams replace RSA but forget that ECDH key exchange in TLS is equally vulnerable. Both key exchange and signatures must migrate.
• Skipping hybrid mode: Cutting over directly to PQ-only without a hybrid transition period breaks interoperability with partners who have not migrated.
• Underestimating key sizes: ML-KEM and ML-DSA keys are larger than RSA/ECC. Systems with hardcoded key size limits, database column constraints, or protocol buffer field limits will break silently.
• DIY implementation: Rolling your own ML-KEM or ML-DSA implementation introduces side-channel vulnerabilities, timing leaks, and specification non-compliance. Cryptographic implementation is the hardest software engineering discipline for a reason.
• Performance regression: Naive PQC implementations can be 10-100x slower than optimized ones. H33's Rust implementation on Graviton4 delivers 38.5 microseconds per authentication—faster than most classical implementations.

Why H33 Exists

H33 was built specifically to make post-quantum migration a solved problem. The entire stack is pure Rust with zero external dependencies. It runs on AWS Graviton4 ARM infrastructure. It implements ML-KEM (FIPS 203), ML-DSA (FIPS 204), BFV fully homomorphic encryption, and STARK zero-knowledge proofs in a single API. SOC 2 Type II, HIPAA, and ISO 27001 compliance is maintained at 100% in Drata.

The alternative is building a team, learning lattice cryptography, implementing constant-time polynomial arithmetic, passing NIST validation, and maintaining it all forever. Or you can call an API.

Start with the free tier. Read the PQC architecture documentation. Explore the API reference. The migration deadline is approaching. The technology to meet it is available today.