Fintech Regulatory Brief

Trust Now, Forge Later: The Quantum Risk to Signatures, Not Just Encryption

September 15, 2026 · PQCClear · 6 minute read

Harvest now, decrypt later gets most of the attention in this space, and for good reason. It has a quieter sibling that deserves equal billing, one that changes which parts of a migration should actually happen first.

Independent quantum security researcher Marin Ivezic coined the term back in 2018, and it resurfaced this week in a major update to his PQC migration methodology: trust now, forge later, shortened to TNFL. If harvest now, decrypt later is about data captured today and read later, TNFL is about trust captured today and abused later. Different mechanism, different clock, and in some ways, a sharper problem once it starts.

Two Different Risks, Two Different Clocks

Track A

Harvest now, decrypt later

An attacker copies encrypted data today. It's unreadable now. Once a capable quantum computer exists, they decrypt what they already stored.

When the clock starts

The moment the data was captured, which is why this risk is already live for anything long-lived and sensitive.

Track B

Trust now, forge later

A digital signature or certificate is trustworthy today because forging one requires solving a math problem that's currently impossible. Once a capable quantum computer exists, that stops being true.

When the clock starts

Not until the quantum computer does, but by then it's too late to fix the trust anchors already in the field.

The distinction matters because signatures and certificates aren’t just protecting a moment in time the way an encrypted message is. They’re often protecting something with a long shelf life of its own: a root certificate, a firmware signing key, a code-signing certificate baked into millions of devices. Once a quantum computer can forge a signature, it doesn’t just threaten new signatures going forward. It threatens the legitimacy of every trust relationship still resting on the old algorithm.

Why Sequencing Gets This Wrong, Often

Because harvest now, decrypt later feels more urgent on first hearing, migration programs frequently treat encryption as the priority and push signature and authentication changes toward the end. Ivezic’s own framework update argues that’s backwards for exactly the systems where it matters most: a forged firmware update or a forged software signing certificate propagates instantly to everything that trusts it. The blast radius from one compromised signing key can move faster than the slow-burn exposure of previously harvested data.

Two standardized signature schemes, LMS and XMSS, are already available today specifically for this kind of trust anchor: firmware signing, software update signing, and secure boot chains, the exact places with the longest validity periods and the most to lose from a delayed migration.

One exposes what already happened. The other lets someone manufacture new, convincing lies going forward.

How Our Own Model Already Reflects This

This distinction isn’t new to us, even though the TNFL vocabulary is worth adopting. PQCClear’s assessment methodology already treats signing and authentication as a genuinely separate line of questioning from encryption in transit, because they’re different risks with different urgency profiles, not two flavors of the same question.

One example, not the whole model

One of our questions, we refer to it internally as Q20, asks specifically how a vendor generates and stores authentication tokens: whether they’re signed with an algorithm that’s directly forgeable once a capable quantum computer exists, signed with a symmetric method that only faces a much smaller quantum slowdown, or avoid the exposure entirely by using opaque, server-side tokens with no client-facing signature at all. That’s a TNFL question, evaluated on its own terms, independent of how that same vendor answers questions about encrypting data in transit.

We’re naming this one question as an illustration of the principle, not a summary of the model. The full set of signature and authentication-related questions, and how they’re weighted, is part of our own developed methodology.

Assess both risks, not just the more familiar one

PQCClear’s vendor assessments cover encryption and signature risk as distinct dimensions, so a vendor’s readiness on one doesn’t quietly stand in for the other.

Request access

trust now forge laterTNFL quantum riskpost quantum digital signaturesharvest now decrypt later vs TNFLquantum risk to certificates

This post represents the editorial analysis of PQCClear as of September 15, 2026. It should not be construed as technical or legal advice.

Key source: Marin Ivezic, “PQC Migration Framework v3.0: Build the Ability to Change Again,” PostQuantum.com (September 15, 2026). The trust now, forge later framing originates with the author, first introduced in 2018, and is described here with attribution, not reproduced.