TNFL: the quantum threat that targets digital trust

Author : Arnaud DUFOURNET, Marketing & CX Director

The quantum threat that currently gets the most attention is HNDL (Harvest Now, Decrypt Later). Its principle is simple: attackers intercept encrypted data today, store it, and wait for a quantum computer capable of breaking current algorithms to reveal its contents.

But this view is actually incomplete. The most insidious threat does not only target data confidentiality: it also targets integrity, authenticity and non-repudiation. This is where TNFL, Trust Now, Forge Later, comes in.

What is TNFL?

TNFL refers to a scenario in which an attacker eventually harnesses the power of a quantum computer to forge valid digital signatures from public keys or signatures collected today.

Unlike HNDL, TNFL does not rely on the mass interception of secrets. It strikes at the heart of the digital trust model: electronic signatures, TLS certificates, code signatures, root certificates, software artifacts, and signed legal or financial documents.

In other words, HNDL breaks secrecy. TNFL breaks trust.

How does TNFL work?

The TNFL scenario can be summarized in four steps.

1. Collect trust elements today.

Attackers do not need to steal a private key right away. They can simply retain public certificates, legitimate signatures, certificate chains or signed artifacts. These elements are publicly accessible or circulate in production systems, software repositories, endpoints, firmware and archives.

2. Wait for quantum capability

Once quantum computers become powerful enough, some classical asymmetric algorithms such as RSA and ECC will become vulnerable. In the feared scenario, Shor’s algorithm will then make it possible to recover a private key from its corresponding public key.

3. Forge a credible digital identity

With the recovered private key, the attacker can sign fake documents, fake software updates, fake certificates or fake messages while impersonating a legitimate entity. The problem is not just technical fraud: it is the ability to rewrite the cryptographic past.

4. Destroy non-repudiation

This is where TNFL becomes particularly serious. If a forged signature is cryptographically valid, it becomes very difficult to prove technically that it is fraudulent. In some contexts, the victim (a company or an individual) may lose the ability to demonstrate that they were not behind the signed action.

Why is TNFL so concerning?

TNFL does not only threaten files or communications. It threatens the very mechanisms that allow digital systems to trust a source, a piece of software or a document.

The consequences could be major in three areas.

• The software supply chain: a malicious update could be signed as if it came from a legitimate vendor, and therefore be installed without suspicion by production systems.
• Certificate authorities: if a root key or a subordinate CA were compromised retroactively, an attacker could issue perfectly valid fake certificates for any website or create fake subordinate CAs. An entire portion of the TLS trust ecosystem could be weakened.
• Legal and financial documents: a contract, a payment order or a regulatory approval could be falsified with an appearance of authenticity that would be hard to challenge.

The risk is therefore not only technical. It is also legal, operational and reputational.

How to protect yourself

TNFL does not just break an algorithm: it calls into question the long-term reliability of signatures. In critical environments, a signature does more than prove the origin of a document; it underpins a chain of accountability. If that chain can be rebuilt or imitated after the fact, digital trust becomes vulnerable to retrospective forgery. This is why TNFL is described as a crisis of digital authenticity as much as a cryptographic threat.

Given what is at stake, the response cannot be limited to “going quantum later”. We must start rethinking the lifetime of digital trust, key rotation and cryptographic agility now.

1. Map your cryptographic asset

The first priority is to build an accurate inventory of every cryptographic use: certificates, signing keys, libraries, algorithms, embedded systems and software dependencies. A CBOM (Cryptographic Bill of Materials) approach helps identify where the weak points lie.

The goal is simple: know where RSA, ECC and legacy mechanisms are used, and measure their exposure over time.

2. Shorten certificate lifetimes

The longer a key or certificate remains valid, the greater its historical value to a future attacker. Shortening lifecycles limits this window of risk.

In practice, this means drastically shortening validity periods, automating renewal and removing outdated certificates as soon as possible. The idea is to minimize the time during which a signed artifact can later be used against you.

In this spirit, in April 2025 the CA/Browser Forum¹ approved a drastic reduction in the lifetime of public TLS certificates according to a very precise schedule:

• Before March 2026: the maximum lifetime is 398 days (~13 months).
• From March 15, 2026 final reduction to 47 days (with domain validation reuse limited to 10 days).
• From March 15, 2027: reduced to 100 days.
• From March 15, 2029: final reduction to 47 days (with domain validation reuse limited to 10 days).

3. Prepare the migration to PQC

Post-quantum cryptography must be built into the roadmap now. NIST’s standards for post-quantum signatures, such as ML-DSA, provide a solid foundation for anticipating the transition.

In many cases, a hybrid strategy makes sense: it combines a classical algorithm with a post-quantum algorithm to maintain compatibility while protecting against forgery attempts. This is often the best approach during the migration phase.

4. Build cryptographic agility

The mistake would be to have to rewrite all the code every time an algorithm changes. Organizations must rely on unified crypto interfaces and certificate lifecycle management (CLM) tools that make it possible to replace one algorithm with another through a simple configuration change. In the event of a quantum technological breakthrough, a company must be able to re-sign its entire infrastructure in a matter of hours, not months.

HNDL threatens what we want to hide. TNFL threatens what we want to prove.

Continuing to sign our critical digital assets with classical asymmetric keys means handing our identities, certificates and proofs of authenticity over to the cybercriminals of the quantum era. The TNFL threat is not fiction: it is already a matter of governance, architecture and operational security. At its core lies the preservation of digital trust.

---

¹The CA/Browser Forum (or CA/B Forum) is an international non-profit organization that brings together:

• Web browser and operating system vendors: the companies that develop the software that verifies these certificates (e.g. Google/Chrome, Apple/Safari, Mozilla/Firefox, Microsoft).
• Certificate Authorities (CAs): the organizations that issue digital certificates (e.g. DigiCert, Let’s Encrypt, Sectigo).