Post-Quantum Cryptography Migration at Meta: Framework, Lessons, and Takeaways

Why Post-Quantum Crypto Migration Is a Pressing Operational Concern

Quantum computing research strongly suggests that conventional public-key cryptography will eventually be broken, creating systemic risk for digital infrastructure. While expert timelines place this threat roughly a decade out, a more immediate concern is the "store now, decrypt later" (SNDL) strategy: adversaries can capture encrypted data today and hold it until quantum decryption becomes viable. That reality makes proactive migration an operational necessity rather than a distant planning exercise.

Standards bodies have responded with concrete guidance. NIST and the UK's NCSC have both published roadmaps targeting foundational post-quantum protections by 2030 for critical systems. The first PQC standards—ML-KEM (Kyber) and ML-DSA (Dilithium)—are now finalized, with additional algorithms such as HQC under development. Meta cryptographers co-authored HQC as one of NIST's newly selected algorithms. These standards give organizations a defensible baseline against SNDL attacks, provided they have a clear path to adoption.

Meta's own infrastructure has already begun carrying post-quantum encryption across significant internal traffic. The multi-year rollout has yielded practical insights that are broadly applicable, regardless of organizational size or sector.

A Goal Structure for PQC Migration

Before diving into tactical steps, it helps to define what success looks like. Meta's migration strategy rests on four pillars:

1. Effectiveness — withstanding quantum adversaries and protecting against emergent threats.
2. Timeliness — deploying protection aligned with evolving standards and threat timelines.
3. Performance — minimizing cryptographic overhead so system behavior and user experience remain intact.
4. Cost efficiency — balancing investment with actual risk reduction, avoiding unnecessary spend.

PQC Migration Levels: A Readiness Ladder

PQC migration is inherently multi-year and complex. To make progress measurable, Meta proposes a laddered framework—PQC Migration Levels—that ranks an organization's position by how quickly it can respond to a relevant quantum event (advances in quantum computing, new standards publications, or shifts in industry practice).

• PQ-Unaware — The organization hasn't yet recognized the quantum threat to its cryptography. This is the most defensively weak position.
• PQ-Aware — The organization acknowledges the threat and has completed an initial assessment of what's needed to reach readiness. No protection design has been initiated yet.
• PQ-Ready — A post-quantum secure solution is fully designed and appropriate for the use case. Enablement is not feasible yet due to cost, prioritization, or other constraints. This position reduces reaction time but does not yet deliver quantum protection.
• PQ-Hardened — All post-quantum protections available in current literature are implemented. Gaps exist only where the industry lacks primitives entirely—for instance, efficient post-quantum Oblivious Pseudorandom Functions (OPRFs) remain unavailable. Use cases relying on such primitives can only achieve this level.
• PQ-Enabled — Full quantum protection is deployed and operational for the use case. This is the target for every application. Meta, for example, has already begun rolling out PQ protections across meaningful portions of its internal traffic at this level.

Organizations without budgets for immediate enablement can still meaningfully strengthen their position by targeting PQ-Ready. It sets a realistic first milestone that builds the necessary components for later mitigation.

Meta's Five-Step PQC Strategy

The overall approach is a sequence of workstreams. Several steps may overlap in practice, but each addresses a distinct need in the migration path.

1. Define Prioritization Criteria

A qualitative framework is needed to classify applications into high, moderate, or low priority. Meta differentiates across three tiers of quantum risk.

High-priority: Applications using quantum-vulnerable public-key encryption or key exchange. These are susceptible to offline attacks that can be initiated today and completed later via Shor's algorithm—the exact SNDL threat. Within this class, Meta further distinguishes applications that can be migrated immediately (no external dependencies) from those that must wait on other conditions.

Medium-priority: Applications using quantum-vulnerable digital signatures. These are only exposed to online attacks—requiring a quantum computer on-site and in real time. This tier splits into two groups: medium-high risk applications that are hard to patch (e.g., public keys baked into hardware) and medium-low risk applications patchable via software. Patch capability matters most for systems with long lifecycles spanning development plus field deployment.

Low-priority: Applications relying on symmetric cryptography with inadequate parameters. These are susceptible only to inefficient Grover's-style attacks, whose resource demands are so enormous that feasibility is in question.

2. Build a Cryptographic Inventory

Importantly, cryptographic algorithms decay in strength over time—not only due to quantum threats but also due to classic cryptanalysis. An organization cannot replace what it cannot find. Crypto inventorying is a fundamental prerequisite for any systematic migration.

Meta uses two complementary approaches to build its inventory:

• Automated discovery: Monitoring tools such as Meta's Crypto Visibility service autonomously map primitives in production, providing high-fidelity data on actual usage within core libraries.
• Developer reporting: Because monitoring can miss edge cases or shadow dependencies, direct reporting from engineers captures cryptographic intent for new architectures and surfaces legacy usage outside standard paths.

3. Address External Dependencies

Migration cannot proceed until the environment is ready. Organizations must track external prerequisites such as finalized PQC standards, post-quantum-capable Hardware Security Modules (HSMs), and mature libraries. Waiting on ecosystem maturity often dictates sequencing more than internal preference.

4. Implement Components and Guardrails

Internal cryptographic components must be built, tested, and made available for integration. In parallel, organizations should enforce migration obligations by updating internal crypto standards, disallowing the creation of new keys under vulnerable algorithms, and restricting use of affected APIs.

5. Integrate and Deploy

The final integration step moves protected components into use across the organization, achieving the PQ-Enabled level for each targeted use case.

External Dependencies That Must Be Unblocked

Even with full internal commitment, a PQC migration cannot proceed solely within an organization's own boundaries. Certain prerequisites depend on outside actors: standards bodies, hardware vendors, and open-source projects. The organization itself is still the right party to push these dependencies forward, but it cannot complete them alone.

Algorithms Are Standardized, but Higher-Layer Protocols Are Not

NIST has now published the first PQC standards: FIPS 203, FIPS 204, and FIPS 205, with a second list of algorithms announced for standardization. The broader cryptography community has contributed extensively to this process. Meta has participated as a co-author of HQC as well as other candidates such as BIKE and Classical McEliece.

IETF has published two RFCs specifying PQC schemes, and ISO has published another standard. However, standards for higher-layer protocols remain largely missing. Preliminary drafts exist that address specific TLS components such as the key encapsulation step, but considerable work remains to finalize them and to cover other pieces — notably PQC X.509 certificates and PQC PKI broadly. Because TLS underpins most of Meta's products, this is a critical roadblock.

Hardware Vendor Alignment

Applications that depend on hardware support, such as HSMs or CPU features, cannot migrate without cooperation from external hardware vendors. Organizations should align with vendors early as they plan for PQC. Meta, for instance, is working closely with its own hardware partners on vetted, standardized PQC approaches.

Production-Grade Software Implementations

Most real-world cryptography failures trace back not to algorithm design but to implementation bugs and side-channel issues. Production-grade libraries that get these details right are essential. The Open Quantum Safe consortium, which is part of the Linux Foundation Post-Quantum Cryptography Alliance, has been building LibOQS since 2019. Industry organizations are starting to integrate it. Meta supports the project, contributes bug fixes, and continues to collaborate with LibOQS leads.

Algorithm Selection

Because PQC is a comparatively young field, established public standards bodies remain the safest reference point. For foundational building blocks, Meta recommends the two NIST-selected algorithm families that are practical to deploy:

• Key exchange / key encapsulation: ML-KEM (NIST FIPS 203)
• Digital signatures: ML-DSA (NIST FIPS 204)

NIST has also selected two additional signature algorithms — SPHINCS+ and Falcon — but each carries adoption barriers: SPHINCS+ has considerably larger signatures, and Falcon requires floating-point arithmetic. Even ML-DSA deployment is already difficult enough; these drawbacks make the other schemes harder still.

Both ML-KEM and ML-DSA define several parameter sets that trade off performance against security strength. For most use cases, ML-KEM768 at NIST Security Level 3 is the sensible default, with ML-KEM512 at Security Level 1 as an exception where performance prohibits the stronger variant — a preference NIST itself has endorsed. The same logic applies to ML-DSA: prefer ML-DSA65, allow ML-DSA44 only under performance constraints.

HQC is also newly selected for standardization. Because it is built on different mathematics than ML-KEM's lattice approach, it offers a hedge: if weaknesses appear in ML-KEM, HQC remains a deployable alternative. NIST is still drafting its HQC standard.

Enforcing Guardrails for New Development

Migration alone is insufficient; net-new code and systems need to avoid repeating the same quantum-vulnerable choices. Three controls add friction against those older primitives:

1. Update internal cryptography guidelines to flag the risks of adopting quantum-vulnerable public-key cryptography and the requirement to move to PQC.
2. Discourage new quantum-vulnerable keys. When the organization controls key-generation tooling, warning on requests for new classical keys discourages their creation — or at least surfaces them to the internal crypto team.
3. Block affected APIs at build time. Standards on constrained build systems such as the Buck build tool can detect use of RSA or ECDH calls during code review and warn teams immediately.

Replacement vs. Hybrid Integration

Deployment of PQC-ready components follows one of two paths. Pure replacement swaps out classical primitives entirely, reducing bandwidth and complexity. But it also depends completely on standards that are still maturing. The fate of SIKE — a final-round NIST competition candidate whose scheme was broken in cryptanalysis — illustrates why relying on very recent algorithms before they have been time-tested is risky.

Meta favors the hybrid approach: layer a PQC primitive on top of a well-established classical one, such that an adversary must break both in order to compromise the system. This lays the new algorithm beside the old as a second layer of defense, providing a safety net while PQC continues to harden.

Closing Note

Work such as this should not be read as completed. Shifting Meta's systems to post-quantum cryptography takes years of phased work spanning protocols, products, and infrastructure, on a timescale that tracks the maturity of standards, implementations, and threats. Meta expects to keep expanding coverage and will report on measurable progress as industry practices continue to settle.