Google Moves Q Day Deadline to 2029, Pressuring Industry on Encryption

Google has sharply revised its estimate for Q Day — the moment quantum computers can break today’s encryption — moving the deadline to 2029, far earlier than the industry had assumed. That’s not a distant research problem anymore. That’s the current product cycle.

The company is now urging the entire tech industry to accelerate migration away from RSA and elliptic-curve (EC) cryptography before that window closes. Meanwhile, two separate supply-chain security incidents this week serve as a sharp reminder of how fragile software trust infrastructure already is — before quantum threats even enter the picture.

Google’s 2029 Q Day Projection: Why It Matters Now

For years, the consensus estimate placed Q Day somewhere in the 2030s or beyond — comfortably far enough away that most security teams could deprioritize post-quantum migration. Google’s revised projection collapses that runway to roughly four years.

The practical implication is blunt: any system encrypting data today that needs to remain confidential beyond 2029 is already at risk. Adversaries executing “harvest now, decrypt later” attacks are already collecting encrypted traffic, betting on quantum decryption capabilities arriving on schedule. Google’s warning is that schedule just moved up.

RSA and EC underpin virtually every TLS handshake, code-signing certificate, and VPN tunnel in production infrastructure today. Replacing them isn’t a configuration change — it requires auditing cryptographic dependencies across entire stacks, updating libraries, rotating key material, and validating new algorithms under real-world load conditions. Four years is tight for large enterprises. For critical infrastructure operators, it may already be insufficient.

What Post-Quantum Alternatives Exist?

NIST finalized its first post-quantum cryptography standards in 2024, including ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation and ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures. These are the migration targets Google and other major vendors are pushing toward. The limitation worth flagging: real-world performance benchmarks for these algorithms at scale remain sparse, and hybrid classical/post-quantum deployments introduce their own complexity and attack surface.

Trivy Scanner Compromised in Active Supply-Chain Attack

Separately, the widely deployed Trivy vulnerability scanner — used by security and DevOps teams to scan container images and infrastructure-as-code — has been compromised in an ongoing supply-chain attack. Administrators using affected versions are being advised to treat any secrets the tool had access to as potentially exposed and rotate credentials immediately.

Trivy’s reach is broad. It integrates into CI/CD pipelines, Kubernetes admission controllers, and developer workstations. A compromised scanner sitting inside a build pipeline has privileged visibility into dependency graphs, container registries, and often cloud provider credentials. The blast radius of such a compromise is disproportionately large relative to the tool’s apparent footprint.

Fair enough — no scanner is inherently trustworthy just because it scans for vulnerabilities in other software. This incident is a textbook case for why security tooling itself belongs in your threat model, not outside it.

Recommended Immediate Actions for Trivy Users

• Audit which pipeline stages Trivy touched and what credentials it had access to
• Rotate any secrets, tokens, or cloud credentials accessible from affected environments
• Pin to a verified, uncompromised version or temporarily remove Trivy from active pipelines
• Review outbound network connections from build environments for anomalous traffic
• Check for indicators of compromise on systems where Trivy ran with elevated permissions

Self-Propagating Malware Targeting Open Source Ecosystems

A third incident rounds out a difficult week for software supply-chain security: self-propagating malware has been identified poisoning open source packages, with confirmed destructive behavior including wiping machines at Iran-based organizations. Development teams are being urged to conduct network-level investigations to check for active infections.

Self-propagating behavior in a package repository context is particularly dangerous. Once a poisoned dependency enters a build environment, it can spread laterally — infecting other packages, corrupting build artifacts, or establishing persistence before detection. The wiper payload component signals a threat actor willing to cause irreversible damage, not merely exfiltrate data.

The geographic targeting of Iran-based machines adds a geopolitical dimension, but development teams outside that region shouldn’t treat this as someone else’s problem. Package ecosystems are global. A poisoned library doesn’t check the developer’s timezone before executing.

What This Means for Security and Engineering Teams

Three separate incidents in the same week — a post-quantum timeline compression, a compromised security scanner, and self-replicating malware in open source packages — aren’t coincidental in their implications. They all attack the same weak point: trust in the software and cryptographic infrastructure that engineering teams rely on by default.

Google’s 2029 Q Day projection means post-quantum migration planning needs to start in current-year roadmaps, not future ones. Waiting for a “mature” migration path is increasingly not an option — the NIST standards are finalized, and the clock is running.

The Trivy and open source malware incidents reinforce a harder organizational truth: security tooling and third-party dependencies carry the same supply-chain risk as any other software. Treating your scanner, your linter, or your build tool as implicitly trusted because it’s a “security product” is a category error that attackers are actively exploiting.

Is your organization’s post-quantum migration on the 2025 roadmap yet? If not, Google’s revised timeline suggests it needs to be.

---