Buying a system with a ten-year operating life means making a cryptographic decision today. The same applies to applications that hold sensitive information for years, equipment that verifies signed firmware and services that depend on an external provider’s upgrade path.
Post-quantum cryptography, or PQC, gives teams new algorithms designed to resist attacks from a cryptographically capable quantum computer. Preparing for the transition means finding where the organisation relies on cryptography and working out how those uses can change without losing the service.
Some standards are already final
NIST published its first three principal PQC standards in August 2024. They cover different security functions. NIST’s current programme summary also identifies further algorithms undergoing standardisation.
| Standard | Function | Status |
|---|---|---|
| FIPS 203 ML-KEM | Key establishment | Final |
| FIPS 204 ML-DSA | Digital signatures | Final |
| FIPS 205 SLH-DSA | Digital signatures | Final |
Falcon, a digital signature algorithm, and HQC, a key-encapsulation mechanism, are in NIST’s ongoing standardisation work. Their selection has a different status from a published final standard.
For an operating team, an approved algorithm is one dependency. The application, protocol, libraries, key storage and communicating peers also need compatible implementations. Ask a supplier to identify the supported function and release behind a claim of “PQC ready”.
Plan around information life and system life
Attackers may retain encrypted information for decryption later. Data that needs long-term confidentiality therefore deserves attention before a cryptographically capable quantum computer exists. ASD’s planning guidance also highlights migration lead times and difficult-to-update systems.
For organisations applying the Australian Information Security Manual, that guidance recommends a refined transition plan by the end of 2026, commencement with priority systems by the end of 2028 and completion by the end of 2030. Use the policy and contractual requirements that apply to your environment when setting dates.
Bring this into procurement and refresh planning. A supplier’s supported operating life should include a credible path for cryptographic changes, with the dependencies, costs and responsibility for implementation made clear.
Inventory the use, then trace the dependency
A useful inventory connects cryptography to an operating service. Record what it protects, how long that protection matters, the algorithm and protocol in use, the implementation version, its owner and the available upgrade path.
Start with a service you understand. Follow its browser or client connection through gateways, application services and identity dependencies. Add private certificate authorities, VPNs, administrative access, device enrolment, software signing and firmware verification where they support that service.
Mark unknowns. An outsourced service still has a supplier and a contract owner who can obtain an answer. For industrial equipment, ask about embedded verification keys and the supported mechanism for changing them before assuming a firmware update will be sufficient.
Turn supplier claims into a change plan
Ask for the specific algorithm, security function, protocol and supported software or hardware release. Confirm whether the capability is available, under test or on a roadmap. A promised date belongs in the dependency register with an owner who will follow it up.
Work through the whole connection: which peer versions interoperate, where keys are generated and held, how certificates or trust stores change, and whether an appliance or cryptographic module needs replacement. Agree what happens when a peer cannot negotiate the intended protection.
Include licensing, maintenance windows and support arrangements. Those details determine whether the team can complete the migration within a normal change programme or needs a separate delivery plan.
Test the service you intend to operate
Choose a supported implementation and a representative environment. Measure connection establishment, processing load and behaviour over the actual network path. Include constrained links, larger messages, reconnect storms and failover where they matter to the service.
Exercise old and new peers together. Confirm the negotiated protection and detect an unexpected fallback. Test certificate renewal, key replacement and recovery with the people who will support the service.
For OT, involve the equipment supplier and operations team in the acceptance conditions. Preserve control behaviour and recovery access through the transition. Plan the live change around an agreed operating window and stop conditions.
Make the first deliverable a funded sequence of work
Start with one service and its difficult dependencies.
Name the owner, document its cryptographic uses, obtain supplier evidence and choose a supported pilot. Record the result, the unresolved dependencies and the next funded change. Repeat across the services in priority order.
That gives leaders something they can schedule and resource. It also gives engineers a basis for checking progress as standards and product support develop.
Practical certificate automation covers the deployment and verification discipline that supports this work. Changing algorithms will require additional compatibility and performance testing.