Australian organisations are now staring at a wall of post-quantum dates. ASD’s ladder runs from a refined transition plan by the end of 2026, through critical-system migration from 2028, to approved algorithms by 2030. The PSPF adds a July 2027 plan requirement for government entities, and the US federal targets sit at 2030 and 2031. Faced with that shelf, the natural instinct is to ask which date you have to hit. But almost none of those dates self-execute for a company outside government, and the question that actually matters is which instrument binds you, through what mechanism, and on what date.
This piece separates the instruments by legal character: political direction in Executive Order 14412, the agency instruction in OMB M-26-15, and ASD guidance that only gains force through contract, procurement or sector regulation.
Everything here reflects October 2026, and the wording moves fast, so check the current text before acting. This is the shift from roadmap to deadline.
Why did the US move its federal deadline from 2035 to 2030?
The pull-forward compressed the schedule; it did not signal that the capability had arrived early. Executive Order 14412, signed on 22 June 2026, sets a 31 December 2030 deadline for agencies to move their most sensitive systems to post-quantum encryption, and a 31 December 2031 deadline for post-quantum authentication. It binds High Value Assets (the US government’s designated crown-jewel systems) and ‘high impact’ systems under FIPS 199, not the whole estate.
The operative text is OMB Memorandum M-26-15, issued 24 June 2026. It runs a five-phase schedule from 2026 to 2035, and its key sentence is hedged in a way that matters more than the headline date: agencies must migrate “with the objective of mitigating as much quantum risk as feasible by December 31, 2030”. “As feasible by” is a qualified target; the 2031 signature phase and the 2035 full-migration phase sit behind it.
Why compress at all? Harvest-now-decrypt-later makes the exposure retroactive. Encrypted traffic captured today can be stored and broken open once a cryptographically relevant quantum computer arrives, so anything recorded now is already at risk. A 2035 endpoint assumed data captured now would still be held in 2035, and federal record-retention periods do not allow that assumption: the data outlives the window, so the exposure does too. And the 120-day inventory and migration-plan filing has to precede any technical work, pulling the whole schedule left. That discovery step is the bottleneck, which is why the inventory obligation inside M-26-15 matters: one of 24 agencies had a complete inventory almost three years after OMB first asked. NIST IR 8547 anchors the change, deprecating RSA and elliptic-curve cryptography by 2030 and disallowing them by 2035.
Which post-quantum rules actually apply to an Australian software company, and what is due first?
The answer is that no Australian statute imposes a single post-quantum deadline on you. What matters is which instrument reaches you, and through what mechanism.
Executive Order 14412 is political direction: it set the clock in motion but does not bind a company outside the US. OMB M-26-15 is the operative instruction to US agencies, with a 120-day inventory and migration-plan filing and a five-phase schedule. ASD’s guidance is neither. It only binds you through a customer contract, a procurement gate or sector regulation.
So does M-26-15 apply to you? For you it does not, directly, unless you supply into a US federal contractor or a regulated entity, in which case the obligation reaches you through the contract, and through the ISM where your customers must comply. The sequence that actually reaches you starts with a refined transition plan by end-2026, critical systems migrated from 2028, and traditional asymmetric cryptography out of use by 2030. Against that, the US lands 2030 for key establishment and 2031 for signatures, and the EU sets 2035 as full migration. This is the regulatory clock.
2030 alone carries roughly 21 separate milestones across jurisdictions, which is the scheduling problem if you sell or operate in more than one market. postquantum.com’s tracker lists 162 of them, and the timeline itself concedes it cannot tell you which ones apply to you. Treat it as a map, and confirm every obligation against the primary text.
On algorithms, FIPS 203/204/205 and ‘ASD-approved algorithms’ overlap heavily because both trace to NIST’s ML-KEM, ML-DSA and SLH-DSA. But ‘approved’ status is a jurisdictional determination; it does not follow automatically from the technical standard. As at October 2026, the ISM approves ML-DSA-65, ML-DSA-87, ML-KEM-768 and ML-KEM-1024, while leaving out the smaller NIST sets such as ML-DSA-44 and ML-KEM-512. Verify against the current ISM chapter rather than assuming a FIPS-validated module satisfies Australian requirements, because that same chapter is where the first obligation actually sits.
What are the ASD’s milestones, and what has to be done before the end of 2026?
The end-2026 milestone asks for a refined transition plan: scope, ownership, a system inventory at some level of fidelity, and a sequencing decision. No production system has to be migrated by then. Those four inputs are what the 2028 critical-systems and 2030 approved-algorithms dates consume.
The authoritative wording lives in two places. The ISM cryptography chapter holds the transition-plan control (ISM-2073) and the procurement-and-development control (ISM-1917), along with the post-2030 sunsets for DH, ECDH, ECDSA and RSA. ASD’s standalone “Planning for post-quantum cryptography” guidance carries the transition phases. ASD recommends organisations ‘cease using’ traditional asymmetric cryptography by 2030. That is a retirement date; systems are not switched off on the day.
Its force arrives through a contract, a procurement gate or a regulator that adopts it. The two mechanisms most likely to convert guidance into an obligation are the SOCI Act 2018, which folds quantum into the risk-management duties of SOCI entities, and APRA CPS 234, which demands an information security capability commensurate with the threats you face. Neither names a post-quantum date: absence of a named date is not absence of obligation. The PSPF adds the one concretely dated plan requirement, July 2027, and government entities pass it down through tenders.
If you have to take this upstairs, the vocabulary is ready-made: accountable executive, documented risk acceptance, documented process. That is the board framing this article hands off to.
What binds an organisation is the instrument that reaches it, and the first thing that reaches most Australian organisations is a plan, rather than a completed migration.
What is due first is that plan. The 2028 critical-system and 2030 approved-algorithm dates follow from it.
The vocabulary is part of the deliverable: “as feasible by December 31, 2030” is a qualified target, and being able to say that to a board is what separates a defensible plan from a panic migration. Check the current ISM cryptography chapter and ASD’s planning guidance, and treat every tracker and secondary summary as a pointer rather than a source of obligation. The plan is your entry point to the full post-quantum readiness picture.
Frequently Asked Questions
Does OMB M-26-15 apply to my Australian company?
No, not directly. M-26-15 instructs US federal agencies, not foreign private companies. It reaches an Australian organisation only by flow-down: if you supply a US federal contractor or agency, your customer’s filing obligations (the 120-day inventory and migration plan) become conditions in your contract. Check your supply agreements before assuming you are out of scope.
Is the ASD’s end-2026 deadline a plan or a migration?
It is a plan. The end-2026 milestone calls for a refined transition plan covering scope, ownership, a system inventory at some level of fidelity, and a sequencing decision. No production system has to be migrated by then. This is the single most common misreading, and correcting it usually removes a great deal of unnecessary panic from the board pack.
Are ASD-approved algorithms the same as FIPS 203/204/205?
Not formally, though they overlap heavily. Both trace back to NIST’s standards (ML-KEM, ML-DSA and SLH-DSA), but “approved” is a jurisdictional determination made by ASD, not a technical equivalence. Verify against the current ISM cryptography chapter rather than assuming a FIPS-validated module satisfies Australian requirements. The parameter sets named in the ISM are the practical reference point.
What happens if my organisation misses the end-2026 milestone?
Nothing automatic, for a private company. ASD guidance is not self-executing, so there is no statutory penalty attached to the date itself. The consequence arrives elsewhere: a customer contract warranty, a procurement gate, an APRA notification obligation, or a board asking why the 2028 critical-systems date now looks unachievable because sequencing was never decided.
Is the ASD 2030 deadline a legal requirement or just guidance?
For most private organisations it is guidance, which gains legal force only when something else adopts it: a contract, a procurement condition, or sector regulation such as the SOCI Act 2018 or APRA CPS 234. Government entities sit differently, because the PSPF and ISM apply to them directly. Establish which category you are in before treating 2030 as a hard legal line.
Do I need to stop using RSA and ECDSA before 2030?
The ISM does not approve traditional asymmetric cryptography beyond 2030, including DH, ECDH, ECDSA and RSA, for the classifications it governs. That is a deprecation signal rather than a switch-off date, and it is why the 2028 critical-systems migration matters. Inventory where those algorithms sit now, because discovery is the part that reliably runs late.
How do I know whether my sector regulator has issued a post-quantum position?
Ask your regulator directly and check its published guidance rather than relying on a tracker. APRA has framed expectations through CPS 234’s information security obligations, and SOCI Act entities carry critical infrastructure risk management duties, but neither publishes a standalone post-quantum date for all regulated firms. Absence of a named date is not absence of obligation.
What is harvest-now-decrypt-later, and why does it change my timeline?
It means an adversary can capture encrypted traffic today and decrypt it once a cryptographically relevant quantum computer exists. Exposure therefore begins at capture, not at decryption. That retroactivity is why a 2035 endpoint was untenable for long-retention data, and why the US compressed its schedule rather than waiting for the capability to arrive.
Does the PSPF July 2027 requirement apply to my private company?
Not directly, but it can reach you. The PSPF binds Australian government entities, which must have transition plans in place by July 2027. Those entities pass the obligation down through contracts and procurement, so if you supply government, expect the requirement to appear in tender documentation well before the date itself.
Should I use the postquantum.com milestone tracker as my compliance source?
Use it as a map, not as the authority. Its 162-milestone cross-jurisdiction view is genuinely useful for seeing how deadlines cluster (2030 alone carries roughly fifteen), but it is a secondary source. Every obligation must be confirmed against the primary text: the ISM cryptography chapter, ASD’s planning guidance, or the regulator’s own instrument.
How do I explain “as feasible by December 31, 2030” to a sceptical board?
Read the hedge literally. “As feasible by” is a compression target with an acknowledged feasibility qualifier, not a completion mandate, and it sits in front of a 2031 signature target and a 2035 full-migration phase. Say that plainly. It reframes the board conversation from a panic migration to a defensible, sequenced plan with named owners.
Can we migrate critical systems before we have a full inventory?
You can start, but the sequencing decision will be weak. The end-2026 plan requires an inventory at some level of fidelity, precisely because you cannot rank critical systems you have not found. Begin with the systems carrying long-retention data and external dependencies, and document the gaps explicitly rather than waiting for completeness.
