A practical guide - getting started on addressing the quantum threats to encryption
How and when to get started in managing quantum risks as part of your cybersecurity strategy
Over the last few weeks, I’ve provided an explainer on the quantum threats to encryption, and hopefully dispelled common myths and misconceptions about what you need to worry about, and what the solutions should be. The conclusion was that the main concern should be data sent across a network protected by quantum-vulnerable public key encryption - generally RSA, Diffie-Hellman and Elliptic Curve Cryptography; as well as any digital signatures that depend on these algorithms. Many solutions are being touted, but my recommendation is to focus on replacing these public key cryptography algorithms with ones that are believed to be quantum-resistant - typically called “Post-Quantum Cryptography” (PQC)1. In this article, we will look at how you can get started in implementing PQC in your organisation, in order to protect against these potential future quantum threats.
As we’ve noted before, there are a range of views of when this quantum threat will eventuate, ie when there will be a “cryptographically relevant quantum computer”. Most estimates are that it will probably be some time between 2030-2040, and my own view is it’s more likely to be the latter half of that window. However, I still always advise everyone that although it may seem a long way off, you really should start now to understand and plan what you need to do to address this threat. This is because it could have a major impact and any fixes can take a long time to implement - so you need to understand the risks and start planning how to respond now. For those of you in Australia, the ACSC recommends you should complete an initial assessment and have a plan in place by the end of this year (2026), and other countries have recommended similar timescales. As we’ll see, even an initial assessment and plan is likely to be an exercise that will take months rather than weeks, so now is a good time to start thinking about it.
In this article, we’ll review some of the potential challenges to getting started, and then walk through some simple suggestions to help you to understand, prioritise and plan the work you need to do. A future article will dive into more detail about the actual implementation work.
The project planning nightmare
PQC isn’t quantum technology - it’s new maths that runs on existing hardware. While there is ongoing research into developing PQC algorithms, for now you can focus on those that have been standardised by NIST in the US that are well understood and are being broadly adopted. Therefore, addressing quantum vulnerabilities in your systems is not a research and development activity, but an implementation program of work.
As anyone who’s done IT systems implementation knows, this doesn’t mean it will be straightforward. To begin with, your IT and cybersecurity teams are probably overstretched and have lots of other competing priorities, so you’ll need to work out priorities for budget and resources. Although the underlying maths has been standardised, work is still in progress to implement this as part of the higher level network protocols such as TLS, IPSec etc. Your implementation program is then also likely to be dependent on the roadmaps of your vendors for implementing such standards.
And don’t forget, every system that you upgrade to PQC communicates with another system that will need to be kept in step. Co-ordinating this will be a challenge even when they are your own other internal systems, but many of the biggest risks will be for systems that connect to other organisations outside your control. Therefore, upgrades will need to provide backwards compatibility, and will only be effective when not only you but all counterparties have completely upgraded. For example, your VPN to your partner’s network will only be quantum resistant when you have upgraded your gateway and your partner has upgraded theirs.
If migrating everything is going to take a long time, this means you should think about the order in which you choose to upgrade systems. Remember that the first cryptographically relevant quantum computers will be scarce and expensive, and potentially take several days to decrypt a single session - so anyone fortunate enough to have one will need to be very picky about what they use it for. There is no such thing as Q-Day when everything will be broken at once, so you should prioritise what an adversary is likely to target first.
Faced with this sort of complexity, and the apparent distant nature of the threat - given a cryptographically relevant quantum computer is many years away - it might be tempting to ignore the problem and do something else, but this would be a mistake. Although the risk may be long-term, the impact couldbe profound, and experience shows that upgrading encryption protocols will take time - just look at how much legacy cryptography is still in use today even though it has been known to be insecure for many years e.g. 64-bit symmetric encryption, TLS1.0 and MD5 hashing.
Taking a structured approach
The right way to go about tackling this problem is actually cybersecurity risk management 101 - you need to understand and assess your risks, prioritise mitigation actions and implement them. Various frameworks have been suggested around this general approach. Here in Australia, the ACSC have proposed a framework of four steps - Locate, Assess, Triage, and Implement, supplemented by ongoing Communication and Education throughout these activities. If you squint, you might see that this can be represented by the acronym LATICE - presumably someone in ACSC has ignored spelling and is making a humorous reference to the fact that the main recommended PQC algorithms are based on something called “lattice-based cryptography” …
As I’m Australian, I’ll be unashamedly parochial and plagiarise heavily from this - although the suggested approach below is my own view of how to use the LATICE framework, not official government guidance.
Step 1 - Locate
You can’t govern what you don’t know - so the first step is to make an inventory, as far as possible, of where encryption is used in your systems. This is often referred to as a “Cryptographic Bill of Materials” (CBOM).
This should include considering all your different IT systems, including cloud services, hardware systems, operational technology and software applications. The focus is on identifying where asymmetric (public key) cryptography is used, which can be not only for protecting data in transit, but also authentication and digital signatures. If systems are using symmetric cryptography, this can be noted but these systems are not a priority for now.
It might feel like trying to boil the ocean to build such a CBOM, and it’s important not to get too hung up on making sure every single thing is documented. It may be helpful to think about it from a “top-down” viewpoint - canvassing a range of sources to make sure you’ve thought about systems that may be protecting the most sensitive data in transit, ones that rely on long lived certificates, and legacy systems where you may have limited information and little or no vendor support available any more.
Even if the quantum threat isn’t top of your mind, having a CBOM will be generally useful for managing cybersecurity risks - and who knows what you might find in the way of systems that use outdated encryption, or maybe don’t even have it enabled when they should?
Step 2 - Assess
This is about collecting the information needed to understand the risks associated with the systems that were located in the first step. It is important to understand:
Potential impact: what could someone do with a cryptographically relevant computer - for example what data could they see, or what systems could they get access to? If the vulnerbaility is data sent across a network, how long could that data be of value to an adversary with large resources and strategic patience?
Likelihood of occurrence: what other controls might an adversary need to also overcome in order to collect the data or to use a forged certificate? For example, data sent across the internet has a high risk of someone being able to copy the encrypted traffic, whereas a login interface that is only accessible from other internal systems would be more difficult to exploit. However, even for data sent across public networks, you should consider how easy it might be to distinguish valuable data from useless data, and how often encryption keys are changed. At least for the first quantum computers, each individual key recovery operation will take a lot of time and money so this will limit what attackers are able to achieve with one.
Potential solution: for now, focus on what would be the simplest solutions to remove the vulnerabilities you’ve identified. For 90% of cases this will probably be applying software updates from the vendor, but for some cases it might be more complex - for example replacing some hardware or even having to procure and deploy a whole new solution. However, in other cases you might be able to apply secondary controls around the system and/or isolate it. For these solutions, estimate how long it will take, how much it will cost, and any constraints on when it could start (e.g. you might be dependent on protocol standardisation, or the vendor roadmap says the patch won’t be available for a few years)
Step 3 - Triage your quantum risks
This is probably the most important step in the whole process. Even if you’ve taken a pragmatic approach of not trying to document everything in immense detail, you will probably have accumulated a lot of information and it would be easy to feel overwhelmed. However, you can probably do a first cut of setting to one side the systems that don’t require any proactive action - where the vendor has a confirmed roadmap on an acceptable timescale, and you know you are in a position to apply the update once it is available; or maybe just you know the system will be replaced in the next few years. This will cut down the volume significantly for now - but don’t forget to put in place triggers to revisit this list regularly in case anything changes.
Then out of the systems that remain, identify the ones that require the most urgent action. This will generally be because they fall into one of these categories:
The system will take a long time to remediate - maybe because it is unsupportable and you need to procure or build a whole new one, or it needs lots of hardware upgrades in multiple locations
There is limited opportunity to upgrade - for example, a long-lived digital certificate gets installed on the hardware that is used to check future software updates
There is a realistic risk of “harvest now, decrypt later” attacks that means you want a solution in place well before a quantum computer might actually become available - but remember this means the encrypted data someone could collect now is sufficiently valuable to them that they will spend money to collect it on the off-chance they might be able to read it at some unknown point several years from now
Again, you can park the other lower priority systems, but make sure you know when you need to come back to them, and have some governance mechanism in place to make sure this actually happens.
Step 4 - Triage against your other enterprise risks
At this point, you should have a good idea of your most significant risks, and how long it is likely to take to address them. The next step is to decide where this fits into your overall enterprise risk management, and the other priorities of your cybersecurity and IT teams.
Opinions vary on when a cryptographically relevant quantum computer might be available - probably sometime in the 2030s, but maybe later. Also, at least at first, such devices will be rare and expensive, so only the most well-resourced adversaries will have access to one. The UK and EU guidelines have set a target window to remediate, with 2031 as tha target for high-risk systems and 2035 for everything else.
The Australian Government has set a more ambitious target to remediate everything by the end of 2030, but it’s worth noting this is a guideline, not a mandate. If your organisation has good security maturity and can realistically meet this target then you should aim for it. But don’t sacrifice other, more important security priorities (like making sure you have multi-factor authentication for all public facing systems) to meet this guideline. Or even worse, kludge together a solution that adds more complexity to your systems, just because the standard vendor upgrade cycle might be a couple of years later (unless it is a really high-risk system that requires urgent action).
At this point you should have a good view of what your priorities are for systems that need to be made quantum-safe, and where this fits into your organisation’s plans and priorities. The high-level plan should be reported to board level (or equivalent governance) so they have an understanding of how you are managing this risk, and progress against this should be regularly reviewed as part of your governance processes.
Of course, real life may not follow such a nice linear pattern. The assessment and triage steps may need to be repeated if new information emerges, and, as noted above, trigger points will need to set to make sure that everything that was put into the “think about it later” bucket doesn’t get forgotten.
Next steps
At this point you should have a credible plan for mitigating your quantum risks. This is something that you should do as soon as possible - quantum computing may seem like a distant threat but could have a major impact. Going through this initial assessment and triage exercise means that you know when and how to act to mitigate this - and so this should be a priority for all organisations.
Of course, a good plan still achieves nothing unless you implement it effectively. In the next article in this series, I’ll discuss in more detail how to decide the most appropriate solution for each system you need to upgrade, and the practical aspects and challenges of the implementation work.
However, in the meantime you might want to note that by adding that second (and very important) “Triage” step we’ve fixed that spelling error in the framework acronym (with apologies to our friends at ACSC).
MDR Quantum helps organisations to understand and assess their quantum risk and to respond accordingly. Our services include executive briefings, policy development, risk assessment and PQC migration strategy and planning - please reach out if you’d like to learn more about how we may be able to help.
Or sometimes QRC - Quantum Resistant Cryptography - but PQC seems to be the more popular term these days.
good explanation. inspite of all theese we may have to check our Cryptographic Secure RAndom number generation algorithm