Google Cloud's 2029 Post-Quantum Deadline: A Defender's Migration and Crypto-Inventory Playbook

Google Cloud has published a formal post-quantum cryptography (PQC) roadmap committing to full PQC readiness across its infrastructure and services by 2029, with intermediate milestones in 2027 and 2028. This is not an academic exercise or vendor marketing. It is a large hyperscaler publicly committing to a hard timeline because the underlying threat — harvest-now-decrypt-later (HNDL) — is already happening.

Nation-state collection programs have been stockpiling intercepted encrypted traffic for years, betting that a cryptographically relevant quantum computer (CRQC) will eventually let them retroactively decrypt it. Any data you encrypt today with RSA, ECDH, or ECDSA that must remain confidential past roughly 2030–2035 is, by conservative estimates, already at risk of future exposure. Google's roadmap is significant for defenders for two reasons: first, it signals that PQC migration is now a board-level infrastructure program with dated deliverables, not a research topic. Second, every organization running workloads on Google Cloud — or exchanging data with parties who do — now has a concrete external dependency timeline to plan against.

If you have not started a cryptographic inventory and migration plan, 2026 is the year you lose the luxury of deferring it.

Technical Analysis

What Google Cloud Announced

Google Cloud's roadmap lays out a phased transition to quantum-resistant cryptography across its control plane, data plane, and customer-facing services:

• 2027 milestone: Initial PQC capability milestones — hybrid key establishment available across core infrastructure and customer-consumable services, aligning with NIST-standardized algorithms.
• 2028 milestone: Broad service-level integration, enabling customers to migrate workloads and dependencies to PQC-protected channels.
• 2029 goal: Full PQC readiness across Google Cloud's stack.

This follows Google's longer internal track record: the company has been deploying hybrid post-quantum key agreement internally for years, and Google Chrome shipped hybrid X25519+ML-KEM-768 key agreement for TLS 1.3 — meaning a meaningful share of global TLS traffic on the public internet is already using quantum-resistant key exchange today.

The Algorithms That Matter

Migration planning should be anchored to the finalized NIST FIPS standards:

The near-universal migration pattern for key establishment is hybrid mode: classical X25519 combined with ML-KEM-768, so that traffic is protected even if either algorithm is later broken. For signatures, migration is harder — certificate hierarchies, HSMs, firmware signing chains, and code-signing pipelines all need rework, and PQC signatures and keys are substantially larger, which has real performance implications for constrained devices and high-volume TLS terminators.

The Threat: Harvest-Now-Decrypt-Later

HNDL is the driver behind every accelerated PQC timeline, including CISA, NSA CNSA 2.0, and now Google Cloud's. The attack requires no quantum computer today:

1. Collection: Adversaries with backbone or upstream access (nation-state SIGINT programs, compromised transit providers) passively record encrypted sessions — TLS handshakes, VPN tunnels, SSH sessions.
2. Storage: Captured ciphertext and full handshake transcripts are warehoused indefinitely.
3. Future decryption: When a CRQC exists, Shor's algorithm breaks the RSA/ECDH key exchange retroactively, exposing session keys and therefore all recorded plaintext.

The critical defender insight: TLS sessions using RSA key transport (no forward secrecy) are the highest-value HNDL targets, because compromising the server's long-term RSA private key — today or via quantum means later — decrypts every recorded session. Sessions using ephemeral ECDHE have forward secrecy against classical key compromise but are still vulnerable to future quantum decryption of the key exchange itself. Only hybrid or pure PQC key establishment closes the retroactive exposure window.

Exploitation Status

There is no CVE and no single exploit here. HNDL is a confirmed, ongoing collection model attributed to nation-state programs; quantum decryption capability itself remains theoretical but drives dated regulatory pressure (CNSA 2.0 targets PQC for national security systems by 2030–2033). Treat this as a strategic risk with an active collection component, not a wait-and-see problem.

Detection & Response

You cannot detect a quantum computer. What you can detect — and what materially reduces HNDL exposure — is where quantum-vulnerable cryptography is still in use in your environment. Crypto discovery is the detection problem for PQC readiness, and it belongs in your SOC's hunting rotation, not just in an annual audit spreadsheet.

Sigma Rules

The following rules support a PQC migration enforcement program: they surface new creation of long-lived RSA keys (which violate migration policy and expand your HNDL exposure) and any attempt to force-disable post-quantum key agreement in browsers — a downgrade behavior consistent with an adversary positioning for interception or a misbehaving inspection middlebox.

---
title: Legacy RSA Key Generation via OpenSSL or ssh-keygen
id: 4c8a2f17-3b91-4d56-9e2a-7f1c5d8b6a42
status: experimental
description: Detects generation of new RSA private keys via OpenSSL or ssh-keygen. New long-lived RSA key material is quantum-vulnerable and typically violates PQC migration policy; legitimate use should be ticketed and tracked against a cryptographic inventory.
references:
  - https://csrc.nist.gov/pubs/fips/203/final
  - https://www.securityweek.com/google-cloud-sets-out-post-quantum-roadmap-with-2029-readiness-goal/
author: Security Arsenal
date: 2026/06/12
tags:
  - attack.collection
  - attack.t1552.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_openssl:
    Image|endswith: '/openssl'
    CommandLine|contains:
      - 'genrsa'
      - 'genpkey'
      - 'req -new'
  selection_keygen:
    Image|endswith: '/ssh-keygen'
    CommandLine|contains:
      - '-t rsa'
      - '-t ecdsa'
      - '-b 2048'
      - '-b 4096'
  condition: 1 of selection_*
falsepositives:
  - Developer and PKI administrative activity — route to inventory review rather than blocking
level: medium
---
title: Post-Quantum TLS Key Agreement Disabled via Policy
id: 9d3e6b25-7a14-4c88-bf53-2e9d1a4c7f06
status: experimental
description: Detects registry or policy changes that disable hybrid post-quantum key agreement (ML-KEM) in Chromium-based browsers or force legacy key exchange. Downgrading key establishment may indicate an adversary positioning traffic for interception or a TLS inspection device forcing downgrade.
references:
  - https://attack.mitre.org/techniques/T1557/
  - https://www.securityweek.com/google-cloud-sets-out-post-quantum-roadmap-with-2029-readiness-goal/
author: Security Arsenal
date: 2026/06/12
tags:
  - attack.defense_evasion
  - attack.collection
  - attack.t1557
logsource:
  category: registry_set
  product: windows
detection:
  selection:
    TargetObject|contains:
      - '\Policies\Google\Chrome'
      - '\Policies\Microsoft\Edge'
    TargetObject|endswith:
      - 'PostQuantumKeyAgreementEnabled'
    Details|contains:
      - '0x00000000'
      - '0'
      - 'false'
falsepositives:
  - Enterprise compatibility workarounds for legacy TLS inspection — validate against change tickets
level: high

KQL — Microsoft Sentinel / Defender

The highest-priority HNDL exposure in most environments is TLS traffic negotiated with RSA key transport cipher suites (no forward secrecy) and endpoints that have not negotiated hybrid PQC key exchange. This query hunts network/session telemetry for legacy key exchange in use, sourced from firewall, ZScaler, or TLS-aware appliance logs ingested via CEF/Syslog:

// Hunt: TLS sessions using RSA key transport or legacy key exchange (no forward secrecy)
// Prioritize for HNDL exposure review — these sessions are decryptable if the server key is ever compromised.
let LegacyKeyExchange = dynamic([
  "TLS_RSA_WITH", "RSA key exchange", "kRSA", "TLS1.0", "TLS1.1"
]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| extend TLSDetail = coalesce(AdditionalExtensions, Message, DeviceCustomString6)
| where TLSDetail has_any (LegacyKeyExchange)
   or ApplicationProtocol in~ ("tls1.0", "tls1.1", "sslv3")
| summarize SessionCount = count(), Destinations = dcount(DestinationIP),
    SampleTLSDetail = any(TLSDetail)
  by SourceIP, DestinationHostName, DeviceVendor
| where SessionCount > 50
| sort by SessionCount desc;

// Companion hunt: hosts still initiating outbound connections over deprecated TLS versions
// via Defender network events (adjust per your TLS inspection telemetry source).
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort in (443, 8443)
| where InitiatingProcessFileName in~ ("curl.exe", "wget.exe", "powershell.exe", "python.exe")
| summarize Connections = count(), DistinctRemote = dcount(RemoteIP)
  by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where Connections > 100
| sort by Connections desc;

Tune the cipher-suite string matching to whatever your TLS inspection or egress telemetry actually records — the intent is to build a repeatable legacy-key-exchange hit list that feeds your migration backlog.

Velociraptor VQL

For endpoint-level crypto inventory, this artifact enumerates certificates in the Windows machine store with RSA public keys and short remaining lifetimes relative to a 2030 confidentiality horizon — exactly the certificate population that must be re-issued under ML-DSA or hybrid schemes:

-- Artifact: PQC.CryptoInventory.MachineCerts
-- Enumerate machine-store certificates with quantum-vulnerable public key algorithms.
-- Output feeds the enterprise cryptographic inventory / CBOM.

SELECT Subject, Issuer, NotBefore, NotAfter, SerialNumber,
       PublicKeyAlgorithm, KeyLength, SignatureAlgorithm,
       StoreLocation, StoreName
FROM certificates()
WHERE PublicKeyAlgorithm =~ 'RSA|ECDSA|DSA'
  AND NotAfter > timestamp(epoch=1735689600)  -- valid past 2025-01-01; still in service
ORDER BY NotAfter ASC

Pair this with a glob() sweep for private key material on servers to catch key files that never touch the certificate store:

-- Sweep common locations for private key files with legacy algorithms
SELECT FullPath, Size, Mtime,
       read_file(filename=FullPath, length=200) AS Header
FROM glob(globs=[
  'C:/ProgramData/**/ *.key',
  'C:/Users/*/.ssh/id_rsa*',
  'C:/ProgramData/ssh/ssh_host_rsa_key*'
])
WHERE Header =~ 'BEGIN RSA PRIVATE KEY|BEGIN PRIVATE KEY|BEGIN OPENSSH PRIVATE KEY'

Remediation Script

This PowerShell script produces a starter cryptographic inventory for a Windows host: machine certificates with quantum-vulnerable keys, enabled TLS protocol versions, and Schannel cipher suite configuration. Run it fleet-wide via your RMM or GPO startup script and centralize the CSV output.

# PQC Cryptographic Inventory - run elevated, fleet-wide
$out = "C:\ProgramData\PQCInventory_$(hostname)_$(Get-Date -Format 'yyyyMMdd').csv"

# 1. Machine certificates with quantum-vulnerable public key algorithms
$certs = Get-ChildItem Cert:\LocalMachine\My, Cert:\LocalMachine\Root -ErrorAction SilentlyContinue |
  Where-Object { $_.PublicKey.Oid.FriendlyName -match 'RSA|ECC|DSA' } |
  Select-Object @{N='Type';E={'Certificate'}}, Subject, Issuer, NotAfter,
    @{N='KeyAlgorithm';E={$_.PublicKey.Oid.FriendlyName}},
    @{N='KeySize';E={$_.PublicKey.Key.KeySize}},
    @{N='SignatureAlg';E={$_.SignatureAlgorithm.FriendlyName}}, Thumbprint

# 2. TLS protocol enablement state (Schannel)
$tls = Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -ErrorAction SilentlyContinue |
  ForEach-Object {
    $proto = $_.PSChildName
    Get-ChildItem $_.PSPath -ErrorAction SilentlyContinue | ForEach-Object {
      [PSCustomObject]@{ Type='TLSProtocol'; Subject="$proto $($_.PSChildName)"
        KeyAlgorithm=''; KeySize=''
        Enabled=(Get-ItemProperty $_.PSPath -Name Enabled -ErrorAction SilentlyContinue).Enabled }
    }
  }

# 3. Flag anything that must remain confidential past 2030 still using RSA/ECC
$report = $certs + $tls
$report | Export-Csv $out -NoTypeInformation
Write-Host "Inventory written to $out"
Write-Host "Certificates expiring after 2030 with RSA/ECC keys — prioritize for ML-DSA migration:"
$certs | Where-Object { $_.NotAfter -gt '2030-01-01' } | Format-Table Subject, KeyAlgorithm, NotAfter

Remediation

There is no patch — there is a multi-year program. These are the steps that separate organizations that hit 2029 comfortably from those that panic in 2028:

1. Build the cryptographic inventory now. You cannot migrate what you cannot enumerate. Catalog every use of RSA, ECDH, ECDSA, and DSA across certificates, TLS terminators, VPN gateways, SSH, code signing, HSMs, databases-at-rest, and application-level encryption. Produce a CBOM (Cryptographic Bill of Materials) and refresh it continuously — use the detection content above to keep it honest.

2. Prioritize by confidentiality lifetime, not by exposure count. Data that must stay secret past ~2030 (health records, financial data, trade secrets, government-adjacent data) is already inside the HNDL risk window. TLS sessions protecting that data should be first in line for hybrid key agreement.

3. Enable hybrid PQC TLS where your stack supports it. Current Chrome and Edge already negotiate X25519+ML-KEM-768 against supporting servers — which includes Google front ends. Verify your load balancers, CDNs, and reverse proxies are not stripping or downgrading hybrid handshakes, and pressure vendors that cannot yet terminate PQC TLS for dated roadmaps.

4. Eliminate RSA key transport cipher suites. Any suite without forward secrecy (TLS_RSA_*) is a double liability: classically weak against key compromise and fully exposed to HNDL. Deprecate TLS 1.0/1.1 and RSA kx suites as an immediate, low-cost win.

5. Align with Google Cloud's milestone dates as planning anchors. Treat 2027 (hybrid availability across core services) as your target for having an approved migration architecture and algorithm selections (ML-KEM-768 for key establishment, ML-DSA for signatures per FIPS 203/204). Treat 2028 as your workload-migration execution year. Do not plan to start in 2029 — that is when Google plans to be done.

6. Test for PQC side effects before you need them. ML-KEM key shares and ML-DSA signatures are significantly larger than classical equivalents. Validate handshake sizes against MTU limits, middlebox behavior, certificate chain sizes, and HSM throughput in a lab now. The most common PQC migration failures are operational, not cryptographic.

7. Track regulatory deadlines that will force your hand anyway. NSA CNSA 2.0 timelines (2025–2033 phase-in for national security systems), PCI DSS 4.0's cryptographic inventory expectations, and emerging sector guidance all converge on the same window. Fold PQC into your existing compliance calendar rather than running it as a separate program.

Reference: Google Cloud Post-Quantum Roadmap — SecurityWeek

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub