In the current rush to secure the “Quantum Era,” we have prioritized confidentiality. We talk about Harvest Now, Decrypt Later (HNDL), the idea that adversaries are stealing encrypted data today to read it once quantum computers are powerful enough. But there is a second, arguably more dangerous threat looming in the shadows of Public Key Cryptography, Trust Now, Forge Later (TNFL).
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 “impossible” to forge today. But a quantum computer advances cryptography. Adversaries can take a public signature you made today, run it through a quantum algorithm (like Shor’s), and work backward until they have your private key.
Once they have that key, they do not just own your current identity; they own your history. They can sign documents, generate malware, or execute fraudulent transactions and backdate them to 2025 or later. Because the private key checks out, the system has no choice but to trust it.
When an attacker captures a signature or a Public Key and a Digital Signature today, they are essentially banking a “frozen” identity. The reason this is so dangerous is that it causes a total collapse of non-repudiation. It means you can no longer prove you didn’t do something.
Step-by-Step Mechanism of How the Forge Happens
Unlike confidentiality attacks (HNDL), which require an adversary to actively intercept and store massive amounts of data 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 “bookmark” 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, your public key is mathematically linked to your private key. All the information needed to derive the private key is there, just “locked” behind a calculation that would take classical computers trillions of years to solve.
Phase 2: The Quantum Calculation
Once a Cryptographically Relevant Quantum Computer (CRQC) is in action, an attacker can run Shor’s Algorithm against a captured RSA/ECC public key to derive the corresponding private key. At this point, the attacker has a “perfect” copy of your 2024 digital identity. At that moment, the attacker doesn’t just “break” the system; they inherit the full authority of the original owner.
Phase 3: The Identity Hijack
Once a private key is derived, the attacker can generate mathematically perfect signatures. This is where the nightmare starts. With that private key, the attacker can now generate a new signature. They create a malicious firmware component or a fraudulent contract and timestamp it to 2024. This is the perfect crime because they are using the actual private key; the resulting digital signature is cryptographically indistinguishable from one you made ten years ago.
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, you cannot deny that you signed it. This is the “cliff” where trust disappears. For instance, a user or consumer of the certificate receives a “signed” shutdown command. It checks the signature, sees it’s from the “trusted manufacturer,” and shuts down. The system has no way to know it’s a forgery.
Can you imagine the chaos? Anyone can hold anyone liable for anything.
Why is This a Liability Apocalypse?
An attacker could forge a digital loan agreement or a massive bank transfer, backdate it five years, and sign it with the original private key. How do you prove in court that you didn’t sign it when the signature checks out against your 2024 key?
When signatures can be forged, the “proof” of your innocence or intent is gone. The following are the major targets for TNFL:
1. Code Signing & Firmware: The Supply Chain Threat
This is the most dangerous operational threat because it bypasses all your perimeter defenses. Most systems, servers, and devices are designed to accept software updates only if they are signed with a trusted manufacturer’s key. If a hacker cracks a manufacturer’s 2024 RSA key in 2035, they can backdate it and sign a malicious “emergency update”. To the system, that malware looks 100% authentic. It has the “authenticated” signature, so the hardware installs it.
The manufacturer has no way to verify that the update didn’t originate from the source. The manufacturer is held liable for a “bug” or “attack” that they never actually sent.
2. Root Certificate Authority
The “green lock” in your browser is the foundation of internet trust. It tells you that the website you are visiting is exactly who it claims to be. This trust is rooted in Certificate Authorities (CAs). If a Root CA’s private key is reverse-engineered via quantum math, the attacker can issue “trusted” certificates for any domain. If a private key of a CA is reconstructed, the consequences worsen: new intermediate CAs can be issued, fraudulent end-entity certificates can be created, and revocation artifacts such as CRLs or OCSP responses can be forged. In such a scenario, the entire trust hierarchy collapses. The forgery is mathematically perfect; even the CA itself couldn’t prove it didn’t issue that certificate.
3. Financial & Legal Records
Digital signatures are often expected to remain verifiable for decades. Legal contracts, regulatory filings, financial transaction records, and long-term archival documents rely on cryptographic signatures as evidence of authenticity and non-repudiation.
If, at some future date, RSA or ECC signatures become breakable, an attacker could reconstruct old private keys and produce forged signatures that appear to have been created years earlier. In many systems, validation engines check that the signature is mathematically correct, that the certificate chain was valid at the claimed signing time, and that the revocation status was acceptable.
If a signature can be recreated and backdated, you lose the ability to say “I didn’t sign that” if the signature is cryptographically valid, leaving you no cryptographic way to prove you didn’t sign it.
Difference Between the 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.
| Factor | HNDL | TNFL |
|---|---|---|
| Attack | Capture encrypted data today and decrypt it when quantum computers can break classical key exchange. | Trust signatures today, but forge them later once quantum breaks classical signature algorithms. |
| Primary Security Property Affected | Confidentiality | Integrity, Authenticity, Non-Repudiation |
| Cryptographic Primitive Targeted | Digital Signature / Key Exchange (RSA, ECC, ECDH) | Digital Signatures (RSA, ECDSA) |
| Dependency on Present-Day | Yes, if data isn’t captured now, it cannot be decrypted later | No, public keys are already available everywhere |
| What Breaks Technically? | Session confidentiality | Signature integrity and identity trust |
| Effect on TLS | Past encrypted sessions become readable | Certificates can be forged |
| Effect on PKI | Confidential communications exposed | CA private keys are derivable, complete PKI hierarchy compromise |
Your Checklist to Mitigate TNFL
Mitigating TNFL requires a different strategy than traditional data protection. Because TNFL is an attack on Integrity, your goal isn’t 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 Discovery and Inventory to identify and map out the following:
- Root and Issuing CA
- Private key used to sign your software, firmware, and patches
- Shadow or wildcard certificates (if any)
- Code signing keys. Enforce signing validation in CI/CD pipelines
- Timestamping Authorities (TSA). Include TSA keys in the PQC migration roadmap
- Use the CBOM (Cryptographic Bill of Materials) tool to perform automated discovery and inventory across
- Move from 1–2-year certificates to 90-day (or shorter 47-day) cycles.
- Identify legacy or embedded devices that are hardcoded to use RSA/ECC and cannot be updated remotely.
- Store all signing keys in FIPS 140-3 certified HSMs. Plan hardware refresh for RSA-hardcoded boot environments
- Define hybrid signature architecture (parallel or composite). Ensure classical signature is retained for backward compatibility
- Design new PQC-ready root hierarchy. Run classical and PQC roots in parallel during transition (if possible)
- Move to a PKI-as-a-Service (PKIaaS) or a cloud-native CA that supports PQC algorithms out of the box.
- For legacy OT/ICS environments that can’t be patched, place them behind a gateway that can verify PQC signatures on their behalf.
- Use abstraction layers (or CLM tool) so you can swap out an algorithm (e.g., moving from RSA to ML-DSA) by changing a configuration file, not by rewriting code.
- Eliminate manual certificate management. If a key is compromised (or a new quantum breakthrough occurs), you should be able to re-sign your entire fleet in hours, not months.
- Validate HSM firmware PQC/hybrid support roadmap
- Benchmark signature throughput with larger algorithms
- Update key ceremony procedures to include PQC keys
- Validate backup/restore procedures for new key types
- Update operational documentation (CP/CPS)
Our goal with this checklist is to move your organization from a state of passive vulnerability to proactive integrity.
TNFL Risk & Mitigation: PKI-Centric View
Mitigating the TNFL threat requires a shift in how we manage the “shelf-life” of trust. Unlike confidentiality threats that can be solved with encryption at rest, TNFL attacks your authority. If a root key or code-signing key is compromised in ten years, an attacker can backdate signatures to today, and your current systems will have no way to distinguish the fake from the real.
This table acts as a vulnerability map. It breaks down the digital world into different “trust domains”, the areas where we rely on digital signatures, and explains how a TNFL turns those areas into liabilities.
| PKI Trust Domain | TNFL Impact | Why It’s High Risk | Practical Mitigation Focus |
|---|---|---|---|
| Trust Anchors (Root CAs / Trust Stores) | Forgery of the root private key enables an attacker to issue fully trusted certificate chains, creating fake identities or signing malicious infrastructure that is validated as legitimate. | Roots are long-lived and broadly trusted; compromise is systemic. | Build a parallel PQC-ready root; distribute trust anchors early (GPO/MDM/images); plan a root rollover; shorten the trust horizon. |
| 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 signs everything; compromise impacts many endpoints quickly. | HSM-backed CA keys, tighter CA lifetimes, staged CA replacement, hybrid issuance policy for long-survival certs. |
| Code Signing | Attackers reconstruct code-signing keys and sign malware or tampered software updates that appear vendor-authentic and pass signature validation checks. | TNFL enables “legit-looking” malicious updates; huge operational blast radius. | HSM-protected signing keys, dual/hybrid signing, enforce signing in CI/CD, provenance controls (SBOM + policy gates). |
| Firmware / 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 and forged signatures can persist for the device’s life. | Dual-sign firmware where possible; plan hardware refreshes for hardcoded RSA/ECC; and add updated gateways with stronger verification. |
| Revocation (OCSP/CRL) | Forged OCSP responses or CRLs falsely indicate revoked certificates are valid, or invalidate legitimate certificates, undermining trust decisions. | If revocation artifacts are forgeable, you lose “is this cert valid?” assurance. | Align revocation signing keys with new hierarchy, strict OCSP signing controls, monitoring, and stapling validation tests. |
| Timestamping / 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. | PQC-ready timestamp strategy, re-timestamp long-lived records, LTV design so archival proof does not collapse. |
| Enrollment Infrastructure | Rogue certificate requests approved or forged under compromised CA keys, enabling unauthorized identity issuance that appears cryptographically valid. | Catastrophic when signatures are forgivable. | Harden enrollment identity, automate approvals, template restrictions, audit trails, and CLM enforcement. |
| Validation Endpoints / Applications | Applications accept forged certificate chains due to trust anchor compromise, making malicious services indistinguishable from legitimate ones. | If validators cannot parse new profiles/OIDs, migration away from classical trust fails. | Crypto-agility testing, trust store update capability, chain/path building tests, size/latency testing. |
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 systems are at risk from quantum threats and assess how ready your current setup is, including your PKI, Hardware Security Modules (HSMs), and applications. The goal is to identify what cryptographic assets exist, where they are used, and how critical they are. Comprehensive scanning of certificates, cryptographic keys, algorithms, libraries, and protocols across your IT environment, including endpoints, applications, APIs, network devices, databases, and embedded systems.
Identification of all systems (on-prem, cloud, hybrid) utilizing cryptography, such as authentication servers, HSMs, load balancers, VPNs, and more. Gathering key metadata like algorithm types, key sizes, expiration dates, issuance sources, and certificate chains. Building a detailed inventory database of all cryptographic components to serve as the baseline for risk assessment and planning.
PQC Assessment
Once visibility is established, we conduct interviews with key stakeholders to assess the cryptographic landscape for quantum vulnerability and evaluate how prepared your environment is for PQC transition. Analyzing cryptographic elements for exposure to quantum threats, particularly those relying on RSA, ECC, and other soon-to-be-broken algorithms. Reviewing how PKI and HSMs are configured, and whether they support post-quantum algorithm integration. Analyzing applications for hardcoded cryptographic dependencies and identifying those requiring refactoring. Delivering a detailed report with an inventory of vulnerable cryptographic assets, risk severity ratings, and prioritization for migration.
PQC Strategy & Roadmap
With risks identified, we work with you to develop a custom, phased migration strategy that aligns with your business, technical, and regulatory requirements. Creating a tailored PQC adoption strategy that reflects your risk appetite, industry best practices, and future-proofing needs. Designing systems and workflows to support easy switching of cryptographic algorithms as standards evolve. Updating security policies, key management procedures, and internal compliance rules to align with NIST and NSA (CNSA 2.0) recommendations. Crafting a step-by-step migration roadmap with short-, medium-, and long-term goals, broken down into manageable phases such as pilot, hybrid deployment, and full implementation.
Vendor Evaluation & Proof of Concept
At this stage, we help you identify and test the right tools, technologies, and partners that can support your post-quantum goals. Helping you define technical and business requirements for RFIs/RFPs, including algorithm support, integration compatibility, performance, and vendor maturity. Identifying top vendors offering PQC-capable PKI, key management, and cryptographic solutions. Running PoC tests in isolated environments to evaluate performance, ease of integration, and overall fit for your use cases. Delivering a vendor comparison matrix and recommendation report based on real-world PoC findings.
Pilot Testing & Scaling
Before full implementation, we validate everything through controlled pilots to ensure real-world viability and minimize business disruption. Testing the new cryptographic models in a sandbox or non-production environment, typically for one or two applications. Validating interoperability with existing systems, third-party dependencies, and legacy components. Gathering feedback from IT teams, security architects, and business units to fine-tune the plan. Once everything is tested successfully, we support a smooth, scalable rollout, replacing legacy cryptographic algorithms step by step, minimizing disruption, and ensuring systems remain secure and compliant. We continue to monitor performance and provide ongoing optimization to keep your quantum defense strong, efficient, and future-ready.
PQC Implementation
Once the plan is in place, it is time to put it into action. This is the final stage where we execute the full-scale migration, integrating PQC into your live environment while ensuring compliance and continuity. Implementing hybrid models that combine classical and quantum-safe algorithms to maintain backward compatibility during transition. Rolling out PQC support across your PKI, applications, infrastructure, cloud services, and APIs. Providing hands-on training for your teams along with detailed technical documentation for ongoing maintenance. Setting up monitoring systems and lifecycle management processes to track cryptographic health, detect anomalies, and support future upgrades.
Transitioning to quantum-safe cryptography is a big step, but you do not have to take it alone. With Encryption Consulting by your side, you will have the right guidance and expertise needed to build a resilient, future-ready security posture.
Reach out to us at info@encryptionconsulting.com 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 our secrets, TNFL reveals an even more existential risk: the potential for a total collapse of digital identity and non-repudiation. If we do not act now to inventory our cryptographic assets and transition to quantum-resistant signatures, we risk a future where history itself can be rewritten, and the digital signature is no longer under our control. Securing the future doesn’t just mean hiding our data today; it means hardening our authority for tomorrow.
