Signatures trusted today, forged later

Digital signatures prove who sent something and that it hasn’t been changed. Software updates, certificates, signed contracts and financial transactions all depend on them. If the method behind a signature can later be broken, someone could forge signatures that systems still trust.

That makes it a problem of trust rather than secrecy, sometimes called “trust now, forge later”: nothing has to be stolen in advance. What’s at risk is whether anyone can rely on a signature in the future.

How it differs from data stolen today

With data stolen today, decrypted later, the damage depends on what was captured. With signatures, there’s nothing to capture. Once a signature method can be broken, an attacker can create new signatures that look genuine: a software update that installs malware, a certificate for a site they don’t own, or an altered record that still verifies.

So the question isn’t how long a secret must stay secret. It’s how long something must stay trusted, and how long it takes to move everything that checks it.

Where long-lived trust shows up

It shows up wherever a signature has to be trusted for years:

• Root certificates that devices and applications trust for their whole working life.
• Firmware and software updates for equipment that stays in the field for a decade or more.
• Signed records, such as contracts, audit evidence and transaction logs, that must stay verifiable long after they were created.
• Code signing for software your customers install and update.

The longer something must be trusted, the earlier its signatures need a plan. Why your most trusted certificate may be your longest project follows one of these cases in detail.

Why it takes planning

Replacing a trusted signing method means every system that checks those signatures must accept the new method first. In a large organization that’s a long list, and some of it belongs to partners, suppliers and customers whose schedules you don’t control.

The order matters: update the checkers, then start signing with the new method, then retire the old one once nothing depends on it. Reverse that order and systems start rejecting genuine signatures.

The dates reflect the effort. The US executive order of June 2026 gives high-value federal systems until the end of 2031 to move signatures to quantum-safe methods, a year after the deadline for key exchange. NIST has also proposed retiring today’s most widely used signature algorithms by 2035.

Running old and new side by side

Because every verifier has to move before signers can switch, most organizations will run traditional and quantum-safe signatures side by side for a period. NIST describes hybrid mechanisms, combining a quantum-safe method with a traditional one, as one way to manage that transition.

Hybrid approaches add work: larger signatures, more testing, and two methods to manage. In exchange, systems that haven’t moved yet keep working while those that have get the new protection. Planning for that overlap, rather than a single switch-over date, is what keeps signatures trusted throughout.

Questions to ask your suppliers

Many of the signatures you rely on are produced or checked by products you buy. Ask your suppliers:

• Which signature methods do your products use today, and where?
• When will they verify signatures made with NIST’s new standards?
• Can firmware and software updates move to a new signature method in the field?
• Will you provide a record of the cryptography inside your products, such as a CBOM?

Where to start

List the signatures your business depends on for the longest time, and the systems that verify each one. That list, with an owner for every item, is the start of the plan. The hardest items, usually roots and device firmware, go first in the sequence because they take longest to move.