Post-quantum cryptography (PQC) is a new generation of encryption designed to resist attacks from both classical and quantum computers. As quantum hardware advances, moving to PQC is becoming essential for protecting data that must stay secret for years.
Meta does not usually publish its internal security playbooks. So, when its engineering team released a detailed account of how it is moving to post-quantum cryptography in April 2026, written by cryptographers Rafael Misoczki, Isaac Elbaz, and Forrest Mertens, it handed the industry something: a clear look at how a company that secures billions of daily users actually does this work.
The reason Meta is moving now, well before a working quantum computer exists, comes down to one idea. An attacker can record your encrypted data today and decrypt it years later, once quantum hardware catches up. This is called harvest now, decrypt later (HNDL), sometimes called store now, decrypt later (SNDL). For anything that must stay secret for a decade or more, the threat is effectively already here. Gartner expects conventional public-key cryptography to become unsafe by 2029, and Meta has been rolling out post-quantum protection across its internal traffic since 2024.
The regulatory timelines reinforce this urgency: CNSA 2.0 directs U.S. National Security Systems to adopt post-quantum algorithms by 2030, and NIST IR 8547 plans to deprecate RSA and ECC for new federal systems after 2030 and disallow them after 2035.
This article walks through Meta’s full framework, the principles that guide it, the levels it uses to measure progress, the six steps it follows, and the specific engineering choices it made along the way.
The Four Principles Steering Every Decision
Before any of the steps, Meta names four goals that every cryptographic choice in the migration has to satisfy. They look obvious, but they pull against each other, which is the point.
- Effectiveness: the protection has to genuinely hold up against a quantum adversary.
- Timeliness: it has to ship in step with evolving standards, not years behind them.
- Performance: it cannot slow systems down or hurt the user experience.
- Cost efficiency: spending should match the real risk, not the hype.
The tension is real. Post-quantum algorithms are bigger and heavier, so effectiveness fights performance. Standards are still landing, so timeliness fights effectiveness. Almost every later choice Meta makes is an attempt to balance these four forces rather than maximize any single one.
Measuring Readiness: Meta’s Five PQC Migration Levels
Meta treats migration as a ladder, not a single finish line. Its PQC Migration Levels are scored by one question: how fast can you react to a “relevant quantum event,” such as a leap in quantum hardware, a new standard, or a new industry norm? The shorter your reaction time, the higher you rank.
| Level | What it means | Reaction speed |
|---|---|---|
| PQ-Unaware | The team does not yet know the quantum threat applies to them. | Slowest (worst) |
| PQ-Aware | The team knows and has done an initial assessment, but has not designed anything yet. | Slow |
| PQ-Ready | A suitable post-quantum solution is built and tested, but not switched on, often due to cost or priorities. | Fast to react |
| PQ-Hardened | Every protection available today is deployed, but full safety is impossible because some needed building blocks are not standardized yet. | Near-complete |
| PQ-Enabled | The use case is fully protected with deployed post-quantum cryptography. The goal. | Fully protected |
Two details show how honest the model is. PQ-Ready counts as a real win on its own because having the solution built means you can switch it on quickly when a deadline lands. And PQ-Hardened admits that sometimes you do everything possible and still cannot fully close the gap, because the math the industry needs does not exist yet. Meta’s example is efficient post-quantum Oblivious Pseudorandom Functions (OPRFs), which are not yet available, so use cases that depend on them top out at PQ-Hardened for now.
Meta’s Six-Step Migration Strategy
The framework itself is a sequence of six steps. They can overlap in time, but together they map out the separate streams of work any large migration runs through.
| Step | What Meta does |
|---|---|
| Prioritization | Sort every application into high, moderate, or low priority by its quantum risk. |
| Cryptographic inventory | Map every place cryptography is used across the organization. |
| External dependencies | Clear the blockers the migration waits on published PQC standards, PQC-ready HSMs, and mature implementations and name who owns each. |
| Implement PQC components | Build the post-quantum components, starting with the algorithm choice, ready to integrate into use cases later. |
| PQC Guardrails | Stop the problem from growing: update crypto standards and block new quantum-vulnerable keys and affected APIs. |
| PQC Integration | Deploy the protection into real use cases, usually as a hybrid of classical and post-quantum. |
The rest of this article walks through each step and the choices Meta made inside it.
Step 1: Prioritization, Deciding What to Fix First
With cryptography in nearly everything, Meta cannot migrate it all at once, so it sorts every application into three priority bands.
| Priority | Why it is risky | Typical example | Move when |
|---|---|---|---|
| High | Can be harvested offline now and decrypted later with Shor’s algorithm (SNDL). | Public-key encryption and key exchange (TLS, VPNs) | First |
| Medium | Only attackable once a real quantum computer exists (an online attack). | Quantum-vulnerable digital signatures | Next, sooner if hard to patch |
| Low | Only exposed to inefficient attacks (Grover’s) needing impractical resources. | Symmetric crypto with weak parameters | Last |
The sharpest insight is inside the medium band. Meta splits it again by how easy a system is to fix later: medium-high risk is hard to patch, such as public keys baked into hardware, while medium-low risk can be fixed with a software update. So Meta prioritizes three things at once: how exposed you are today, how long the data stays sensitive, and how hard the fix will be later.
Step 2: Building the Cryptographic Inventory
Every other step depends on knowing where cryptography actually lives. Meta calls this crypto inventorying, and it is hard at scale because cryptography is everywhere and often invisible, buried in libraries, services, and code nobody remembers writing.
Meta builds the picture two ways at once. Automated discovery comes from its Crypto Visibility service, which monitors production and maps which cryptographic primitives are actually in use across its main libraries. Because monitoring cannot catch everything, developer reporting fills the gaps, capturing intent in new designs and surfacing legacy usage that standard monitoring never touches. NIST’s practice guide, NIST SP 1800-38, Migration to Post-Quantum Cryptography, treats this same discovery work as the prerequisite for the whole migration.
Step 3: Clearing the External Dependencies
One of the most candid parts of the playbook is that Meta cannot finish on its own. Three things depend on the wider industry, and Meta names who has to unblock each one.
| Dependency | Who has to unblock it | Where it stands |
|---|---|---|
| Community-vetted standards | Standards bodies (NIST, IETF, ISO) | Core algorithms done; public-web key protocol standards (TLS/PKI authentication standards still being finalized) |
| Hardware support | HSM, CPU, and other hardware vendors | In progress, tied to vendor roadmaps |
| Production-grade implementations | The cryptography engineering community | Maturing through shared open-source libraries |
On standards, NIST has published the core algorithms in FIPS 203, 204, and 205, and the IETF has standardized hash-based signatures in RFC 8554 and RFC 8391. Meta is not a bystander: its cryptographers co-authored HQC and contributed to candidates like BIKE and Classic McEliece. But the standards that matter most to Meta are still in draft, since there is no finished standard yet for post-quantum TLS, post-quantum X.509 certificates, or post-quantum PKI.
Because most Meta products run on TLS, the team calls this the single most important roadblock. On implementations, Meta contributes to the Open Quantum Safe project and its LibOQS library, including fixing bugs, because most crypto failures come from buggy code, not broken math. Organizations in regulated sectors should note that production PQC deployments usually require FIPS 140-3 validated hardware security modules (HSMs).
Step 4: Choosing the Algorithms
Meta’s advice here is: do not stray from what reputable standards bodies recommend. For key exchange it uses ML-KEM at the ML-KEM-768 level (NIST Security Level 3), dropping to ML-KEM-512 only when performance demands, an exception NIST itself endorses. For signatures it uses ML-DSA, preferring ML-DSA-65. It avoids the other standardized signatures, SLH-DSA, the FIPS 205 standard formerly called SPHINCS+ (signatures too large) and FN-DSA, formerly Falcon (FIPS 206 draft; tricky floating-point math prone to side-channel risks), and keeps HQC as a hedge built on different math from ML-KEM. NIST selected HQC for standardization in March 2025 (NIST IR 8545), and a dedicated FIPS standard is now in development.
| Job | Classical today | Meta’s post-quantum choice | Note |
|---|---|---|---|
| Key exchange | X25519 (32-byte key) | ML-KEM-768 (1,184-byte key, NIST Level 3) | ML-KEM-512 allowed if performance is tight |
| Signatures | Ed25519 (64-byte signature) | ML-DSA-65 (~3,309-byte signature) | ML-DSA-44 allowed under constraints |
| Backup KEM | n/a | HQC (different math from ML-KEM) | Insurance if a lattice weakness appears |
The reason these choices are so careful is size. As the table shows, post-quantum keys and signatures are tens of times larger than today’s. Multiply that across every handshake, certificate, and signed update, and parameter choices become the difference between a migration that ships and one that breaks.
Step 5: Putting up Guardrails
Migrating old systems is only half the job. If new projects keep creating quantum-vulnerable keys, you are bailing water with the tap still running. So Meta adds friction to anything that would make the problem bigger: it updates internal cryptography guidelines, its key-generation tools warn engineers who request new quantum-vulnerable keys, and its centrally managed build system (Buck) can flag risky APIs such as RSA or ECDH right inside code review. The principle is simple: prevention is cheaper than cleanup.
Step 6: Integrating with a Hybrid Approach
Finally, Meta deploys. There are two ways to roll out a new algorithm: replace the old one outright, or run both together in a hybrid manner. Meta prefers hybrid, and its reasoning is a cautionary tale. A clean replacement bets everything on algorithms that are still young, and Meta points to SIKE. The recent cryptanalysis and invalidation of a fourth-round alternate candidate like SIKE in the NIST PQC standardization process underscores the importance of relying on thoroughly time-vetted, standardized algorithms through this period of transition to maintain security.
So, Meta layers a post-quantum algorithm on top of a proven classical one, ensuring an attacker must break both layers to compromise the connection while the hybrid stays at least as strong as today’s cryptography. This is the mainstream web choice too: the hybrid X25519MLKEM768 key exchange, defined in an IETF draft, already ships by default in major browsers.
Where Meta is Today, and What Comes Next
Meta is clear that sharing the strategy does not mean the work is finished. It has begun deploying post-quantum protection across significant portions of its internal traffic, but hardening systems to post-quantum cryptography takes years of phased work across protocols, products, and infrastructure as standards, implementations, and threats mature. Meta says it will keep expanding coverage and sharing progress, and it frames its own guidance as informational rather than a guarantee of any specific outcome.
Read as a whole, the framework is a model of doing this calmly: measure where you stand, fix the most exposed systems first, build a real inventory, lean on shared standards and code, prevent new problems, and deploy defensively with hybrids. None of it depends on a quantum computer arriving on any particular date. It depends only on starting early enough to do the work carefully.
How Encryption Consulting can Help
If you’re still unsure where to begin your post-quantum journey, Encryption Consulting is here to guide you. As your trusted partner, we’ll support you at every stage, offering clarity, confidence, and proven expertise.
PQC Assessment
We start by mapping your current cryptographic landscape. This involves discovering and inventorying all cryptographic assets like certificates, keys, and related dependencies. We then evaluate which systems are vulnerable to quantum threats and review the readiness of your PKI, HSMs, and applications. This leads to a detailed cryptographic inventory, quantum risk impact analysis, and a clear, prioritized action plan.
PQC Strategy & Roadmap
Next, we design a tailored migration strategy aligned with your business goals. This includes updating cryptographic policies in line with NIST and NSA guidelines, creating governance frameworks, and embedding crypto agility principles so your systems remain adaptable. This leads to a comprehensive PQC strategy, a crypto-agility framework, and a phased migration roadmap built around your priorities and timelines.
Vendor Evaluation & Proof of Concept
Selecting the right solutions is critical. We help you define RFP/RFI requirements, shortlist the most suitable vendors for PQC algorithms, key management, and PKI, and conduct proof-of-concept testing in your environment. This gives you a vendor comparison report and tailored recommendations to support informed decision-making.
PQC Implementation
With the plan in place, we assist in deploying post-quantum algorithms within your infrastructure: PKI, enterprise apps, or broader ecosystems. We also enable hybrid cryptography models, ensuring seamless integration across cloud, on-prem, and hybrid environments. This helps in validated interoperability, strong documentation, and hands-on training so your team can manage and maintain the system confidently.
Pilot Testing & Scaling
Before enterprise-wide deployment, we run controlled pilot tests to validate performance and resolve integration issues. Once optimized, we support a phased rollout to replace legacy algorithms, minimize disruption, and maintain compliance. This enables smooth, scalable deployment with ongoing monitoring and optimization to keep your systems secure and future safe.
CBOM Secure
Our Encryption Consulting CBOM Secure tool plays a key role in helping organizations prepare. Instead of dealing with spreadsheets, manual OpenSSL outputs, or scattered configuration files, our CBOM tool gives a clear view of crypto usage across environments. It shows which algorithms are in use, what needs to change for post-quantum security, and whether systems meet security goals. For organizations getting ready for board meetings, architecture choices, or compliance planning, our tool provides clarity and speed.
Our CBOM Secure is more than just a reporting tool; it also speeds up the process. It automates crypto inventories, checks TLS configurations, validates algorithms, and aligns policies, so teams can move from discovery to action without guessing.
Now is a great time to get started: test PQC in a staging environment, map your current crypto usage, and begin creating internal policies.
If your organization needs support, structured assessments, or a guided approach, Encryption Consulting is ready to help with workshops, advice, and deployment assistance. Contact us today and we’ll help you move into the transition with confidence, instead of waiting until you are forced to change.
Conclusion
Meta’s framework is valuable because it is honest and practical. It treats migration as a multi-year ladder, prioritizes by real risk, insists on a cryptographic inventory, relies on standardized algorithms, prevents new problems with guardrails, and deploys defensively with hybrids. Together those choices turn a frightening, open-ended threat into sequenced engineering.
You do not need Meta’s scale to use Meta’s thinking. The same four principles, five levels, and six steps work for an organization of any size. The best first move is the one Meta made first: find out where your cryptography lives, and start climbing the ladder.
