Most of the encryption that protects Australian organisations today rests on mathematics that a large enough quantum computer could break. No such machine exists yet. ASD's guidance is that this is not a reason to wait, and it has put dates on the work.
In its Information security manual (ISM), ASD recommends ceasing the use of traditional asymmetric cryptography, including RSA, Diffie-Hellman, ECDH and ECDSA, by the end of 2030. It has also set two earlier milestones, and the first falls at the end of this year. This article explains what ASD says, what it means for different kinds of organisation, and how to turn it into a plan that a board can oversee.
What ASD has actually said
ASD's publication Planning for post-quantum cryptography (last updated in September 2025) sets out three milestones for organisations working towards a 2030 finish:
- By the end of 2026: organisations should have a refined plan for their transition to post-quantum cryptography. The plan should account for security goals, risk tolerances, dependencies and the value of the organisation's data.
- By the end of 2028: organisations should have started the transition, beginning with critical systems and data. ASD names three priorities: systems critical to the organisation's function, systems that handle highly sensitive, classified or long-lived data, and systems likely to be difficult or slow to update.
- By the end of 2030: organisations should have completed the transition.
ASD adds that the 2030 target already includes contingencies for disruptive technology breakthroughs and other external factors, and that organisations should build in their own contingencies for internal delays. The dates are not a comfortable buffer.
The ISM's Guidelines for cryptography (September 2026 edition) back this up in control language. The ISM states that RSA, DH, ECDH and ECDSA will not be approved beyond 2030. It requires that a post-quantum cryptography transition plan is developed, implemented and maintained, and it requires that new cryptographic equipment, applications and libraries support ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030.
Why a 2030 date matters now: harvest now, decrypt later
The quantum threat is often framed as something that starts on the day a capable machine arrives. ASD names a different problem. An adversary can copy encrypted traffic or stolen data today, store it, and decrypt it once a cryptographically relevant quantum computer (CRQC) exists. ASD calls this a "harvest now, decrypt later" attack and says data protected by classical encryption may be exposed to it.
The exposure depends on how long the data needs to stay confidential. A session token that expires in an hour is not worth harvesting. Customer identity records, health information, merger documents, legal advice, defence-related material and long-term contracts are different. If data must stay secret for 15 years, the relevant deadline is 15 years before a CRQC appears, and nobody can say when that is. ASD notes that the timeline for a CRQC is uncertain and that deploying protections often takes longer than expected. Those two facts are the case for starting now.
Who this applies to
The ISM is ASD's cyber security framework for government. The guidelines page is written for large organisations and government, and the transition plan control applies at every classification level the ISM covers, from non-classified upwards. Government entities, and suppliers that are contractually required to apply the ISM, should treat the milestones as their own.
For everyone else the ISM is not a legal requirement, but ASD describes it as a framework any organisation can apply, and its post-quantum planning page is marked as written for small and medium business and large organisations as well as government. Financial services firms, critical infrastructure operators and any organisation holding long-lived sensitive data have good reasons to follow the same timetable. Customers and regulators often borrow ASD's benchmarks, and a supplier that cannot answer questions about its cryptography will be asked to.
Step 1: build a cryptographic inventory
ASD's LATICE framework has five phases: locate, assess, triage, implement, and communicate. Locate comes first because nothing else works without it. Most organisations cannot say where they use RSA or elliptic curve cryptography, because it sits inside products they did not write.
ASD suggests a cryptographic bill of materials (CBOM), which works like a software bill of materials but records cryptographic products, libraries, algorithms, protocols, parameters and configurations. It also says a first version can be a simple list of the critical security functions that depend on cryptography. Start there and improve it.
Places to look include:
- TLS on websites, APIs and internal services, including load balancers and gateways
- VPNs and remote access platforms
- Public key infrastructure, certificate authorities and the certificates they issue
- Code signing and software update mechanisms
- SSH keys and administrative access paths
- Identity providers, single sign-on, smartcards and tokens
- Databases, backups and key management systems
- Embedded, operational technology and Internet of Things devices
- Third-party software as a service, managed services and cloud platforms
ASD's vendor guidance points out that in industrial control, access control and network devices, cryptography is often embedded, hard to update and tied to long asset lifecycles. Those items may need vendor support or hardware replacement, so flag them early.
Step 2: triage by data lifespan and sensitivity
Once the inventory exists, rank the systems. ASD's triage factors include whether a system handles sensitive or classified data, interacts with external organisations, is expected to transition easily, supports legacy interoperability, is bespoke or commodity, has other protections that reduce the exposure, and follows a particular refresh cycle.
A practical way to apply this is to give each system two scores. The first is how long its data must stay confidential. The second is how hard the system will be to change. A system that scores high on both, such as a long-retention archive on a fixed-function appliance, goes to the top of the list. A system that holds short-lived data and updates automatically can wait.
Signing and authentication need separate treatment from encryption. ASD's vendor questions ask whether suppliers distinguish between signing, encryption and authentication risks, because each has a different impact and timeline. Long-lived signatures, such as firmware signing and root certificates, are hard to change once deployed, so they need early attention even though they are not exposed to harvesting in the same way as stored ciphertext.
Step 3: ask your vendors the right questions
Much of your cryptography is controlled by someone else. ASD published Post-quantum questions to ask your vendors in July 2026 for that reason. It explains that vendors often implement and control the cryptography, so their readiness determines yours, and that weaknesses or delays in the supply chain can undermine even a strong internal plan.
ASD says organisations are not expected to ask every question of every vendor. Choose questions based on the risk of the product, how much cryptographic control the vendor holds, and the sensitivity and lifespan of the data involved. Questions worth prioritising include:
- Do you keep a current inventory of cryptographic dependencies, such as a CBOM?
- Is any cryptography hardcoded, fixed or bound to hardware, and how is cryptography updated?
- Are firmware and boot processes updatable to support post-quantum signature schemes?
- Which products or services will be ready early enough for customers to complete rollout before the end of 2030?
- Which components need hardware replacement or re-architecture?
- Which post-quantum algorithms will you support, and is the implementation production ready?
- Is post-quantum support included in base licensing?
- Do you support hybrid modes only as a temporary measure, and when will you move to post-quantum only?
ASD also lists common warning signs in vendor answers: limited visibility of cryptographic use, general assurances instead of dates, unclear or deferred timelines, proprietary or opaque cryptography, post-quantum support treated as an optional extra, and no clear governance or ownership. Build these questions into procurement, contract renewals and vendor assurance reviews now, before long contracts lock in choices you cannot change.
Step 4: design for crypto-agility
Crypto-agility means being able to change algorithms without rebuilding the system. ASD's vendor guidance links it to patch-based updates that avoid large-scale system replacement. In practice that means keeping algorithm choices in configuration rather than code, using standardised and reputable libraries, and avoiding new systems that hardwire RSA or elliptic curves with no upgrade path.
The ISM approves ML-DSA and ML-KEM, which are based on the NIST standards FIPS 204 and FIPS 203 (NIST published these, along with FIPS 205, in August 2024). Within those, the ISM approves ML-KEM-768 and ML-KEM-1024, and ML-DSA-65 and ML-DSA-87, and prefers the larger parameter sets. It also states that ML-KEM-768 and ML-DSA-65 will not be approved beyond 2030. A system that adopts the smaller sets now will need another change before the end of the decade. Aiming for ML-KEM-1024 and ML-DSA-87 from the start avoids that.
ASD also warns against rushing ahead of standardised, verified implementations. Do not build your own post-quantum code or deploy experimental libraries in production.
Hybrid schemes and the risk of migrating twice
A post-quantum/traditional hybrid scheme combines a post-quantum algorithm with a traditional one, for example ML-KEM alongside RSA. Vendors increasingly offer hybrid modes, so you may inherit one without choosing it.
ASD's position, in both its planning page and the ISM, is that it does not recommend hybrid schemes but does not prohibit them. It says they may be considered for interoperability and resiliency reasons. It also says that once a CRQC exists the traditional half is obsolete, so all organisations should expect to move to purely post-quantum algorithms later. The ISM adds that hybrid schemes bring extra complexity and overhead, and tells organisations that choose them to keep in mind the eventual additional cost of moving to a pure post-quantum scheme.
The practical lesson is to treat hybrid as a stage, not a destination. Record where hybrid modes are enabled, ask each vendor how and when they will move to post-quantum only, and put that second change on the roadmap so that it does not arrive as a surprise budget item.
A 12-month roadmap
ASD sets the milestones but not the schedule for any one organisation. The plan below is a suggested way to use the next year, with the first milestone in mind. Adjust it for your size and risk.
- Months 1 to 3: Name an executive owner. Build the first-pass inventory from architecture diagrams, certificate and key management tools, network scans and vendor lists. Approve a written transition plan by the end of 2026.
- Months 4 to 6: Score systems by data lifespan and difficulty of change. Send vendor questions to your most critical suppliers and log the answers. Add post-quantum requirements to procurement templates.
- Months 7 to 9: Run test deployments of approved algorithms in a non-production environment, using vendor-supported releases. Identify systems that need hardware replacement and add them to capital planning.
- Months 10 to 12: Begin migrating the highest-priority systems, with a rollback plan. Report progress to the board and review the roadmap against the 2028 milestone.
Governance and board reporting
This is a multi-year programme that cuts across infrastructure, applications, procurement and risk. It needs an accountable executive, a place on the risk register and a regular reporting line. ASD's vendor guidance asks suppliers about executive ownership of their own transitions, and organisations should hold themselves to the same standard.
Useful measures for board reporting include the percentage of systems inventoried, the number of high-priority systems with a funded migration path, the number of critical vendors that have given dated commitments, and the number of systems that still depend on hardware replacement. Questions a board can ask:
- Who owns the post-quantum transition, and where is it on the risk register?
- Do we have a written plan that meets ASD's end-of-2026 milestone?
- Which data do we hold that must stay confidential beyond 2030?
- Which critical vendors have not given us a dated roadmap?
- What budget is set aside for hardware replacement and for a possible second migration away from hybrid modes?
Key takeaways
- ASD recommends ceasing traditional asymmetric cryptography (RSA, DH, ECDH, ECDSA) by the end of 2030, and the ISM states these algorithms will not be approved beyond 2030.
- ASD's milestones are a refined transition plan by the end of 2026, a transition under way for critical systems and data by the end of 2028, and completion by the end of 2030.
- Harvest now, decrypt later means long-lived sensitive data is exposed before any quantum computer exists, so data lifespan should drive priority.
- The ISM applies directly to government and suppliers bound to it. For other organisations it is a benchmark worth following, not a legal obligation.
- Start with a cryptographic inventory, then triage, and use ASD's vendor questions in procurement and renewals.
- ASD does not recommend hybrid schemes and expects a later move to pure post-quantum, so plan for that second step.
- The ISM approves ML-KEM-768 and ML-KEM-1024, and ML-DSA-65 and ML-DSA-87, but the smaller sets end at 2030. Prefer ML-KEM-1024 and ML-DSA-87.
CyberCorp's GRC specialists help Australian organisations turn ASD guidance into a costed, board-ready cryptographic transition plan, from inventory and risk triage to vendor assurance and reporting. Schedule a GRC Assessment to see where your organisation stands against ASD's 2026 milestone, or learn more about our Cybersecurity Risk Management services.
