Your Guide to Understand Trust Now Forge Later Attack: Enterprise PQC Guidance

In the current rush to secure the quantum era, most attention goes to the confidentiality threat: adversaries stealing encrypted data today to decrypt it once quantum computers are powerful enough. That threat is real. But there is a second, arguably more dangerous quantum threat operating in the background of every Public Key Infrastructure (PKI) deployment today. It is called Trust Now, Forge Later (TNFL), and it attacks not the confidentiality of your data but the integrity of your identity. When a cryptographically relevant quantum computer (CRQC) arrives, any RSA or ECDSA public key that is currently publicly available can be used to derive the corresponding private key, enabling an attacker to forge signatures backdated to any point in the past. The recommended action: build a complete cryptographic inventory of all signing keys now, prioritize Root CA and code-signing keys for earliest migration to NIST-finalized quantum-resistant signature algorithms (FIPS 204 ML-DSA, FIPS 205 SLH-DSA), and implement shorter certificate lifetimes to limit the useful window of each captured key. For the complementary confidentiality threat, see Harvest Now, Decrypt Later: Preparing for the Quantum Threat. For the cryptographic discovery methodology that underpins both defenses, see You Can’t Secure What You Can’t See.

Quick Answer: What Is Trust Now, Forge Later?

Trust Now, Forge Later (TNFL) is a quantum-era attack in which an adversary collects publicly available RSA or ECDSA public keys and digital signatures today, waits until a quantum computer running Shor’s algorithm can derive the corresponding private key, and then forges backdated signatures that are mathematically indistinguishable from those produced by the original key holder. TNFL requires no present-day active interception, because public keys are already embedded in every TLS certificate, every code-signing certificate, every firmware validation chain, and every root CA trust store. The attack collapses non-repudiation: once an attacker holds the private key, neither you nor any verification system can prove you did not produce a forged signature. TNFL is distinct from HNDL in that it attacks integrity and non-repudiation rather than confidentiality, and it requires zero collection effort today.

The Core Logic of Trust Now, Forge Later

Right now, we use RSA and ECC to sign everything, from digital signatures to software updates. These signatures are mathematically infeasible to forge today. But a cryptographically relevant quantum computer changes that calculus entirely. An adversary can take a public key that exists today, run Shor’s Algorithm against it, and derive the corresponding private key. Once they hold that private key, they do not just own a current identity; they own every signature that key ever produced, and they can produce new signatures indistinguishable from any that the original key holder could have produced, including backdated ones.

When an attacker captures a public key or a signed artifact today, they are banking a frozen identity. The reason this is so dangerous is that it causes a total collapse of non-repudiation: the principle that if a signature is valid, the signer cannot deny producing it. When signatures can be forged with perfect mathematical validity, you can no longer prove you did not sign something. That is the liability catastrophe at the heart of TNFL.

Step-by-Step Mechanism: How the Forge Happens

Unlike HNDL, which requires an adversary to actively intercept and store massive amounts of encrypted traffic today, TNFL requires zero effort in the present. Here is the step-by-step procedure for how this attack unfolds over time.

Phase 1: The Trust (Happening Right Now)

Public keys are not secrets; they are intended to be globally available. Every TLS certificate, every code-signing certificate, every firmware validation chain, and every root certificate embedded in operating systems contains public key material. An attacker simply needs to record these public keys today. RSA relies on the difficulty of factoring large numbers, while ECC relies on the elliptic curve discrete logarithm problem. In both cases, the public key is mathematically linked to the private key. All the information needed to derive the private key is there, just locked behind a calculation that would take classical computers an infeasible amount of time to solve. A quantum computer running Shor’s algorithm removes that lock.

Phase 2: The Quantum Calculation

Once a Cryptographically Relevant Quantum Computer (CRQC) becomes available, an attacker runs Shor’s Algorithm against a captured RSA or ECC public key to derive the corresponding private key. At this point, the attacker holds a perfect copy of the original signer’s digital identity as it existed when the key was created. They inherit the full authority of the original owner, including the ability to produce new signatures that no verification system can distinguish from those produced by the legitimate key holder.

Phase 3: The Identity Hijack

With a derived private key in hand, the attacker can generate mathematically perfect signatures and backdate them to any point the key was valid. They create a malicious firmware component or a fraudulent contract, timestamp it to the original signing period, and produce a signature using the actual private key. The resulting digital signature is cryptographically indistinguishable from one produced by the legitimate key holder at that time. From a verification perspective, it is the perfect crime: the signature checks out against the known public key, the timestamp falls within the certificate validity period, and the certificate chain validates correctly.

Phase 4: The Collapse of Non-Repudiation

In our legal and technical systems, we rely on non-repudiation: the principle that if a signature is valid, the signer cannot deny producing it. TNFL destroys this principle. A consumer or device receives a signed shutdown command, a signed software update, or a signed contract. It verifies the signature, confirms it is from the trusted entity, and complies. The system has no mechanism to distinguish a forged signature from an authentic one, because the forged signature is cryptographically identical to an authentic one.

Why Is This a Liability Catastrophe?

An attacker with a derived private key can forge a digital loan agreement or a massive bank transfer, backdate it to five years prior, and sign it with the original private key. The signature checks out. The certificate chain validates. The timestamp falls within the original validity period. How do you prove in court that you did not sign it when every technical verification system confirms that you did? When signatures can be forged, the cryptographic proof of your innocence or intent is gone. The following are the three major target categories for TNFL, ordered by operational blast radius.

1. Code Signing and Firmware: The Supply Chain Threat

This is the most dangerous operational TNFL threat because it bypasses all perimeter defenses. Most servers, devices, and operational technology systems are designed to accept software and firmware updates only if they are signed with a trusted manufacturer’s key. If an attacker derives a manufacturer’s 2026 RSA code-signing key in 2035 and backdates a malicious firmware update to fall within the original certificate’s validity period, every device that trusts that key installs the malware. To the device, the update is 100% authentic: it carries the verified signature, the certificate chain validates, and the timestamp is in range. The manufacturer cannot revoke a key that has already been compromised quantum-computationally; revocation only stops future trust decisions, not the verification of signatures that appear historically valid. For how Encryption Consulting helps protect code signing keys, see CodeSign Secure.

2. Root Certificate Authority: The Trust Hierarchy Threat

The trust model of the internet rests on Certificate Authorities (CAs). If a Root CA private key is derived quantum-computationally, the attacker can issue fully trusted certificates for any domain, forge CRLs or OCSP responses to make revoked certificates appear valid or to revoke legitimate certificates, and create new intermediate CAs with their own issuance authority. The entire trust hierarchy collapses. The forgery is mathematically perfect: even the CA itself could not prove it did not issue a given certificate. Every system that trusts that Root CA, including browsers, operating systems, and enterprise applications, accepts the attacker’s forged infrastructure as legitimate. For PKI management that supports the migration to quantum-resistant trust anchors, see PKI-as-a-Service.

3. Financial and Legal Records: The Non-Repudiation Threat

Digital signatures on contracts, regulatory filings, financial transaction records, and long-term archival documents are often required to remain verifiable for decades. Legal frameworks accept a valid cryptographic signature as proof of authenticity and intent. If RSA or ECC signatures on these records can be forged and backdated once a quantum computer exists, the non-repudiation foundation of digital legal records collapses. An attacker reconstructing an old private key can produce a forged signature that appears to have been created years earlier, and validation engines checking mathematical correctness, certificate chain validity, and revocation status at the claimed signing time will confirm the forgery as legitimate.

Difference Between TNFL and HNDL

Both Harvest Now, Decrypt Later (HNDL) and Trust Now, Forge Later (TNFL) are quantum-era threat models, but they attack different security properties, use different mechanisms, and produce different long-term consequences. Understanding both is essential for a complete PQC risk assessment.

Factor	HNDL	TNFL
Attack	Capture encrypted data today and decrypt it when a quantum computer can break the classical key exchange algorithm	Collect public keys and signatures today; forge backdated signatures when a quantum computer derives the private key
Primary Security Property Affected	Confidentiality	Integrity, Authenticity, Non-Repudiation
Cryptographic Primitive Targeted	Key Exchange (RSA key transport, ECDH, DH)	Digital Signatures (RSA, ECDSA)
Present-Day Collection Required?	Yes: if traffic is not captured now, it cannot be decrypted later	No: public keys are already permanently available everywhere
What Breaks Technically?	Session confidentiality; past encrypted sessions become readable	Signature integrity and identity trust; signed artifacts become unforgeable
Effect on TLS	Past encrypted sessions become readable	Certificates and trust chains can be forged
Effect on PKI	Confidential communications exposed	CA private keys are derivable; complete PKI hierarchy compromise
Primary NIST Remedy	FIPS 203 ML-KEM (key encapsulation)	FIPS 204 ML-DSA, FIPS 205 SLH-DSA (quantum-resistant signatures)

Your Checklist to Mitigate TNFL

Mitigating TNFL requires a different strategy than traditional data protection. Because TNFL attacks integrity rather than confidentiality, the goal is not just to hide data but to ensure that your proof of authenticity remains unbreakable for decades. The following checklist provides a structured path from immediate visibility to long-term quantum resilience.

• Perform cryptographic discovery and inventory; map all signing keys including Root and Issuing CA private keys, private keys used to sign software, firmware, and patches, shadow and wildcard certificates, code-signing keys used in CI/CD pipelines, and Timestamping Authority (TSA) keys. Use CBOM Secure for automated discovery across all environments
• Identify legacy and embedded devices that are hardcoded to use RSA or ECC signing and cannot receive remote updates; plan hardware refresh timelines for these environments
• Store all signing keys in FIPS 140-3 validated HSMs; confirm your HSM vendor’s firmware roadmap for ML-DSA and SLH-DSA support; plan re-validation timelines for FIPS 140-3 certification of PQC algorithms
• Move from 1 to 2 year code-signing certificates to 90-day or shorter cycles; shorter lifetimes reduce the useful window of each captured public key for TNFL attackers
• Define hybrid signature architecture: run classical signature (RSA or ECDSA) and a PQC signature (ML-DSA or SLH-DSA) in parallel during the transition period to maintain backward compatibility while providing forward security
• Design a new PQC-ready root hierarchy; run classical and PQC root CAs in parallel during transition; distribute new PQC trust anchors via GPO, MDM, and OS images before decommissioning classical roots
• Include TSA keys in the PQC migration roadmap; PQC-ready timestamping is essential to prevent attackers from combining forged signatures with compromised timestamp chains to fabricate historically valid audit evidence
• Migrate to PKI-as-a-Service (PKIaaS) or a cloud-native CA that supports PQC algorithms natively, eliminating the manual certificate lifecycle management that slows emergency response
• For legacy OT/ICS environments that cannot be patched, deploy a verification gateway that can validate PQC signatures on behalf of devices that cannot run PQC signature verification natively
• Implement abstraction layers or a CLM tool so that algorithm migration (from RSA to ML-DSA) requires a configuration change rather than application rewrite
• Eliminate manual certificate management; automate the entire signing fleet so that emergency re-signing in response to a key compromise can be executed in hours rather than months
• Validate HSM firmware PQC and hybrid support roadmap with your HSM vendor; get written confirmation of ML-DSA and SLH-DSA support timelines
• Benchmark signature throughput with larger PQC algorithms; ML-DSA produces larger signatures than ECDSA and signature verification performance must be tested across all validation endpoints
• Update key ceremony procedures to include PQC key generation, storage, and backup; validate backup and restore procedures for new key types
• Update Certificate Policy (CP) and Certification Practice Statement (CPS) operational documentation to reflect hybrid and PQC signing architecture

TNFL Risk and Mitigation: PKI-Centric View

Mitigating the TNFL threat requires a shift in how organizations manage the shelf-life of trust. Unlike confidentiality threats that can be addressed with encryption at rest, TNFL attacks authority: if a root key or code-signing key is compromised quantum-computationally in ten years, an attacker can backdate signatures to today, and current systems will have no technical mechanism to distinguish the forgery from the real thing. This table acts as a vulnerability map across all major PKI trust domains.

PKI Trust Domain	TNFL Impact	Why It Is High Risk	Practical Mitigation Focus
Trust Anchors (Root CAs and Trust Stores)	Derivation of the root private key enables an attacker to issue fully trusted certificate chains, creating fake identities or signing malicious infrastructure that validates as legitimate	Roots are long-lived and broadly trusted; compromise is systemic across every relying party	Build a parallel PQC-ready root hierarchy; distribute trust anchors early via GPO, MDM, and OS images; plan a root rollover; shorten the trust horizon for new roots
Issuing (Intermediate) CAs	Compromising the issuing CA key enables mass issuance of forged end-entity certificates, allowing impersonation of services, users, or devices at scale	Issuing CAs sign everything; compromise impacts many endpoints simultaneously	HSM-backed CA keys, tighter CA lifetimes, staged CA replacement, hybrid issuance policy for long-survival certificates
Code Signing	Attackers reconstruct code-signing keys and sign malware or tampered software updates that appear vendor-authentic and pass all signature validation checks	TNFL enables legitimate-appearing malicious updates with a large operational blast radius affecting all devices trusting that key	HSM-protected signing keys, dual and hybrid signing, enforce signing validation in CI/CD, provenance controls including SBOM and policy gates
Firmware and Secure Boot Signing	Forged firmware images signed with derived vendor keys are accepted by devices, bypassing secure boot and installing persistent malicious code	Often non-upgradeable validators mean forged signatures can persist for the device’s full operational life	Dual-sign firmware where possible; plan hardware refreshes for hardcoded RSA and ECC environments; add verification gateways with stronger validation for legacy devices
Revocation (OCSP and CRL)	Forged OCSP responses or CRLs falsely indicate revoked certificates are valid, or invalidate legitimate certificates, undermining all trust decisions based on revocation status	If revocation artifacts are forgeable, the fundamental question of whether a certificate is currently valid cannot be answered reliably	Align revocation signing keys with new PQC hierarchy, enforce strict OCSP signing controls, monitoring, and OCSP stapling validation tests
Timestamping and Long-Term Validation	Backdated forged signatures combined with compromised timestamp chains make malicious artifacts appear historically valid and legally authentic	TNFL is amplified by weak timestamp chains; legal and audit impacts are severe and may not be discovered for years	PQC-ready timestamp strategy, re-timestamp long-lived records with new PQC-secured TSA, design LTV (Long-Term Validation) so archival proof does not collapse when classical algorithms are deprecated
Enrollment Infrastructure	Rogue certificate requests approved or forged under compromised CA keys, enabling unauthorized identity issuance that appears cryptographically valid	Catastrophic when all signatures from the enrollment CA become unforgeable and enrollment approvals cannot be proven authentic	Harden enrollment identity, automate approvals with policy-based template restrictions, enforce audit trails, CLM enforcement for all issued certificates
Validation Endpoints and Applications	Applications accept forged certificate chains due to trust anchor compromise, making malicious services indistinguishable from legitimate ones	If validators cannot parse new PQC profiles and OIDs, migration away from classical trust fails silently	Crypto-agility testing across all validation endpoints, trust store update capability testing, certificate chain and path building tests for PQC profiles, size and latency testing for larger PQC signatures

How Can Encryption Consulting Help?

If you are wondering where and how to begin your post-quantum journey, Encryption Consulting is here to support you. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise.

Cryptographic Discovery and Inventory

This is the foundational phase where we build visibility into your existing cryptographic infrastructure. We identify which signing keys and certificate hierarchies are at risk from quantum threats and assess how ready your current setup is, including your PKI, Hardware Security Modules (HSMs), and applications. The result is a comprehensive cryptographic inventory, including all signing keys by algorithm, key size, HSM binding, and certificate lifecycle status, that forms the baseline for your TNFL mitigation roadmap.

PQC Assessment

Once visibility is established, we assess the cryptographic landscape for quantum vulnerability. For TNFL-specific risk, this includes identifying all RSA and ECDSA signing keys and their associated certificates and trust hierarchies, assessing HSM firmware support for ML-DSA and SLH-DSA, reviewing CI/CD pipelines for code-signing key exposure, and evaluating timestamping authority architecture. We deliver a detailed report with an inventory of vulnerable signing assets, risk severity ratings, and TNFL-specific prioritization for migration.

PQC Strategy and Roadmap

With risks identified, we develop a custom, phased migration strategy aligned with your business, technical, and regulatory requirements. For TNFL mitigation, this includes a hybrid signature architecture plan, a new PQC root hierarchy design, a trust anchor distribution strategy, a certificate lifetime reduction plan, and a long-term validation (LTV) design for archival records. We align the roadmap with NIST FIPS 204 and 205 and CNSA 2.0 deadlines.

Vendor Evaluation and Proof of Concept

We help you identify and test the tools and platforms that can support your post-quantum signing goals, including HSM vendors with validated PQC firmware support, CA platforms supporting ML-DSA issuance, timestamping services with PQC support, and CLM platforms that support hybrid certificate management. We run PoC tests in isolated environments and deliver a vendor comparison report.

Pilot Testing, Scaling, and Implementation

Before full implementation, we validate hybrid signing, PQC certificate issuance, and trust anchor distribution in a controlled environment. We test for signature size impacts on network bandwidth and validation performance, interoperability with legacy systems that cannot yet verify PQC signatures, and the accuracy of automated re-signing in emergency scenarios. Once testing is complete, we support a smooth, scalable rollout.

Reach out to us at [email protected] and let us build a customized roadmap that aligns with your organization’s specific needs.

Conclusion

While the industry has long focused on the HNDL threat to confidentiality, TNFL reveals an even more existential risk: the potential for a total collapse of digital identity and non-repudiation. If organizations do not inventory their cryptographic signing assets and transition to quantum-resistant signatures before a CRQC arrives, they face a future where history itself can be rewritten with perfect cryptographic validity, and the digital signature is no longer under the control of the party that originally held the key. Securing the future does not just mean hiding data today; it means hardening authority for tomorrow. The standards are finalized: FIPS 204 ML-DSA and FIPS 205 SLH-DSA provide the quantum-resistant signature algorithms needed to address TNFL. The work is to discover what signing keys you have, migrate the highest-risk ones first, and design your PKI hierarchy and certificate lifecycles to minimize the TNFL attack surface before the quantum window opens. For the cryptographic discovery foundation, see You Can’t Secure What You Can’t See. For the CBOM inventory that structures the findings, see Why a CBOM Is Essential Now More Than Ever. For the complete PQC migration framework, see PQC Advisory Services.

Frequently Asked Questions

What is a Trust Now, Forge Later (TNFL) attack?

Trust Now, Forge Later (TNFL) is a quantum-era threat model in which an adversary collects public keys and digital signatures today, waits until a quantum computer running Shor’s algorithm can derive the corresponding private key, and then forges backdated signatures that are mathematically indistinguishable from those produced by the original key holder. TNFL requires no present-day active interception because public keys are already globally available in TLS certificates, code-signing certificates, firmware validation chains, and root CA trust stores.

How is TNFL different from Harvest Now, Decrypt Later (HNDL)?

HNDL attacks confidentiality: an adversary intercepts and stores encrypted data today, then decrypts it once a quantum computer can break the key exchange algorithm. TNFL attacks integrity and non-repudiation: an adversary collects public keys today, derives private keys quantum-computationally later, and forges signatures backdated to the present. HNDL requires active interception today. TNFL requires no collection effort because the public keys are already permanently and publicly available.

Which systems are most vulnerable to TNFL attacks?

The three highest-risk categories are: code signing and firmware validation (devices accept updates only if signed by a trusted key; a derived private key enables malicious firmware that appears completely authentic); Root Certificate Authorities (a compromised Root CA private key allows forging trusted certificates for any domain and collapsing the entire trust hierarchy); and long-lived financial and legal records (digital signatures required to remain verifiable for decades become forgeable, collapsing the non-repudiation foundation of digital legal records).

What is the most important first step for mitigating TNFL risk?

The most important first step is a comprehensive cryptographic discovery and inventory that specifically maps all signing keys: Root CA and issuing CA private keys, code-signing keys, firmware signing keys, timestamping authority keys, and shadow or wildcard certificates. A CBOM (Cryptography Bill of Materials) structures this inventory in machine-readable form and supports ongoing governance.

What algorithms replace RSA and ECDSA for signatures in a TNFL-resistant system?

NIST finalized three quantum-resistant signature algorithms in August 2024: FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) as the primary replacement for RSA and ECDSA signatures; FIPS 205 (SLH-DSA, derived from SPHINCS+) as a hash-based alternative; and FIPS 206 (FN-DSA based on FALCON) still being finalized. For the highest-value, longest-lived signing keys, a hybrid strategy combining a classical signature with ML-DSA or SLH-DSA is recommended during the transition period.

Why does TNFL make certificate lifetimes a critical mitigation factor?

Shorter certificate lifetimes limit the window during which a captured public key remains useful to a TNFL attacker. A 90-day certificate that has already expired at the time a quantum computer derives its private key provides no signing advantage to the attacker. Longer-lived certificates, including multi-year code-signing certificates and Root CA certificates with 20-year lifetimes, are the highest-priority TNFL mitigation targets. Reducing certificate lifetimes directly shrinks the TNFL attack surface per key.