CyphrQ
Menu

What Is Q-Day? A Calm Guide to Post-Quantum Readiness

Q-Day is when a quantum computer could break today's encryption. What it is, what NIST has standardised, and a practical checklist for you.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

Q-Day is the day a quantum computer becomes powerful enough to break the public-key encryption that protects most internet traffic, banking and messaging today. Nobody knows when it will come. But data stolen now can be decrypted later, so the switch to quantum-safe encryption has already started. Most of it will reach you through ordinary updates.

You don't need to panic about quantum computers. You do need to know which of your systems will still hold secrets in 2035.

What is Q-Day, exactly?

Most secure connections rely on public-key cryptography, such as RSA and elliptic-curve algorithms. It lets two strangers agree on a secret key over an open network and lets you check that a website or software update is genuine.

Those algorithms are safe against today's computers. A large enough quantum computer, which experts call a "cryptographically relevant quantum computer" (CRQC), could break them. Q-Day is the informal name for the day one exists.

Two things are worth knowing:

  • It isn't the end of encryption. Symmetric encryption (like AES), which protects data once a key is agreed, is far less exposed. The weak point is how keys are exchanged and how signatures are checked.
  • Replacements already exist. They're called post-quantum cryptography, explained next.

What is post-quantum cryptography?

Post-quantum cryptography (PQC) is a set of new encryption and digital-signature algorithms designed to stay secure against both today's computers and future quantum computers (NIST).

You don't need a quantum computer to use it. PQC runs on the computers and phones you already own, and it reaches most people through ordinary software updates.

When will Q-Day happen?

Honest answer: nobody knows, and experts disagree.

  • NIST, the US standards body, says nobody knows when a CRQC will arrive and that predictions vary widely.
  • The Global Risk Institute's Quantum Threat Timeline Report 2025 surveyed 26 experts. They put the chance of a CRQC at 28-49% within 10 years and 51-70% within 15 years. That is a survey of opinion, not a forecast, and it shows how wide the uncertainty is.

So treat any single date you see online, earlier or later, with caution. What matters more is that governments have set migration deadlines regardless.

Why does "harvest now, decrypt later" matter today?

"Harvest now, decrypt later" means an attacker copies encrypted data today and stores it until a quantum computer can unlock it.

NIST calls "harvest now, decrypt later" one of the reasons to start encrypting with post-quantum methods as soon as possible, because some secrets stay valuable for many years (NIST: What Is Post-Quantum Cryptography?). NIST's transition plan, NIST IR 8547, is still an initial public draft from November 2024: as of 24 October 2026, NIST hasn't published a final version.

The practical test is simple: if a piece of data would still hurt you if it leaked in ten years, it is already exposed to this risk. Think health records, legal files, long-term contracts, intellectual property, and identity documents.

A daily sales report from 2026 probably doesn't matter in 2036. Your customers' passport scans might.

Signatures are a different case. Forging a signature needs a quantum computer at the moment of the attack, so recorded traffic doesn't help anyone forge yesterday's signatures. That makes key exchange the first priority, and it is where browsers started.

What are NIST's post-quantum standards?

In August 2024, NIST approved its first three post-quantum standards:

Standard Name What it does Based on
FIPS 203 ML-KEM Agrees a shared secret key between two parties CRYSTALS-Kyber
FIPS 204 ML-DSA Digital signatures (proves who signed, detects tampering) CRYSTALS-Dilithium
FIPS 205 SLH-DSA Digital signatures, using a different maths approach as a backup SPHINCS+

More is on the way. NIST is working on a fourth standard, FIPS 206, for FN-DSA, a signature algorithm based on FALCON. As of 24 October 2026 I couldn't find a final FIPS 206 on NIST's site.

In March 2025 NIST also selected HQC as a backup to ML-KEM, built on different maths, with a final standard expected in 2027. NIST's post-quantum project page lists both Falcon and HQC as in ongoing standardisation, so check there for current status.

NIST's advice hasn't changed: organisations should keep migrating to the 2024 standards now, and ML-KEM remains the recommended choice for general encryption.

Is there a deadline for moving to post-quantum encryption?

There are official target dates, not a single global deadline:

The NCSC's guidance is aimed mainly at large organisations and those with custom-built IT. For most small businesses, the change will mostly arrive through vendors' normal updates.

What is already changing?

More than most people realise, and most of it happens without you doing anything.

  • Web browsers. Chrome uses a "hybrid" key exchange that combines a classical algorithm with a post-quantum one, so an attacker would need to break both. Since Chrome 131 it has used the standardised ML-KEM for this. Earlier versions used a draft called Kyber (Google). It only applies when the website's server supports it too.
  • Messaging apps. Signal added post-quantum protection to its key exchange in 2023. Apple added PQ3 to iMessage in 2024, which also refreshes post-quantum keys during a conversation.
  • Governments. The US agencies CISA, NSA and NIST published a joint quantum-readiness factsheet in 2023 telling organisations to build a cryptographic inventory and talk to their vendors.

In practice: on 28 October 2025, Cloudflare reported that the majority of human-initiated traffic through its network was already using post-quantum encryption. The same post notes Apple rolling it out by default in iOS, iPadOS and macOS 26 (Cloudflare). No user setting is involved. It happens when the browser and the server both support it.

What should a business owner do now?

You don't need a quantum budget. You need a list and some vendor questions.

  1. Name an owner. One person accountable for "post-quantum readiness", even if it's part-time.
  2. List your long-lived data. What must stay confidential for 5, 10 or 20 years? Start there.
  3. Find where encryption lives. Websites, VPNs, email, cloud storage, payment systems, backups, and any custom software. Your IT provider can help.
  4. Ask every key vendor three questions: - Do you have a post-quantum roadmap, and when will you support ML-KEM? - Will the upgrade arrive as a normal update, or will we need to act? - Does your product support hybrid key exchange today?
  5. Keep everything updated. Browsers, operating systems, VPNs and servers. Most post-quantum protection will arrive this way.
  6. Write PQC into new contracts. For any system you expect to run past 2030, ask for post-quantum support as a requirement.
  7. Diarise 2028. That is the NCSC's first milestone, and a sensible checkpoint for a plan.

What should an individual do now?

Much less, and none of it costs money.

  • Turn on automatic updates for your phone, computer and browser. That's how quantum-safe encryption reaches you.
  • Use messaging apps that have published post-quantum protection, such as Signal or iMessage, for sensitive conversations, and keep them updated.
  • Think before uploading long-lived documents like passport scans or medical records to services you don't trust.
  • Ignore anyone selling "quantum-proof" products by fear. The real upgrades come from the companies that already make your software.

Going deeper: for security and IT teams

This part assumes you know TLS and PKI.

Which FIPS algorithm goes where

  • ML-KEM (FIPS 203) replaces ECDH and RSA key transport for agreeing session keys. It has three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, "in order of increasing security strength and decreasing performance" (FIPS 203).
  • ML-DSA (FIPS 204) is the general replacement for RSA and ECDSA signatures: certificates, code signing, documents (FIPS 204).
  • SLH-DSA (FIPS 205) is the signature hedge on a different mathematical basis, worth considering for long-lived roots of trust where you want diversity from ML-DSA.

Read FIPS 204 and 205 themselves before choosing signature parameter sets.

How hybrid key exchange works in TLS 1.3

The IETF published the hybrid groups as RFC 10024 in August 2026. The client's key share carries both a classical and an ML-KEM public key. The two shared secrets are concatenated and fed into the TLS 1.3 key schedule, so an attacker has to break both.

TLS group Codepoint Recommended Shared secret
X25519MLKEM768 0x11EC Yes ML-KEM then X25519, 64 bytes
SecP256r1MLKEM768 0x11EB No ECDHE then ML-KEM, 64 bytes
SecP384r1MLKEM1024 0x11ED No ECDHE then ML-KEM, 80 bytes

The RFC puts the secrets in a different order per group for FIPS-compliance reasons.

Clients are mostly ready. Cloudflare's compatibility list shows X25519MLKEM768 on by default in Chrome and Edge 131+, Firefox 132+ on desktop, Safari 26, OpenSSL 3.5.0+, Go 1.24+, and NGINX built against OpenSSL 3.5+. The gap is usually yours: servers, load balancers, TLS-inspecting proxies, and appliances linked against older libraries.

How to check whether a server negotiates it

Cloudflare's origin guide uses BoringSSL:

bssl client -connect <host>:443 -curves X25519MLKEM768

The "ECDHE curve" line should read X25519MLKEM768. The guide's OpenSSL 3.5.0+ check looks for Negotiated TLS1.3 group: X25519MLKEM768. Test from a client that supports the group, or you'll only ever see a classical result. For browsers, Cloudflare Radar has a support check.

Where cryptography hides in your estate

An inventory that stops at the certificate list misses most of it. Check:

  • public and internal TLS endpoints, including load balancers and service meshes;
  • VPN gateways and SSH;
  • internal CAs and everything that trusts them;
  • code-signing and firmware-signing keys;
  • HSMs and cloud KMS: which algorithms the firmware supports, and the upgrade path;
  • crypto libraries and runtimes compiled into your apps, with versions;
  • vendor products and SaaS where someone else holds the keys.

Record it as a cryptographic bill of materials (CBOM). CycloneDX can represent cryptographic assets such as algorithms, keys and certificates and tie each to the software component that uses it (CycloneDX). That lets the inventory live in your SBOM pipeline instead of a spreadsheet.

Crypto-agility as an engineering habit

Crypto-agility means you can change algorithms without rewriting software. In practice: algorithm and TLS group lists live in configuration, not code. Each language uses one approved crypto library, not raw primitives. Keys and certificates are tracked centrally, with owners and expiry dates.

The test is one question: how long would it take to change the TLS group list on every endpoint? If it would take a project, write that down as finding number one. Then ask each vendor which RFC 10024 groups they support by default, which TLS library and version they ship, and whether their TLS inspection passes hybrid groups through.

Key takeaways

  • Q-Day is when a quantum computer could break today's public-key encryption. Its date is unknown and contested.
  • "Harvest now, decrypt later" makes long-lived data the priority today.
  • NIST published FIPS 203, 204 and 205 in August 2024; FN-DSA (FIPS 206) and HQC were still being standardised as of October 2026.
  • Browsers and major messaging apps have already started switching.
  • Hybrid TLS key exchange (X25519MLKEM768) is now an IETF standard, RFC 10024. Most clients support it, so check your servers and proxies.
  • Businesses: inventory, ask vendors, update. Individuals: keep updates on.

Sources