Explore how enterprise networks can prepare for post-quantum cryptography, address migration risks, and protect critical systems before quantum computing threatens current encryption.
Roohan Adeel
A quantum computer capable of breaking today’s public-key cryptography doesn’t exist yet. However, organisations don’t seem to have much time to prepare. An attacker can collect encrypted traffic and store it until the technology becomes powerful enough to decrypt it. This is one of the most common philosophies known as harvest-now, decrypt-later. The migration also takes longer than many organisations expect.
Cryptography is built into applications, network equipment, certificates, and connected devices. Replacing it means finding those dependencies, checking compatibility and coordinating changes across teams and suppliers.
NIST just issued the final version of IR 8547, setting out the planned retirement of ECDSA, RSA, EdDSA, elliptic-curve Diffie-Hellman, and Diffie-Hellman. These algorithms are due to be deprecated after 2030 and disallowed after 2035 as per the final transition schedule. For security teams, the work starts even before those dates.
Many governments and standards bodies have published transition schedules. Their requirements don’t apply equally to every business, but they offer a helpful picture of how quickly the migration is expected to progress.
Every date has a different scope. CNSA 2.0 concerns suppliers of US national security systems, and ASD guidance is directed at Australian Commonwealth entities. A private company may not fall under either requirement. However, organisations that handle long-lived sensitive information should pay attention to the same deadlines when planning their own systems.
The risk isn’t limited to the day a quantum computer becomes capable of breaking encryption. Information captured today may remain valuable years later. Mosca’s inequality offers a practical way to assess that exposure. Consider three periods:
When X and Y together exceed Z, the organisation may run out of time before the information is safe. The difficulty is that nobody can give a reliable date for Z.
Research has also changed the assumptions around quantum computing. In a 2025 paper, Craig Gidney estimated that breaking RSA-2048 could require fewer than one million noisy qubits. His earlier 2019 estimate, developed with Martin Ekerå, was around 20 million. These are theoretical resource estimates, not evidence that such an attack is currently practical. They do show why organisations should not base their plans on older assumptions alone.
It may be part of a VPN gateway, a TLS connection, an SSH service, a certificate, a code-signing process or an HSM. It can also sit inside databases, firmware, SaaS integrations and equipment supplied by third parties. A migration plan built around the systems an organisation owns will miss dependencies buried in vendor products.
Post-quantum algorithms bring different data sizes and performance requirements. Network teams need to test these changes against their existing infrastructure rather than assume that every device will handle them. For example, ML-KEM-768 uses a 1,184-byte public key and a 1,088-byte ciphertext. X25519 uses 32-byte public keys. ML-DSA-44 signatures are 2,420 bytes, compared with 64 bytes for ECDSA.
Those differences can affect network traffic, certificate handling, and equipment with limited capacity. ARMChain’s whitepaper reports an ML-KEM-768 handshake taking roughly 55 microseconds of CPU time on one laptop core. In that test, the larger data exchanged over the network is a more noticeable consideration than the processing time.
Older gateways and middleboxes deserve early attention. They may impose message-size limits or handle unfamiliar cryptographic exchanges poorly. Key exchange support is also moving faster than certificate and signature standards. The X25519MLKEM768 hybrid key exchange is available in Chrome 131+, Edge 131+ and Firefox 132+, according to Cloudflare Radar. It combines X25519 with ML-KEM-768.
Post-quantum signatures are a separate challenge. The UK NCSC has noted that there is still no agreement on how they should be used in WebPKI certificates. An organisation may therefore be able to test hybrid key exchange today while still waiting for wider agreement on certificate changes.
The Australian Signals Directorate uses the LATICE model to organise quantum-readiness work. Its five stages give security teams a way to move from discovery to implementation without treating every system as equally urgent.
Locate: Start by listing where RSA, Diffie-Hellman and elliptic-curve cryptography appear. Record the system owner, algorithm, key size and purpose of each implementation. Include firmware, supplier products and managed services. An incomplete inventory makes every later decision harder.
Assess: Look at the information each system protects. How long must it remain confidential? Could someone intercept and store the traffic? Can your team update the system directly, or must a supplier make the change? These details help establish the level of exposure and the work involved.
Triage: Give priority to information with a long confidentiality requirement. Data intercepted today may still be useful to an attacker years later. Code-signing and firmware-signing systems also need attention, with CNSA 2.0 setting 2030 as a key milestone. Certificate infrastructure and PKI should be included in the migration plan. Lower-value, short-lived information may have less immediate exposure.
Implement: Where the TLS stack supports it, test hybrid X25519 and ML-KEM key agreement. Check gateways, libraries and connected equipment for compatibility. Measure handshake size, latency and network behaviour in the organisation’s own environment. Keep cryptographic choices configurable so a future algorithm replacement does not require extensive application changes.
Communicate and educate: The inventory needs owners, and those owners need to understand what is expected of them. Brief senior management on the deadlines and risks. Ask suppliers for specific transition dates and supported algorithms. Engineers responsible for maintaining the inventory should receive the guidance and training needed to keep it accurate.
Post-quantum cryptography addresses particular weaknesses in current cryptographic systems. It does not replace every security control an organisation already uses.
NIST published FIPS 203, FIPS 204 and FIPS 205 on 13 August 2024. The final IR 8547 material also discusses FN-DSA and HQC, which remain under development in the material referenced by this guide. Organisations should base current deployments on published standards and track developments before making decisions about algorithms that are not yet finalised.
Changing cryptographic algorithms will not resolve every route an attacker can use to compromise an organisation. Phishing can still expose employee credentials. Ransomware can still disrupt business operations. An attacker who gains access to an endpoint may be able to read information before encryption protects it. Poor server configuration can also leave sensitive services exposed.
Cryptographic migration belongs alongside identity controls, endpoint security, patching, backups, and incident response. It should not be treated as a replacement for them. Crypto-agility matters here too. If algorithm choices are hard-coded across applications, another standards change can trigger a costly redevelopment project. Keeping those choices configurable gives engineering teams more room to respond when standards or approved implementations change.
Supplier assessments should be part of the same exercise. ASD’s July 2026 vendor questions provide a useful starting point. Ask suppliers which post-quantum algorithms they plan to support, when those changes will be available, and which data flows still rely on classical public-key cryptography. Record the answers rather than relying on general statements about future readiness.
Blockchain networks rely on cryptographic signatures to authenticate transactions and network activity. Their migration to post-quantum algorithms is therefore relevant to the wider transition.
ARMChain is an EVM-compatible Layer 1 designed around post-quantum cryptography. Its whitepaper describes ML-DSA-44 for account and validator signatures, alongside ML-KEM-768 for node connections.
Organisations considering the network should review its current development status before making deployment decisions. At the time covered by this article, ARMChain operates on a devnet, with a public testnet targeted for 15 November 2026. Throughput and finality measurements have not been published, and the network has not undergone an external audit.
There is also an important transaction compatibility consideration. The whitepaper states that accounts using standard Ethereum transaction types remain exposed to the same risks as accounts on Ethereum. Organisations with Australian government security obligations should check the Information Security Manual’s approved cryptographic parameters. The relevant requirements may call for a higher ML-DSA parameter set than ML-DSA-44. For a closer look at how ARMChain compares with other post-quantum blockchain projects, see our comparison of quantum-resistant blockchain platforms.
It starts with identifying systems that rely on quantum-vulnerable algorithms. The organisation then assesses exposure, selects suitable standards, plans replacements and coordinates the work with suppliers and internal teams.
Discovery should begin now. ASD’s schedule calls for refined plans by the end of 2026, while the UK NCSC sets 2028 as a milestone for goals and discovery. NIST’s retirement schedule places further pressure on organisations to complete the transition before 2035.
Yes. Hybrid key exchange combines a traditional algorithm with a post-quantum algorithm, allowing systems to test and deploy newer protection while retaining compatibility. It is a transition measure, not a reason to postpone a full migration plan. The hybrid mechanism itself also needs to be assessed against the relevant standards and guidance.
No. It addresses risks associated with quantum attacks on public-key cryptography, including future decryption of recorded traffic and forged digital signatures. Phishing, stolen credentials, compromised devices, and ransomware require separate security measures.