Skip to content
IC
All posts

Cryptography

Managing cryptography in the post-quantum era: what businesses need to do now, and the attacks already hitting encryption

The post-quantum standards are finalised and ASD's Information Security Manual stops approving RSA and elliptic-curve cryptography after the end of 2030, ahead of most of the world. The operational playbook: the attacks on encryption happening now, the honest quantum timeline, and how to run the migration.

Mathew Sayed Mathew Sayed
· · 12 min read

The migration to post-quantum cryptography stopped being a research topic in August 2024, when NIST finalised the first three standards. It gained a hard date in December 2024, when the Australian Signals Directorate updated its Information Security Manual to stop approving RSA and elliptic-curve cryptography after the end of 2030, five years ahead of the timelines most other national agencies published. That cut-off binds systems assessed against the ISM directly, and it sets the benchmark every other Australian organisation will be measured against. If you run information risk for a financial services or regulated mid-market organisation, the question is no longer whether to move. It is how to manage a multi-year cryptographic transition without breaking production, and how to defend encrypted data against the attacks that are landing today rather than the quantum computer that arrives later.

This post is the operational side of that problem. Our post-quantum planning timeline covers the when and the how-urgent. This one covers the how: the current threats to encryption, the honest state of quantum hardware, the regulatory deadlines that actually bind Australian firms, and the four disciplines that turn a scary headline into a managed program.

Where the standards actually landed

On 13 August 2024, NIST published three finalised post-quantum standards: FIPS 203, 204 and 205.

  • FIPS 203 (ML-KEM) is the module-lattice key encapsulation mechanism, derived from CRYSTALS-Kyber. It replaces the key exchange that protects data in transit, the RSA and Diffie-Hellman handshakes underneath TLS, VPNs and SSH.
  • FIPS 204 (ML-DSA) is the module-lattice digital signature algorithm, derived from CRYSTALS-Dilithium. It replaces RSA and ECDSA signatures for authentication, code signing and certificates.
  • FIPS 205 (SLH-DSA) is a stateless hash-based signature scheme, derived from SPHINCS+. It is slower and produces larger signatures, but its security rests only on hash functions, which makes it a conservative choice for long-lived signing keys.

A fourth signature standard, FIPS 206 (FN-DSA, derived from FALCON), is still in development. In March 2025 NIST also selected HQC as a backup key encapsulation mechanism. HQC is built on error-correcting codes rather than lattices, so if a structural weakness is ever found in the lattice family that ML-KEM belongs to, there is a mathematically independent fallback already standardised. That decision matters for how you plan: it is a reminder that the algorithms you deploy in 2027 may not be the algorithms you run in 2032, which is the entire argument for cryptographic agility.

The attacks on encryption that are happening now

The quantum computer capable of breaking RSA does not exist yet. The attacks on encryption in production do. Treating post-quantum migration as the only cryptographic risk on the register is a mistake, because the practical failures are the ones your organisation is exposed to this quarter.

Harvest now, decrypt later

The threat that makes post-quantum migration urgent is not a future quantum machine breaking today’s traffic in real time. It is an adversary recording encrypted traffic today and storing it until a quantum computer can decrypt it. CISA, the NSA and NIST named this explicitly in their joint Quantum-Readiness fact sheet: threat actors are assumed to be collecting encrypted data now with long confidentiality lifetimes, on the expectation of decrypting it later. Anything encrypted today with RSA or ECDH that must remain confidential into the 2030s is already at risk, because the interception can have happened before the algorithm is retired.

The plausibility of large-scale interception is not hypothetical. The Salt Typhoon intrusions into major telecommunications carriers, disclosed through late 2024 and into 2025, led CISA to recommend end-to-end encrypted messaging for senior officials. Salt Typhoon is a live interception and espionage campaign, not proof of quantum harvesting, and the distinction matters. What it demonstrates is that nation-state actors already sit on the infrastructure where bulk encrypted traffic transits. The capability to collect is present. The decryption is the part that is on a clock.

Protocol and downgrade attacks

The Terrapin attack (CVE-2023-48795), disclosed by researchers at Ruhr University Bochum, is a working example of how encryption fails in practice. It is a prefix-truncation attack against the SSH transport protocol. An attacker positioned in the network path manipulates sequence numbers during the handshake to silently delete messages, downgrading the security features that were negotiated. It affected the widely used ChaCha20-Poly1305 and CBC Encrypt-then-MAC modes, and the fix, strict key exchange, had to be rolled into OpenSSH, PuTTY, libssh and every other implementation. The lesson is not that SSH is broken. It is that cryptographic security depends on the protocol around the algorithm, and downgrade paths are where real attacks live.

The collapse of certificate lifetimes

The most operationally significant change to encryption management in 2025 was administrative, not mathematical. In April 2025 the CA/Browser Forum passed Ballot SC-081v3, with 25 of the certificate-issuing members voting yes and all four browser vendors in favour. It sets a phased reduction in the maximum validity of public TLS certificates:

Effective dateMaximum certificate validityDomain validation reuse
Now to 14 March 2026398 days398 days
15 March 2026200 days200 days
15 March 2027100 days100 days
15 March 202947 days10 days

By March 2029, a certificate lives 47 days and domain control has to be re-validated every 10 days. Any organisation still renewing certificates by hand, or tracking them in a spreadsheet, will not survive that cadence. The DigiCert breakdown of the schedule is a useful reference for the phased dates. The reason this belongs in a post-quantum discussion is that the same capability, an accurate inventory of every certificate and automated issuance, is a prerequisite for migrating those certificates to post-quantum signatures later. If you cannot rotate a certificate in an afternoon today, you cannot re-key your estate to ML-DSA in 2029.

The quantum timeline, without the hype

A credible program needs an honest read on the hardware, because the deadlines only make sense against it.

The best experimental quantum processors today operate at roughly one hundred physical qubits. Google’s Willow processor, demonstrated in December 2024, showed error rates that fall as the error-correcting lattice grows, which is the property fault tolerance requires. IBM has published a roadmap targeting a large-scale fault-tolerant machine, “Starling,” with around 200 logical qubits by 2029. These are real milestones on the path to a cryptanalytically relevant machine. None of them can factor RSA-2048.

The distance is still large. The 2019 estimate by Gidney and Ekerå put the cost of breaking RSA-2048 at roughly 20 million noisy physical qubits running for about eight hours. In May 2025 Gidney published a revision, factoring 2048-bit RSA with fewer than one million noisy qubits, a roughly twenty-fold reduction in the qubit requirement, at the cost of a longer runtime. That is the number that should shape planning. Nobody has a million-qubit machine, and the gap between one hundred and one million is enormous. But the requirement dropped by an order of magnitude in six years through better algorithms alone, with no new hardware. The trend is toward the bar getting lower, which is exactly why national agencies set deadlines in the early 2030s rather than waiting for a working machine.

The deadlines that actually bind Australian organisations

Most published post-quantum guidance is aimed at national security systems or the UK and US public sector. For an Australian financial services or regulated firm, the binding reference is the Australian Signals Directorate, and its position is more aggressive than the international consensus.

The ASD’s planning guidance for post-quantum cryptography, and the underlying Information Security Manual guidelines for cryptography, set the following:

  • Traditional asymmetric algorithms, RSA, Diffie-Hellman, ECDH and ECDSA, are no longer approved for ISM purposes after the end of 2030. Organisations are told to cease using them by then.
  • ML-KEM-1024 and ML-DSA-87 are the parameter sets approved for use beyond 2030. The smaller sets, ML-KEM-768 and ML-DSA-65, are approved now but not approved after 2030, so anything provisioned to last should be sized to the larger parameters from the start.
  • SHA-224 and SHA-256 are not approved beyond 2030, pushing hashing to SHA-384 and SHA-512, and symmetric encryption to AES-256, for anything that must remain secure past 2030.

Set against the UK NCSC roadmap, which targets full migration by 2035 across three phases, and the NSA CNSA 2.0 timeline, which reaches exclusive post-quantum use around 2033 to 2035, the Australian 2030 cut-off gives local organisations roughly five fewer years. NIST’s own draft transition guidance, IR 8547, which remains an initial public draft, proposes deprecating the legacy algorithms around 2030 and disallowing them after 2035. The direction is uniform. The Australian date is earlier. Planning to the international 2035 horizon leaves an Australian firm five years behind its own regulator’s expectation.

What businesses need to do: the four disciplines

A post-quantum program is not a procurement exercise where you buy new algorithms and switch them on. It is a change to how the organisation manages cryptography as an asset. Four disciplines carry the weight.

1. Build a cryptographic inventory

You cannot migrate what you cannot see, and almost no organisation knows where all its cryptography lives. It is embedded in TLS termination, VPN concentrators, code signing, database encryption, message queues, hardware security modules, third-party APIs, IoT firmware and the libraries inside applications nobody has recompiled in years.

The inventory has to capture, for each cryptographic use: the algorithm and key size, where the keys are stored, who owns the system, the data it protects, and how long that data must stay confidential. The ASD frames this as the first stage of its planning approach, and NIST’s National Cybersecurity Center of Excellence runs a dedicated migration to post-quantum cryptography project with practical guidance on automated discovery. The output should be structured, not a document. The emerging standard is a Cryptography Bill of Materials, and the CycloneDX CBOM format gives you a machine-readable inventory of algorithms, certificates, keys and protocols that sits alongside your software bill of materials. A CBOM you can query is what lets you answer “where do we still use RSA-2048” in minutes rather than a quarter.

2. Engineer for cryptographic agility

Cryptographic agility is the ability to change algorithms without re-architecting the systems that use them. Most existing systems fail this test: the algorithm is hard-coded, the key sizes are baked into buffer allocations, and swapping ML-KEM for HQC would mean a code change and a release. Given that NIST has already standardised a backup KEM precisely because the primary one might need replacing, agility is not optional.

In practice, agility means abstracting cryptographic operations behind an interface rather than calling a specific algorithm directly, negotiating algorithms rather than assuming them, and sizing storage and protocols for the larger keys and signatures that post-quantum schemes produce. Post-quantum certificates and signatures are meaningfully bigger than their RSA equivalents, and systems with fixed-size fields will break on contact. This is also where prioritisation happens. The systems to make agile first are the ones protecting data with the longest confidentiality lifetime, because those are the ones exposed to harvest-now-decrypt-later.

3. Deploy in hybrid, not big-bang

The mature deployment pattern is hybrid: run a classical algorithm and a post-quantum algorithm together, so the connection is secure as long as either one holds. This protects against two failure modes at once, a future quantum break of the classical algorithm, and an as-yet-undiscovered flaw in the young post-quantum implementation. Major browsers and cloud providers already default to hybrid ML-KEM key exchange for TLS, which means a large share of your web traffic may already be post-quantum protected without any action on your part. The migration work is concentrated in the systems you control directly and the ones you buy.

4. Turn vendor roadmaps into contractual commitments

For most mid-market organisations, the majority of cryptography is inside products they did not build. Your migration is gated by your vendors’ migration. That makes post-quantum readiness a third-party and supply chain risk question, not just an internal engineering one. The practical move is to add post-quantum roadmap questions to procurement and renewal: which standardised algorithms will the product support, on what timeline, and will it support crypto-agile configuration. A vendor with no answer in 2026 is a migration blocker you want to identify while you still have leverage in the contract, not in 2030 when the deadline is on you. The same discipline that keeps secrets from sprawling across modern stacks applies here: you cannot govern cryptographic material you have not catalogued and do not own.

The financial-services picture

The financial sector has moved from awareness to roadmaps. The Bank for International Settlements published BIS Paper 158, a quantum-readiness roadmap for the financial system, in mid-2025, urging institutions to begin with a cryptographic inventory now, plan through 2026 to 2028, and migrate across the late 2020s, with cryptographic agility as the organising principle. The BIS Innovation Hub’s Project Leap has run proof-of-concept work on quantum-proofing central bank payment systems. The direction of travel among central banks and market infrastructure is clear.

Australian prudential regulation has not yet caught up in specifics. As of now there is no APRA guidance that names post-quantum cryptography. Neither CPS 234 on information security nor CPS 230 on operational risk mentions it. That is not an exemption. Both standards are outcomes-based, and an APRA-regulated entity is expected to maintain information security capability commensurate with the threat and to manage the resilience of critical operations. A cryptographic estate that is undocumented, non-agile and running algorithms its own national signals directorate has told it to retire by 2030 is difficult to reconcile with either obligation. The mandate is inferred rather than explicit, but the inference is not a stretch, and it is the kind of gap an audit will eventually test.

Frequently asked questions

Do we need to replace all our encryption immediately? No. The urgency is set by data confidentiality lifetime. Session-bounded and short-retention data can wait. The priority is data that must stay confidential into the 2030s and is exposed to interception now, and long-lived signing keys and certificate authorities. Start the inventory immediately, because that is what tells you what is actually urgent.

Is our encrypted data being stolen right now? Assume long-lived, high-value encrypted data in transit could be collected by a well-resourced adversary today under a harvest-now-decrypt-later model. This is the stated position of CISA, the NSA and NIST. It does not mean the data is decrypted yet. It means the clock started when the traffic was captured, not when a quantum computer arrives.

When will a quantum computer break RSA? Nobody knows, and anyone giving you a firm date is guessing. Current machines are around one hundred qubits; breaking RSA-2048 needs on the order of a million noisy qubits per the most recent estimates. The gap is large, but the estimated requirement has fallen by an order of magnitude in six years, which is why regulators set deadlines rather than waiting for proof.

What is the single most important first step? A cryptographic inventory. Every subsequent decision, what to migrate first, which vendors are blockers, whether you can meet the 2030 date, depends on knowing where your cryptography is and what it protects. It is also the step most organisations skip, which is why they discover their exposure late.

Where to start

The organisations that will manage this well are not the ones that pick the right algorithm first. They are the ones that build the capability to see, change and govern their cryptography as an asset, then use that capability to migrate on a schedule that meets the 2030 deadline. The algorithms are standardised and the deadlines are published. The work now is inventory, agility, hybrid deployment and vendor pressure, run as a governed program rather than a fire drill.

If you want a view on how this sequences against your other obligations, the post-quantum planning timeline sets out the year-by-year horizon, and a zero-trust architecture that avoids vendor capture is the environment in which crypto-agility is easiest to achieve.

Get started

Bring AI risk under board oversight in two weeks.

A thirty-minute discovery call costs nothing. We confirm fit, scope, and timing, then issue a fixed-fee statement of work within two business days.