The Australian Signals Directorate requires traditional asymmetric cryptography (RSA, Diffie Hellman, ECDH and ECDSA) to be out of use by the end of 2030. That is five years earlier than NIST, the UK's NCSC, the EU and Canada.
The first ASD milestone is a refined transition plan by the end of 2026, roughly four months from now.
95% of organisations have no defined quantum roadmap, according to ISACA's poll of more than 2,600 professionals, even though 56% say they are worried about harvest now, decrypt later attacks.
Google Cloud published its own migration roadmap on 11 August 2026, committing to full post quantum readiness by 2029, a year ahead of the ASD deadline its customers have to meet.
1. The deadline that binds you is Australian, not American
2. Data you encrypt today can be broken later
3. What ASD is actually asking for by December
4. Cryptographic agility is the real deliverable
5. The honest version of the quantum timeline
6. What we would do with the next four months
7. Frequently asked questions
Most of the post quantum coverage an Australian or New Zealand CTO reads is written for an American audience, and it sets the wrong clock. NIST's transition schedule deprecates 112 bit RSA and elliptic curve algorithms in 2030 and disallows all classical public key cryptography in 2035. The UK's NCSC, the European NIS Cooperation Group and Canada's cyber centre all land on 2035 as well. Read only that coverage and you would reasonably conclude you have nine years.
You do not. ASD's Information Security Manual requires that traditional asymmetric cryptography is no longer in use after the end of 2030, and that new cryptographic equipment and software procured from now on supports ML KEM 1024, ML DSA 87, SHA 384, SHA 512 and AES 256. Australia set the most aggressive published deadline in the developed world, and it did so quietly, through an ISM revision rather than a press cycle.
Alt text: Bar chart comparing post quantum deadlines by jurisdiction: Australia's ASD ISM requires traditional asymmetric cryptography retired by 2030, five years ahead of NIST IR 8547, the UK NCSC, the EU and Canada at 2035. Source: ASD ISM, NIST IR 8547, Executive Order 14412, UK NCSC, EU NIS Cooperation Group
The obligation is not uniform, and it is worth being precise about who it actually binds. The ISM is mandatory for Commonwealth entities and, in practice, for the technology providers contracting to them. For everyone else (an APRA regulated insurer, a listed retailer, a New Zealand health provider) it is prudential rather than statutory. But prudential is not the same as optional. APRA's CPS 234 and CPS 230 are outcomes based standards, and the ISM is the reference an Australian regulator, an auditor or a plaintiff's lawyer will reach for when asking whether your encryption was reasonable. If you are a New Zealand organisation serving Australian customers or bidding for Commonwealth work, you inherit the 2030 date through your contracts whether or not your own regulator has published a timeline.
The reason this is not a 2030 problem is that the threat is retrospective. An adversary who copies encrypted traffic or an encrypted backup today does not need to break it today; they need to store it until a cryptographically relevant quantum computer exists. Any data whose sensitivity outlives that gap (health records, insurance claims, source code, superannuation data, legal privilege, long lived credentials, anything with a statutory retention period) is exposed from the moment it crosses the wire, not from the moment the machine is switched on.
This is what "harvest now, decrypt later" means in practice, and it is why the migration cannot be sequenced behind other 2029 work. In our experience the conversation gets much more concrete once someone asks a simple question of each system: how long does this data need to stay confidential? Anything answering "more than five years" belongs in the first migration wave, regardless of how modern the system otherwise looks.
Alt text: Bar chart of ISACA Quantum Computing Pulse Poll results: 95% have no defined quantum roadmap, 62% worry quantum will break today's encryption, 56% are concerned about harvest now decrypt later, 55% have taken no preparation steps, 44% have never heard of the NIST post quantum standards, and only 5% have a defined quantum strategy. Source: ISACA Quantum Computing Pulse Poll, 28 April 2025
The awareness gap here is unusually wide. ISACA's poll of over 2,600 digital trust, cybersecurity, audit and risk professionals found 62% worried that quantum computing will break today's internet encryption and 56% specifically concerned about harvest now, decrypt later, but 95% with no defined roadmap, 55% who have taken no preparation steps at all, and 44% who had never heard of the NIST post quantum standards. Concern is not scarce. Ownership is.
Jamie Norton, ISACA board director
ASD's guidance stages the transition across three dates: a refined transition plan by the end of 2026, transition commenced on the most critical systems and data by the end of 2028, and traditional asymmetric cryptography retired by the end of 2030. The first of those is four months away, and it is the only one you can still comfortably meet.
A refined plan is a lower bar than a migration, but it is a higher bar than a slide. It means a cryptographic inventory: every place your organisation uses public key cryptography, including the places you inherited rather than chose: TLS termination, VPN tunnels, code signing, document signing, HSMs, hardware roots of trust, database and backup encryption, SSH, embedded devices, and every SaaS platform holding your data. It means a data lifetime assessment against that inventory. And it means a costed, sequenced, owned plan, with named accountability rather than a standing agenda item.
The inventory is where these programmes stall, and it is worth being blunt about why: most enterprises genuinely do not know where all their cryptography lives. It is embedded in vendor products, in firmware, in certificates issued by a team that has since been restructured. Discovery is the expensive part. It is also the part that cannot be compressed later, which is precisely why ASD put it first.
JURISDICTION
INSTRUMENT
DEADLINE
WHO IT BINDS IN ANZ
Australia
ASD Information Security Manual
End of 2030
Mandatory for Commonwealth entities and their major technology providers; prudential benchmark for everyone else
United States
Executive Order 14412 (22 June 2026)
31 Dec 2030 encryption; 31 Dec 2031 signatures
Federal agencies and contractors; reaches ANZ firms selling into US government
Global standard
NIST IR 8547
Deprecated 2030; disallowed 2035
Not binding, but the reference most vendors build to
United Kingdom
NCSC migration timelines
Discovery and plan by 2028; complete by 2035
UK operations and UK regulated subsidiaries
European Union
NIS Cooperation Group roadmap
2035
EU operations; relevant to NIS2 scoped entities
The mistake we see most often is treating this as a single algorithm swap with an end date. It is not. ML KEM and ML DSA are the current answers; they will not be the last ones, and the standards bodies have been explicit that hybrid modes and parameter changes will keep arriving. What survives the decade is not a particular algorithm but the ability to change algorithms without a project.
There is a useful proxy for whether you have that ability, and it has nothing to do with quantum computing. Under CA/Browser Forum ballot SC 081v3, the maximum lifetime of a public TLS certificate has already dropped from 398 days to 200, falls to 100 days in March 2027, and reaches 47 days in March 2029. Domain validation reuse windows compress alongside it. An organisation that cannot rotate certificates automatically today will be renewing them roughly eight times a year by 2029, and an organisation that cannot do that will not manage a cryptographic migration.
Alt text: Bar chart showing maximum public TLS certificate validity falling from 398 days to 200 days now, 100 days from March 2027 and 47 days from March 2029 under CA/Browser Forum ballot SC 081v3. Source: CA/Browser Forum, Ballot SC 081v3, adopted 11 April 2025
We would treat certificate automation as the first funded piece of post quantum work, because it pays for itself on operational grounds alone and it builds exactly the discovery, inventory and rotation muscle the 2030 deadline needs. Your hyperscaler is already moving on the same assumption. Google Cloud's roadmap, published on 11 August 2026, commits to mitigating store now decrypt later exposure by the end of 2027, quantum safe signatures and key management by the end of 2028, and full post quantum readiness by 2029, with load balancers and API endpoints already running hybrid ML KEM key exchange. That helps with the traffic you send to Google. It does nothing about the certificate your payments partner issues, or the signing key in your build pipeline.
No machine capable of breaking RSA 2048 exists today, and nobody credible claims one is imminent. Anyone selling you a countdown clock to a specific Q Day is selling you a guess. That is the honest caveat, and it belongs in any board paper on this subject.
What has changed is not the hardware but the arithmetic. In 2019, Gidney and Ekerå estimated that factoring a 2,048 bit RSA key would take around 20 million noisy qubits running for eight hours. In May 2025, Craig Gidney published a revised estimate: fewer than one million noisy qubits, running for under a week. That is a 95% reduction in the resource requirement achieved entirely through better algorithms, with no hardware breakthrough involved.
Alt text: Comparison of published resource estimates for factoring a 2,048 bit RSA key: 20,000,000 noisy qubits over 8 hours in the 2019 estimate, versus fewer than 1,000,000 noisy qubits over under a week in the 2025 estimate. Source: Gidney and Ekerå, arXiv:1905.09749; Gidney, arXiv:2505.15917
The implication for planning is not that Q Day is close. It is that the estimate moves in one direction, and it moves without warning. A migration programme scoped against a fixed threat date is fragile in a way that a programme scoped against a regulatory date is not. The 2030 obligation is knowable; the threat is not. Plan against the one you can read.
The ISM's 2030 date is a compliance obligation, not a prediction that encryption breaks in 2030. Conflating the two damages your credibility with a technical audience and invites the reasonable objection that the whole thing is vendor driven. The defensible framing is narrower and stronger: the deadline is fixed and published, discovery takes years, and data encrypted today may need to stay confidential past 2035.
If you hold Commonwealth contracts or sell technology into government, the 2030 date is already a procurement question and will appear in your next tender response. If you are APRA regulated, expect the ISM to be the yardstick against which "reasonable" encryption is judged, whether or not it is named in the standard. If you are a New Zealand organisation with Australian customers, you will inherit the deadline contractually before your own regulator sets one. In all three cases the practical answer this quarter is the same: fund the inventory, not the migration.
TIMEFRAME
ACTIVITY
TYPICAL OWNER
OUTPUT
Sep 2026
Scope and mandate the cryptographic inventory; name an accountable owner
CISO / CTO
One page mandate, funded discovery
Oct 2026
Automated discovery across TLS, VPN, code signing, HSMs, databases, backups, SaaS
Security engineering
Cryptographic bill of materials
Nov 2026
Data lifetime assessment; classify by confidentiality horizon
Data governance, legal
Prioritised system list
Nov 2026
Vendor questionnaire: PQC roadmap and dates from every material supplier
Programme lead
Board ready plan meeting the ASD milestone
2027 to 2028
Execute wave one; commence critical system migration
Engineering
ASD 2028 milestone met
None of this requires a decision about quantum computing. It requires a decision about whether you know where your cryptography is. Most organisations do not, and the four months between now and the ASD milestone is enough time to find out, but only if the discovery work starts this quarter rather than after the next planning cycle.
No. The ISM is mandatory for Commonwealth entities and flows to their major technology suppliers through contract. For a private company it is a prudential benchmark. The practical significance is that it is the benchmark an Australian regulator, auditor or court is most likely to reference when assessing whether your encryption was reasonable, and that it will appear in government adjacent tenders well before 2030.
No, and it is important not to argue it that way. 2030 is a compliance date, not a forecast. No quantum computer capable of breaking RSA 2048 exists, and none is publicly expected imminently. The case for acting now rests on the retrospective threat: data captured today and decrypted later, and on the fact that discovery takes years.
Directly, only if you hold Australian government contracts or serve Australian regulated customers, in which case the requirement reaches you through procurement. Indirectly, yes: the vendors you buy from are building to the ASD and NIST dates, and your certificate and key management practices face the same CA/Browser Forum changes regardless of jurisdiction.
Partly. Hyperscalers are migrating the infrastructure you rent: Google Cloud has committed to full readiness by 2029, and hybrid post quantum key exchange is already live on its load balancers and API endpoints. What they cannot do is inventory your application layer cryptography, your code signing, your partner integrations or the encrypted archives you hold. That work is yours.
It varies too much with estate size and documentation quality for a defensible general figure, and we would not give you one. What we can say is that discovery is consistently the largest single line item in these programmes and the one most often underestimated, because cryptography is embedded in vendor products and firmware rather than sitting in a register.
Deploy in hybrid mode where your platforms already support it: hybrid key exchange gives you post quantum protection against harvest now attacks while retaining classical security if a new algorithm is weakened. Avoid committing to bespoke implementations. The more valuable investment right now is agility: automated certificate and key rotation, so that the next algorithm change is an operation rather than a programme.
Maheen Abeysooriya
Software Engineer Intern
Blog
