Q-Day is the notion that there will come a time where a sufficiently powerful quantum computer can break widely used public-key cryptographic systems such as RSA and ECC. Mohan Veloo, Chief Technology Officer, Asia Pacific, China, and Japan at F5, draws comparisons between Q-Day and the turn of the millennium, outlining steps for building crypto agility and planning ahead.
Those of us old enough to remember the turn of the millennium will remember the concern around Y2K. Organisations spent years finding systems that might fail when the clock rolled over to 2000 and billions were spent fixing the problem. Then midnight came and, for the most part, nothing happened.
It is tempting to look back and conclude that Y2K was overhyped. I think the opposite is true. Nothing happened because organisations did the work before the deadline.
We now face another technology transition that is eerily similar – Q-Day, when a sufficiently powerful quantum computer could break much of today’s public key cryptography.
The big difference is that Y2K had a date. Q-Day doesn’t and that makes it much easier for organisations to treat it as tomorrow’s problem.
The risk begins before Q-Day
One of the mistakes made is assuming the risk commences when a cryptographically relevant quantum computer arrives. For some organisations, the risk has already started.
Attackers can collect encrypted data today and decrypt it later; a tactic known as ‘harvest now, decrypt later’.
So, the question isn’t when quantum computers will be powerful enough, it’s how long your data needs to remain secret.
If you are protecting government information, financial data, intellectual property, health records or anything else that needs to remain confidential for another 10 or 20 years, your quantum timeline may already have started. The migration itself will also take years because cryptography is deeply embedded across applications, APIs, certificates, PKI, identity systems, network infrastructure, cloud services, hardware and software. Some of those systems have been around for decades and some will probably still be around a decade from now.
This is why waiting for certainty around Q-Day is the wrong strategy.
ANZ got Y2K right
Australia and New Zealand handled Y2K well because organisations started early and treated it as a serious technology programme. We need the same discipline with post-quantum cryptography, but this time there is no single, universal deadline forcing everyone to act.
The Australian Signals Directorate’s (ASD) Australian Cyber Security Centre published guidance in September 2025 setting a phased timeline: a refined transition plan by the end of 2026, migration of the highest-risk systems by the end of 2028 and full transition by 2030. That’s a sensible structure, but it’s guidance, not law. And there’s no penalty for missing it.
New Zealand’s approach is looser still. The GCSB’s National Cyber Security Centre has folded quantum-readiness into the NZ Information Security Manual but hasn’t set a migration deadline.
By comparison, Google has committed to a hard 2029 deadline for full post-quantum migration across its products and infrastructure and the UK’s National Cyber Security Centre has given organisations until 2035.
That matters particularly in Australia and New Zealand because so much of the technology we consume is developed elsewhere. Cloud platforms, SaaS applications, operating systems, security products, hardware and certificate authorities all have their own technology roadmaps. The uncomfortable reality is that your PQC migration timeline may not actually be yours. It may belong to your cloud provider, software vendor, hardware supplier or another part of your technology supply chain. Start with the question most organisations struggle to answer: where exactly are you using cryptography today?
The answer is rarely straightforward. Cryptography is everywhere, in certificates, APIs, VPNs, applications, databases, identity systems, firmware, devices and infrastructure accumulated over many years. Before organisations start talking about replacing algorithms, they need to understand what they actually have and what breaks if we change the cryptography.
PQC is a migration. Crypto agility is the capability.
Becoming quantum-safe matters, but if all we do is replace today’s algorithms with new algorithms, we will miss a much bigger opportunity. We need to use this transition to build crypto agility, which does not simply mean supporting multiple algorithms.
The real test is how quickly and safely we can change cryptography across a critical business service without redesigning or disrupting that service. That takes visibility, clear policy, automation to make changes at scale and the ability to roll back changes safely.
Architecture matters
If cryptographic decisions are hard coded independently into thousands of applications, every future transition becomes hundreds or thousands of migration projects. That isn’t sustainable. So, organisations should separate cryptographic policy from application business logic where possible.
That does not magically solve every cryptographic dependency, but the principle is more pragmatic: centralise cryptographic change where you can and expose and manage it where you cannot.
Don’t wait for the perfect deadline
So, what should organisations do now? Three steps matter more than a date to mark on a calendar.
First, build and maintain a cryptographic inventory. Understand not just where certificates exist, but where cryptography is being used, what it protects, who owns it and what other systems depend on it.
Second, start asking every strategic technology supplier a very direct question: what is your post-quantum migration roadmap? And get the answer in writing. If an important supplier cannot answer that question, I would treat that as a supply chain risk rather than somebody else’s technical problem.
Third, prioritise according to the lifetime and sensitivity of the data. Not everything needs to migrate tomorrow, but information that must remain confidential for many years needs to move towards the front of the queue because of harvest now, decrypt later.
Y2K was solved because there was a date that forced organisations to act. Q-Day gives us no such luxury, so this time we have to create the urgency ourselves.
And perhaps the best measure of whether we got this right is surprisingly simple: the next cryptographic transition should be boring.
