Trust Now, Forge Later (TNFL): The PQC Signature Threat

Trust Now, Forge Later (TNFL) is the risk that a quantum computer will be able to forge digital signatures — allowing an attacker to produce software updates, contracts, certificates and identity assertions that systems accept as genuine.

If you have been following the post-quantum conversation, you will almost certainly have encountered Harvest Now, Decrypt Later, the risk that encrypted data collected today could be decrypted by a future quantum computer. It is legitimate, well documented, and rightly features in government advisories.

TNFL receives far less attention yet arguably poses a greater systemic risk. Where HNDL targets the confidentiality of historical data, TNFL strikes at the integrity and authenticity of the trust mechanisms underpinning modern business, government and critical infrastructure.

For CISOs, CTOs and board members, the implications extend well beyond data protection. TNFL challenges how we verify identity, validate software and establish trust across connected systems.

What is Trust Now, Forge Later?

TNFL is the forward-looking counterpart to HNDL. Where HNDL concerns the future exposure of data already encrypted and collected, TNFL focuses on a different moment: the point at which quantum computers become capable of breaking today's digital signature algorithms.

Digital signatures are how we verify that a document, a software update or a communication is authentic and has not been tampered with. When a signature can no longer be trusted, because an attacker can forge one, the consequences ripple across every process depending on that trust.

The critical difference from HNDL is that TNFL requires no advance collection of data. HNDL depends on an adversary having captured and stored ciphertext. TNFL becomes an active threat the moment a cryptographically relevant quantum computer exists, and at that point every system still relying on classical signature algorithms is vulnerable.

One qualification. Deriving a private key requires the corresponding public key, so the attack depends on that key being obtainable. In practice this is a low barrier for most signature use cases — public keys in TLS certificates, code signing certificates and publicly trusted roots are broadcast by design, and Certificate Transparency logs make them permanently retrievable. The qualification matters more in closed systems where verification keys are not published, though those are the minority and often rely on the same publicly trusted roots higher up the chain.

Why signatures break differently from encryption

Both threats stem from the same underlying capability — Shor's algorithm breaking RSA and elliptic curve cryptography — but they behave differently in practice.

With encryption, the damage is retrospective. Data captured in the past becomes readable. Going forward, you can switch algorithms and new data is protected.

With signatures, the damage is prospective and it is not limited to new material. An attacker able to forge signatures can produce a document, firmware image or certificate that appears to have been signed at any point, including years ago. The signature does not carry proof of when it was created unless a trusted timestamp was applied at the time.

That distinction matters for anything relying on signatures as evidence. A contract signed in 2024 and verified in 2032 has no inherent defence against having been forged in 2032, unless the signature was timestamped by a trusted authority while the algorithm was still sound.

Why digital signatures matter more than most leaders realise

Digital signatures are invisible to senior leaders because they operate quietly behind virtually every digital interaction. Their role is foundational. They verify the authenticity of legal documents, contracts and regulatory filings. They validate financial transactions and commercial agreements. They authenticate users, devices and services connecting to corporate networks. And they ensure software updates and firmware deployments are genuine.

That last point is where TNFL becomes particularly dangerous. In a world where virtually every device receives over-the-air updates secured by digital signatures, the ability to forge those signatures gives an attacker the means to deploy malicious code at scale, with updates appearing entirely legitimate to the receiving systems.

Digital signatures are not an optional security layer. They are woven into how modern organisations operate, communicate and transact. A failure of signature trust is not a contained incident. It is a systemic event.

The critical infrastructure dimension

The most serious implications sit beneath the surface of everyday operations. Virtually every modern device — industrial equipment, consumer electronics, critical national infrastructure — depends on digitally signed software and firmware. If an attacker can forge those signatures, they can deploy malicious updates that conventional monitoring will not detect, because everything about them looks correct.

For a household appliance this is a contained risk. For systems controlling aircraft engines, air traffic management, railway signalling, ATM networks, energy distribution or nuclear facilities, a forged firmware update could compromise safety-critical operations.

For any organisation that manufactures, deploys or operates devices with signed firmware, TNFL is among the most urgent drivers for quantum-resilient planning. The devices being deployed today will in many cases remain in service for 10, 15 or 20 years. If the signatures securing their update mechanisms can be forged before those devices reach end of life, the entire model for maintaining their security is compromised.

That creates a planning horizon extending well beyond typical IT refresh cycles. Decisions being made now about device procurement, firmware architecture and update mechanisms will determine exposure for years.

The legal and commercial impact

Beyond critical infrastructure, digital signatures underpin the enforceability of electronic contracts, the integrity of regulatory submissions and the authenticity of audit trails. If signatures can be forged, the evidential value of signed documents comes into question.

Consider a financial services organisation. If signatures on transaction records, client agreements or regulatory filings can no longer be trusted, the consequences extend beyond cybersecurity into legal liability, regulatory compliance and reputational damage. The same applies to healthcare organisations relying on signed records for clinical decisions, or government departments authenticating policy documents.

This is not simply a question of individual document forgery. It is a systemic erosion of the trust model underpinning digital business processes. Once confidence in signatures is undermined, rebuilding it — through alternative verification, manual processes or legal remediation — would be substantial in both cost and complexity.

The AI dimension

One further dimension amplifies TNFL in ways only now being understood.

As organisations increasingly rely on AI and automated decision-making, the integrity of the data feeding those systems becomes paramount. An AI system processing forged or manipulated data will produce outputs that appear authoritative but are fundamentally unreliable — and it will do so at machine speed, across far more decisions than a human process would.

The relationship also runs the other way. Cryptographic signatures are one of the few workable answers to the authenticity problem AI-generated content creates, which is the basis of cryptographic content provenance. If signature trust fails, the mechanism being built to verify what is genuine fails with it.

That intersection — quantum risk undermining the verification layer that AI dependency makes essential — is an area few organisations have yet considered in detail.

How TNFL differs from HNDL

The two demand different assessment approaches and different mitigations.

Harvest Now, Decrypt Later

• Targets confidentiality of historical data.
• Requires the attacker to have collected data in advance.
• Risk scales with how long your data remains sensitive.
• Mitigation centres on protecting data flows with quantum-resistant key exchange.
• Assessment examines data sensitivity timelines and collection threat models.

Trust Now, Forge Later

• Targets integrity and authenticity of signatures.
• Requires no advance preparation at all.
• Risk scales with the service life of signed assets and the reliance placed on signature evidence.
• Mitigation requires transitioning signature algorithms and addressing devices already deployed.
• Assessment examines where signatures are used and what depends on them.

Both are real and material, and both belong in a comprehensive approach to post-quantum readiness. But TNFL's systemic nature and its implications for long-lived physical assets make it, in many respects, the harder of the two to address.

Why the signature migration is harder than the encryption one

This is the part that tends to surprise people, and it explains why TNFL deserves earlier attention than its profile suggests.

Post-quantum signatures are considerably larger. An ML-DSA-65 signature is around 3,309 bytes against 256 bytes for RSA-2048 — roughly thirteen times the size. SLH-DSA signatures are larger still, running from around 8KB to nearly 50KB depending on the parameter set. For constrained devices, protocols with packet size limits, and firmware images with fixed layouts, that is not a configuration change.

Verification code is often embedded and unreachable. The routine that checks a firmware signature frequently sits in a bootloader or secure element. Updating it may require physical access, a hardware revision, or may simply be impossible on devices already in the field.

The chicken-and-egg problem. To deploy an update that adds post-quantum signature verification, you have to send that update — signed with the classical algorithm the device currently understands. Devices that cannot receive such an update before the algorithm is broken cannot be remediated at all.

Encryption can be changed unilaterally; signatures cannot. You can upgrade the encryption protecting your own data without asking anyone. A signature only works if the verifier also understands the new algorithm, which means the transition has to be coordinated across every party in the chain.

This is why hybrid signature schemes matter — signing with both a classical and a post-quantum algorithm so that the transition can proceed without every verifier upgrading simultaneously.

There is a design tension worth understanding. If verifiers accept either signature on its own, older systems keep working, but an attacker who breaks the classical algorithm can still forge successfully. If verifiers must validate both, security holds but nothing that has not been upgraded can verify at all. Composite schemes that bind the two signatures together address this, at the cost of backwards compatibility. Which model applies determines whether your hybrid deployment is a migration aid or a genuine security control, and it is a question worth putting to any vendor claiming hybrid support.

What organisations should do

Organisations relying on digital signatures to secure long-lived assets — firmware, legal documentation, operational data or commercial agreements — should be assessing TNFL exposure now. That does not mean implementing quantum-resistant signature algorithms immediately. It means taking several practical steps.

Map your digital signature dependencies

Understand where signatures are used across the organisation, which systems and processes depend on them, and what the consequences would be if they could be forged. This exercise alone provides valuable insight into exposure, and it is the signature equivalent of building a cryptographic inventory.

Assess the lifecycle of your signed assets

Devices deployed today with 15-year service lives, contracts with long-term enforceability requirements and regulatory records with extended retention all need considering through the TNFL lens. The question is simple: will this asset still be relied upon after the signature protecting it can be forged?

Apply trusted timestamping where evidence matters

A timestamp from a trusted authority records when a signature was created, which is what allows a signature to retain evidential weight after the algorithm behind it is deprecated. For contracts, regulatory filings and audit records, this is the most immediately actionable mitigation available, and it does not require post-quantum algorithms to be deployed first.

One caveat matters. A timestamp is itself a digital signature, so it carries the same eventual vulnerability. Long-term validation formats address this through archive timestamping — applying a fresh timestamp with a stronger algorithm before the existing one becomes weak, so the chain of evidence is continuously renewed.

The overhead is more than it first appears. Each re-timestamp has to preserve the entire validation chain alongside it: the certificates, the CRLs and OCSP responses that proved those certificates were valid at the time, and the previous timestamp. Without that, a future verifier cannot establish that the signature was sound when it was made, because the revocation infrastructure that would have answered the question no longer exists. Timestamping is therefore an ongoing archival obligation rather than a one-off action, and any long-term signature strategy needs a defined process for it.

Factor TNFL into procurement and design

New devices, systems and applications being specified now should be evaluated for their ability to support quantum-resistant signature algorithms, natively or through a credible upgrade path. Ask specifically about signature size handling and whether verification logic can be updated in the field. Crypto-agility in the signing and verification chain is what determines whether this becomes a configuration exercise or a recall.

Bring TNFL into the boardroom

Senior leaders who understand the data confidentiality risk of HNDL also need to understand the integrity and trust risk of TNFL. Together the two provide a complete picture of why post-quantum readiness is a strategic imperative rather than a technical project.

For the full timeline driving these actions, including the approved algorithms and deprecation deadlines, see our guide to the NIST PQC roadmap. Code signing is also moving independently, with certificate validity reducing to 460 days, which affects release processes and CI/CD pipelines now rather than later.

How Unsung can help

We help organisations map their digital signature dependencies, assess TNFL exposure and develop practical, phased approaches to quantum-resilient security. We work across PKI architecture, certificate lifecycle management and cryptographic strategy to ensure the trust mechanisms underpinning your operations are fit for the quantum era.

Our vendor-neutral position means we focus entirely on what is right for your organisation. We do not promote specific platforms or products. Instead we provide independent guidance that helps you understand your exposure, prioritise your response and build a roadmap proportionate to your risk profile and operational reality.

A cryptographic bill of materials establishes where signatures and algorithms sit across the estate, and our PKI consultancy team takes that into a migration plan.

If TNFL is a risk your organisation has not yet assessed, now is the time to start that conversation. The devices, contracts and systems being deployed today will define your exposure for years to come. Talk to our team.

‍

Want to explore this topic further?

This blog is part of a series drawn from our strategic whitepaper, Post-Quantum Cryptography: A Strategic Whitepaper for the C-Suite. It provides vendor-neutral, business-focused guidance on navigating the quantum era — covering the threats already in play, lessons from previous hype cycles, and practical steps your organisation can take today. Download your copy here: https://2f4v3l.share-eu1.hsforms.com/20qJjHSynQkuJKhI_xq9Msg