Analysis · 3 min read
Q-Day planning: the deadline already inside your data
How to turn uncertain quantum timelines into a concrete migration plan with priorities, owners and dates.

"Q-Day" is shorthand for the day a quantum computer can break the public-key cryptography the internet relies on. It makes for good headlines, but it is a poor planning tool. No one can tell you the date, and organizations that wait for one will start too late. A better approach treats Q-Day as a range and works backward from the data you need to protect.
Your deadline is set by your data, not by physicists
The useful question is not "when will quantum computers arrive?" but "how long must our data stay secret, and how long will it take us to migrate?" If a record must stay confidential for fifteen years and your migration will take seven, the window that matters started long ago. Every year of delay shrinks the safety margin for data being created and transmitted right now.
Anchor to the regulatory timeline
Standards bodies have removed some of the uncertainty. NIST finalized its first post-quantum standards in 2024: ML-KEM for key establishment (FIPS 203), and ML-DSA and SLH-DSA for digital signatures (FIPS 204 and 205). NIST IR 8547 proposes deprecating RSA and ECC for many uses by 2030 and disallowing them by 2035. National security guidance such as CNSA 2.0 sets similar milestones. These dates give a defensible backbone for any roadmap.
Build the plan in phases
Successful programs follow a predictable sequence. Discover: build a complete cryptographic inventory. Assess: score each asset by algorithm strength, data shelf-life and exposure. Prioritize: rank systems by harvest-now-decrypt-later risk and business impact. Migrate: deploy hybrid key exchange and quantum-safe algorithms, starting with the highest-risk systems. Verify: confirm handshakes negotiate as intended and cannot be downgraded. Monitor: detect drift and block new vulnerable cryptography from entering the estate.
Prioritize ruthlessly
You cannot migrate everything at once, and you do not need to. Start where long-lived sensitive data crosses vulnerable key exchange: external TLS endpoints carrying customer data, inter-site VPNs and partner integrations. Hybrid key exchange, which combines a classical algorithm with ML-KEM, protects against harvest-now-decrypt-later while preserving compatibility. Signature migration — for code signing, certificates and firmware — can follow on a schedule aligned with hardware and vendor readiness.
Don't forget vendors
Much of your cryptography is controlled by suppliers: cloud providers, SaaS platforms, network appliances and hardware security modules. Ask vendors for their post-quantum roadmaps, track their commitments and build those dates into your plan. A vendor that cannot answer is itself a risk signal.
Make progress measurable
Boards and regulators will increasingly ask how ready you are. A single risk score, tracked over time and broken down by business unit, answers that question clearly. Pair it with a roadmap that names owners and target dates for each phase, and quantum readiness becomes a managed program rather than an open-ended concern.
Start with what you can know
You cannot know the date of Q-Day. You can know what cryptography you run, what data it protects and how long migration will take. That is enough to build a plan — and the organizations that start now will meet the deadline on their own terms.