Post-Quantum Security Starts Before Quantum Computers Are Ready

EditorsDossiers2 weeks ago68 Views

The quantum threat does not begin on the day RSA breaks. Migration takes years, which makes cryptographic inventory and crypto-agility a problem for the present.

Preparing for quantum computing does not require waiting for the day a quantum computer can break the cryptography we use now. In fact, waiting for that day would probably be the worst possible strategy. The transition toward quantum-safe systems involves software, certificates, devices, archives and suppliers that can take years to update.

The US National Institute of Standards and Technology is now explicit: organizations should begin moving toward finalized post-quantum cryptography standards that are already available for implementation. The reason is not that quantum computers have already broken RSA or elliptic-curve cryptography. It is that cryptographic infrastructure is replaced much more slowly than an ordinary software patch.

Post-quantum cryptography asks a more practical question: what has to change before some of today’s cryptographic techniques become vulnerable?

What post-quantum cryptography actually is

Post-Quantum Cryptography (PQC) includes algorithms designed to resist attacks from both classical computers and sufficiently powerful future quantum machines. It does not require quantum hardware: the new algorithms can run on conventional computing systems.

That distinction matters. “Quantum-safe” does not mean moving everything onto a quantum network. It means progressively replacing encryption and digital-signature algorithms that could be compromised by a quantum computer capable of running algorithms such as Shor’s at useful scale.

NIST has already finalized standards including ML-KEM for secure key establishment and ML-DSA for digital signatures. Migration can therefore begin before the full operational threat exists.

Why migration has to begin before the quantum computer arrives

There are two reasons. The first is technical: cryptography is everywhere. It sits inside network protocols, certificates, identity systems, VPNs, firmware updates, industrial devices, banking systems and archives. Many organizations do not even know exactly where particular algorithms are being used.

The second is the risk commonly described as harvest now, decrypt later. An attacker can intercept encrypted information today and store it in the hope of decrypting it in the future. That matters most for information that must remain confidential for many years: health records, industrial secrets, government communications and financial data.

That is why asking “when will the quantum computer arrive?” is less useful than it sounds. If a dataset must remain secret for ten or twenty years, its quantum risk already exists at the moment it is transmitted.

The first step is finding where cryptography lives

NIST’s migration work repeatedly emphasizes an apparently mundane idea: the cryptographic inventory. Before replacing algorithms, an organization has to know which systems use them, which data they protect, which software dependencies exist and which suppliers have to be involved.

For a company, that means mapping certificates, protocols, libraries, hardware, SaaS applications and legacy systems. The problem becomes harder when cryptography is embedded inside products purchased from third parties. In those cases, migration depends on the supplier’s timetable as well as the customer’s.

On September 23, 2026, Deloitte suggested a four- to five-year horizon for banks to define strategies covering data protection, internal organization and supplier networks. That timescale fits the real nature of the problem: this is not a patch. It is an infrastructure transition.

Crypto-agility matters beyond quantum computing

The most important lesson of post-quantum migration may ultimately have little to do with quantum technology itself. A well-designed infrastructure should allow cryptographic algorithms to be replaced without rebuilding the entire system. That capability is often called crypto-agility.

Standards can change, new vulnerabilities can appear and some implementations can prove less robust than expected. In July 2026, HAWK, an algorithm under consideration for standardization, was withdrawn after a vulnerability was identified. NIST clarified that the issue did not affect already finalized PQC standards such as ML-KEM and ML-DSA.

The episode is a useful reminder that security is not about selecting the “right” algorithm once and for all. It is about building systems that can evolve when assumptions change.

What an organization should do now

A realistic strategy can begin with four steps: inventory cryptographic use; classify data according to how long it must remain sensitive; check supplier migration roadmaps; and introduce new standards when systems are being renewed anyway.

Not every system has to migrate at the same time. A machine scheduled for retirement next year has a different priority from infrastructure that must remain operational for fifteen years. The aim is to avoid reaching quantum maturity with a mountain of cryptographic dependencies that nobody ever mapped.

The quantum-safe future therefore begins with something spectacularly un-futuristic: an inventory. The exotic technology comes later. First come governance, updates and an accurate map of the infrastructure we currently take for granted.

Sources and references

Leave a reply

Loading Next Post...
Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...