Post quantum migration, are we actually prepared or just talking about it?

[Daemon82]

The strange thing about post quantum migration in 2026 is that the hard research part is basically done, and yet almost nothing is actually moving. NIST finalised the first three standards back in August 2024, giving us ML-KEM for key exchange and ML-DSA and SLH-DSA for signatures, and it added HQC as a code based backup in 2025. So the algorithms exist, they are standardised, and they are ready to deploy, which means the excuse of waiting for the science to settle has quietly expired

The genuinely hard problem now is not cryptography, it is inventory, and this is the part almost nobody wants to talk about. Most large organisations do not actually know everywhere they use vulnerable cryptography, because it is buried in libraries, embedded devices and vendor products three layers deep in the supply chain. You cannot migrate what you cannot find, so cryptographic discovery and a proper cryptographic bill of materials is the unglamorous first step that has to come before any algorithm swap

There is also the question of how you deploy, and the recent history argues loudly for hybrid caution. One of the alternate candidates in the NIST process, the isogeny based scheme SIKE, was famously broken on a single classical computer after years of scrutiny, which is a sobering reminder that new maths can fail suddenly. That is exactly why the sensible pattern is hybrid or composite deployment, pairing a classical algorithm with a post quantum one so a flaw in either does not sink you

What has actually changed the temperature is that the deadlines now have teeth rather than being polite suggestions. CNSA 2.0 requires new national security acquisitions to be compliant from January 2027, NIST plans to deprecate the vulnerable algorithms after 2030, and Boston Consulting Group bluntly warned that starting in 2030 will already be too late. Against that, there is real progress worth celebrating, because by late 2025 more than half of human web traffic through Cloudflare was already using post quantum key exchange

On the positive side, and I do want to end the framing here, this is one of the rare security problems that came with a long warning and a ready made fix. We know the threat, we have standardised the solution, and we have years of runway if organisations start now, which is a luxury almost no other security crisis offers. The failure mode is not a technical impossibility, it is plain organisational inertia, and inertia is something we can actually choose to overcome

So I want to take the temperature of the forum honestly rather than theoretically. Is anyone here actually running a migration in production, or is it still all roadmaps, pilots and slideware for most organisations? And given harvest now decrypt later means long lived secrets are already exposed, do you think these 2027 and 2030 deadlines are about right, or are they already too late for anything that has to stay secret for decades?

[TechPriest]

The inventory problem is the entire ballgame, and I say that having watched organisations faceplant on exactly this step. I have seen enterprises confidently declare themselves ready while having no idea their payment systems embedded vulnerable crypto three vendors deep, discovered only when someone finally ran a proper cryptographic discovery scan. You genuinely cannot plan a migration when you do not have an honest map of where the cryptography lives

This is why I roll my eyes at anyone treating the algorithm choice as the hard decision, because ML-KEM versus the parameter sets is trivial next to knowing your own estate. The cryptographic bill of materials work is boring, unglamorous and completely unavoidable, and the organisations that started it two years ago are the only ones who will hit the deadlines. Everyone else is going to discover their real scope far too late to react calmly. How many people in here have actually completed a full cryptographic discovery scan, rather than just assuming they know where their crypto lives?

[202694]

Your SIKE point is the most important cautionary tale in the whole field and I am glad you raised it. An isogeny based scheme that survived years of NIST scrutiny got shattered on a single classical core, which should permanently humble anyone who wants to rip out classical crypto and trust the new stuff alone. That failure is the single best argument for hybrid deployment that exists

So the composite certificate approach, pairing a classical signature with an ML-DSA one so both must validate, is not paranoia, it is basic engineering prudence. Yes it inflates chain sizes and complicates the relying parties, but that overhead is a cheap insurance premium against the nightmare of a standardised algorithm failing after you have bet everything on it. Anyone deploying pure post quantum without a classical hedge right now is taking a risk I would not sign off on

[Amber90]

I think you are being too generous about the deadlines being comfortable, because harvest now decrypt later quietly makes them retroactive. Nation state actors are capturing TLS sessions and encrypted backups today and simply warehousing them, so for any secret that must survive twenty years the practical deadline was several years in the past. The 2030 deprecation date is meaningful for active attacks, but it is almost irrelevant for data already being harvested

So my honest answer to your question is that the deadlines are roughly right for new traffic and far too late for long lived secrets. If you hold diplomatic cables, health records or anything with a multi decade secrecy requirement, the correct migration date was yesterday and every day of delay adds to a pile of data that is already effectively compromised. The only rational response is to triage by secrecy lifetime and migrate the long lived material first, immediately

[Jordan89]

To actually answer your question about who is in production, we are, and I want to share how it is going because the theory undersells the pain. We started with the highest value long lived data and moved it to a hybrid ML-KEM key exchange first, and the biggest surprise was not the cryptography but the sheer number of systems that could not handle the larger key and signature sizes. Plenty of older protocols and constrained devices simply choke on the bigger artifacts

The lesson we learned the hard way is that crypto agility matters more than any specific algorithm choice. If your systems can swap algorithms without a re architecture, migration is a project, and if they hardcode the crypto, it is a multi year rebuild, which is exactly the split the guidance keeps warning about. So my advice to anyone starting is to invest in agility first, because you will be swapping algorithms again when HQC finalises and probably again after that

[Cole_55]

The organisational inertia framing is exactly right, and honestly it is a bit depressing how true it is. The technology is ready, the standards are final, the deadlines are published, and yet the actual blocker is budgets, priorities and the fact that crypto migration is nobody's exciting flagship project. It is pure unglamorous plumbing, and unglamorous plumbing is precisely what large organisations are worst at prioritising until something breaks

What might finally break the inertia is procurement pressure rather than good intentions, because CNSA 2.0 requirements are now cascading into contracts and RFPs across the defense supply chain. Once you cannot win a federal contract without a credible post quantum roadmap, suddenly the migration stops being optional and starts being a revenue issue. That commercial forcing function will probably move more organisations than a decade of security warnings ever did

[Blake_73]

I want to gently push back on the idea that this is basically solved just because the standards are final. Finalised algorithms are not the same as a mature ecosystem of libraries, hardware security modules and vendor products that all support them reliably and interoperably at scale. That integration and testing gap is real, and it is where a lot of migrations will quietly stall for a year or two regardless of good intentions

There is also the awkward fact that the standards themselves are still evolving around the edges, with HQC not finalised until around 2027 and the FALCON based signature standard still in the pipeline. So anyone who migrates today has to accept they are building on ground that is still settling, which is another argument for crypto agility over committing hard to one algorithm. The starting gun has fired, but pretending the race is a short one does nobody any favours

[Anthony92]

The one genuinely hopeful thing here, and I do not want it to get lost in the doom, is the Cloudflare data point you mentioned. More than half of human web traffic already using post quantum key exchange by late 2025 is a staggering achievement that happened almost invisibly, because it was rolled out at the infrastructure layer where individual users never had to lift a finger. That is the template for how this should work

It suggests the migration succeeds fastest where a small number of infrastructure providers can flip it on for everyone at once, and struggles most in the fragmented long tail of enterprise systems and embedded devices. So the realistic picture is a two speed transition, where the internet backbone quietly goes quantum safe while a messy tail of legacy systems drags on for a decade. Celebrating the backbone win while staying honest about the tail is the right way to hold both truths at once