The question is no longer whether to prepare for Q-Day — it is how, and how quickly. With Google's internal planning deadline set to 2029 and the NSA mandating migration of all U.S. national security systems by 2030, organizations that depend on encrypted data have a finite window to complete a substantial infrastructure transition. Given that large-scale cryptographic migrations typically take three to seven years, the preparation needed to be underway yesterday.
This guide describes the practical steps that security teams, CISOs, and CTOs should be working through right now.
Step 1 — Conduct a comprehensive cryptographic inventory
Start immediately
Before any migration can begin, you need to know what you are migrating. A cryptographic inventory is a systematic catalogue of every place your organization uses public-key cryptography. This includes TLS certificates on web servers and internal services, SSH keys for administrative access, code signing certificates, VPN tunnels, email encryption (S/MIME, PGP), HSMs and TPMs, and any application that performs key exchange or digital signing.
Most organizations discover during this process that their cryptographic surface is significantly larger than expected. Shadow IT, inherited systems from acquisitions, and third-party integrations all add to the inventory. Tools like certificate lifecycle management platforms, network scanning, and code analysis can help automate discovery — but human review of the results is always necessary, because cryptographic dependencies are often undocumented.
NIST's Cybersecurity Practice Guide SP 1800-38 provides detailed methodology for constructing a cryptographic inventory. CISA has published complementary guidance specifically addressing the transition to post-quantum cryptography.
Step 2 — Prioritize by data longevity and sensitivity
Weeks 2–4
Not all encrypted data carries equal risk. The exposure that matters most is data with a long secrecy requirement that is being transmitted or stored today. Medical records, legal communications, financial transaction histories, intellectual property, and government communications that must remain confidential for years or decades are at the highest risk from harvest now, decrypt later attacks.
Classify your data into tiers: data that must remain confidential beyond 2029 (migrate first), data with a 2–5 year confidentiality requirement (migrate second), and data whose confidentiality expires within 2 years (lower urgency). This triage allows you to focus limited resources on the exposures that actually matter to your organization's risk profile.
For most organizations, the highest-priority category includes: long-term customer or patient records, privileged legal communications, trade secrets, and any data subject to regulations that mandate long retention periods (e.g., financial records, healthcare data).
Step 3 — Adopt the NIST post-quantum standards
Planning phase
NIST finalized its first post-quantum cryptography standards in 2024. These are the algorithms you should be migrating to:
ML-KEM (CRYSTALS-Kyber) — the primary standard for key encapsulation. Use this wherever you currently use RSA or Diffie-Hellman key exchange, including TLS, encrypted file storage, and email encryption.
ML-DSA (CRYSTALS-Dilithium) — the primary standard for digital signatures. Use this wherever you currently use RSA or ECDSA signatures, including code signing, certificate authorities, and document authentication.
SLH-DSA (SPHINCS+) — a hash-based signature scheme. More conservative than ML-DSA and based on different mathematics; useful for high-assurance contexts where you want redundancy against algorithm-specific vulnerabilities.
In March 2025, NIST also selected HQC as a fifth algorithm — a code-based scheme that serves as a backup to ML-KEM, built on entirely different mathematical assumptions. Incorporating HQC into your architecture provides insurance against a potential future vulnerability in lattice-based cryptography.
Step 4 — Deploy hybrid encryption as a bridge
Implementation phase
A complete overnight migration from classical to post-quantum cryptography is not realistic for most organizations. The practical approach is hybrid encryption: running both classical and post-quantum algorithms simultaneously, combining their outputs so that a connection is secure as long as either algorithm is unbroken. Hybrid encryption protects you against Q-Day without creating a gap in security if post-quantum algorithms are later found to have vulnerabilities.
Major TLS libraries and cloud providers already support hybrid key exchange. Google Chrome, Firefox, and Cloudflare have been deploying X25519+ML-KEM hybrid TLS since 2024. If you use a major cloud provider's TLS termination, you may already have partial protection without explicitly configuring it — but you need to verify, because defaults vary by service and version.
For your own services, upgrading to TLS 1.3 with ML-KEM key exchange is the most impactful near-term action. Most modern TLS libraries (OpenSSL 3.x, BoringSSL, wolfSSL) have experimental or stable support for ML-KEM. The cost of enabling hybrid mode is low; the protection it provides is immediate.
Step 5 — Extend your assessment to vendors and supply chain
Ongoing
Your cryptographic security is only as strong as the weakest link in your supply chain. If you migrate your own systems but continue to exchange sensitive data with partners, vendors, or cloud services that have not yet migrated, the harvest-and-decrypt exposure persists for all of that data.
Include post-quantum readiness in your vendor security assessments. Ask key technology vendors what their PQC migration timeline is and what algorithms they are testing. For mission-critical integrations — payment processors, identity providers, cloud storage — require contractual commitments to migration timelines aligned with your own.
This is particularly important for financial institutions (see Q-Day and Banking), healthcare organizations, and any sector where data flows across multiple organizations with interconnected security dependencies.
Step 6 — Build a migration roadmap with 2029 as your backstop
Strategic planning
The Q-Day timeline presents a specific planning problem: the date is uncertain, but the migration takes a fixed amount of time regardless. Working backwards from Google's 2029 estimate — the most aggressive credible deadline from a major institution — means a migration that starts in 2026 has three years to completion. For large organizations with complex infrastructure, three years is tight.
A practical roadmap might look like this: 2026 — complete cryptographic inventory and data classification; 2027 — deploy hybrid TLS across all external-facing services, begin migrating highest-priority data stores; 2028 — migrate internal services and key management infrastructure; 2029 — complete migration of legacy systems, conduct audit and validation. Build in contingency time for vendor delays and unforeseen dependencies.
Governance matters here. PQC migration cannot be treated as a routine IT project. It needs board-level visibility, dedicated budget, and a single accountable owner — typically the CISO or CTO. Organizations that have gotten ahead of the problem have done so because their leadership understood the stakes and funded the work accordingly.
What individuals can do
For individuals, the Q-Day threat is largely mediated through the products and services they use. The most impactful actions are indirect: keeping software up to date (which ensures you benefit from TLS upgrades as they roll out), using services that have publicly committed to PQC migration, and being aware that communications with a very long secrecy requirement — legal documents, sensitive business negotiations, health information — transmitted today may be at risk.
The most direct exposure for individuals is in cryptocurrency. Wallets that use ECDSA — which includes most Bitcoin wallets — are vulnerable to Q-Day attacks on any address that has previously spent funds (exposing the public key). If you hold significant value in cryptocurrency, understand your wallet's exposure and follow the quantum threat to Bitcoin as the discussion around migration paths evolves.