With the industry’s attention locked onto AI, it’s easy to forget that another computing shift has been accelerating in the background. Quantum computing used to live comfortably in the “interesting theory, far from production” bucket. It doesn’t anymore. The serious money, the serious lab time, and the steady cadence of capability gains have pushed it into a category security architects can’t ignore, because cryptography is a foundational dependency, and foundational dependencies fail loudly when the underlying assumptions change.

Quantum computers exploit properties of physics—superposition and entanglement—to handle certain classes of problems in a way classical machines can’t realistically match. That doesn’t mean they instantly become faster at everything. It means they become dangerously good at very specific tasks. Unfortunately for defenders, some of those tasks line up neatly with the math we’ve relied on for decades to keep secrets and prove identity on the internet.

Modern public-key cryptography is built on the idea that some mathematical problems are easy to do in one direction and infeasible to reverse at scale. RSA depends on the difficulty of factoring large integers. Elliptic Curve Cryptography leans on the hardness of discrete logarithms in elliptic curve groups. These aren’t obscure academic constructs; they are the scaffolding underneath TLS, VPNs, authentication flows, and digital signatures. They’re the invisible machinery that lets systems trust each other across hostile networks.

The quantum-shaped crack in that scaffolding has a name: Shor’s algorithm. Proposed by Peter Shor in 1994, it showed that a sufficiently capable quantum computer could factor large numbers and compute discrete logarithms efficiently enough to break RSA and ECC in practice. That’s the sentence that should make any security architect pause, not because it guarantees imminent catastrophe, but because it changes the timeline logic. Crypto migrations are slow. Legacy systems linger. Certificates and embedded devices often outlive the teams who built them. When the day arrives that the underlying math is no longer safe, the organisations that treated this as “a problem for later” will discover that later is not a helpful time to rewrite the foundations.

There’s also a more immediate, less glamorous risk that tends to get overlooked: store now, decrypt later. Adversaries don’t need quantum capability today to benefit from it tomorrow. If traffic is captured now and retained, future breakthroughs can retroactively expose what used to be confidential. For some data classes—long-lived intellectual property, strategic planning, sensitive personal data—the shelf life is measured in years, not weeks. That alone is enough to justify planning, even if practical quantum machines capable of breaking modern crypto are not yet sitting in a datacentre somewhere waiting for a target list.

So what does defence look like when the old assumptions start to wobble?

The security community’s answer is post-quantum cryptography: new public-key schemes designed to resist both classical and quantum attacks. The important nuance is that this isn’t about inventing crypto for the sake of novelty. It’s about finding constructions that don’t collapse under the kinds of speedups quantum algorithms provide. A lot of the most promising candidates are built on different hardness assumptions—lattice problems, code-based systems, hash-based signatures, multivariate constructions. The point is to move away from the exact problems Shor’s algorithm makes tractable.

The standardisation effort matters here because crypto doesn’t become real when it exists in papers; it becomes real when it’s implementable, reviewable, and adopted across libraries, protocols, and hardware. NIST’s post-quantum work is a major part of turning this into something deployable at scale, and the organisations that will handle this well are the ones treating it as an engineering programme rather than a panic response.

The migration itself will be the hard part, not the algorithm names. Crypto is deeply embedded in systems: certificate lifecycles, hardware root of trust, authentication protocols, key management processes, IoT firmware, third-party integrations, and software that nobody wants to touch because it “just works”. Post-quantum schemes also tend to come with trade-offs, particularly in key sizes and performance characteristics, which can ripple into bandwidth, latency, storage, and constrained devices in ways that aren’t obvious until you test them.

The practical starting point isn’t to rip out RSA tomorrow. It’s to understand where your organisation uses public-key cryptography, what needs to remain confidential for a long time, and where you’re exposed to long-lived keys and signatures. It’s to get crypto agility onto the roadmap so the organisation can swap algorithms without rewriting everything that depends on them. And it’s to start testing in controlled places—internal services, non-critical integrations, build pipelines—so the change doesn’t arrive as a surprise in the middle of a crisis.

Quantum computing is both a threat and a forcing function. It’s a threat because it undermines assumptions we’ve treated as stable. It’s a forcing function because it pushes us toward more resilient, more adaptable cryptographic architectures. The organisations that do well in the next wave won’t be the ones who guessed the exact date quantum arrives. They’ll be the ones who made their systems ready for crypto change before the change became mandatory.