Post-quantum readiness FAQ

Quantum computing creates a future risk for the encryption that protects identity, financial, health, operational and commercially sensitive information. The business issue is the lifetime of that information: data collected today may need to remain confidential long after a future capability can defeat current protections.

ASD recommends a refined transition plan by the end of 2026, commencement for critical systems and data by the end of 2028, and completion by the end of 2030. Large estates need time for discovery, supplier coordination, architecture decisions, testing and change delivery. Starting early preserves choice and avoids a rushed programme.

You retain uncertainty about where exposure exists, risk falling behind supplier and regulatory expectations, and may have less time to protect long-life sensitive data. The cost of a later, urgent response is usually higher because decisions must be made with less visibility and less flexibility.

Priority is highest where confidential data has a long useful life, critical services depend on complex technology, or change is difficult. This commonly includes financial services, insurance, healthcare, government, critical infrastructure, organisations with extensive APIs and cloud estates, and businesses holding valuable intellectual property.

It depends on the estate, but complex organisations should treat it as a multi-year programme. Early discovery and assessment can be completed in weeks or months; remediation then depends on application lifecycles, vendors, certificates, integration points and release windows.

There is no responsible single figure without understanding scope. An initial discovery or assessment is a bounded way to establish exposure and make a proportionate investment decision. The larger cost is shaped by the number of systems, their lifecycle, vendor readiness and the extent of change already planned.

Expectations are evolving by sector, but the direction is clear: organisations should understand material cyber and operational risks, maintain appropriate controls, manage dependencies and be able to explain their plans. ASD provides Australia-wide PQC planning guidance; sector obligations remain risk-based and should be considered in each organisation's own regulatory context.

ASD's planning guidance gives Australian organisations a concrete planning horizon. It recommends moving away from traditional asymmetric cryptography by the end of 2030, with interim milestones for planning and critical-system transition. It is a useful benchmark for management discussions even where it is not a direct legal obligation.

CPS 234 does not prescribe a PQC migration. It requires APRA-regulated entities to maintain information-security capability and controls appropriate to their vulnerabilities and threats. A documented view of long-term cryptographic exposure, risk ownership and remediation planning can support that broader obligation.

CPS 230 does not mandate a PQC programme. Its focus on operational risk, critical operations and service-provider risk makes PQC relevant where legacy encryption, third-party dependencies or constrained technology lifecycles could affect resilience. The connection should be assessed against your specific operating model.

No. Government has clear security drivers, but any organisation holding sensitive long-life information or operating important digital services has a reason to assess its exposure. The question is not sector alone; it is the value and lifetime of your data, the importance of your services and the complexity of your estate.

It describes an attacker collecting encrypted data now, storing it and attempting to decrypt it later when stronger computing capability is available. It matters when the stolen information will still be valuable or sensitive in the future.

The immediate planning focus is traditional asymmetric cryptography used for key exchange, signatures and authentication. The practical task is to identify where those functions sit in your environment and what they protect, rather than treating every cryptographic control as equally exposed.

Yes. TLS, certificates and digital-signature workflows commonly rely on traditional asymmetric cryptography. Their exposure depends on configuration, data sensitivity, protocol support, certificate lifecycles, product roadmaps and the systems that depend on them.

Potentially. Cloud services, APIs and SaaS platforms can contain both provider-managed and customer-managed cryptographic dependencies. Providers will deliver parts of the transition, but customers still need visibility of their data flows, identity integrations, configurations, contracts and applications built around those services.

Yes, in the sense that their services, your configurations and your applications all form part of the estate to understand. The right question is not whether a cloud provider has a future roadmap; it is which services you use, where you manage keys or certificates, and which dependencies need coordinated change.

Crypto agility is the ability to change cryptographic controls without major disruption. It reduces future cost and risk by making algorithms, certificates, protocols and key-management choices easier to update as standards and threats evolve.

It is a structured record of where cryptography is used, what it protects, who owns it and what dependencies exist. It gives leaders the visibility required to assess exposure, prioritise investment and sequence change. It is more useful than a generic asset list because it connects technical use to business impact.

We deliver a practical view of cryptographic exposure, the systems and data that deserve attention, a prioritised roadmap and executive-ready decision support. The exact deliverables are tailored to scope, but are designed to give leadership a clear basis for action.

We work with relevant security, architecture, infrastructure, application and vendor stakeholders to locate cryptographic touchpoints and dependencies. The goal is a useful initial inventory and a clear view of the blind spots that need deeper validation, not an academic catalogue.

An assessment relates cryptographic exposure to business criticality, data sensitivity, confidentiality life, external exposure, regulatory context, technology lifecycle and delivery complexity. It translates technical findings into priorities, trade-offs and decision points.

A focused discovery or risk assessment can usually be scoped over a number of weeks. A roadmap, governance or broader readiness programme depends on estate size, stakeholder availability and the depth of validation required. We define the intended decision and practical scope before starting.

We are an advisory consultancy, not an implementation factory. We help clients decide what needs to change, prepare a practical transition plan and support the teams responsible for delivery. That independence keeps the advice focused on your risk and operating context.

We complement established security, architecture, cloud, engineering and risk functions. We can work alongside existing consultancies and providers, bringing specialist PQC readiness focus while your teams retain ownership of the environment and delivery decisions.

Where exposure is concentrated, how it intersects with the technology roadmap, what needs executive sponsorship and the likely sequence, cost drivers and resourcing implications of transition.

Which information assets and trust relationships face the greatest long-term exposure, how strong the current evidence is, what controls and suppliers are involved, and how residual risk will be governed while transition takes place.

Which platforms, protocols, certificate flows, APIs and vendor products create the major dependencies; which changes are already on the roadmap; and how to design for crypto agility so the organisation does not repeat the same problem later.

Is this a material risk for us, what information supports that conclusion, what happens if we defer, what management plan is proposed and what decisions or funding are needed now versus later.

Who owns the risk, how exposure is being identified and reported, how management validates progress, how third-party dependencies are handled and whether the roadmap is proportionate to the organisation's regulatory and risk context.