Australia’s cyber security authorities published new Guidelines for cryptography on September 3. The guidance brings cryptographic lifecycle management, implementation assurance, approved algorithms and protocols, post-quantum transition planning, and procurement into one control framework for government and large organizations.
For PQC programs, the operational message is precise: policy applies to implementations and use cases, not algorithm names in isolation. To determine whether a system satisfies the guidance, an organization needs an inventory that can distinguish parameter sets, cryptographic functions, modules, protocols, configurations, assurance evidence, and target dates.
Approved algorithm names are only the first field
The guidelines approve ML-DSA for signatures and ML-KEM for key encapsulation, but they make specific parameter choices. ML-DSA-65 and ML-DSA-87 are approved. The procurement control calls for new equipment, applications, and libraries intended for use beyond 2030 to support ML-DSA-87 and ML-KEM-1024, as well as SHA-384, SHA-512, and AES-256 by 2030.
An inventory entry that says only “ML-DSA” or “PQC supported” cannot support that evaluation. Teams must record the parameter set, purpose, implementation, module, version, and actual configuration. They should also distinguish capability from use: available in a library, enabled by policy, negotiated in a protocol, observed in production, and verified by a test are separate states.
The guidance also discusses hedged and deterministic ML-DSA signing and conditions around pre-hashed variants. These details show why compliance cannot be inferred from a package name. The operating mode and surrounding implementation affect both assurance and policy.
Implementation assurance belongs in the record
Australia’s guidance ranks several forms of cryptographic implementation assurance, including Common Criteria evaluations, FIPS 140-3 module evaluation, algorithm validation, and independent review. It also says supply-chain risk and secure configuration remain relevant when a preferred evaluated product is unavailable.
Validation evidence needs exact scope. A certificate normally applies to a defined cryptographic module and version under stated conditions; it does not automatically cover every product deployment or configuration that uses a vendor’s technology. Inventory records should link the deployed component to the relevant certificate, security policy, configuration baseline, and evidence date.
This prevents two common errors: treating a validated algorithm as proof of a secure product, and treating a validated module as proof that every consuming application uses it correctly. Assurance should be traceable from the claim to the deployed boundary.
The hybrid decision is jurisdiction-specific
The Australian guidance does not recommend post-quantum/traditional hybrid schemes, although it does not prohibit them. It notes their additional implementation, analysis, computational, bandwidth, maintenance, and eventual transition costs. Other authorities and protocols may recommend or require hybrid approaches for certain periods or use cases.
That difference is exactly why global organizations need policy-aware evaluation. “Hybrid” is not inherently compliant or noncompliant everywhere. Teams need to know the jurisdiction, system classification, customer requirement, protocol specification, component algorithms, combination method, and exception authority.
A canonical inventory should describe the observed cryptographic construction once. Separate policy evaluations can then determine whether it is acceptable under Australian guidance, another national profile, a contract, or an internal standard. This avoids fragmenting one asset into inconsistent spreadsheets.
2030 is a procurement and lifecycle deadline
The guidelines require a PQC transition plan to be developed, implemented, and maintained. Their 2030 procurement language means organizations should examine expected service life now. Equipment purchased before 2030 may still operate after it. Software libraries, appliances, embedded systems, and managed services acquired today can become blockers if they lack a credible upgrade path.
Procurement questions should cover exact PQC mechanisms, firmware and software roadmaps, hardware constraints, module validation plans, interoperability, key management, performance, monitoring, rollback, and support dates. Contract terms should require notification when cryptographic behavior, validation status, or support changes.
The inventory should connect these answers to refresh cycles and owners. A target algorithm without a budgeted replacement, supplier milestone, and acceptance test is an aspiration rather than a migration plan.
What organizations should do next
- Increase inventory precision. Capture algorithm, parameter set, function, protocol, mode, implementation, module, version, and configuration.
- Link assurance evidence. Record certificates, evaluations, scope, conditions, evidence dates, and deployment mappings.
- Maintain policy profiles. Evaluate the same assets against national, contractual, classification, and internal requirements.
- Connect procurement to migration. Track service life, upgrade paths, supplier commitments, refresh dates, and acceptance tests.
- Verify actual use. Test negotiated behavior and production configuration rather than relying on support claims.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop is discovery, canonical inventory, evaluation, action, and proof. Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps.
Vista helps organizations reconcile cryptographic observations, evaluate them against applicable policies, assign migration actions, and preserve evidence. It tracks and governs PQC migration; it does not generate PQC keys or perform every migration. Vista is not a vulnerability scanner. Selected-asset Active Scan is not indiscriminate network scanning, and discovery gaps do not prove absence. Teams can explore the evaluation workflow on Try Vista.
Where uncertainty remains
The guidelines contain applicability markings for Australian government classifications and reference additional doctrine for high-assurance equipment. Organizations must determine which controls apply to their environment and should not treat this article as a substitute for official guidance. Standards, module availability, and other national positions will continue to evolve. The durable preparation is an evidence-backed inventory capable of applying new policy at implementation-level precision.
Sources
- Guidelines for cryptography, Australian Signals Directorate / Australian Cyber Security Centre, September 3, 2026.
- FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard, NIST, August 13, 2024.
- FIPS 204: Module-Lattice-Based Digital Signature Standard, NIST, August 13, 2024.