Everyone Heard 2030. The First Post-Quantum Milestone Is the End of 2026.

Quantum computing arrives in most boardrooms as a 2030 problem, which is a comfortable place to file it. Four years is somebody else’s budget cycle.

The date worth writing down is nearer than that. ASD’s recommended transition timeline puts the first milestone at the end of 2026, and what it asks for is not a cryptographic upgrade. It asks for a plan.

That is a much smaller ask, and a much harder one to fake.

What ASD has recommended, and what it has made a control

Two different things are often reported as one, and the difference matters if you are the person who has to answer for it.

The milestones are recommendations. In its guidance on planning for post-quantum cryptography, ASD sets out a timeline:

The plan itself is a control. In the Information Security Manual, updated September 2025:

ISM-2073: A post-quantum cryptography transition plan is developed, implemented and maintained.

And alongside it:

ISM-1917: The development and procurement of new cryptographic equipment, applications and libraries ensures support for the use of ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030.

Be precise about what that means for you. ISM controls bind Commonwealth entities through the Protective Security Policy Framework. If you are a private-sector organisation, the ISM is guidance rather than law. What has changed is that a post-quantum transition plan is no longer buried in advice. It has a control number, a revision history and a date, which is the form obligations take shortly before somebody starts asking for them in tenders.

ISM-1917 is worth reading twice if you buy anything. It reaches procurement, and it names the algorithms: ML-DSA-87 and ML-KEM-1024, the highest parameter sets of the two post-quantum algorithms ASD has approved. If you are signing a multi-year contract for anything that does cryptography, that is the line to put in front of the vendor now, because the equipment you buy this year will still be running in 2030.

Harvest now, decrypt later is a retention question

The reason the timeline starts before the threat exists has a name, and ASD uses it.

Harvest now, decrypt later describes an attacker who copies encrypted data today and waits. They do not need to break the encryption now. They need only to keep the ciphertext until a machine exists that can.

Read as an auditor, that turns a technology question into a records retention question, and it lands squarely in clause 6.1.2 risk assessment. The consequence of a confidentiality breach is usually scored against how sensitive the data is today. Harvest now, decrypt later asks a different question: how long does this data stay sensitive?

ASD’s own triage guidance points the same way. It tells organisations to prioritise systems that handle data with long-lived confidentiality requirements. So:

• A password database is acutely sensitive today and worthless once rotated.
• Employee health records, legal advice, merger material, intellectual property and anything with a statutory retention period stay sensitive for decades.

The second category is what a harvesting attacker is collecting. If your risk assessment scores both the same way, it is not modelling this risk at all. That is a change to your risk criteria rather than to your cryptography, and it costs nothing to make.

You cannot plan what you cannot locate

The first phase of ASD’s framework is the one that stops most organisations. ASD calls the framework LATICE: Locate, Assess, Triage, Implement, and Communicate and educate.

Locate means discovering and documenting where you use traditional asymmetric cryptography, across cloud services, applications, hardware and operational technology. ASD’s method for that is a cryptographic bill of materials, which it compares directly to a software bill of materials: an inventory of cryptographic products, libraries, algorithms, protocols, parameters, versions and configurations.

Most organisations react to that as an impossible project. ASD says otherwise, and the line is worth quoting because it lowers the barrier:

Initially, organisations’ high-level CBOMs may be a simple list of critical security functions that they rely on for cryptography to perform.

Not every library. A list of the things that would stop working. That is an afternoon, not a programme.

This is the same argument that runs through the assets nobody put on the register and through the certificate inventory in TLS certificates drop to 100 days in March 2027, and the connection is not ours. ASD’s introduction names TLS as its example of what a quantum computer threatens: web applications using TLS to authenticate users and encrypt data in transit. Your certificate inventory is the first page of your CBOM. If you built one for the certificate schedule, you have started this without meaning to.

Under Annex A this is A.5.9, inventory of information and other associated assets, doing work most registers were never built for.

What a cryptography policy usually says, and what A.8.24 asks

Every certified ISMS has a cryptography policy, because A.8.24, use of cryptography, requires rules for the effective use of cryptography including key management.

Open a dozen of them and most say the same thing: approved algorithms, minimum key lengths, TLS version, a line about storing keys securely. All correct, all static, and none of it answers the question ASD is now asking, which is what happens when the approved list changes.

That is what crypto agility means in practice, and it is a policy property rather than a technology:

• Does the policy name who decides which algorithms are approved, and on what trigger?
• Does it require new systems to be able to change algorithm without being rebuilt?
• Does it say anything about how long a cryptographic decision is expected to last?
• Does it reference an external source of truth, such as the ISM’s Guidelines for cryptography, or does it hard-code a list that somebody must remember to update?

A policy that hard-codes RSA-2048 and says nothing else will be wrong by 2030, and nobody will notice until an auditor reads it against the ISM.

The plan is a clause 6.2 objective

ASD asks for a plan accounting for security goals, risk tolerances, dependencies and the value of data. An ISMS already has a place for exactly that shape of thing.

Clause 6.2 requires information security objectives that are measurable where practicable, monitored, communicated and updated, with resources and responsibility assigned. A post-quantum transition objective fits without modification: a dated end state, an owner, a measure such as the proportion of critical systems on post-quantum algorithms, and a review point.

• Clause 7.1, resources. The Implement phase is procurement and patching. It needs money, and an objective without it will be carried forward at every review.
• Clause 8.1, operational planning and control. Where the phases become controlled process rather than a slide.
• Clause 9.2, internal audit. The test is sampling the cryptography policy against the CBOM: does the policy describe what the estate does?
• Clause 9.3, management review. Where a four-year programme survives a change of priorities, or does not.

We made the same case for turning an external number into an internal objective in what your Microsoft Secure Score makes a SMARTER objective.

What an auditor asks for

1. The plan. Does one exist, is it dated, and does it name an owner? ISM-2073 asks for developed, implemented and maintained, which is three verbs and most organisations manage one.
2. The CBOM. Even at ASD’s minimum: the critical security functions that depend on cryptography.
3. The retention view. Which data has long-lived confidentiality requirements, and whether the risk assessment reflects that.
4. The policy test. Read the cryptography policy against the CBOM. Do they describe the same organisation?
5. The procurement line. What your last cryptographic purchase says about algorithm support beyond 2030.
6. The trigger. Who decides when the approved algorithm list changes, and what tells them.
7. The loop. Whether any of this reached management review.

Points 1 and 4 are where it usually comes apart, and for the same reason: the policy was written once and the estate moved.

Where this comes unstuck

Waiting for certainty. The date a quantum computer arrives is unknown. That is the argument for planning now rather than against it, because harvesting is happening against today’s traffic.

Rushing ahead. ASD warns organisations not to get ahead of standardised and verified implementations. Planning early and deploying early are different things, and only one of them is being recommended.

Reaching for quantum key distribution. QKD comes up in every conversation about this. ASD’s position is explicit: because of specialised hardware, availability and native authentication concerns, it does not support QKD for secure communications.

Treating hybrid as the destination. ASD neither recommends nor prohibits post-quantum and traditional hybrid schemes, and notes that a quantum computer renders the traditional half obsolete. Hybrid is a staging post.

Leaving it with the IT provider. If a third party runs your systems, the plan is still yours. The question to ask them is which of your systems use RSA, Diffie-Hellman, ECDH or ECDSA, and what their own timeline is.

Frequently asked questions

Is post-quantum cryptography a legal requirement in Australia?

No. ASD’s timeline is a recommendation, and the Information Security Manual is guidance for private-sector organisations, binding on Commonwealth entities through the Protective Security Policy Framework. What exists today is a control number, ISM-2073, and a recommended milestone of end of 2026 for the plan.

What has to be done by the end of 2026?

A refined transition plan, accounting for your security goals, risk tolerances, dependencies and the value of your data. Not the transition itself, which ASD recommends commencing by end of 2028 and completing by end of 2030.

What is a cryptographic bill of materials?

An inventory of the cryptography your systems depend on: products, libraries, algorithms, protocols, parameters, versions and configurations. ASD compares it to a software bill of materials and says a first version can be a simple list of the critical security functions that rely on cryptography.

Which algorithms are affected?

ASD recommends ceasing traditional asymmetric cryptography by end of 2030: RSA, Diffie-Hellman, Elliptic Curve Diffie-Hellman and ECDSA. Hashing and symmetric algorithms such as SHA-2 and AES are not under the same pressure, though the ISM points at SHA-384, SHA-512 and AES-256 for new equipment.

Does ISO 27001 mention post-quantum cryptography?

Not by name. A.8.24 requires rules for the effective use of cryptography including key management, clause 6.1.2 covers the risk assessment, and clause 6.2 covers objectives. The standard supplies the structure and ASD supplies the timeline.

We outsource all our IT. Does this apply to us?

Yes, in the part that matters. The plan and the risk decisions are yours. The implementation may not be, which makes the supplier conversation part of your plan rather than a substitute for it.

Where Streamline fits

A transition plan is a governance document before it is a technical one, which is why it tends to stall. Somebody has to decide what matters, in what order, with what money.

Streamline builds and audits ISO 27001 information security management systems for Australian organisations, and you work directly with a practising ISO Lead Auditor. A gap analysis will tell you whether your cryptography policy describes your actual estate, an independent internal audit under clause 9.2 tests it properly, and ISO mentoring suits the organisation that would rather build the capability in-house.

Start with ASD’s minimum. Write down the critical security functions that depend on cryptography. If that list is hard to produce, that is the finding, and it is the reason the plan is due before the transition. Get in touch if you would like help with it.

Sources

• Australian Signals Directorate, Planning for post-quantum cryptography
• Australian Signals Directorate, Information Security Manual, Guidelines for cryptography, controls ISM-2073, ISM-1917 and ISM-0472, updated September 2025
• ISO/IEC 27001:2022, clauses 6.1.2, 6.2, 7.1, 8.1, 9.2, 9.3 and Annex A controls 5.9 and 8.24

General information from an auditing and management system perspective, current at 21 September 2026. Not legal advice, and not technical advice on a specific environment.