The Quantum Threat Organizations Cannot Ignore: From “Harvest Now, Decrypt Later” to “Trust Now, Forge Later”

Quantum threats extend beyond encrypted data to digital signatures, software integrity and device identity. Insights from the Quantum Club Thailand launch.

Quantum computing may eventually threaten more than the confidentiality of encrypted information. It could also challenge digital identity, software authenticity, device trust and the systems that determine what is genuine.

Thailand officially launched Quantum Club Thailand at True Digital Park on 3 August 2026, bringing together participants from government, academia and industry. The initiative involves organizations including Thailand’s Ministry of Higher Education, Science, Research and Innovation, Charoen Pokphand Group, Arise, True Corporation, QTRic and the US-based quantum platform provider qBraid.

One of the event’s central sessions was Quantum Talk: Perspectives and Opportunities of Quantum Technology for Thailand, held from 14:10 to 16:00. The discussion explored the present state of quantum computing, real-world applications and the development of a national quantum ecosystem.

Beyond the economic and scientific opportunities, however, the discussion raised an issue that deserves immediate attention from Thai organizations: the effect of quantum computing on cybersecurity.

The risk is not limited to whether a future quantum computer could read information that is encrypted today. It also concerns whether digital systems will continue to distinguish a genuine identity, command, document or software release from a convincing forgery.

The quantum threat is not only about decryption

Most discussions of quantum-related cybersecurity begin with Harvest Now, Decrypt Later, or HNDL.

Under this scenario, an adversary captures encrypted communications or databases today, even though the information cannot currently be read. The attacker stores the material until a cryptographically relevant quantum computer becomes available and then attempts to break the public-key protection surrounding it.

HNDL primarily threatens confidentiality. It is particularly relevant to information that must remain secret for many years, including national-security material, health records, intellectual property, financial information and long-term commercial plans.

But confidentiality represents only one side of the problem.

An emerging industry expression, Trust Now, Forge Later, or TNFL, focuses on risks to integrity and authenticity. Instead of asking whether an attacker could eventually read a protected message, it asks whether the attacker could create a new message, signature, certificate or software package that a legacy system would accept as genuine.

Cisco describes TNFL as the possibility that digital signatures trusted today could be forged once sufficiently capable quantum computers become available. It connects the threat to code signing, device identity, secure boot, software verification and hardware roots of trust.

TNFL should currently be understood as an emerging industry shorthand rather than a formally standardized NIST threat category. Nevertheless, it provides a useful way to explain the signature and identity side of quantum risk.

What does “forge later” actually mean?

A digital signature is not simply a visual signature placed on a document. It is a mathematical value generated using the signer’s private key and verified using a corresponding public key.

Many present-day systems rely on RSA or elliptic-curve cryptography for digital signatures, authentication and key establishment. If a future quantum computer could solve the mathematical problems underlying these systems, an adversary might be able to derive a private key from publicly available information and generate new signatures that pass verification under a legacy trust system.

TNFL does not necessarily mean that an attacker can invisibly alter a correctly archived historical signature. More precisely, it describes the possibility of creating fraudulent artifacts that appear to have been authorized by a trusted person, organization or device, especially if old keys, certificates and algorithms remain accepted.

Potential consequences include the following.

Forged software and firmware updates

An attacker could distribute malware or ransomware inside a package that appears to carry a valid signature from a trusted developer. Users and devices might install it without producing the warnings normally associated with unsigned software.

Forged device identities

IoT devices, industrial systems, vehicles, medical equipment and telecommunications infrastructure frequently use digital certificates to authenticate devices. If that identity layer can be forged, a malicious device could impersonate one that the organization already trusts.

Fraudulent machine-to-machine commands

APIs, cloud workloads, payment systems and operational platforms often rely on signed requests, tokens or messages. A forged signature could make an unauthorized command appear legitimate.

Compromised software supply chains

Code-signing systems sit at the center of modern software distribution. If an attacker can impersonate a trusted vendor, malicious updates could be delivered through channels that users and enterprises have been trained to trust.

Long-term uncertainty around digital evidence

Contracts, audit records, financial instructions and other signed artifacts may need to remain verifiable for decades. Organizations must consider whether those records will still provide defensible evidence after their original cryptographic algorithms are no longer considered secure.

In other words, protecting the content of a message is not sufficient if a system can no longer determine who sent it, whether it was modified or whether the approving identity was genuine.

AI is not directly accelerating the arrival of quantum computers, but it is accelerating cyber operations

Another issue raised during the event was the role of artificial intelligence in cybersecurity, including the use of language models to review code, identify vulnerabilities, support tool development and improve the efficiency of cyber operations.

The distinction is important.

Current AI systems do not remove the need for the quantum hardware required to attack large real-world RSA or elliptic-curve systems. An LLM cannot simply replace a cryptographically relevant quantum computer.

AI can, however, make many existing cyber activities faster, cheaper and more scalable.

The United Kingdom’s National Cyber Security Centre assesses that AI will make elements of cyber intrusion more effective and efficient, including reconnaissance, vulnerability research, exploit development, social engineering and the processing of stolen data. The NCSC identifies AI-assisted vulnerability research and exploit development as one of the most significant near-term changes to the cyber threat landscape.

Frontier-model red teaming is therefore important on the defensive side. It tests what advanced models can do, where safeguards may fail and how models might affect cybersecurity, national security and autonomous operations.

The relationship between AI and quantum risk is not that AI is already breaking major public-key systems. The more immediate concern is that AI is shortening the time between vulnerability discovery and exploitation while organizations face a cryptographic migration that may take many years to complete.

Do not wait for 2030

The years 2030 and 2035 frequently appear in quantum-readiness discussions. They should not be interpreted as precise forecasts for the arrival of a quantum computer capable of breaking today’s cryptography.

They are primarily risk-management and migration milestones.

In August 2024, the US National Institute of Standards and Technology finalized its first principal post-quantum cryptography standards:

FIPS 203, ML-KEM, a key-encapsulation mechanism for establishing shared secrets FIPS 204, ML-DSA, a post-quantum digital-signature standard FIPS 205, SLH-DSA, a hash-based digital-signature standard using a different mathematical approach

NIST has urged organizations to begin adopting the standards because updating products, services, protocols and infrastructure will require substantial time and coordination.

NIST’s transition framework aims to deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with higher-risk systems expected to transition sooner.

A recent development also illustrates why organizations should rely on openly evaluated standards rather than adopting untested algorithms solely because they are marketed as quantum-safe. On 28 July 2026, NIST reported that HAWK, a digital-signature candidate under consideration, had been withdrawn after an AI model helped identify a vulnerability. NIST stated that the issue did not affect its finalized standards, including ML-KEM and ML-DSA.

The incident does not demonstrate that post-quantum cryptography as a whole is insecure. Instead, it demonstrates the value of open evaluation, independent testing and algorithm diversity before deployment.

The United States has turned migration into an organizational obligation

The US approach shows that post-quantum migration is not being treated as a project owned only by an IT department.

OMB Memorandum M-23-02, issued under the framework of National Security Memorandum 10, directed federal agencies to inventory active cryptographic systems. The requirements prioritize high-value assets, high-impact systems and technologies used for key establishment, encrypted connections and digital signatures. The memorandum also required agencies to designate a cryptographic inventory and migration lead.

In June 2026, OMB issued M-26-15, requiring agencies to prepare PQC migration plans within 120 days. The memorandum describes a phased, multi-year effort, beginning with governance, discovery and inventory in 2026–2027, followed by pilots and early migration in 2027–2028, prioritized migration in 2028–2030 and risk-based migration of remaining systems toward 2035.

It also calls for a dynamic and continuously updated understanding of cryptographic assets. Where possible, agencies are encouraged to automate discovery and populate a central Cryptographic Bill of Materials, or CBOM, covering algorithms, protocols, keys and cryptographic dependencies.

Where should an organization begin? 1. Establish accountable governance

PQC migration should not be left to a small security or infrastructure team. It requires accountable executive ownership and participation from legal, procurement, risk, product, engineering and business-system owners.

Organizations should define who can approve architectural changes, how funding will be allocated and which risk criteria determine migration priorities.

2. Build a living cryptographic inventory

An organization must know where cryptography is being used before it can replace it.

The inventory should cover more than a list of algorithms. It should include:

Algorithms and key sizes Certificates and public-key infrastructure TLS, VPN and SSH deployments Code signing and firmware signing API tokens and authentication mechanisms Hardware security modules and key-management services IoT, operational-technology and embedded systems Third-party software and cloud services Data and signed records requiring long-term protection

The inventory should be continuously maintained because certificates, software dependencies and cloud services change over time.

3. Assess both data lifetime and trust lifetime

Prioritization should consider how long information must remain confidential, but it should also ask how long an identity, signature, device or record must remain trustworthy.

Industrial firmware may remain in use for a decade. Legal documents may need to be authenticated for much longer. A hardware root of trust may be difficult or impossible to replace after a device has been deployed.

These assets can carry TNFL-related risk even when they do not store large volumes of confidential information.

4. Use evaluated standards

Moving to PQC does not mean installing the first product described as quantum-safe.

Organizations should refer to standards such as FIPS 203, FIPS 204 and FIPS 205, alongside sector-specific regulatory guidance.

Where full native support is not yet available, some organizations may test hybrid approaches that combine classical and post-quantum mechanisms. These deployments must still be assessed for interoperability, performance, downgrade resistance and key-management complexity.

5. Design for cryptographic agility

Cryptographic agility is the ability to change algorithms, certificates, key types or cryptographic providers without rebuilding an entire business system.

A crypto-agile architecture separates cryptography from business logic, supports configurable cipher suites, uses adaptable key-management infrastructure and avoids permanently embedding a single algorithm into software or hardware that cannot be updated.

The objective is not to select an algorithm that will remain secure forever. It is to ensure that the organization can change course quickly when another transition becomes necessary.

6. Engage the supply chain now

Most organizations do not control every cryptographic component they use. They rely on cloud providers, operating systems, networking equipment, payment platforms, hardware manufacturers and third-party software.

PQC readiness should therefore become part of procurement and contract renewal. Organizations should ask vendors:

Which PQC algorithms will the product support? Can firmware-signing and hardware roots of trust be updated? What is the vendor’s migration timeline? Can the product export cryptographic inventory or CBOM information? Will it remain supported throughout the migration period? From organizational readiness to Thailand’s digital trust infrastructure

The launch of Quantum Club Thailand signals growing coordination around quantum research, skills, industrial experimentation and innovation. Its announced activities include Quantum Academy Thailand, Quantum Industry Lab and the Quantum Innovation Challenge.

The next opportunity is to expand the national discussion beyond what Thailand may be able to compute with quantum technology and ask how the country will protect the digital infrastructure it already depends on.

Possible starting points include national guidance for cryptographic inventories, training in post-quantum cryptography and cryptographic engineering, industry testbeds, procurement requirements for crypto-agile systems and migration planning for critical infrastructure.

A large-scale quantum attack on present-day public-key cryptography may not be visible today. Yet organizations are already buying systems, signing long-term contracts and deploying devices that could remain operational for five, ten or twenty years.

The most important question is therefore not simply when a cryptographically relevant quantum computer will arrive.

It is whether, when that moment comes, our systems will still be able to establish which software came from a genuine developer, which device is authentic and which digital information deserves to be trusted.