“Q-Day” — the point at which quantum computers become capable of breaking current public-key cryptography — gets treated in a lot of planning conversations as the moment risk begins. It isn’t. It’s the moment a specific consequence becomes possible. The risk itself, for a large category of data, began the day that data was first encrypted with a vulnerable algorithm.

The Logic of “Wait and See”

The appeal of waiting is understandable: Q-Day’s timing is genuinely uncertain, migration is disruptive and resource-intensive, and acting early on an uncertain timeline feels like it risks wasted effort. This logic works reasonably well for risks that only materialise at the trigger event. It fails for “harvest now, decrypt later,” because the exposure accrues continuously, well before the trigger.

What “Waiting” Actually Costs

Every month spent waiting is a month of newly generated long-lived sensitive data encrypted under algorithms that may not hold up — data that, once harvested, can’t be retroactively protected no matter how quickly the organisation moves afterward. Waiting doesn’t pause the exposure; it just delays the response to exposure that’s still accumulating.

There’s Also a Capacity Argument

Cryptographic migration at scale takes real time — building an inventory, piloting hybrid deployments, automating certificate lifecycle management, rolling out across an estate. None of that compresses well under pressure. An organisation that starts discovery now, calmly, on its own timeline, ends up in a fundamentally better position than one that starts under regulatory or competitive pressure once the conversation shifts from “eventually” to “immediately.”

What “Not Waiting” Actually Looks Like

It doesn’t mean migrating everything today — that’s neither necessary nor realistic. It means starting the parts of the programme that have no reason to wait: discovery, inventory, and exposure assessment. None of that requires certainty about Q-Day’s date. It requires only the acknowledgement that the exposure clock on long-lived data is already running.

You can’t retroactively protect data that’s already been harvested. The only lever available is reducing what remains exposed, starting now.