Encryption is a depreciating technology. Over time, the value of the control decreases unless the encryption is periodically updated.

For the last few years, cryptography teams have been thinking about how they would keep data secure when sufficiently capable quantum computers could break widely used cryptography. The practical concern is the vulnerability of network and storage encryption to quantum-computing threats. In practical terms, quantum risk for today’s enterprise systems comes down to the expectation that quantum computers will eventually advance to a point where they can be used to attack both asymmetric and symmetric encryption using Shor’s and Grover’s algorithms:

Shor’s Algorithm affects asymmetric cryptography. In practice, it threatens public key systems, such as those used for key establishment and digital signatures, including RSA, Diffie Hellman, and elliptic curve cryptography. That matters because Transport Layer Security (TLS) commonly relies on these primitives to securely exchange the session encryption key and authenticate the endpoints.

Grover’s algorithm affects symmetric cryptography by reducing the effective strength of keys by half. In practical terms, shorter symmetric keys become less comfortable as a long-term choice. For example, AES-256 algorithm essentially becomes as strong as AES-128 algorithm.  This matters because AES is commonly used to encrypt data at-rest including databases, backups, and exports. A quantum computer of sufficient strength to leverage Grover’s algorithm implies that if you are encrypting your data with AES-128 algorithm, it is equivalent to using a key with half the length (64 bits) – which most security professionals would classify as an unacceptable risk.

Why should you worry about this threat now?

Both algorithms remain impractical to execute at scale on today’s quantum hardware for breaking modern, well-configured systems.

But, the primary threat today is one of “harvest now, decrypt later (HNDL),” where attackers intercept and copy encrypted data (network and storage) for later use. HNDL is not a theoretical threat but an active present-day threat. When the adversaries are successful in making copies, all your sensitive data especially with a long shelf life such as personally identifiable data could become available to the adversaries at a future point. Your live database may change tomorrow, but your backup preserves yesterday’s secrets for years, which makes AES-128 encrypted backup data especially exposed to HNDL attacks.

Nation-state actors and hackers could already be collecting and stockpiling data, expecting to be able to decrypt it when quantum computers of sufficient strength are available sometime in the future.

What might cause the timeline to jump?

Quite frankly, most of the industry has been so focused on the need for “sufficiently powerful” quantum computers to appear that it didn’t account for the possibility of more algorithms to join the earlier Shor’s and Grover’s algorithms.  

For example, last month, three researchers released a paper titled “A Novel Hybrid Quantum Circuit for Integer Factorization: End-to-End Evaluation in Simulation and Real Quantum Hardware” that introduced the Jesse-Victor-Gharabaghi (JVG) Algorithm that cuts down the time, memory, and compute needed by an order of magnitude or more. The validity of the JVG algorithm’s claims was quickly called into question by other cryptography researchers and may have been a false alarm. The Pinnacle Architecture also claims to reduce the cost of breaking RSA-2048 by an order of magnitude.  However, even if these algorithms are not the “Cybersecurity Apocalypse in 2026,” they do highlight a critical planning lesson: timelines can compress not only through hardware advances but also through algorithmic innovation.

What should you do?

If “Q-day” were today, you would no longer be able to rely on encryption to keep your data secure and would need to respond quickly to rapidly changing conditions that could pose a threat to your business operations.

 As Van Griensven said when releasing the paper on JVG, “The lesson from JVG is that the timeline is accelerating not only because hardware advances, but also because algorithms improve. That is why post-quantum upgrades must be treated as urgent infrastructure work.” The work to get ready for Q-day is real. You’ll need time to inventory where your systems use crypto, validate client and partner compatibility, update configurations, and deploy changes safely across environments.

If you do only one thing this quarter: run a cryptographic inventory. You can’t mitigate what you can’t see, so create a cryptographic bill of materials (CBOM). Begin with crypto hygiene and reduce your exposure where you can by doing the following:

• Inventory crypto (systems + protocols + certificates + key sizes + ownership) so that when new vulnerabilities are uncovered, you can react quickly. We wrote earlier about the importance of creating a cryptographic bill of materials and gave an example of a CBOM in that blog.
• Enforce TLS 1.3 where possible but a minimum of TLS 1.2 everywhere; deprecate legacy versions (1.1, 1.0) if you can’t remove them.
• Adopt post-quantum or hybrid key establishment for TLS 1.3. ML-KEM (module-lattice-based key-encapsulation mechanism) is the current NIST-standardized post-quantum KEM. Hybrid approaches can help you balance compatibility and risk reduction during migration.
• Raise symmetric key-length floors and use AES-256 for long-lived data.
• Check your older backups and see if any of them are encrypted using weaker algorithms such as AES-128? If so, evaluate your risk against the effort required to update the encryption algorithm or securely destroy those backups.
• Evaluate switching to public key certificates that use a quantum-resistant signature algorithm like ML-DSA (module-lattice-based digital signature algorithm).  At minimum, ensure that all of your certificates are for RSA 2048-bit or higher.

Support for quantum-resistant crypto in Oracle AI Database 26ai

Oracle AI Database 26ai introduced a quantum-resistant module-lattice key exchange mechanism (ML-KEM) and support for ML_DSA certificates beginning with the 23.26.0 release (October, 2025) and added hybrid key exchange support beginning with release 23.26.1 (January, 2026).

Oracle AI Database 26ai users can get ahead of the HNDL threat by reviewing settings such as:

• Ensure TLS_VERSIONS includes TLS1.3.
• Ensure TLS_KEY_EXCHANGE_GROUPS prioritizes hybrid and/or ml-kem first (for example, hybrid,ml-kem,ec).
• Ensure that Transparent Data Encryption (TDE) uses AES-256, which is the default.
• Consider moving towards ML-DSA signed certificates.

If you haven’t adopted Oracle AI Database 26ai yet, consider layered security controls – network segmentation, strict access controls, and continuous monitoring – to help reduce overall interception risk.

What if you are on Oracle Database 19c?

Later this year, Oracle plans to introduce TLS 1.3 support, including quantum-resistant key exchange, in Oracle Database 19c. For now, you should:

• Ensure you are using TLS 1.2 with strong cipher suites like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 or TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
• Double-check your data-at-rest symmetric encryption (Transparent Data Encryption in most cases) to be sure you are using AES-256. The default tablespace encryption algorithm for 19c is AES-128, so unless your team explicitly called out AES-256 when encrypting your data, you may have to re-encrypt the tablespaces with the stronger AES-256 algorithm.

Conclusion

Quantum risk has moved from a future scenario to a present planning requirement. Shor’s and Grover’s algorithms already define the contours of risk for TLS and AES, and new research indicates that algorithmic innovation may reduce the time and resources needed to attack non-quantum-resistant systems. Treat post-quantum preparedness as essential infrastructure. Start with visibility, modernize your TLS posture, adopt post-quantum or hybrid key establishment where supported, and raise symmetric key baselines for long-lived data.

Additional Reading

Oracle Database cryptographic roadmap: https://www.oracle.com/security/database-security/crypto-roadmap

Blog: You Can’t Modernize Database Cryptography You Can’t See – First Create a Crypto Inventory: https://blogs.oracle.com/database/cbom

Blog: Security Oracle AI Database 26ai for the Quantum Era:  https://blogs.oracle.com/database/oracle-ai-database-26ai-pqc

Blog: Both is better – Oracle AI Database 26ai adds hybrid-mode quantum-resistant support: https://blogs.oracle.com/database/hybrid-pqc

Database Security eBook: https://download.oracle.com/database/oracle-database-security-primer.pdf

Database Security Guide (26ai): https://docs.oracle.com/en/database/oracle/oracle-database/26/dbseg/index.html

Database Security Guide (19c): https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/index.html