Why “safe today” and “safe tomorrow” are different answers

“This key is too weak” and “this system needs a plan for quantum-safe encryption” are two different findings. They’re often collapsed into one, and both directions of that mistake cost money: one leaves real exposure unplanned, the other turns every system into an emergency.

Mistake one: strong today means safe tomorrow

A key that meets today’s approved minimum can still use a method that quantum computers threaten. Making the key longer doesn’t change that. NIST has proposed retiring RSA and elliptic-curve methods by 2035 at every key size, not just the small ones, because the threat comes from the mathematics behind them rather than the length of the key.

So a clean result on today’s checks tells you nothing about tomorrow. The two questions need two answers, and the second one needs a plan, explained in more depth in does quantum computing break all encryption?

Mistake two: every affected system is equally urgent

RSA and elliptic-curve methods are everywhere, so it’s tempting to treat every system that uses them as an emergency. That spreads effort thinly and burns goodwill. Urgency depends on three things:

• How long the data or signatures must stay trustworthy. A session token that expires in minutes is a different case from a medical record kept for decades.
• How deeply the method is embedded. A setting on one service is quick to change; a method built into devices, partner connections or firmware is not.
• How long a realistic change would take, including testing, change windows and anyone outside your organization who has to move first.

Putting the two answers together

Plot every system on both questions and four groups appear. Systems weak today and long-lived need both a fix now and a quantum-safe plan. Systems weak today but short-lived need the fix and can wait for the plan. Systems strong today but long-lived go to the front of the quantum-safe queue. And systems that are strong and short-lived can follow the normal upgrade cycle.

That grouping is easy to explain to a board, and it turns a vague worry into a schedule.

A worked example: four systems

Illustrative: a bank looks at four systems. Its internal chat service uses a key below today’s minimum, but messages are deleted after thirty days: fix the key now, and the quantum-safe change can follow the normal upgrade cycle. Its customer records archive uses a strong key today, but the records must stay private for decades: it goes to the front of the quantum-safe plan. Its card authorization service has a weak key and long-lived trust relationships: it needs both a fix now and an early place in the plan. Its marketing site is strong and short-lived: no action beyond routine upgrades.

Common objections

• “We’ll just use bigger keys.” Longer keys fix today’s weaknesses. They don’t protect public-key methods against a capable quantum computer, which is why NIST’s proposal covers every key size.
• “It’s years away, so it can wait.” Data captured today can be read later, and the change itself takes years, so waiting only shortens the time you have.
• “We’ll do everything at once when the time comes.” The systems with the longest lead times can’t be rushed, and a big-bang change is the riskiest way to move cryptography.

What to do

Answer both questions for every system, separately. Fix what’s weak today now, because those fixes are usually quick and remove real exposure.

Sequence the quantum-safe work by how long your data must stay private and how long the change will take, not by which systems are easiest to rescan. The reasoning behind data lifetime is set out in data stolen today, decrypted later.