META 2026-04-16

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

Summary¶

Meta's Security team publishes a strategy paper on its multi-year PQC migration, describing the principles, prioritisation framework, migration-level ladder, external dependencies, internal guardrails, and deployment paths it uses to drive the transition across its infrastructure. The post introduces PQC Migration Levels (PQ-Unaware → PQ-Aware → PQ-Ready → PQ-Hardened → PQ-Enabled) as a maturity ladder that lets organisations "manage the complexity of PQC migration for their various use cases" at their own pace. It lays out a concrete prioritisation criteria distinguishing offline-attackable (HNDL-vulnerable public-key encryption + key exchange — highest priority), online-attackable (quantum-vulnerable digital signatures — medium, split by patching capability), and Grover-only (symmetric with weak parameters — low). Meta describes two complementary cryptographic inventory mechanisms (automated discovery via its 2024 cryptographic monitoring service + developer reporting for shadow dependencies), names three external dependencies the migration blocks on (community- vetted standards, hardware PQC support, production-level implementations — Meta contributes to all three, co-authoring HQC, BIKE, and Classical McEliece and supporting LibOQS), and names PQC guardrails (crypto-guideline updates, friction against new quantum-vulnerable-key creation, build-system rules that warn on RSA/ECDH API use in its centrally-managed source repo with Buck). Meta states it prioritises the hybrid deployment path (PQC primitive layered on top of a classical one) over replacement, citing the cryptanalytic invalidation of final-round NIST candidate SIKE as the precedent forcing caution during the transition period.

The post is an architecture overview + operational-discipline piece — it does not disclose production numbers (no fleet percentages, no latency data, no deployment timelines beyond "multi-year"), does not name specific products beyond "our internal infrastructure," and does not name TEE / HSM vendors. The value for the wiki is the PQC Migration Levels ladder (a new governance primitive), the three-tier prioritisation criteria, the two-mechanism crypto-inventorying approach, and the PQC-guardrails playbook — all of which are reusable frameworks for any organisation planning a PQC migration.

Key takeaways¶

PQC Migration Levels are a ladder, not a binary. "The levels are laddered in terms of how rapidly they allow an organization to respond to a quantum threat. The shorter the time to react to a relevant quantum event the better." Canonical wiki framing of PQC Migration Levels as a five-rung maturity scale: PQ-Unaware (no awareness) → PQ-Aware (assessed but not designed) → PQ-Ready (implemented but not enabled — "not a desirable end goal given the fact it is not yet protecting the use case against quantum attacks, but it does reduce the time to react when compared to lower levels") → PQ-Hardened (all available protections deployed, some primitives still missing in literature — e.g. efficient PQ-OPRFs) → PQ-Enabled ("the ultimate goal," full PQ protection deployed). Even PQ-Ready is valuable: it "reduces the time to react" and builds the necessary blocks for future enablement. (Source: this post)
Three-tier prioritisation by attack class, not impact. Meta classifies applications by how easy the quantum attack is, not how valuable the protected asset is:
High: vulnerable to offline attacks initiatable today (SNDL via Shor) — any app using quantum-vulnerable public-key encryption or key exchange. Split by has-external-dependencies vs no-external-dependencies — the latter are migrated immediately, the former must wait for dependencies.
Medium: vulnerable to online attacks requiring a CRQC (digital signatures). Split by patching capability — "medium-high risks are hard to patch (e.g., applications that have public keys baked into hardware) and medium-low risks are those that are possible to patch (e.g., software upgrades)" — particularly relevant for applications with long lifespans.
Low: vulnerable only to inefficient Grover attacks on symmetric crypto with inadequate parameters. "The enormous resource requirements to run such an attack (which even raises doubts about whether such an attack will ever be feasible) make them the lowest risk." Canonical wiki framing of the PQC prioritisation framework. (Source: this post)
Cryptographic inventorying is the load-bearing prerequisite. "The continuous need to replace cryptographic algorithms requires at the very minimum an understanding of where cryptography is being used. The problem is cryptography is ubiquitous, and finding all instances of a cryptographic primitive in a large infrastructure and codebase is inherently challenging." Meta uses two complementary strategies: (a) Automated Discovery via monitoring tools like its Crypto Visibility service (the 2024-12-02 ingest), which "autonomously map[s] cryptographic primitives used in production" and "provides high-fidelity data on active usage within our primary libraries"; (b) Reporting, because "monitoring cannot capture every edge case or shadow dependency" — supplements automation with developer reporting that "captures cryptographic intent for new architectures and uncovers legacy usage in systems outside standard monitoring paths." Canonical crypto-inventory concept + automated-discovery + developer-reporting pattern. (Source: this post)
Three external dependencies the migration blocks on. Meta names the dependencies and unblocking actors:
Community-vetted PQC standards (unblocked by NIST, IETF, ISO): NIST has published FIPS 203, 204, 205 and announced HQC; IETF has two RFCs (8554, 8391) + TLS drafts in progress; ISO has one PQC standard. "A considerable amount of work is still needed to finalize the drafts and cover other portions of the TLS stack, such as PQC X.509 certificates and PQC PKI in general. Most Meta products rely on TLS so lifting this roadblock is of utmost importance."
PQC support in hardware (unblocked by HSM, CPU, and other hardware vendors): "Meta, for example, is working closely with its hardware vendors on community-vetted, standardized PQC strategies."
Production-level PQC implementations (unblocked by crypto engineering community): Meta supports and contributes to LibOQS under the Linux Foundation Post-Quantum Cryptography Alliance (PQCA), including bug fixes. Meta has co-authored three PQC candidates through the NIST process: HQC (NIST-selected in 2025 as the fifth PQC algorithm), BIKE, Classical McEliece. (Source: this post)
Algorithm selection: stick to public standards. "Post-quantum cryptography is a comparatively new field, and therefore organizations should not deviate from what reputable public standardization bodies are recommending." Meta recommends:
ML-KEM-768 as the default (NIST Security Level 3), ML-KEM-512 as allowable exception (NIST Level 1, endorsed by NIST PQC FAQ) for performance-constrained cases.
ML-DSA-65 as the default (NIST Level 3), ML-DSA-44 as allowable exception for performance constraints.
SPHINCS+ and Falcon are "considerably harder" to deploy than ML-DSA (SPHINCS+: much larger signatures; Falcon: floating-point arithmetic); Meta implicitly defaults to ML-DSA.
HQC is important as a non-lattice alternative "if weaknesses are discovered in ML-KEM or its modular lattices approach, ensuring that an alternative method for PQC protection can still be deployed to protect organizations from SNDL attacks." (Source: this post)
PQC Guardrails prevent new vulnerable-code creation. Three-pronged discipline:
Update internal cryptography guidelines to warn teams about adopting quantum-vulnerable public-key cryptography.
Discourage the creation of new quantum-vulnerable keys — if the organisation controls key-generation tools, those tools warn teams on requests for new quantum-vulnerable keys. "This wouldn't fully prevent teams from generating such keys using other interfaces but would likely require them to engage with the internal crypto team."
Discourage the usage of affected APIs — if the organisation has a centrally-managed source repo with tightly- controlled build system ("e.g., Buck system"), it can create rules that "warn teams during code review if they try to use" potentially-affected APIs (RSA, ECDH, etc.). Canonical crypto-API guardrails pattern — sibling of Meta's broader code-review-gating posture (Glean-based diff-sketches, CI policy checks). (Source: this post)
Hybrid over replacement — SIKE is the cautionary tale. "The deployment of PQC-based solutions generally follows one of two paths: replacement (swapping classical for PQC) or hybrid (combining both). While replacement reduces bandwidth and complexity, it relies entirely on newer PQC standards that are still maturing. The recent cryptanalysis (and invalidation) of algorithms like SIKE (final-round candidate running in the NIST PQC standardization process) underscores the importance of relying on thoroughly time-vetted, standardized algorithms during this period of transition to maintain robust security. To mitigate this, we prioritize the hybrid approach by layering a PQC primitive on top of an established classical one, designed so that the combined system should remain at least as secure as the current standard. An adversary would need to break both layers to compromise the system, providing a critical safety net." Canonical Meta statement of the hybrid-over- replacement decision, with SIKE named as the precedent forcing the caution. (Source: this post)
Four migration-strategy principles. Meta's migration aspires to: (1) Effectiveness — withstanding quantum adversaries; (2) Timeliness — aligned with evolving standards; (3) Performance — "minimizing overhead and ensuring that the new cryptographic solutions do not compromise system performance or user experience"; (4) Cost Efficiency — "avoiding unnecessary expenditure by adopting a strategic approach that balances investment with risk mitigation." The four principles together are a Tier-1-scale framing of the PQC migration as a constrained-optimisation problem — not a security-at-all-costs rollout. (Source: this post)

Systems extracted¶

ML-KEM — Kyber, NIST FIPS 203, module- lattice KEM. Meta's recommended PQ KEM. ML-KEM-768 default; ML-KEM-512 exception.
ML-DSA — Dilithium, NIST FIPS 204, module-lattice signature. Meta's recommended PQ signature. ML-DSA-65 default; ML-DSA-44 exception. Preferred over SPHINCS+ (larger signatures) and Falcon (float arithmetic).
HQC — NIST-selected 2025 (fifth PQC algorithm). Meta cryptographers are co-authors. Code-based, non-lattice — provides diversity hedge against potential weaknesses in ML-KEM's lattice approach.
LibOQS — Open Quantum Safe library under Linux Foundation PQCA. Meta actively contributes (supports + fixes bugs).
FBCrypto — Meta's unified managed crypto library (2024-12-02 ingest). The surface PQ guardrails are applied to + the substrate Crypto Visibility instruments.
Buck — Meta's build system. Named as the policy-enforcement point for "rules that prevent the usage of potentially affected APIs" during code review.

Concepts extracted¶

concepts/pqc-migration-levels — new canonical concept. Five-rung maturity ladder (PQ-Unaware → PQ-Aware → PQ-Ready → PQ-Hardened → PQ-Enabled) organised around time to react to a relevant quantum event. Even PQ-Ready is valuable: it reduces reaction time without yet enabling protection.
concepts/crypto-inventory — new canonical concept. The organisation-wide mapping of where cryptographic primitives are used. Prerequisite for any targeted migration (PQC, algorithm deprecation, key rotation). Meta's two strategies: automated discovery + developer reporting.
concepts/pqc-prioritization-framework — new canonical concept. Three-tier classification by attack class (offline / online / Grover-only) rather than by asset value. Offline = HNDL via Shor on public-key encryption + key exchange; Online = Shor on signatures (further split by patching capability); Grover-only = symmetric with inadequate parameters (lowest priority).
concepts/time-to-react-to-quantum-event — new canonical concept. The urgency metric that organises the PQC Migration Levels ladder. Each rung on the ladder reduces the time the organisation needs to respond to a quantum event (standards publication, CRQC breakthrough, new attack).
concepts/hybrid-vs-replacement-pqc-deployment — new canonical concept. The decision axis for PQC deployment: hybrid (PQ-on-top-of-classical) vs replacement (PQ-only). Meta's position: hybrid by default during transition, because SIKE's cryptanalytic invalidation demonstrates newer-standards risk.
concepts/post-quantum-cryptography — extended with Meta's migration-strategy framing (principles + levels + prioritisation
guardrails + hybrid default).
concepts/cryptographic-monitoring — extended with explicit "Crypto Visibility" positioning as the automated-discovery leg of the crypto-inventory approach (follow-on to the 2024-12-02 post).
concepts/harvest-now-decrypt-later — referenced as the canonical threat driving High-priority classification for applications using quantum-vulnerable public-key encryption + key exchange.
concepts/hybrid-key-encapsulation — referenced as the dominant transition-era deployment shape underpinning the hybrid-over-replacement decision.
concepts/long-lived-key-risk — referenced in the medium-high-risk category ("applications that have public keys baked into hardware").
concepts/post-quantum-authentication — referenced on the medium-priority track (quantum-vulnerable digital signatures).

Patterns extracted¶

patterns/pqc-migration-ladder — new canonical pattern. Structure a PQC migration as a laddered set of reachable milestones (Aware → Ready → Hardened → Enabled) so organisations can commit to and budget for intermediate goals that reduce quantum-event reaction time without requiring full enablement.
patterns/crypto-api-guardrails — new canonical pattern. Prevent creation of new quantum-vulnerable cryptographic usages by: (1) updating internal crypto guidelines; (2) adding friction to key-generation tooling for vulnerable primitives; (3) build-system rules that warn on RSA/ECDH/vulnerable-API use during code review. Sibling of Meta's 2024-09-10 Sapling + Glean code-review-gating posture but applied to cryptographic APIs specifically.
patterns/automated-discovery-plus-developer-reporting — new canonical pattern. Build cryptographic inventory with two complementary mechanisms: automated discovery (monitoring libraries, code-graph analysis) + developer reporting (captures edge cases, shadow dependencies, new architectures). Neither is sufficient alone; both together close the coverage gap.
patterns/third-party-dependency-quantum-assessment — referenced via Meta's explicit external-dependencies block (standards, hardware, implementations). Meta's treatment of "external dependencies for PQC migration" is the organisational case of this pattern — identifying the three external-actor classes and engaging with each.
patterns/protocol-algorithm-negotiation — referenced implicitly via the hybrid-deployment posture and the TLS-stack focus.

Operational numbers¶

2030 — target timeframe cited from NIST + NCSC for prioritising PQC protections in critical systems.
10-15 years — experts' estimate for CRQC emergence (from Global Risk Institute 2022 Quantum Threat Timeline).
FIPS 203, 204, 205 — published NIST PQC standards.
HQC — NIST-selected fifth PQC algorithm (2025), co-authored by Meta cryptographers; standard still being drafted.
RFC 8554, RFC 8391 — IETF PQC signature RFCs.
LibOQS issue #1548 — example Meta-contributed bug fix.
No production deployment numbers disclosed — no fleet percentages, no traffic-class coverage, no latency deltas, no deployment timeline beyond "multi-year process."

Caveats¶

Architecture-preview / strategy-paper voice — the post is published as a framework + lessons document, not a retrospective with shipped-numbers. No deployment percentages, no performance deltas, no timelines beyond "multi-year."
No specific product named beyond "our internal infrastructure" — WhatsApp / Messenger / Instagram receive acknowledgements but no product-specific PQC disclosures.
No TEE / HSM vendor named — the hardware-dependency section is generic.
PQ OPRFs named as blocking PQ-Enabled for some use cases — no timeline given for when efficient PQ OPRFs are expected.
Hybrid-vs-replacement argument is structural, not data-backed — Meta cites SIKE's invalidation as precedent but does not quote specific hybrid-vs-replacement performance / wire-size numbers for its own deployments.
ML-KEM-512 / ML-DSA-44 exceptions are allowed but criteria for granting are not specified beyond "performance constraints."
Acknowledgements section is extensive — Transport Security, WhatsApp, Facebook/Messenger, Infrastructure, Reality Labs, Hardware, Payments teams are named, indicating a broad cross-product footprint — but no per-team deployment disclosure.