A researcher studies encryption risks and PQC strategies that highlight the urgency of the quantum threat.
Quantum computing makes today’s strongest public key cryptography a time-limited shield, which is why “harvest now, decrypt later” attacks turn a theoretical risk into an immediate problem for long‑lived data. The only realistic defense is to start inventorying cryptography and planning migration to NIST‑standardized post‑quantum algorithms now, well before a large‑scale quantum computer exists.
Harvest now, decrypt later
“Harvest now, decrypt later” (HNDL) describes adversaries stealing encrypted traffic and storing it until quantum computers can break the underlying algorithms. This is most dangerous for data with long sensitivity lifetimes: state secrets, healthcare records, intellectual property, financial histories, and high‑value credentials.
Nation‑states and sophisticated criminal groups can passively collect VPN tunnels, TLS sessions, satellite links, and backup archives even if they cannot decrypt them today. When “Q‑Day” arrives and Shor‑class machines are available at scale, that historical ciphertext can be retrospectively mined for strategic, commercial, or identity‑theft value.
Where quantum stands today
Breaking RSA or ECC at meaningful key sizes requires thousands of logical qubits and very low error rates, which in practice means hundreds of thousands to around a million physical qubits or more, depending on architecture and error correction. Recent analyses suggest RSA‑2048 could be factored with on the order of one to a few thousand logical qubits and under one million physical qubits using optimized Shor implementations, significantly lower than older multi‑million‑qubit estimates but far beyond current devices.
Current noisy intermediate‑scale quantum (NISQ) systems have at most a few thousand physical qubits with high error rates, so they cannot yet run large‑scale Shor to break RSA‑2048 or standard ECC in practice. The risk arises from trajectory rather than capability: hardware roadmaps and algorithmic improvements keep shrinking the effective “bar,” narrowing the timeline between laboratory prototypes and cryptographically relevant quantum machines.
NIST PQC standards and what to deploy
NIST has finalized its first three post‑quantum cryptography standards, marking a historic transition point for defensive planning. These include:
- ML‑KEM (formerly CRYSTALS‑Kyber) for key establishment and general encryption.
- ML‑DSA (formerly CRYSTALS‑Dilithium) and SLH‑DSA (formerly SPHINCS+) for digital signatures.
A fifth algorithm, HQC, has been selected as a backup KEM for encryption and will be standardized to hedge against unforeseen weaknesses in lattice‑based schemes. A fourth signature standard based on FALCON (to be published as FIPS 206 / FN‑DSA) is also planned, adding another high‑performance option for constrained environments.
Enterprise and IoT migration priorities
For enterprises, the first step is a cryptographic inventory: catalog where RSA, DSA, and ECC are used across TLS, VPNs, S/MIME, code signing, firmware signing, databases, and internal protocols. This needs to extend into the supply chain, including third‑party services and OEM appliances, because any non‑quantum‑safe link in a critical data path will remain a long‑term weakness.
Next comes crypto‑agility: update architectures so protocols and products can swap algorithms without disruptive redesign. Practically, that means preparing for hybrid modes (for example, combining classical and PQC key establishment or signatures), upgrading PKI to issue PQC‑capable certificates, and validating performance and size impacts on applications and hardware security modules.
Special challenges for IoT and OT
IoT and operational technology are uniquely exposed because devices often ship with hard‑coded RSA or ECC keys, limited compute, and long lifespans in the field. Any sensor, controller, or consumer device that will remain deployed for a decade or more can become a “frozen” cryptographic liability if it cannot receive PQC‑capable firmware and key updates.
Designing or buying new devices should now include explicit requirements for PQC readiness: sufficient memory and CPU for lattice‑based or hash‑based schemes, secure boot that can accept PQC signatures, and support for hybrid certificate chains from vendors.
Existing fleets need segmentation, gateway‑level quantum‑safe protections where possible, and a lifecycle plan that prioritizes replacement of non‑upgradable high‑risk assets that handle sensitive or safety‑critical data.
About the Author
