The quantum "Q-Day" security deadline exists in a state of uncertainty. That's a problem
"Organizations that understand their cryptographic dependencies are better prepared to respond when standards change or algorithms are retired."
Ask when organizations need to prepare for post-quantum cryptography, and it is tempting to answer with another question: when will we have a quantum computer powerful enough to break the cryptography we use today? I think that misses the point.
Nobody can give businesses a reliable date for when a cryptographically relevant quantum computer will arrive. What we do know is that changing the cryptography embedded across modern technology takes time.
That makes the more useful question much simpler. If you had to change your cryptography, how long would it take? In many cases, the answer is uncomfortable.
Cryptography is everywhere. It protects connections between systems, secures data and authenticates users. It sits inside applications, infrastructure, devices and software supplied by other organizations. Much of it works so reliably that companies rarely need to think about it. Until they need to change it.
You can't replace what you can't find
The first stage of post-quantum preparation isn't choosing a new algorithm. It is understanding what you already have.
Where is cryptography being used? Which algorithms are involved? What information are they protecting? How long does that information need to remain confidential? Which systems depend on them? Which elements can you control directly, and which rely on suppliers?
For a small technology environment, answering those questions might be relatively straightforward. Across a large enterprise with years of accumulated infrastructure and software dependencies, it can be considerably harder.
That discovery work has value regardless of when quantum computing reaches the point that concerns cryptographers. An organization that understands its cryptographic dependencies is better prepared to respond when standards change, algorithms are retired, or vulnerabilities emerge.
Post-quantum cryptography is exposing a broader resilience issue: organizations need to become better at changing cryptography.
A standard isn't the end of the story
We have already passed an important milestone. Post-quantum algorithms have moved beyond academic research into published standards and real implementations. OpenSSL Library 3.5, for example, introduced support for the NIST-standardised ML-KEM, ML-DSA and SLH-DSA algorithms. That is significant, but publishing and implementing standards does not mean the transition is finished.
The mathematics behind post-quantum cryptography is different from the mathematics underpinning established approaches such as RSA and elliptic curve cryptography. Those differences create practical engineering considerations.
Signature sizes are one example. An algorithm might offer the security properties cryptographers are looking for, but if using it dramatically increases the amount of data that needs to move through an existing protocol, that matters.
Performance matters too. So does interoperability with systems that will not all migrate at exactly the same time. Security cannot exist only on paper. Cryptography has to work inside the infrastructure people actually use.
Debate is part of the process
There is still disagreement within the cryptographic community about aspects of the post-quantum transition. I don't think organizations should be surprised by that.
Cryptographers challenge assumptions. They examine standards closely and look for weaknesses. When technology may eventually protect enormous amounts of sensitive information, scrutiny is healthy.
One of the practical questions is whether organizations should move entirely to new post-quantum algorithms or combine them with established classical cryptography.
READ MORE: Google speeds up post-quantum migration to counter "harvest now, decrypt later" attacks
Hybrid approaches allow both to be used together. For organizations that want the protection offered by a new post-quantum approach without relying on it alone, that can be an attractive option during the transition.
OpenSSL's approach is not to pick favorites between published national or international standards.
We implement standards and give users choices. That allows organizations to evaluate their own circumstances rather than being forced into a single answer.
Don't wait for the countdown
There is another reason some organizations may need to think about migration sooner than others. Sensitive information does not stop being valuable simply because it is encrypted today.
An attacker can collect encrypted information now and retain it.
If technology capable of defeating the cryptography protecting that information becomes available later, data that still has value could become exposed.
The significance of that risk depends heavily on the information involved.
Data that becomes irrelevant after a few hours is very different from government, healthcare, or commercial information that may need to remain confidential for decades.
This is why a universal migration date isn't particularly useful. Organizations need to understand their own information, infrastructure and risk.
The real goal is cryptographic agility
If post-quantum migration teaches us anything, I hope it is that changing cryptography should not be an extraordinary event. Algorithms will change again, and the technologies we trust today will eventually be replaced.
Organizations therefore need the ability to identify where cryptography is used and change it without rebuilding enormous parts of their infrastructure every time.
That is cryptographic agility, and it may ultimately be one of the most valuable outcomes of the post-quantum transition.
The organizations best prepared for the quantum era won't necessarily be those that rushed to deploy a particular algorithm first.
They will be the ones that understood their dependencies, tested new approaches carefully and built systems capable of adapting as the technology develops.
A conversation we need to have now
The post-quantum transition has reached an interesting point. Standards exist and implementations are available, but many of the difficult questions now concern deployment.
How do new algorithms behave in existing infrastructure? Where does hybrid cryptography make sense? How should migration be prioritized? How do we avoid replacing one form of technical debt with another? Those questions require input from more than cryptographers.
READ MORE: When will quantum computing have its "ChatGPT moment"?
Developers need to talk to security leaders. Researchers need feedback from people implementing their work. Organizations need to understand what standards mean for the systems they operate.
That is one of the conversations we'll be having at OpenSSL Conference 2026 in Prague from 13 to 15 October. The conference brings together people working on these problems from different perspectives. At this stage of the post-quantum transition, that exchange of practical experience matters.
Quantum computing still has an uncertain timetable. The preparation work is concrete, and it can start now.
Tim Hudson is President of the OpenSSL Corporation
