Is the quantum computing threat to encryption is being taken seriously enough?

[Nina81]

Sky News ran a segment putting the quantum threat question to the people who actually have to defend against it, rather than the vendors trying to sell a fix for it. The framing is simple and has been circulating in cybersecurity circles for a while now under the name harvest now, decrypt later, the idea that hostile actors are already scooping up encrypted traffic today with no ability to read it, banking on a future quantum computer to crack it open once one exists.

That waiting game matters because some categories of data stay sensitive for decades. Government communications, health records, long term financial data and intellectual property do not lose their value just because nobody can decrypt them yet, so an adversary with patience and cheap storage can simply sit on stolen traffic until the maths catches up. The segment frames this as a live rather than theoretical risk, since the storage cost of hoarding intercepted data has fallen dramatically while the timeline for a cryptographically relevant quantum machine has been steadily pulled forward by researchers across the field.

The uncomfortable part for a lot of organisations is that migrating away from vulnerable encryption is not a software patch, it is closer to a multi year infrastructure project touching everything from VPNs to certificate authorities to embedded devices that were never designed to be updated in the field. NIST has already finalised post quantum cryptography standards, but standards existing on paper and organisations actually deploying them across legacy systems are two very different states of readiness.

What gives the segment its edge is the gap between how seriously governments talk about this and how seriously most private organisations actually act on it. National agencies have been issuing migration guidance for a couple of years now, yet plenty of businesses still treat post quantum migration as a someday problem rather than a now problem, largely because the payoff is invisible until the day it very much is not.

The segment does not pretend there is a single dramatic fix, and that is probably the most honest thing about it. Post quantum migration is inherently a slow, unglamorous, multi year slog through legacy systems, and the risk of leaving it too late is that the harvesting has already happened long before anyone notices the theft.

Are We Taking The Threat From Quantum Technology Seriously Enough 13589004news.sky.com

[AEWCallum93]

Harvest now decrypt later sounds abstract until you think about what kind of data actually needs to stay secret for thirty years. State secrets obviously, but also things like adoption records, witness protection details, weapons designs. That is the category where waiting a decade for the maths to catch up is a completely rational strategy for an attacker.

[Rooney]

Storage getting cheap enough to make harvesting worthwhile is the part people miss. A decade ago hoarding petabytes of encrypted traffic on the off chance you might crack it later was expensive enough to be a niche strategy. Now it barely registers as a cost for a well resourced state actor, so the calculus has shifted entirely in the attacker's favour.

[Amy96]

Skeptical framing aside, is there actually a hard timeline anyone agrees on for when a cryptographically relevant quantum computer arrives? Every estimate I have seen ranges from five years to twenty five depending on who you ask and what they are trying to sell you.

[Wardlow86]

The gap between government urgency and private sector inaction is the real story here and it never gets enough attention. Agencies have been shouting about this since 2022 at least. Most companies still have it filed under someday because nobody gets fired for not migrating early, they only get in trouble for migrating badly or expensively.

[Firewall Hollow]

I work adjacent to this field and the underestimated cost is not even the cryptography itself, it is discovering everywhere in your own infrastructure that uses vulnerable encryption in the first place. Nobody has a complete inventory. You find certificate dependencies buried in systems nobody has touched in a decade and half the time the original engineers have long since left.

[Dolphin43]

The NIST standards being finalised is genuinely underrated news given how much of this debate assumes we are still waiting on the cryptography itself. We are not, the algorithms exist and have been through years of review. What is missing is deployment, and deployment is the boring unfunded part that never makes headlines the way a new algorithm does.

[Caitlin_69]

The part that worries me most is the data with a long shelf life. A company might have customer records, legal documents or research data that needs to remain confidential for 10, 20 or even 30 years. If an attacker can copy encrypted traffic today and keep it until sufficiently capable quantum machines exist, the problem does not start on the day someone builds the machine.

That makes the migration issue feel much more practical than the usual sci-fi framing. A business does not need a quantum computer in its server room to have a quantum-readiness problem; it needs to know where vulnerable cryptography is being used and how long the protected information needs to remain secret. That inventory work sounds boring, but boring security work is often the stuff that saves you later.

[Neil82]

There's a weird optimism in assuming quantum computers capable of breaking crypto are decades away. History says timelines compress faster than expected. Better to be early than late on this one.

[Eagle84]

The media coverage has been oddly balanced lately. Less "quantum computers will break everything tomorrow" and more "here's what needs to happen and why it's taking time." Progress, even if it's slow.

[Mark94]

The "harvest now, decrypt later" idea is probably the strongest argument for taking this seriously before a large-scale quantum computer exists. An attacker does not necessarily need to understand the contents of intercepted encrypted data today if that data could still be valuable years from now.

Consider diplomatic communications, medical research or intellectual property. Losing confidentiality after twenty years is still losing confidentiality. For something like a disposable password reset link, the situation is obviously very different. Risk depends heavily on how long the information needs protection, which is why blanket statements about the quantum threat can be misleading.

[Jordan_68]

Financial services are moving faster than most. When your entire business model depends on trust and encryption, suddenly "maybe next year" doesn't fly. Other sectors should take notes.

[Mesh Ross]

Quantum threat fatigue is real. People hear "quantum" and tune out because it sounds like sci-fi. Meanwhile, actual migration work is happening in boring spreadsheets and architecture docs. That's where the real story is.

[TechPriest45]

Some orgs treat quantum readiness like a fire drill they'll never actually use. Others are already swapping out algorithms in test environments. The gap between those two groups is where the risk lives.

[Vulcan]

There's also an important distinction between encryption and authentication that sometimes gets lost in these discussions. Quantum algorithms don't simply turn every security mechanism into digital confetti. Different cryptographic constructions have different levels of exposure, and some symmetric cryptography can be strengthened by using larger key sizes rather than being replaced wholesale.

Public-key systems are where the migration discussion gets particularly urgent because of the potential impact of algorithms such as Shor's algorithm. That is one reason the transition cannot just be described as "make all encryption quantum-proof". There are several different cryptographic jobs being performed across a modern system, and each needs to be considered separately.

[GateWalker49]

Cloud providers are quietly rolling out post-quantum options already. If your vendor offers it and you're not testing, that's on you. The tools exist; adoption is the lag.

[AlphaDarren12]

There is a slightly funny irony here: one of the biggest quantum security challenges may be convincing organisations to change systems that currently appear to work perfectly. Nobody likes replacing infrastructure because of a future risk that cannot be demonstrated with today's hardware.

That's where good planning can make the difference. Build quantum readiness into normal upgrade cycles rather than launching a gigantic emergency project later. If a VPN, certificate platform or application is due for replacement anyway, asking about post-quantum support costs far less than discovering five years from now that the shiny new system is already difficult to migrate.

[HeartbreakKidCurtis18]

One thing I'd push back on is the idea that this is only a problem for governments, banks and giant technology companies. Smaller organisations inherit cryptographic choices from the software and cloud services they use, so they can still be affected even if they never implement cryptography themselves.

That said, expecting a five-person business to become a quantum cryptography laboratory would be ridiculous. The sensible approach is probably to ask suppliers useful questions: which cryptographic standards are supported, whether products can be upgraded, how certificates and keys are managed, and whether the vendor has a migration plan. You don't need a PhD in quantum information to ask where your encryption roadmap is heading.

[Jade77]

The standards point is important, but standards alone do not migrate networks. Plenty of organisations have excellent policies sitting in documents that nobody has opened since the last audit. The real test is whether teams know what cryptographic algorithms they are actually running and whether their systems can be upgraded without rebuilding half the infrastructure.

A useful example is a long-lived industrial system. Imagine equipment expected to remain in service for 15 years, with firmware updates protected by public-key signatures. If the hardware cannot support a newer post-quantum scheme, that becomes an engineering problem rather than a theoretical cryptography problem. Planning for replacement cycles now could be much cheaper than discovering the limitation later.

[WonderWoman73]

The strongest argument for taking this seriously is not that quantum computers are guaranteed to break everything. It's that cryptographic migration has historically been slow, complicated and full of dependencies. If the eventual threat arrives faster than organisations can replace vulnerable systems, then starting late becomes expensive

There is also a nice security principle hiding underneath all this: design systems so that changing cryptography is possible. Algorithms have been retired before for other reasons, so crypto-agility should not be treated as a feature that only exists for the quantum era. Quantum computing is simply another reason to stop welding one cryptographic assumption permanently into an application

[Always_David72]

Ask any cryptographer and they'll tell you the math is ready. Ask any IT ops person and they'll tell you the infrastructure isn't. That tension is the whole story

[Nova]

Maybe the most useful comparison is Y2K, although the analogy has limits. The danger was not that computers suddenly became evil at midnight; it was that huge amounts of old software contained assumptions that were going to stop working. The solution was preparation, testing and replacement before the deadline arrived

Quantum migration has a similar planning flavour. Nobody knows exactly when a cryptographically relevant quantum computer will become practical, but organisations do know that replacing deeply embedded technology can take years. Waiting for a precise countdown clock may therefore be a poor strategy. You can prepare without pretending to know the future

[Seb]

One thing I'd like to see more of is discussion about suppliers. A company can have a sensible internal security team and still be stuck if a critical piece of third-party software only supports older cryptographic algorithms

Procurement could help here. Instead of asking vendors vague questions about whether they are "quantum safe", buyers could ask whether products support recognised post-quantum standards, how upgrades will be delivered, and whether cryptographic components can be changed without replacing the entire platform. That turns a futuristic security concern into a fairly ordinary technology procurement requirement

[Dataset Cheetah]

Final thought: the quantum threat isn't a sprint or a marathon; it's a relay race. Different teams handle different legs, and dropping the baton anywhere breaks the whole chain. Coordination is everything

[Freddie79]

A fair question is whether the threat is being overstated because quantum computing has become a convenient marketing word. There are certainly vendors who can make almost anything sound urgent if it helps sell a product. That shouldn't mean the underlying security issue gets dismissed, though

The useful middle ground is to ignore the hype and look at concrete dependencies. Which systems rely on vulnerable public-key algorithms? How long must the information remain confidential? Can the software support post-quantum algorithms? How long would migration take? Those questions produce much more useful answers than arguing about whether the quantum apocalypse arrives in 2035 or 2045

[StormForge62]

The defenders on that Sky segment nailed it: this isn't about fear, it's about preparation. You don't wait for the storm to start fixing the roof. Same logic applies here

[RedWrench]

The hardware uncertainty actually makes preparation more sensible to me, not less. Nobody can give us a reliable date for when a quantum computer capable of breaking deployed public-key systems will exist. That uncertainty is exactly why organisations should avoid making their security plan depend on a precise prediction

It's similar to preparing for a technology refresh when you know the current platform has an eventual end-of-life but don't know the exact day everything will change. You build flexibility into procurement and software design so that migration becomes manageable. Crypto-agility sounds dull, but being able to swap algorithms without rebuilding an entire product is a pretty valuable feature

[Velvet Connor]

NIST finalising standards is the quiet win everyone's sleeping on. Now the argument isn't "which algorithm?" but "why haven't you started yet?" That shift matters.

[Hermit]

The encouraging thing about the current situation is that the cryptographic community isn't waiting around for somebody to demonstrate the apocalypse first. Post-quantum algorithms and standards are already being developed and deployed, which gives organisations a route forward

The frustrating part is that migration is slow because cryptography is infrastructure. A website certificate is easy to see, but cryptographic operations can also be hidden inside VPNs, identity systems, software signing, databases, mobile applications and embedded devices. Replacing one component can create compatibility problems three systems away. That's where careful inventory and staged testing become more valuable than dramatic headlines

[Sequence19]

The real bottleneck isn't technology; it's organisational bandwidth. Teams are already stretched thin dealing with ransomware, supply chain attacks, and compliance audits. Quantum gets queued behind the fires

[Runtime Arrow]

One practical headache is certificates. Imagine an organisation with thousands of devices, internal services and applications, all relying on public-key infrastructure. Moving those systems to new cryptographic schemes may involve certificate authorities, operating systems, network appliances, application libraries and hardware security modules

None of that sounds particularly glamorous, but it explains why migration needs to begin well before anyone expects a cryptographically relevant quantum machine. The hard part may not be inventing the mathematics. It may be finding every dusty corner of the organisation where someone quietly hard-coded an algorithm in 2008.

[Clever Wrench]

Organisations that treat crypto agility as a core design principle will fare better. Those that bolt it on as an afterthought? They'll be the case studies in "what not to do" presentations.

[Holly78]

Taken seriously enough? Depends who you ask. CISOs are sweating; boards are nodding vaguely; budgets are... still "under review." Classic disconnect between knowing and doing

[Sharon95]

Some people seem to interpret post-quantum cryptography as meaning we have already solved the entire quantum security problem. That's a bit like installing a better lock and declaring the building permanently secure. It is an important step, but implementation, key management, software updates and operational security still matter

A mathematically sound algorithm can be undermined by a bad implementation or a poorly managed key. So the migration needs to be treated as normal security engineering rather than a special quantum checkbox. The exciting mathematics gets the headlines; the certificate rotation scripts probably get the actual work done

[ControlPlane Priya]

The Sky News segment was refreshing precisely because it skipped the vendor pitch deck energy. Actual defenders talking about actual timelines and actual constraints. That's the conversation we need more of

[HeartbreakKidCurtis18]

NIST's standards being finalised removes a huge excuse. No more "we're waiting for guidance." Now it's just "we haven't prioritised it." Different problem, harder to justify

[CyberWarden61]

The threat is taken seriously by the people who have to live with the consequences. Whether that translates into action at the pace required remains the open question. Time will tell

[Patrick93]

The NIST standards being finalised are useful because they turn a vague warning into something engineers can actually work with. Standards give vendors and customers a common target, which is much more practical than every organisation inventing its own interpretation of quantum-safe cryptography

Still, the next step is adoption. Standards sitting in a document do not protect archived records, software updates or network traffic. The interesting question over the next few years will be how quickly those standards become ordinary components of operating systems, browsers, VPNs, cloud platforms and enterprise products. Once the quantum-safe option becomes boring and routine, we'll probably know the migration is finally gaining traction.

[ECWRobert81]

There is a temptation to say that because today's quantum computers cannot break modern cryptography, there is no immediate issue. That conclusion skips over the lifetime of the systems being protected. Security planning routinely deals with threats that are not currently practical because replacing infrastructure takes time

At the same time, panic is not useful either. Organisations should not rip out every cryptographic system overnight simply because the word quantum appeared in a headline. A risk-based migration programme makes more sense: identify long-lived sensitive information, map vulnerable algorithms, prioritise systems that are difficult to replace, and test suitable post-quantum alternatives

[Slate Mike]

The threat is real, but so is the inertia. Migrating crypto across an enterprise is like repainting a skyscraper: by the time you finish the top, the bottom needs redoing. Scale is the enemy here

[Wizard72]

Some countries are treating this like national security infrastructure. Others are treating it like a nice-to-have IT project. Guess which approach actually works when the clock runs down?

[NeutrinoX74]

Vendors love to frame this as "buy our quantum-safe box and sleep soundly." Reality is messier: legacy systems, embedded devices, protocols that haven't been touched in a decade. No single product fixes that

[Vacant Niamh]

Would love to see more cross-industry working groups on this. Sharing playbooks, migration patterns, lessons learned. No point every org reinventing the wheel when the clock's ticking.

[BigDog10]

There is a tendency to hear "quantum threat" and imagine someone cracking every HTTPS connection next Tuesday. That is probably the wrong mental model. The concern is that sufficiently capable quantum computers could undermine some widely used public-key cryptographic systems, particularly those based on mathematical problems for which quantum algorithms offer major speedups

What makes the NIST work encouraging is that organisations can start replacing vulnerable algorithms before the theoretical threat becomes an operational one. The awkward bit is that large companies rarely have a neat button labelled "replace cryptography". Algorithms are buried in libraries, certificates, devices, firmware and old systems that somebody installed in 2011 and has been afraid to touch ever since