Cryptography works because it is assumed that it is too computationally and economically expensive to be practical. That assumption sits underneath TLS, certificates, signed software, VPN services, and identity systems across enterprise networks.
When that cost drops far enough, the protection stops holding. That is why two recent back-to-back papers from researchers at Google and Caltech on quantum computing matters to security and business leaders everywhere.
Co-Founder and executive at QuSecure.
These recent research articles suggest that the resources required to break traditional cryptography used on the internet and with cryptocurrencies may now be materially lower than earlier estimates.
Article continues below
Many conflicting factors still exist: The exact timeline is still uncertain, there is still a large gap between research papers and real-world capability, and further advancements are not guaranteed.
Thus far, however, the trend has only been moving toward increasing acceleration in the capability of quantum computers and the risk that they present to internet security.
Many articles have already been written about these recent announcements, but after spending many years educating organizations and deploying these algorithms in enterprise environments, there are two very salient points I would encourage leaders to pay attention to today.
Issues of practicality
The first is that the question of the practicality of quantum-enabled attacks has largely been settled. Many leaders have now heard of specialized attacks (such as harvest-now-decrypt-later or trust-now-forge-later) that may be enabled by a sufficiently powerful quantum computer, but much skepticism still exists about the ability to actually execute these in practice.
These new papers show that the possibility of a quantum-enabled attack can no longer be ignored. In fact, it is now increasing to the level of organizational policy at places such as Google, where they have moved up their quantum-secure transition timelines to 2029 with other major players and verticals to follow suit.
Execution risk
The second is execution risk. Most organizations still talk about post-quantum migration as though it were a normal upgrade cycle. It is not. Cryptography is buried in more places than most teams realize – including TLS stacks, VPNs, PKI, software signing, SSH, identity management, embedded systems, partner integrations, and vendor products that may or may not have a roadmap.
That is where the problem becomes concrete. Even though NIST standardized quantum-resistant algorithms in 2024, the problem of how to actually deploy and use these algorithms (in particular with the heterogeneity and scale of an enterprise) is still an open question.
The EU and US have each laid out roadmaps with the first deadlines coming into effect at the end of this year. At this point, the blocker is not whether the industry knows where to go. The blocker is whether organizations can actually get there in time.
The usual migration plan
The usual migration plan sounds reasonable on paper: Inventory the environment, find dependencies, work with vendors, test, validate, and roll out in phases. In a large enterprise, that process can take years.
A complete cryptographic inventory alone can be a major program. After that come procurement cycles, lab testing, maintenance management windows, change control, and deployment across environments that were never designed for algorithm agility.
That is why waiting for a perfect migration plan is risky. A lot of teams are assuming they will get to full visibility first, then protection later. In practice, that sequence may prove to be too slow.
What organizations need now is a practical way to start to spend down tech debt and reduce exposure while the longer migration continues. That starts with continuous visibility. If you do not know where vulnerable cryptography is deployed, you cannot scope the problem, prioritize it, or measure progress.
It also requires creative ways to become more agile in managing cryptography (so called “crypto-agility”). If every algorithm change turns into an application rewrite, a hardware refresh, or a long vendor cycle, your timeline likely already extends well into 2030 or even later.
This also means dealing with real environments as they exist today, not as they would look in a clean-sheet architecture. Most teams are working across heterogeneous IT infrastructure, legacy systems, third-party dependencies, and operational constraints that make a clean transition unrealistic in the near term.
Questions worth asking now
If you are leading this internally, there are a few questions worth asking right away.
1. Do you actually have full cryptographic visibility, beyond a certificate inventory? You need to know where vulnerable RSA and ECC (or even older) algorithms show up across transport security, authentication, signing, firmware, and third-party integrations.
2. Are your systems genuinely crypto-agile? Or does changing a primitive, protocol, or algorithm still require code changes, vendor intervention, and a long validation cycle every time?
3. And how does your migration plan compare to the timeline you are actually operating against? Whether the driver is CNSA 2.0, customer requirements, or internal risk management, the answer should be grounded in execution time, not optimism.
The biggest mistake right now is assuming there is still plenty of time because a cryptographically relevant quantum computer is not sitting in production yet.
Enterprise transitions of this size almost always take longer than expected and often times organizational leaders find that their teams and infrastructure are less prepared than they had hoped.
In short, these new papers now make it clear that post-quantum readiness is now a near-term execution issue. The organizations that handle it well will be the ones that start actively budgeting for and reducing exposure this year.
We’ve ranked the best encryption software.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit
https://cdn.mos.cms.futurecdn.net/sqGgDPxHyGtqunPo56h9cL-2560-80.jpg
Source link
