Post-quantum cryptography is now a migration programme, not a prediction contest. An organisation does not need to guess the date of a cryptographically relevant quantum computer before it can locate vulnerable dependencies, assess the lifetime of protected information and ask suppliers for an upgrade path.
The Australian Signals Directorate (ASD) recommends a refined transition plan by the end of 2026, commencement of migration for critical systems and data by the end of 2028, and completion by the end of 2030. That is a demanding timetable for environments containing legacy systems, hardware security modules, certificates, embedded devices, external APIs and long-lived vendor contracts (ASD — Planning for post-quantum cryptography).
Correct the threat model first
The original version of this article said quantum computers perform calculations “exponentially faster” and treated RSA and elliptic-curve cryptography as if both depended on integer factoring. That is inaccurate.
Shor's algorithm threatens the mathematical problems used by widely deployed public-key systems. RSA relies on integer factorisation; Diffie–Hellman and elliptic-curve systems rely on discrete-logarithm problems in different groups. A sufficiently capable, fault-tolerant quantum computer would undermine both families, but not because they use the same problem.
Symmetric encryption and hash functions have a different risk profile. Quantum search can reduce the effective work factor of brute-force search, which influences key-size and design choices, but it does not mean every cryptographic primitive instantly fails or that quantum speed-up is universal.
The practical risk is broader than encrypted archives. Vulnerable asymmetric cryptography is used for:
- TLS authentication and key establishment;
- VPNs and remote administration;
- software and firmware signing;
- document and email signatures;
- device identity and update chains;
- public-key infrastructure and certificates; and
- machine, workload and API authentication.
Information with long-lived confidentiality requirements may also be exposed to “harvest now, decrypt later”: encrypted traffic or data captured today could be retained for an attempt to decrypt it in the future. ASD advises organisations to begin planning even though the arrival date of a cryptographically relevant quantum computer remains uncertain (ASD — Planning for post-quantum cryptography).
Use final standards, not old candidate names
In August 2024, the US National Institute of Standards and Technology (NIST) approved three post-quantum standards:
| Standard | Function | Important distinction |
|---|---|---|
| FIPS 203 — ML-KEM | Establishing shared secrets | A key-encapsulation mechanism, not general-purpose “encryption” by itself |
| FIPS 204 — ML-DSA | Digital signatures | Derived from the CRYSTALS-Dilithium submission |
| FIPS 205 — SLH-DSA | Digital signatures | A stateless hash-based signature scheme derived from SPHINCS+ |
These are final standards, not merely candidates under evaluation (NIST — Post-Quantum Cryptography FIPS Approved). NIST says the standards are ready to implement, while work continues on additional algorithms and migration guidance (NIST — Post-quantum cryptography).
For Australian organisations that apply the Information Security Manual, current ASD-approved choices, parameters and transition rules should be checked directly in ASD guidance. Do not assume that a library exposing an algorithm name is approved, interoperable or safely configured for the intended use.
Follow a Locate–Assess–Triage–Implement–Communicate path
ASD's LATICE framework provides a useful migration sequence.
1. Locate cryptography and its owners
Build a cryptographic inventory. Begin with high-impact services and record:
- the business function and information protected;
- algorithm, key size, protocol, certificate type and library;
- product, version, hardware or managed service involved;
- whether the organisation controls the configuration or depends on a supplier;
- key and certificate lifetimes;
- data-confidentiality lifetime;
- interoperability and external-party dependencies; and
- accountable business and technical owners.
A cryptographic bill of materials can mature from a simple list into a machine-readable record, but perfect tooling is not a prerequisite for beginning. Certificates alone are not a complete inventory: cryptography may be compiled into applications, embedded in devices or hidden behind a SaaS interface.
2. Assess value, lifetime and business impact
Prioritise more than secrecy. A future loss of signature trust could affect software updates, device identity, records, contracts or evidence. Ask how long the protected information or authenticity decision must remain trustworthy and what happens if a dependency cannot be updated.
Document regulatory, contractual and customer requirements without assuming that adopting a NIST algorithm automatically proves compliance.
3. Triage difficult and externally connected systems
Critical, sensitive, long-lived and slow-to-change systems usually need earlier attention. Include operational technology, appliances, mobile applications, identity platforms and services whose vendors control the implementation. Record legacy interoperability that may delay a clean cutover.
4. Implement through supported products and controlled tests
Do not design proprietary cryptography or rush an unreviewed library into production. Prefer standardised implementations, supported products and vendor guidance. Test in a representative non-production environment for:
- protocol and certificate interoperability;
- larger keys, signatures, certificates and messages;
- latency, memory, CPU and storage effects;
- monitoring, logging and failure behaviour;
- downgrade and fallback handling;
- key lifecycle, backup and recovery; and
- rollback without silently returning to an insecure state.
ASD does not recommend, but does not prohibit, post-quantum/traditional hybrid schemes. A hybrid can support interoperability and resilience during transition, but its traditional component remains vulnerable to a future cryptographically relevant quantum computer. Treat it as a transition design requiring review, not a permanent endpoint.
5. Communicate with vendors and stakeholders
Ask each critical supplier:
- Which cryptographic dependencies are in the product, including third-party libraries and hardware?
- Which final standards and profiles will be supported?
- Is the implementation production-ready, independently tested and enabled by default or by configuration?
- What versions, contracts, hardware replacements or downtime are required?
- How will keys, certificates, backups, logs and rollback be handled?
- Does the roadmap align with ASD's 2030 objective?
- How will vulnerabilities or standards changes be communicated?
ASD published a current vendor-question set in 2026 that can be adapted to procurement and renewal reviews (ASD — Post-quantum questions to ask your vendors).
A realistic 2026 starting point
For a smaller organisation, the first deliverable is not a fleet-wide cryptographic replacement. It is an owned transition plan:
- name the accountable owner and affected teams;
- identify the ten most critical services and their suppliers;
- document certificates, libraries, protocols and long-lived data for those services;
- ask vendors for current evidence and dates;
- rank dependencies by impact and difficulty;
- select one supported non-production pilot; and
- fund the next inventory and migration milestones.
Measure progress by inventory coverage, supplier evidence, tested compatibility and closed migration risks—not by the number of products that display a “quantum-safe” badge.
For help turning an infrastructure and software inventory into a scoped security roadmap, see Ozlin Info's cybersecurity services or contact Ozlin Info.
Related reading: Cybersecurity fundamentals for business risk.
General-information disclaimer
This article provides general technical information only. It is not cryptographic, legal, regulatory, procurement or compliance advice. Approved algorithms, profiles and transition obligations depend on the organisation, information, jurisdiction, system and applicable ASD or sector requirements. Obtain qualified cryptographic and legal advice for high-consequence systems.
AI-assistance disclosure
AI tools assisted with source discovery, outlining and copyediting. A human reviewer must verify every source, technical statement, organisational claim and publication decision before release. No claim is made that any Ozlin or client system is quantum-ready.
Primary sources checked
- ASD — Planning for post-quantum cryptography
- ASD — Planning for post-quantum cryptography: background and current considerations
- ASD — Post-quantum questions to ask your vendors
- NIST — Post-Quantum Cryptography FIPS Approved
- NIST — Post-quantum cryptography
Source access date: 29 August 2026.
Leave a Reply