On 25 March 2026, Google published a blog post with a deliberately understated title: “Quantum frontiers may be closer than they appear.” Buried inside was a commitment that should sit on every board risk agenda: Google is targeting 2029 to complete its migration to post-quantum cryptography. Not 2035. Not 2030. 2029, a full year ahead of the official NIST deprecation deadline. The reason given was blunt: quantum computing hardware, error correction, and factoring resource estimates are all advancing faster than expected.
Google builds quantum computers. It runs Chrome, Android, and one of the largest cloud platforms on the planet. When it shortens its own migration window and frames the announcement as an industry-wide call to action, that is a signal worth reading. For Australian organisations regulated under the Privacy Act 1988 (Cth), the Security of Critical Infrastructure Act 2018 (Cth) (SOCI Act), or APRA’s prudential standards, the question is no longer whether post-quantum cryptography (PQC) is relevant. It is whether your organisation has a plan.
Why the timeline has compressed
Most of today’s internet security depends on mathematical problems that classical computers cannot solve in any practical timeframe: RSA encryption, Diffie-Hellman key exchange, and elliptic curve cryptography. A sufficiently powerful quantum computer - often referred in technical parlance as a "cryptographically relevant quantum computer" or "CRQC" - would be capable of solving those problems efficiently, compromising the confidentiality of encrypted data and the integrity of digital signatures.
For years, the standard reassurance was that a CRQC was decades away. That reassurance is eroding. In 2019, Google estimated it would take approximately 20 million qubits to break RSA encryption. By 2025, that estimate had dropped to around one million. In early 2026, a research team including Australian researchers suggested the number may be closer to 100,000 physical qubits. The qubit count is falling faster than anticipated. The honest answer has shifted from “probably not this decade” to “possibly within a few years.”
“Store now, decrypt later”: adversaries do not need a CRQC today to benefit from one later. Sophisticated threat actors, including state-sponsored actors, are likely already capturing encrypted data in transit, waiting for the day a quantum computer can unlock it. Data being transmitted right now may be read in the future. For organisations holding sensitive personal, financial, or commercial information, the exposure is already accruing.
Digital signatures present a different but equally serious problem. Unlike encrypted data, you cannot retroactively fix a compromised signature infrastructure after a CRQC arrives. Code signing, certificate authorities, and authentication systems must be migrated before that point. Google’s March 2026 announcement specifically prioritised authentication services for this reason, and Android 17 (expected in mid-2026) will ship with ML-DSA post-quantum digital signature protection built in.
The new algorithms: Ready and deployed
In August 2024, the US National Institute of Standards and Technology (NIST) finalised three post-quantum cryptographic standards, the product of an eight-year global evaluation process. These are classical algorithms running on ordinary hardware, designed to resist both classical and quantum attacks:
- ML-KEM (FIPS 203): Replaces RSA and Diffie-Hellman for key exchange. Already the default in OpenSSL 3.5 (released April 2025) and used in hybrid mode by Chrome and other major browsers since 2024.
- ML-DSA (FIPS 204): Replaces ECDSA for digital signatures, including certificate signing, code signing, and peer authentication. Shipping in Android 17.
- SLH-DSA (FIPS 205): A hash-based backup signature scheme with more conservative mathematical assumptions, providing resilience if ML-DSA is later found to have weaknesses.
A common misconception is that these algorithms involve a significant performance trade-off. Benchmark data from OpenSSL 4.0 (released April 2026) shows ML-KEM-512 outperforming ECP-256 on standard hardware for key exchange operations. Performance is not the barrier. Planning and implementation are.
OpenSSL 3.5 and 4.0 now enable hybrid PQC key agreement in TLS by default, combining classical and post-quantum algorithms so connections remain secure even if one scheme is later compromised. Many organisations are already running PQC in their TLS traffic on updated systems without necessarily realising it. The harder work is identifying and upgrading the parts of the environment that have not been updated: legacy systems, long-lived certificates, stored encrypted data, and embedded devices.
The regulatory case for acting now
The regulatory case for acting now
APP 11 requires APP entities to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access or disclosure. Amendments effective December 2024 confirmed those steps must include both technical and organisational measures (APP 11.3).
“Reasonable steps” is not a fixed standard. In Australian Information Commissioner v Australian Clinical Labs Limited (No 2) [2025] FCA 1224, Australia’s first civil penalty decision under the Privacy Act, the Federal Court confirmed this is an objective standard that adapts to the changing cybersecurity environment. What was adequate in 2020 is not necessarily adequate in 2026. As PQC becomes embedded in vendor products, government frameworks, and industry practice, the bar rises. The Office of the Australian Information Commissioner's guidance identifies adoption and implementation of standards as an element of what reasonable steps should include.
For organisations holding sensitive personal data with a long confidentiality shelf life, the store-now-decrypt-later risk means failure to plan for PQC is not just a future problem. It bears on the adequacy of protection being provided today.
SOCI Act, APRA, and AFSL obligations
Responsible entities for critical infrastructure assets must maintain a Critical Infrastructure Risk Management Program (CIRMP) addressing cyber and information security hazards. A CIRMP that has not assessed the quantum computing risk horizon will be increasingly difficult to defend as the threat becomes more defined and timelines compress.
APRA’s CPS 234 requires an information security capability commensurate with the size and extent of threats faced, with controls commensurate with the criticality and sensitivity of information assets. CPS 230 requires material operational risks to be identified and managed. Both engage the quantum threat directly, particularly for entities holding sensitive customer financial data. For AFSL holders, ASIC’s enforcement actions against RI Advice Group and FIIG Securities confirmed that the adequacy of cybersecurity measures is assessed objectively by reference to the threat environment. That environment has materially changed.
The industry timeline: 2029 is the new 2035
The regulatory and industry landscape has moved decisively in the past 12 months:
- Google: 2029 hard deadline for full PQC migration across all products and infrastructure, announced March 2026. Framed explicitly as an industry-wide call to action.
- ASD/ACSC: September 2025 guidance directs all Australian organisations to have a PQC transition plan by end of 2026, begin implementation on highest-risk systems by end of 2028, and complete the transition by end of 2030.
- NIST: Traditional asymmetric cryptographic algorithms (RSA, ECDH, ECDSA) will be deprecated from 2030 and disallowed entirely by 2035.
- NSA (US): New acquisitions into US national security systems must support PQC from 1 January 2027. All software and firmware must use quantum-resistant signatures by end of 2030.
- Microsoft: Targeting full PQC migration by 2033, with core infrastructure migration beginning in 2026.
- OpenSSL: PQC algorithms (ML-KEM, ML-DSA, SLH-DSA) are production-ready and shipping in OpenSSL 3.5 and 4.0, the cryptographic foundation of the global internet.
Google’s 2029 announcement carries particular weight because Google also builds quantum computers. Its timeline is not driven by regulatory obligation alone. It reflects what the company sees coming from its own research.
What to do
Migration to PQC is a multi-year, operationally complex undertaking. Comparisons to Y2K in scope have been made by multiple international bodies. The following steps are aligned with ASD’s guidance and the practical expectations of regulated organisations.
- First, conduct a cryptographic inventory. Map where public-key cryptography is used across systems, protocols, certificates, applications, and third-party services. You cannot plan a migration without knowing the terrain.
- Second, assess long-lived data risk. Identify sensitive data with a long confidentiality shelf life that is already exposed to store-now-decrypt-later risk.
- Third, develop a transition plan. Develop a staged plan aligned to ASD’s 2026/2028/2030 milestones, prioritising highest-risk systems and those with the longest replacement cycles.
- Fourth, review vendor and procurement readiness. Check whether current technology vendors and cloud providers support PQC (many already do), and include PQC readiness as a criterion in new technology procurement.
- Fifth, ensure board-level ownership and documentation. Decisions about PQC transition, resource allocation, and risk acceptance must be made and documented at board level. Regulators assess not just what was done, but whether the process was reasonable.
The bottom line
The window for treating post-quantum cryptography as a future concern has closed. Google has set 2029 as its migration deadline. ASD has set 2030. NIST standards are finalised and deployed.
For boards, general counsel, and risk leaders in regulated industries, the issue is straightforward: the standard for what constitutes a reasonable step to protect data is shifting, the timeline is compressing, and regulators are paying attention. Organisations that begin planning now will have time and options. Those that wait will find themselves making harder decisions under greater pressure.
This article was prepared by Partner Hayden Delaney, a specialist technology, privacy, and intellectual property lawyer at Thomsons.