What Is Q-Day, and Is Your Data Ready for It?

What Q-Day is

Q-Day is the day a quantum computer becomes powerful enough to break the public-key cryptography we run today. RSA, Diffie-Hellman, elliptic curve. That is the math behind your TLS sessions, your certificates, and your signed software.

The question is when, and the forecasts are all over the place. The U.S. GAO says 10 to 20 years. NIST says as early as 2030 or as late as three decades out. The NSA wants quantum-resistant algorithms in all new deployments by January 1, 2027. Google says it intends to be ready by 2029.

Pick whichever number you like. For planning, it does not matter.

Harvest now, Decrypt later

The risk on your register today is not the quantum computer. It is a copy of your data sitting on someone else's storage.

It is called harvest now, decrypt later. An attacker captures your encrypted traffic and backs it up today. They do not break anything now. They sit on it and decrypt later when the hardware shows up. Your live database changes tomorrow. Your backup freezes yesterday's secrets for years. Anything that must stay confidential for a decade is already inside the harvest window.

The two threats in plain terms

Shor's algorithm breaks asymmetric crypto. RSA, Diffie-Hellman, elliptic curve. These are exactly what TLS uses to exchange your session key and authenticate endpoints.

Grover's algorithm weakens symmetric crypto by halving effective strength. AES-256 drops to roughly AES-128. AES-128 drops to an effective 64 bits, which no one should accept for long-lived data. If your old backups are on AES-128, those are your most exposed assets.

The hardware is not there yet, but timelines compress not only when hardware improves, but when someone publishes a smarter algorithm. The needle can jump without warning, and you do not get advance notice to go re-encrypt a decade of backups.

What PQC is

PQC stands for Post-Quantum Cryptography. It means new cryptographic algorithms designed to protect data against both today’s conventional computers and future, sufficiently powerful quantum computers. NIST describes the problem this way: many current encryption systems are safe against normal computers, but a powerful quantum computer could break the math that protects much of today’s online security.

The first three Post-Quantum standards

On August 13, 2024, NIST finalized the first three post-quantum standards.

ML-KEM is the primary one for key exchange. Small keys, fast, lattice-based. ML-DSA is the primary one for signatures. SLH-DSA is the hash-based backup, there in case lattice signatures ever turn out to have a problem.

What Oracle AI Database 26ai does about it

26ai shipped quantum-safe TLS in two steps. Release 23.26.0 (October 2025) added ML-KEM key exchange and ML-DSA certificates. Release 23.26.1 (January 2026) added hybrid key exchange.

• Key exchange. Enable it with TLS_KEY_EXCHANGE_GROUPS on the server and client. At least one side must require ML-KEM, or it falls back to ECDHE. Recommended order on 23.26.1 is hybrid,ml-kem,ec. Hybrid runs classical and post-quantum together, so you do not bet everything on a young algorithm during migration.
  
  

• No flag day. The server can accept both traditional and quantum-safe TLS 1.3 clients at once, then tighten to ML-KEM only when every client supports it.
  
  

• ML-DSA certificates. Supported in the handshake. Public CAs are only expected to issue them from 2026 on, so for urgent cases, you can generate self-signed ML-DSA certs with orapki.
  
  

• AES-256 at rest. Default for TDE in 26ai, paired with SHA-256. Watch the trap. On 19c and 21c, the tablespace default was AES-128. Find any AES-128 data and re-encrypt with ALTER TABLESPACE ... REKEY.
  
  

• Performance. Post-quantum keys are about 10x larger, but Oracle's benchmarks put ML-KEM up to 10 percent faster than ECDHE. Moving off TLS 1.2 can leave you safer and quicker.
  
  

• Driver gaps. Quantum-safe works today on the OCI path. SQL*Plus, thick-client SQL Developer, ODP.NET Unmanaged, and the server. Not yet: JDBC, SQLcl, the VS Code plug-in, and the Python, Node.js, and managed ODP.NET drivers. Check your client stack before assuming end-to-end coverage.

Still on 19c? Oracle plans to bring TLS 1.3 with quantum-resistant key exchange to 19c later this year. Until then, run TLS 1.2 with strong suites, confirm TDE is AES-256 and not the 19c AES-128 default, and lean on segmentation and monitoring.

Your follow-through

Open a terminal against one database. Check three settings. Is TLS_VERSIONS including TLS1.3? Does TLS_KEY_EXCHANGE_GROUPS lead with hybrid or ml-kem? Is TDE on AES-256, or did you inherit the old AES-128 default? That is your first CBOM entry.

Then ask the harder question. Where are the backups, and what encrypted them? That is where harvest-now actually bites.

Conclusion

Q-Day will come sooner or later. The harvest-now threat is active today; your long-lived data is already in the window, and the fix takes time to do safely.

The good news for the Oracle estate is that the hard parts already ship in 26ai. ML-KEM, hybrid key exchange, ML-DSA certificates, AES-256 by default, and a TLS 1.3 path that can run faster than what you have.

If you want a second set of eyes on your crypto posture across the estate, that is the kind of work we do at DSP-Eclipsys, contact us today to learn more. Either way, run the inventory and start thinking about your data security.