Key Takeaways from Meta’s Post-Quantum Migration Plan

In April 2026, Meta’s engineering team published a detailed account of its migration to post-quantum cryptography. The value for the rest of us is not Meta’s scale, which almost no one shares. It is the set of lessons that still hold once you strip that scale away. This blog gathers those lessons into practical takeaways, then closes with a simple plan to get started.

The backdrop is the same urgency Meta faces. Attackers can record encrypted data today and decrypt it later under harvest now, decrypt later, and Gartner’s 2024 post-quantum cryptography report expects conventional public-key cryptography to become unsafe by 2029. Analysts have even warned that this cleanup will be larger than any previous cryptographic migration.

The question is not whether to migrate, but how to do it without chaos, and that is exactly what Meta’s experience helps answer. Think of what follows as the short list of steps that still work even when you don’t have a large team to dedicate to the problem.

Why Starting Early Is Beneficial

Most risks are about the future. This one is partly about the present. Data you send today can be quietly stored and decrypted years later, so waiting has a cost right now, not just on some future “Q-Day.” The practical takeaway is to rank your data by how long it must stay secret. Health records, financial files, legal contracts, trade secrets, biometric data, and government communications often stay sensitive for decades, which means anything in those categories is already exposed and belongs at the front of the queue.

Meta acted years before any quantum computer existed for exactly this reason, and the same logic applies to a ten-person startup with a single database of customer records.

Starting early pays off because the advantage builds over time. Every month you act sooner means less data exposed to harvest-now-decrypt-later. It also means a smaller backlog to clear before deadlines are reached. Early movers can spread the work across calm quarters instead of a crisis. They reach PQ-Ready in time to enable protection the moment standards arrive. Late starters do the same work later, under more pressure, and at higher cost.

Map Your Cryptography Before You Plan Anything

Meta treats a cryptographic inventory as the foundation of the entire migration, and so should you. Cryptography hides in TLS endpoints, VPNs, certificates, code-signing keys, databases, and hard-coded library calls. Map it before planning anything else, using automated discovery where you can and developer reporting to catch the shadow systems that scanning misses. NIST’s practice guide, NIST SP 1800-38, Migration to Post-Quantum Cryptography, makes this same discovery work the prerequisite for everything that follows.

A useful starting point is your ten most data-sensitive applications: trace every certificate, key store, and library call they depend on, then widen out from there. For each use, record the algorithm, the key size, where it runs, how sensitive the data is, and who owns it, because that is what turns a flat list into a plan. If you have not built an inventory, you have not started.

Once you can see your cryptography, you can rank it. Meta sorts systems by three factors together: how exposed they are today, how long their data stays sensitive, and how hard they will be to fix later. Asymmetric encryption and key exchange come first, because they are exposed to harvest-now-decrypt-later right now. Signatures come next. Systems that are hard to patch, such as a connected device shipped with a fixed public key, move up the list because “we will fix it later” may not be an option. That three-part lens consistently outperforms a generic risk score.

Score Yourself on a Maturity Ladder

One of Meta’s most reusable ideas is its PQC Migration Levels, a ladder scored by how fast you can react to a quantum event, such as a new standard or a hardware breakthrough. From bottom to top, the five rungs are:

• PQ-Unaware: you do not yet know the threat applies to you.
• PQ-Aware: you know and have assessed it, but have not designed a fix.
• PQ-Ready: a solution is built and tested, but not switched on yet.
• PQ-Hardened: every available protection is deployed, with gaps only where the industry has not standardized a needed piece.
• PQ-Enabled: the use case is fully protected. The goal.

The takeaway is that you do not have to reach full deployment to make real progress. Reaching PQ-Ready, where the solution is built but not yet enabled, already shortens the time needed to react when a deadline approaches. The model is also honest about limits: PQ-Hardened exists because sometimes you deploy every protection available and still cannot fully close the gap, since a needed building block (efficient post-quantum Oblivious Pseudorandom Functions, for one) is not standardized yet. The ladder also turns a vague worry into a status you can report to leadership for every system you own.

Pick Proven Algorithms

Post-quantum cryptography is young, so Meta sticks to NIST-standardized algorithms: ML-KEM for key encapsulation and ML-DSA for signatures, with HQC chosen by NIST as a code-based (error-correcting code) backup in case ML-KEM is ever weakened. More importantly, it deploys them as a hybrid, layering a post-quantum algorithm on top of a trusted classical one, so an attacker has to break both. The cautionary tale is SIKE, a late-round candidate that was broken on an ordinary computer before it could be standardized.

The lesson is that during this transition, hybrid is the safe default. The web agrees, with the hybrid X25519MLKEM768 exchange (an IETF draft) already shipping by default in major browsers. One significant operational consequence of parameter selection is key and message size: an ML-KEM-768 key is about 1,184 bytes next to X25519’s 32, and an ML-DSA-65 signature runs around 3,309 bytes next to 64 today. Hybrid is not free; you pay in larger handshakes and slightly higher CPU usage. But when a brand-new algorithm could still turn out to be weak, paying twice for safety is by far the cheaper mistake.

Start With What Is Standardized, Stage the Rest

Meta has acknowledged that it cannot complete the transition on its own because some pieces depend on the wider industry. The core algorithms are standardized, but the higher-layer standards for post-quantum TLS, X.509 certificates, and PKI are still being written. Meta’s response is the lesson worth copying: deploy what is ready now, such as hybrid key exchange in TLS, and keep everything else at PQ-Ready so you can activate it as soon as standards are finalized.

Waiting for every standard to be final before you begin is how organizations end up rushing the whole migration at the last minute. Move on the stable parts, and stage the rest.

Stop New Problems Before They Start

Migrating old systems is only half the job. If new projects keep creating quantum-vulnerable keys, you are remediating old systems while new exposure keeps accumulating. Meta adds friction in three places worth copying:

• Guidelines: update internal crypto standards so teams know to avoid quantum-vulnerable public-key algorithms.
• Key generation: make key-generation tools warn engineers who request new RSA or ECC keys.
• Build and review: add a rule in the build pipeline or code review that flags risky APIs such as RSA or ECDH.

A single check that warns about new vulnerable usage can save months of future cleanup. Prevention is far cheaper than cleanup, and every quantum-vulnerable key you stop today is one you will not have to migrate tomorrow.

Build for Change: Crypto-Agility and Your PKI

Here is the lesson Meta’s framework implies but leaves to you. Between putting up guardrails and rolling out new components sits a question: how do you build systems that can absorb a future cryptographic change without re-engineering them? Meta operates at a scale where it can engineer around this. Most enterprises need to make it explicit. The answer is crypto-agility, the ability to swap an algorithm through configuration instead of a rebuild.

This matters most in your PKI. Certificates sit under TLS, code signing, device identity, and machine-to-machine authentication, all signed with RSA or ECC today. Changing that touches your Certificate Authorities (CA), issuance policies, validation logic, and HSMs, and one missed dependency can cause an outage.

The practical route is hybrid or composite certificates, which carry both a classical and a post-quantum key, paired with automated certificate lifecycle management so you can rotate thousands of certificates safely. Long-lived firmware and code signing deserve extra care, where standardized stateful hash-based signatures (the LMS and XMSS schemes) are the recommended path. The simple test for any system is this: could you change its default algorithm next quarter without a redesign? If the honest answer is no, that gap is your first project.

Make It a Team Effort, Not a Security Project

Meta’s write-up ends with a long acknowledgements list, and it is one of the most important parts. The work pulled in Transport Security, WhatsApp, Messenger, core Infrastructure, Reality Labs, Hardware, and even the Payments team. The lesson is that post-quantum migration is not something a security team can finish alone. The inventory needs application owners, deployment needs platform and network teams, hardware support needs procurement, and the multi-year timeline needs an executive sponsor who can fund it.

If everyone treats post-quantum readiness as “the crypto team’s problem,” it stalls. Name an owner, brief leadership, and give each affected team a clear slice of the plan. A short monthly check-in on inventory coverage and migration status keeps the effort visible and stops it from quietly stalling between teams.

Sidestep the Traps That Derail Real Rollouts

Meta’s scale exposes the traps that catch everyone eventually, and all of them are avoidable. The easiest one to miss is a problem called middlebox intolerance. Because post-quantum keys are large, they can push a TLS handshake past a packet boundary and split it across packets, and some older firewalls and load balancers silently drop connections they cannot reassemble. This is why even large providers rolled out gradually over the years, so test against your real network path, not a clean lab.

Two more deserve the same attention. During the hybrid period, when old and new run side by side, lock your configuration so an attacker cannot quietly force a connection back to classical-only mode. And resist the urge to migrate the busiest systems first while leaving the quiet archive of long-lived records for later, because that archive is exactly what harvest-now-decrypt-later is after. Finally, treat the whole effort as repeatable rather than a one-time task; standards and threats keep moving, which is the entire reason crypto-agility matters.

Keep an Eye on the Compliance Clock

Even if you are skeptical about exact dates, the regulatory clock is now concrete enough to plan around. NIST IR 8547 points to deprecating today’s quantum-vulnerable algorithms around 2030 and disallowing them by 2035. The NSA’s CNSA 2.0 sets staged dates for the federal supply chain, expecting post-quantum software and firmware signing to be supported and preferred by 2025 and used exclusively by 2030, and web, cloud, and operating systems to follow by 2033. Europe’s coordinated roadmap asks member states to inventory and pilot first and to protect high-risk critical infrastructure by 2030.

These map onto frameworks you may already be familiar with. ISO/IEC 27001, PCI DSS, and GDPR Article 32 all expect appropriate cryptographic protection, which now reasonably includes quantum risk. Increasingly, auditors and cyber-insurers simply ask to see a post-quantum roadmap, so having one is becoming part of staying compliant.

Where to Start: A 90-Day Quantum-Readiness Plan

You do not need to solve everything at once. The takeaways above collapse into a simple first quarter that moves you from PQ-Unaware to a credible, tested plan.

Phase	Focus	Outcome
Days 1-30	Name an owner, brief leadership, and scope your most data-sensitive systems.	A clear mandate and a shortlist
Days 31-60	Start the cryptographic inventory; map public-key usage and data lifetimes.	A risk-ranked inventory
Days 61-90	Pilot a hybrid in a lab and set guardrails against new vulnerable keys.	A tested plan and a prevention rule

Ninety days will not finish your migration, but it gives you the two things that matter most early on: a clear picture of where your cryptography lives, and a rule that stops the problem from growing while you work.

How Encryption Consulting Can Help

If you are wondering where and how to begin your post-quantum journey, Encryption Consulting’s PQC advisory services are here to support you. You can rely on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise.

We begin with a Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the baseline you need before any migration can begin.

From there, we conduct a PQC Assessment to evaluate your exposure to quantum threats, identify RSA- and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.

With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve.

We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.

Finally, we manage Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and setting up monitoring for long-term cryptographic health.

Conclusion

Meta’s biggest contribution is a way of thinking that any organization can borrow. Start now because the threat is retroactive. Map your cryptography before you plan. Prioritize by exposure, data lifetime, and patchability. Measure on a ladder. Use standardized algorithms and prefer a hybrid. Add guardrails, design for crypto-agility, and bring the whole organization along.

The data you send this year can be unlocked later, which is why the largest engineering teams have already moved from “someday” to “now.” The path forward is now well understood. Take the first ninety days, find out where your cryptography lives, and begin moving up the maturity levels.