Encrypted traffic being siphoned off networks right now may already be compromised - not because today's codes have broken, but because someone is betting they eventually will. That is the warning from Dr. Peter Huynh, Chairman APAC of SpecterAI Quantum Security, who told attendees at HPT D-DAY 2026 that so-called "harvest now, decrypt later" operations are an active practice, not a speculative future scenario.
A threat that is already underway
The mechanics are straightforward. Intelligence services and criminal groups capture encrypted communications as they cross the internet, store them, and wait. Once quantum computers reach sufficient scale to break RSA and elliptic-curve cryptography - the mathematical foundations securing TLS connections and transaction signing worldwide - that stockpiled data becomes readable. The U.S. National Institute of Standards and Technology has already standardized replacement algorithms, including ML-KEM, ML-DSA and SLH-DSA, designed to resist attacks from both classical and quantum machines. The existence of these standards confirms the industry consensus that current public-key cryptography has a shelf life.
Five stages, one non-negotiable final step
SpecterAI's readiness framework moves through five stages, beginning with a cryptographic inventory that reaches beyond conventional network defenses. Huynh pointed to overlooked corners of institutional infrastructure - hard-coded cryptographic libraries buried inside mobile banking applications, and key storage mechanisms inside ATMs - as places where legacy encryption quietly persists.
From there, organizations must classify data according to how long it needs protection. A one-time password and a thirty-year mortgage contract do not carry the same risk profile. Biometric data sits at the extreme end of that scale. "A password can be changed in thirty seconds," Huynh said. "Nobody can change their face or their fingerprints." That permanence, he argued, should drive how aggressively an organization prioritizes its defenses.
Assessment follows, shifting focus from what is merely visible to what is genuinely exposed. Hardware security modules demand early attention, since those unable to support post-quantum algorithms will block any later migration outright. Migration itself centers on hybrid cryptography - pairing a classical algorithm such as X25519 with the post-quantum ML-KEM-768 inside TLS 1.3 - alongside crypto-agility, meaning systems built to swap algorithms through configuration rather than rewritten code.
- Cryptographic inventory, including mobile applications and ATM key storage
- Data classification by confidentiality lifespan
- Exposure-based assessment, starting with hardware security modules
- Migration through hybrid cryptography and crypto-agile design
- Independent validation performed outside the implementing team
Procurement contracts, Huynh noted, should explicitly require post-quantum compatibility from vendors and partners. Without that clause, a hybrid connection can silently fall back to classical cryptography the moment it meets a partner system that lacks post-quantum support. Transactions keep processing, dashboards stay green, and the organization believes it is protected when it is not.
A timeline problem, not a waiting game
Huynh framed the urgency through a model attributed to Professor Michele Mosca: if the time data must stay confidential (X) plus the time migration takes (Y) exceeds the time before a capable quantum computer exists (Z), the data in question is already at risk. Leaders cannot control X or Z. The only variable within reach is Y. "The only lever leaders hold is Y, and the way to shorten it is a disciplined program that starts now," Huynh said - a framing that turns quantum risk into a scheduling discipline rather than a distant contingency.
Why organizations cannot grade their own homework
The final stage of the framework, independent validation, is where Huynh placed the greatest weight. Internal audits and penetration tests, however rigorous, cannot substitute for review by a separate party. "No organization can independently validate work it performed itself," he said. "This is not a judgment about anyone's capability. The team that designed and configured a system is the least likely to find the failure it did not anticipate, because it built the system on its own assumptions." His framework calls for a strict separation between implementation teams and validation teams, with validation repeated continuously as systems, partners and security patches evolve - since a quantum-safe posture achieved once can quietly erode with every subsequent change.
