Your encryption strategy just got a deadline. Google's warning about quantum computers potentially breaking current encryption by 2029 has shifted post-quantum cryptography from a future concern to an immediate priority. Privacy officers and security teams are now asking: Is this real? What do we do first? Can we wait?
Here's what you're actually asking in team meetings and risk committees.
The Source of These Concerns
These aren't theoretical issues. If you're managing authentication systems, storing classified documents, or handling data with retention periods longer than five years, your threat model changed last month. The intelligence community has been preparing for quantum decryption for over a decade. Your board is now asking why you aren't.
The questions below come from conversations with privacy officers, CISOs, and compliance teams who need to explain post-quantum migration timelines to executives who just read the same headline you did.
Is 2029 Realistic, or Just Vendor Fear-Mongering?
It's not fear-mongering, but it's not a guaranteed deadline either.
Google adjusted its threat model to prioritize post-quantum cryptography migration for authentication services based on 2029 as a planning horizon. Expert timelines for a cryptographically relevant quantum computer range from the 2030s to the 2050s. The UK's National Cyber Security Centre set 2035 as the date by which organizations should have quantum-resistant systems in place.
Here's what matters: the range of estimates now starts in the late 2020s. That's close enough that you can't defer the work. If your data retention periods extend past 2030, you're already in the risk window.
The threat isn't just "will quantum computers exist by 2029?" It's "are adversaries already storing our encrypted data today, planning to decrypt it when quantum systems mature?" That attack pattern is known as "store now, decrypt later."
What Is "Store Now, Decrypt Later," and Should You Care?
You should care if you're encrypting anything with a shelf life longer than the time it'll take to build a working quantum computer.
The attack works like this: an adversary intercepts and stores your encrypted data today using current encryption standards. They can't decrypt it now, but they hold onto it, waiting for quantum computers capable of breaking today's Asymmetric Encryption to become available. When that happens, they decrypt everything they've been stockpiling.
This isn't hypothetical. As one expert noted, "National security documents from 1920 are not relevant today. But stuff from 10 years ago is much more relevant, and should not get into the wrong hands in the future."
If you're encrypting:
- Authentication tokens with session data
- Health records with 7-year retention periods
- Financial transaction logs
- Classified internal communications
- Trade secrets or M&A documents
...then assume someone is already collecting that encrypted traffic.
What Breaks When Quantum Computers Arrive?
Most current encryption relies on mathematical problems that are hard for classical computers to solve but trivial for quantum computers.
Asymmetric Encryption (public-key systems) is the primary target. RSA, elliptic curve cryptography, and Diffie-Hellman key exchange all become vulnerable. These systems protect:
- TLS/SSL connections
- Digital Signature verification
- Key exchange protocols
- Certificate-based authentication
Symmetric Encryption (like AES-256) is more resistant but not immune. You'll need to double key sizes to maintain Essential Equivalence.
The practical impact: your authentication services, API security, and any system relying on public-key infrastructure need re-architecting.
Do You Need to Replace Everything, or Can You Layer Post-Quantum Crypto on Top?
You can layer, but you need a migration plan, not a patch.
Google's approach: prioritize authentication services and Digital Signature systems first. These are the highest-value targets because they control access to everything else.
Your migration strategy should sequence:
- Authentication systems, anything issuing tokens, verifying identities, or managing sessions
- Data at rest with long retention periods, re-encrypt archives, backups, and records you're required to keep
- Inter-service communication, API calls, microservice traffic, internal certificates
- External-facing systems, customer portals, partner integrations, public endpoints
Don't try to do everything at once. You'll need to run hybrid systems where post-quantum algorithms coexist with classical encryption during the transition.
What's the First Step You Can Take This Month?
Inventory what you're protecting and how long it needs to stay protected.
Build a spreadsheet with three columns:
- System or data category (authentication service, customer records, financial logs)
- Current encryption method (RSA-2048, AES-256, etc.)
- Protection horizon (how long does this data need to remain confidential?)
Anything with a protection horizon extending past 2030 goes on your priority list. Anything using RSA or elliptic curve cryptography for authentication goes on your immediate action list.
Then identify your cryptographic dependencies. You're not just replacing algorithms; you're replacing libraries, certificate authorities, key management systems, and potentially hardware security modules. Map those dependencies now.
How to Explain This to Executives Who Think Encryption Is Encryption
Frame it as a retention period problem, not a technology problem.
Use this script: "The data we're encrypting today using current standards could be decrypted by quantum computers within the protection period we've committed to. If we're required to keep customer data confidential for seven years, and quantum computers capable of breaking our encryption arrive in six years, we're in breach of our data protection obligations."
That's a GDPR Technical and Organisational Measures failure. It's a contractual liability. It's a board-level risk.
You're not asking for budget to chase emerging tech. You're asking for budget to maintain the confidentiality commitments you've already made.
Are There Standards or Frameworks You Can Point To?
Yes. NIST has been running a post-quantum cryptography standardization process since 2016 and published its first set of approved algorithms in 2024. Those algorithms are:
- CRYSTALS-Kyber for Key Wrapping
- CRYSTALS-Dilithium for Digital Signatures
- SPHINCS+ for stateless hash-based signatures
Start with NIST's guidance. The National Cyber Security Centre also published quantum-readiness guidance you can reference.
Your compliance framework likely doesn't mention post-quantum crypto yet, but it does require you to implement appropriate Technical and Organisational Measures based on the state of the art. Once NIST publishes standards and major tech companies announce migration timelines, "state of the art" shifts.
Where to Go for More
If you're responsible for authentication systems, start with Google's engineering blog on their post-quantum migration. It's not marketing; it's their actual implementation roadmap.
For policy guidance, review the National Cyber Security Centre's quantum-readiness materials. They include risk assessment templates and migration planning tools.
And if you're managing long-term data archives or classified documents, calculate your protection horizon now. The question isn't whether quantum computers will break your encryption. It's whether they'll break it before your retention period expires.
