Meta's Post-Quantum Crypto Migration Playbook

Picture a Meta security engineer on April 15, 2026, sitting on a Slack thread with the TLS team. The draft blog post is ready for legal review. Someone asks the question everyone is avoiding: "Can we say what percentage of traffic is actually PQ-protected?" Silence. Then: "Let's just say 'significant portions of our internal traffic.' Ship it."

That hedge made it into the published post on April 16. For the world's second-largest CDN, "significant" is a word you pick when the real number is either embarrassingly small or operationally terrifying to disclose. Either way, the vagueness is the signal. Post-quantum cryptography migration is harder in production than any vendor slide deck admits, and Meta just published the most honest playbook we have.

I read the whole thing twice. Here is what it actually says, what it refuses to say, and what you should do about it before your CNSA 2.0 deadline crashes into you in nine months.

5-Minute Skim: What changed this week?

• Meta published a real migration framework on April 16, 2026. Six steps, specific algorithm recommendations, and a refreshingly honest threat model. Not marketing — a playbook.
• Default recommendation: hybrid, not pure-PQ. ML-KEM768 for key exchange paired with X25519. ML-DSA65 for signatures paired with ECDSA. HQC as a hedge.
• What breaks in production: middleboxes that can't handle a 1,184-byte ClientHello extension, CAs that don't yet issue hybrid certs at scale, and firmware that ships with pinned classical verifiers.
• Key trade-off: hybrid doubles your handshake surface area but keeps you safe if either ML-KEM or X25519 falls. Pure-PQ is lighter but puts all your faith in lattice math that is barely five years into peer review.
• Bottom line: If you have not started your PQC inventory, the CNSA 2.0 deadline (January 1, 2027) is already inside your planning horizon.

Why does this week matter for PQC?

Three things converged between April 13 and 19.

First, Meta broke its silence. Until now, the big PQC voices were Cloudflare, Google, and AWS — companies whose threat models are public and whose customers demand transparency. Meta's internal traffic is a black box. When they publish a framework, they are signaling that the migration has moved past the "interesting research" phase into "we are burning real engineering quarters on this."

Second, CNSA 2.0's January 1, 2027 deadline is nine months away. That is the US government's Commercial National Security Algorithm Suite 2.0 requirement, and it cascades. If you sell to federal agencies, you need PQC. If you sell to companies who sell to federal agencies, you need PQC. If you process data that might touch a regulated industry, your auditors are going to start asking about PQC readiness this year.

Third, the industry wave is visible now. Cloudflare reported 16% of human requests PQC-protected back in 2024 and is ramping to majority share. Akamai flipped the default to hybrid ML-KEM+X25519 for all customers in February 2026. AWS's s2n-tls has production PQ key exchange. Microsoft shipped PQC APIs GA on Windows Server 2025, Windows 11, and .NET 10. Google's Android 17 stable release in June 2026 will carry ML-DSA in the boot chain. Everyone is on the same clock.

What did Meta actually choose?

Meta's framework rejects pure-PQ and commits hard to hybrid. That choice deserves unpacking because it is the single most consequential architectural decision in the post.

For key exchange: ML-KEM768 wrapped with X25519. Both run in parallel during the TLS handshake. The session key is derived from both shared secrets, so an attacker has to break both schemes to decrypt the traffic. ML-KEM (formerly Kyber) is the NIST FIPS 203 standard; it is a lattice-based key encapsulation mechanism whose security rests on the hardness of the Module Learning With Errors problem.

For signatures: ML-DSA65 (FIPS 204) paired with ECDSA. Same logic — a forger needs to break both. ML-DSA is another lattice construction, and while signatures are less urgent than KEX for "harvest now, decrypt later" attacks, they matter enormously for firmware and supply-chain trust.

As an algorithmic hedge: HQC (Hamming Quasi-Cyclic). This is code-based, not lattice-based. Meta explicitly flags that if some clever cryptanalyst finds a structural weakness in Module-LWE over the next decade, the entire lattice family collapses together. HQC uses completely different math, so it is insurance against a category-level break.

Size guidance: stick with the 768/65 variants unless performance forces you smaller. The 512-bit variants exist for embedded and constrained devices, but on general-purpose servers the ~2.5% handshake overhead is worth the extra margin.

The important detail is the parallel derivation. Both shared secrets feed a key derivation function, and the output is the session key. An attacker with a future quantum computer can crack X25519 but still faces ML-KEM. An attacker with a lattice-cryptanalysis breakthrough cracks ML-KEM but still faces X25519. You fail only if both fall, which is the whole point of defense in depth.

What is the operational reality nobody wants to discuss?

Here is where Meta's framework gets honest and where your production rollout is going to bleed.

Middlebox intolerance is the silent killer. Adding ML-KEM public keys to the ClientHello balloons the extension by roughly 1,184 bytes. That pushes the ClientHello past the first TLS record boundary, forcing fragmentation. Corporate firewalls, load balancers, and "next-gen" inspection appliances from 2015-2019 often drop or mangle fragmented ClientHellos. Cloudflare spent five years (2019-2024) ramping PQC incrementally precisely because of this. They documented cases where a single misbehaving middlebox would break 2-3% of a customer's traffic in ways that looked like random TLS errors. You cannot fix this centrally. You have to detect, attribute, and either upgrade the middlebox or carve out a fallback path.

Performance degrades sharply under packet loss. In ideal network conditions, the extra bytes cost you under 2.5% of handshake time and somewhere between 5-15% of page load time. On a clean fiber link you will barely notice. But under 3% packet loss, the larger handshake means more retransmissions, and latency balloons to 32% over the classical baseline. Mobile users on congested cell networks are going to feel this. Your p99 is going to look worse before it looks the same.

The CA bottleneck is real. Public CAs are understaffed for hybrid certificate issuance. AWS Certificate Manager opened hybrid support in 2025 and discovered that legacy validators silently failed on the dual-signature certificate chain. The chain parses, but the second signature is ignored, so you think you have PQC protection when you don't. Hybrid cert issuance windows are opening at major public CAs in Q3 2026, but availability at scale will lag into 2027. If your application depends on client certs or mTLS, plan for a long tail.

Firmware is the worst deployment target. Google's Android 17 rollout for ML-DSA in bootloader validation required 12-18 months of OEM coordination even with a single company driving the schedule. Every handset SoC has its own secure boot chain. ROM-baked classical verifiers cannot be patched. If your product ships with long-lived firmware — IoT, automotive, industrial — you are looking at multi-year lead times, and anything already shipped is effectively stuck on classical signatures until hardware refresh.

Is the harvest-now-decrypt-later threat actually real?

Yes, and this is the slide your CISO needs to show the board.

The threat model is simple. An adversary records encrypted traffic today. They store it cheaply — at a few cents per gigabyte, even nation-state-scale capture is operationally feasible. They wait. When a cryptographically relevant quantum computer comes online, they decrypt retroactively. Your TLS key exchange from 2026 is readable in 2035 or 2040.

This is not a speculative framing anymore. The US Department of Homeland Security, the UK's NCSC, the EU's ENISA, and the Australian Cyber Security Centre have all published guidance that treats harvest-now-decrypt-later as a documented, active risk. HashiCorp's write-up frames it clearly: you are not protecting against tomorrow's interception, you are protecting yesterday's already-captured traffic that has a decade or more of shelf life.

Which data actually matters?

• Intellectual property that retains value for 10+ years: pharmaceutical research, unreleased product designs, trade secrets.
• Diplomatic and intelligence communications with effectively infinite sensitivity.
• Healthcare records that are protected under HIPAA for the patient's lifetime.
• Financial and legal data with 7-30 year retention requirements.
• Personally identifiable information that will embarrass you on tomorrow's front page regardless of when it was captured.

Insurers are pricing this now. Several cyber-insurance carriers have started requiring PQC roadmaps as part of underwriting renewals in 2026. Regulators — especially in financial services and healthcare — are treating absence of a migration plan as failure to meet the reasonable standard of care. If you get breached in 2030 and your 2026 traffic is decrypted, "we hadn't gotten to PQC yet" will not hold up in litigation.

Hybrid versus pure-PQ: which side wins?

This is the live debate inside every security team, so let me lay out the argument honestly.

The pure-PQ camp says hybrid is a transitional crutch. Lattice cryptography has been studied for three decades. ML-KEM went through multiple rounds of NIST competition with hundreds of cryptanalysts hammering at it. Every year you run hybrid, you pay double — double the handshake bytes, double the CPU, double the code to maintain. If you trust the standardization process, commit and move on.

The hybrid camp — which includes Meta, Cloudflare, Akamai, AWS, and basically everyone running production at scale — says the lesson of cryptographic history is humility. RSA looked bulletproof in 1994. SHA-1 was safe until it wasn't. Lattice crypto at production scale is new. Five years of serious deployment scrutiny is not enough. The extra bytes and CPU are cheap insurance. And critically, hybrid lets you fail safe if either family is broken, rather than fail catastrophically if the one you bet on is broken.

My read: hybrid wins for the next five to seven years, then the argument flips. Once ML-KEM and ML-DSA have a decade of adversarial review behind them and no structural weakness has emerged, dropping the classical side becomes defensible. Until then, hybrid is the correct default.

One more point the pure-PQ camp underweights: algorithm agility matters more than algorithm choice. Whatever you deploy in 2026 should be swappable via configuration, not a code change. If HQC needs to replace ML-KEM in 2032 because somebody publishes a Module-LWE break, you want that to be a config push, not a six-month engineering project.

What are the implementation gotchas?

Meta's six-step framework is: Prioritize → Inventory → External deps → Implement → Guardrails → Integrate. Each step has a trap.

Prioritize by data shelf life, not by traffic volume. The chatty internal telemetry service that carries gigabits of ephemeral metrics is lower priority than the boring admin API that handles customer PII with 7-year retention.

Inventory is where most teams discover they do not actually know what crypto runs where. Every TLS endpoint, every signed artifact, every encrypted field in a database, every JWT-signing service, every mutual-TLS service mesh. Build the asset graph before you write a line of migration code. Meta's framework spends real time on this for a reason.

External dependencies are the scary part. You control your own services. You do not control the SaaS vendors, payment processors, identity providers, and partner APIs in your dependency graph. Start the vendor PQC roadmap conversation now. Many will not have answers, and that is itself useful signal about which partners are serious.

Implement with hybrid from day one. Do not deploy classical-only into a system you plan to PQC later — you will end up doing the migration twice.

Guardrails means feature flags, gradual rollout, and the ability to instantly disable PQ if middlebox incompatibility surfaces. Cloudflare's five-year ramp worked because they had per-customer, per-edge-location toggles.

Integrate PQC into the normal SDLC so new services are born PQ-native. Otherwise you are signing up for a perpetual migration.

Anti-patterns I am seeing:

• Treating PQC as "a TLS thing." It is also a signature thing, a long-lived-key thing, and a firmware thing. TLS is just the loudest.
• Waiting for "the standard to settle." ML-KEM and ML-DSA are standardized. The waiting game is done.
• Deploying pure-PQ for performance reasons without accepting the risk. If perf is that tight, fix the perf path, don't drop the hybrid protection.
• Ignoring the deployment order. TLS endpoints first (fast to roll out, high value for HNDL defense), then long-lived data encryption keys (medium complexity, enormous value), then signatures (slowest, requires firmware and PKI coordination).

What should you actually do this quarter?

Five concrete actions for the next 90 days:

1. Run the crypto inventory. Every TLS endpoint, every signing service, every long-lived encrypted data store. If your team cannot produce this list in a week, that gap is your first finding.
2. Pick your algorithm pair. Default to ML-KEM768 + X25519 for key exchange and ML-DSA65 + ECDSA for signatures. Document the decision and the hedge plan (HQC) in an ADR.
3. Audit your middleboxes. Run synthetic ClientHello traffic with PQ extensions through every load balancer, firewall, WAF, and inspection appliance in your path. Log every failure. This is the #1 thing that will break your rollout.
4. Start the vendor conversation. Email every critical SaaS and infrastructure vendor asking for their PQC roadmap and target hybrid-cert support date. The non-responders become your risk register.
5. Write the board-level HNDL brief. One page. What data has 10+ year shelf life, what the threat model is, what the CNSA 2.0 deadline means for the business, and what your 2026-2027 investment is. Get the budget conversation started now, because you will need it.