If you’ve been running Oracle Database for more than a few years, you’ve heard the phrase “quantum threat” before. You’ve also probably filed it under “that’s a problem for 2032” and moved on to the backup window that’s actually broken right now.

You can’t move on anymore. Some people are intercepting and storing your encrypted database traffic today, with the explicit intention of decrypting it once quantum computers can break RSA and ECC. This is the Harvest Now, Decrypt Later (HNDL) attack model, and it’s the single most compelling reason to care about post-quantum cryptography before your next major version upgrade.

Oracle AI Database 26ai (released October 2025) is the first major database system to ship a comprehensive quantum-resistant encryption architecture: NIST-standardized ML-KEM key exchange for data-in-flight via TLS 1.3, combined with enhanced AES256 with XTS mode Transparent Data Encryption (TDE) for data-at-rest. As of August 2026, no other enterprise database vendor has delivered both layers simultaneously with production-ready, NIST-standardized algorithms.

This article breaks down what changed under the hood, shows you the actual SQL and Bash commands to enable it, and gives you a realistic migration path from 19c and 26ai.

Why This Matters Now: The HNDL Threat and NIST’s Timeline

HNDL isn’t theoretical. It’s a three-phase attack that’s been actively discussed in intelligence circles since at least 2019. Here’s how it works:

1. Harvest – An adversary intercepts encrypted traffic flowing between your application and your Oracle database. This could be TLS-protected SQL*Net traffic, RMAN backups in transit, Data Guard redo transport, or GoldenGate replication streams. The adversary stores the ciphertext. They don’t need to decrypt it yet.

2. Store – The captured traffic sits in a database somewhere, indexed by source IP, protocol, and cipher suite. Financial transaction payloads, PII, and health data are particularly valuable targets because their sensitivity doesn’t expire.

3. Decrypt – Once a sufficiently powerful quantum computer exists – one capable of running Shor’s algorithm on the key sizes currently protecting your connections – the adversary decrypts everything they harvested. Your data that was “safe” in 2025 becomes exposed in 2031.

The critical insight for DBAs: the key exchange mechanism is the weak point. AES-256 itself is considered quantum-resistant when used with proper key management (Grover’s algorithm only reduces its effective strength to 128 bits, which remains acceptable). But RSA-2048, RSA-3072, and ECDSA/ECDHE – the algorithms that negotiate your session keys – are vulnerable to Shor’s algorithm. If the key exchange is broken, the symmetric cipher protecting your data doesn’t matter.

This is why ML-KEM – the post-quantum key exchange – is the most urgent component of any PQC strategy, and why Oracle prioritized it for the TLS layer first.

NIST’s Standardization Timeline

The National Institute of Standards and Technology published two post-quantum cryptography standards that Oracle implemented in 26ai, both finalized in August 2024: FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA)

In USA the regulatory clock is now ticking. Executive Order 14028 (2021, “Improving the Nation’s Cybersecurity”) and OMB Memorandum M-24-11 (May 2024) mandate that all federal systems migrate to PQC by December 2030.

If your organization operates in Europe like I do, the regulatory picture is equally urgent – and in some ways more granular. The EU hasn’t issued a single executive order; it has built a layered regulatory framework where PQC compliance emerges from the interaction of several directives.

NIS2 (Network and Information Security Directive 2) applies to essential and important entities across energy, transport, health, digital infrastructure, and more. It explicitly requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption” as part of mandatory cybersecurity risk-management measures. Management bodies must approve these measures and can be held personally liable for infringements, with fines reaching €10 million or 2% of annual worldwide turnover. In January 2026, the European Commission took this further with COM(2026) 13, a proposed amendment that would explicitly require Member States to adopt national policies “for the transition to post-quantum cryptography” – moving PQC from an implied obligation to a named one in the directive text.

DORA (Digital Operational Resilience Act), which applies to financial entities, operationalizes crypto agility as a supervisory expectation. It requires financial institutions to maintain cryptographically agile systems that can adapt when algorithms are weakened or broken – language that directly targets the RSA/ECC-to-PQC transition. DORA’s technical standards mandate documented cryptographic inventories, migration procedures, and testing programs.

ENISA, the EU’s cybersecurity agency, published its Post-Quantum Cryptography: Current State and Quantum Mitigation guidance, recommending that Member States initiate their PQC migration process by the end of 2026. For DBAs and infrastructure teams, this means the inventory-and-planning phase needs to start now – not when the 2030 deadline is around the corner.

Under the Hood: What Oracle Actually Implemented

Oracle’s approach in 26ai isn’t a single feature but a coordinated set of changes across the cryptographic provider, the TLS stack, and the Transparent Data Encryption subsystem. Let’s walk through each layer.

ML-KEM for Data-In-Flight (TLS 1.3 Key Exchange)

ML-KEM (FIPS 203) replaces the classical ECDHE key exchange in TLS 1.3 handshakes. Oracle supports all three NIST security levels:

The size increase is the first thing you’ll notice. A classical X25519 key exchange uses 32-byte public keys. ML-KEM-768 uses ~1,200 bytes. This means larger TLS handshakes, which translates to slightly higher latency on the initial connection – typically 2-5 ms of additional round-trip overhead on a LAN, more on WAN links.

Oracle’s January 2026 Release Update introduced hybrid mode, which is the recommended configuration. Hybrid mode combines classical ECDHE with ML-KEM in a single handshake:

TLS_KEY_EXCHANGE_GROUPS = (hybrid)

In hybrid mode, the session key is derived from both the classical and post-quantum key exchanges. An attacker would need to break both algorithms simultaneously to recover the session key. If a flaw is found in ML-KEM (theoretically possible, though unlikely given the NIST review process), your classical ECDHE still protects the session. And if a quantum computer breaks ECDHE, ML-KEM still protects it.

The default in 26ai is hybrid, which means new installations get post-quantum hybrid key exchange out of the box. For production systems, Oracle recommends restricting this to (hybrid) or (hybrid, ec) to avoid falling back to weak algorithms.

ML-DSA for Digital Signatures

ML-DSA (FIPS 204) is used for TLS certificate validation and authentication. Three parameter sets map to classical RSA equivalents:

ML-DSA-65 is the sweet spot for most deployments – it provides security equivalent to RSA-3072 while keeping signature sizes manageable for wallet storage and certificate exchange.

TDE Enhancements for Data-At-Rest

Here are the default algorithm changes:

The shift from AES-CFB to AES-XTS for tablespace encryption is significant. XTS (XEX-based Tweaked Codebook Mode with Cipher Text Stealing) is the standard mode for disk encryption – used by LUKS, BitLocker, and FileVault – because it provides security against sector-level manipulation attacks that CFB mode doesn’t prevent. In CFB mode, an attacker who can swap encrypted data blocks can potentially manipulate the decrypted output in predictable ways. XTS mode binds each block to its position on disk, preventing this class of attack.

Deprecated algorithms: GOST and SEED encryption algorithms are deprecated in 26ai. Decryption libraries remain available (you can still read existing data), but encryption libraries are fully desupported.

The Cryptographic Provider in 26ai

PQC algorithms require the cryptographic provider included with 26ai. The legacy provider available in earlier versions does not support any post-quantum algorithms.

The provider included with 26ai is available in both FIPS 140 and non-FIPS modes. As of August 2026, it has completed lab testing and appears on the NIST CMVP modules in-process list, but the final FIPS 140 certificate has not been issued yet. If you’re in a compliance environment that requires a signed FIPS certificate (not just “lab-tested”), you’ll need to track the CMVP publication.

In 19c, switching to the next-gen provider requires a binary relink, which means downtime. In 26ai, the PQC-capable provider is native – new installations automatically get PQC support.

Limits: What’s Not Covered and What to Watch For

TLS 1.3 for PQC, TLS 1.2 Fully Supported

Post-quantum algorithms in Oracle are available exclusively through TLS 1.3. Oracle AI Database 26ai supports both TLS 1.2 and TLS 1.3, with TLS 1.3 as the default. If a client connects using TLS 1.2 – which is fully supported alongside TLS 1.3 – the connection automatically falls back to classical ECDHE. There is no PQC protection for TLS 1.2 connections.

This means you need to audit your client base before relying on PQC. Any application, ODBC/JDBC driver, or middleware component that’s pinned to TLS 1.2 will bypass the entire post-quantum key exchange layer. In 26ai, TLS 1.0 and 1.1 are desupported, but TLS 1.2 remains fully supported for backward compatibility.

Performance Impact

The performance characteristics of post-quantum algorithms are fundamentally different from their classical counterparts:

• Key exchange overhead: ML-KEM handshakes add 2-5 ms of latency on LAN connections and 10-30 ms on WAN connections. Hybrid mode compounds this slightly because both ECDHE and ML-KEM keys are exchanged in the same handshake. For OLTP workloads with connection pooling – where the TLS handshake happens once per pooled connection, not per query – this is negligible. For connection-per-request architectures, it can be measurable.

• Signature sizes: ML-DSA-65 signatures (~2.4 KB) are 6-12× larger than ECDSA-P256 signatures (~256 bytes). This affects wallet file sizes, certificate exchange during handshake, and any logging or auditing that stores certificate data.

• TDE throughput: AES256 with XTS mode has comparable throughput to AES-256-CFB on modern CPUs with AES-NI instructions. The difference is in the security model, not the speed. You shouldn’t expect a measurable performance regression from the algorithm change alone.

As always, you should test in non-production with your actual workload profile before enabling PQC in production.

Migration Path from 19c and 26ai

If you’re not ready to jump to 26ai, here’s what to know about your current version. Oracle Database 19c: PQC support is now available in 19c via the next-generation cryptographic provider. When you enable it, you’ll need to:

1. Switch from the legacy to the next-generation cryptographic provider (requires binary relink and downtime)
2. Update sqlnet.ora with TLS_KEY_EXCHANGE_GROUPS and SSL_ENABLE_WEAK_CIPHERS
3. Regenerate certificates using ML-DSA (requires JDK 24+)
4. Test all client connections for TLS 1.3 compatibility

The provider switch is the blocking step. In a RAC environment, this means a rolling restart of all instances. Plan for a maintenance window.

Oracle Database 26ai: If you’re on 26ai, the upgrade path to 26ai includes the cryptographic provider change automatically. However, you’ll still need to regenerate certificates and update sqlnet.ora. TLS 1.3 is not the default in 26ai, so you’ll need to set SSL_VERSION explicitly during the transition period.

What About Key Management?

Oracle’s PQC implementation addresses the algorithm layer but not the key management lifecycle. Your keystore password policy, HSM integration, key rotation schedule, and certificate renewal process all still matter. Post-quantum algorithms don’t fix weak key management practices.

If you’re using Oracle Key Vault or an external HSM, verify that your hardware supports the key sizes required by ML-KEM and ML-DSA. Some older HSM models have fixed-size key storage that can’t accommodate 1,200+ byte lattice keys.

Wrapping up

Oracle AI Database 26ai delivers the first comprehensive, production-grade quantum-resistant encryption story in the database industry. It addresses the two dimensions that matter for any DBA running regulated workloads: data-in-flight via ML-KEM hybrid key exchange over TLS 1.3, and data-at-rest via AES256 with XTS mode Transparent Data Encryption.

The urgency is driven by the “Harvest Now, Decrypt Later” (HNDL) attack model. Adversaries are already intercepting encrypted database traffic, storing it, and waiting for cryptographically relevant quantum computers to break the RSA and ECC key exchanges that protect today’s sessions. NIST’s FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) standards – finalized in August 2024 – give the industry its first vetted post-quantum algorithms, and Oracle is the only enterprise database vendor to ship both simultaneously in a production release as of August 2026. The regulatory clock is ticking.

IBM Db2 12.1.5 has started embedding quantum-safe capabilities including ML-KEM for TLS and FIPS 140-3 alignment. Microsoft SQL Server targets 2029 for PQC support. PostgreSQL depends on OpenSSL 3.5+ and has no database-level PQC implementation. Snowflake and SAP HANA have no public PQC announcements. If quantum resistance matters to your compliance posture Oracle 26ai addresses both the in-flight and at-rest dimensions today.