A practical CISO guide to moving Oracle Database traffic toward quantum-safe TLS 

Hybrid protection for database traffic: established cryptography and a lattice-based post-quantum layer operate together during the transition.

The risk already exists

Your database traffic may be encrypted today and still be at risk tomorrow. An attacker does not need a quantum computer to start causing harm. They can capture protected traffic now, retain it, and wait for future advances to challenge the public key cryptography used to establish TLS sessions. This is the harvest now, decrypt later risk.

For a CISO, the question is straightforward: Which information leaving our databases must remain confidential long enough that future decryption would be unacceptable? For customer records, payment data, health information, intellectual property, and long retention data, the answer is often measured in years, not months.

Patching is necessary, but it is not the finish line

As AI accelerates vulnerability discovery and exploitation, keeping Oracle Database on a supported, current Release Update is an essential control. For Oracle Database 19c, TLS 1.3 and PQC capabilities depend on a current release and the next-generation cryptographic provider. Oracle AI Database 26ai supports TLS 1.3 by default.

But patching alone cannot answer the broader exposure question. A resilient database-security program must also address configuration drift, privileged access, credentials, sensitive-data exposure, audit coverage, network paths, certificate trust, and recovery readiness.

The next high-value uplift is to modernize data in transit. That means treating TLS 1.3 and post-quantum key exchange as an operational security program – not as a single database parameter change.

Why conventional TLS planning is no longer sufficient

Modern encryption remains robust against conventional attacks when it is correctly deployed. The issue is the long lifespan of sensitive information and the possibility that traffic collected today could be analyzed later.

Traditional TLS deployments may also leave operational blind spots: an untested client runtime, a connection pool with an outdated driver, a partner integration, or a monitoring agent can prevent a stronger policy from being enforced safely. Moving directly to a PQC (Post Quantum Cryptography) only posture without inventory and testing risks disrupting critical applications.

The objective is therefore twofold: reduce long-term confidentiality exposure and preserve business availability throughout the transition.

Hybrid ML-KEM lets you act now without a big-bang cutover

Oracle Database supports NIST standardized Post Quantum Cryptography (PQC) for TLS 1.3. The practical starting point is hybrid ML-KEM key exchange: it combines a classical ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) secret with an ML-KEM secret to establish the TLS session keys.

How ML‑KEM relates to AES‑256: ML‑KEM is not the algorithm that encrypts database traffic. In a TLS 1.3 session, hybrid ECDHE and ML‑KEM establish shared secret material; TLS derives separate session traffic keys from that material; then an AEAD (Authenticated Encryption with Associated Data) algorithm such as AES-256-GCM, AES-128-GCM, or ChaCha20-Poly1305, specified by the negotiated TLS 1.3 cipher suite, encrypts and authenticates the database traffic. ML-KEM helps protect the confidentiality of TLS sessions against future attacks on classical key-establishment algorithms, while the negotiated AEAD algorithm  encrypts and authenticates the database traffic in the session.

How hybrid ML-KEM protects Oracle TCPS traffic: Hybrid ECDHE and ML‑KEM establish shared secret material; the TLS 1.3 key schedule derives traffic keys; the negotiated TLS 1.3 AEAD algorithm protects database traffic.

  • The Handshake (ML-KEM + ECDHE): The client and Oracle Database talk to each other to establish a session key. By combining ECDHE (classical protection) with ML-KEM (quantum protection), you get a hybrid key exchange. Hybrid key exchange combines classical ECDHE with NIST-standardized ML-KEM, protecting TLS sessions against both conventional attacks and the emerging threat from quantum computers.
  • Key Derivation: The TLS 1.3 key schedule takes that hybrid shared secret and generates session-specific traffic keys.
  • Data Encryption (for example, AES-256-GCM ): ML-KEM doesn’t encrypt the payload itself. Once the keys are derived, the negotiated AEAD algorithm takes over to encrypt and authenticate the actual SQL traffic moving over TCPS.

Hybrid operation gives organizations a controlled migration path. When the client and server negotiate a compatible hybrid group, the connection gains a post-quantum component. When a legacy client cannot yet do so, explicit classical fallback can preserve availability while the owner remediates the dependency.

Keep these two controls distinct

ML-KEM: protect key establishment; ML-KEM (Module-Lattice Key Encapsulation Mechanism) protects the creation of the TLS session secret. It addresses the harvest-now, decrypt-later concern for data in transit.

ML-DSA: protect identity and signatures; ML-DSA (Module-Lattice Digital Signature Algorithm) is for post-quantum digital signatures, including certificate use cases. It addresses authentication and integrity rather than TLS key establishment.

These are complementary, not interchangeable. You can deploy hybrid ML-KEM while retaining existing RSA(Rivest–Shamir–Adleman)  or ECC/ECDSA (Elliptic Curve Cryptography)  server certificates during the first phase. This distinction matters because the public CA and trust-store ecosystem for ML-DSA certificates is still evolving.

Deep dive: A safe Oracle Database implementation path

Act now: Emerging agentic-AI models are drastically accelerating vulnerability discovery and automated exploitation. Keeping database platforms current is no longer just maintenance; it is a vital security defence.

Apply the latest applicable Release Updates (RUs) through your approved change-management process:

  • Oracle Database 19c: RU 19.32 (July 2026) or later
  • Oracle AI Database 26ai: RU 23.26.1 (January 2026) or later

These updates establish an essential security baseline by delivering critical security patches, enabling the transition of database network paths to TLS 1.3, and retiring legacy cryptographic algorithms such as 3DES.

*Note: For Oracle AI Database 26ai: TLS 1.3 is enabled by default when both server and client run 26ai without overriding configurations. While you can skip 19c-specific provider migration steps, still validate the negotiated TLS version, cipher suite, certificate, and client compatibility.

1. Establish the baseline (Oracle Database 19c Only)

(Note: Skip this step entirely if you are running Oracle AI Database 26ai).

For Oracle Database 19c (19.32), confirm that the next-generation cryptographic provider is active before claiming TLS 1.3 or ML-KEM capability. Oracle’s documented provider utility is the supported way to make and verify that change. The script switches the cryptographic-provider libraries associated with the Oracle home. The change can affect multiple database instances or Oracle components using the same Oracle home.

Shut down the database before running the provider-switch script.

Note: The commands below apply to 19.33+. For 19.32, use set_crypto_provider.py instead.

$ python “$ORACLE_HOME/bin/crypto_provider.py” status

Current mode is: Legacy

$ python “$ORACLE_HOME/bin/crypto_provider.py” next-generation

Switched successfully.

$ python “$ORACLE_HOME/bin/crypto_provider.py” status

Current mode is: Next Generation

After the switch, start the database and restart the Oracle Net listener, then revalidate the provider state. Follow Oracle’s documented migration procedure, including compatibility checks, required restarts, and rollback planning. Inventory TLS clients, wallets, certificate algorithms, and application dependencies before implementing the change.

2. Make TLS 1.3 the verified transport baseline

PQC key exchange is available only with TLS 1.3. Review existing TLS_CIPHER_SUITES settings before enabling TLS 1.3. Ensure that the configuration permits compatible TLS 1.3 cipher suites, or use Oracle’s recommended defaults where appropriate.

  • For Oracle AI Database 26ai: Because TLS 1.3 is enabled by default, you do not need to manually configure TLS_VERSION = (1.3). However, verify your cipher suite settings to ensure no legacy configurations are overriding the default.
  • For Oracle Database 19c: Apply policy deliberately across the server, listener, and client paths that need it. Use TCPS for protected connections, validate the server certificate identity, and restrict access to the TCPS listener.

# Migration Phase (Phased Rollout): To maintain client compatibility during the migration period, allow both TLS 1.2 and TLS 1.3:

TLS_VERSION = (1.2 or 1.3)

# Final Hardening Phase: After verifying that all client applications successfully support TLS 1.3, restrict protocol versions exclusively to 1.3:    

TLS_VERSION = (1.3)

Apply policy deliberately across the server, listener, and client paths that need it. Use TCPS for protected connections, validate the server certificate identity, and restrict access to the TCPS listener.

3. Begin with compatible hybrid PQC

During the transition, configure TLS to prefer hybrid ML-KEM while allowing classical ECDHE for clients that do not yet support PQC:

TLS_KEY_EXCHANGE_GROUPS=(hybrid,ec)

The actual negotiated group depends on the capabilities and preferences of both endpoints. This policy preserves compatibility but does not guarantee post-quantum protection for every connection. Verify the negotiated key-exchange group for each client before claiming PQC protection.

Test every client family separately: OCI and SQL*Plus clients, JDBC Thin and Thick, connection pools, ETL tools, monitoring agents, backup and recovery tooling, database links, DR systems, and partner integrations. Record the owner, data classification, driver/runtime version, negotiated outcome, and remediation date for each exception.  Only after all relevant clients have demonstrated compatible PQC behavior should a stricter policy be considered:

TLS_KEY_EXCHANGE_GROUPS=(hybrid,ml-kem)

This is an enforcement milestone, not a routine clean-up. Clients that cannot offer a matching PQC-capable group will fail to connect.

4. Modernize ML-DSA certificates as a separate workstream

Oracle Database supports ML-DSA certificate validation with TLS 1.3. Creating and managing ML-DSA certificates using orapki requires JDK 24 or later. Both communicating endpoints must support the relevant ML-DSA certificate algorithms and validation procedures. Oracle currently recommends self-signed ML-DSA certificates for development, interoperability testing, and controlled internal environments. For production, retain a mature CA-signed trust model until your certificate authority, client trust stores, and application runtimes are proven ready (Runbook for step-by-step implementation ).

If a compliance framework requires FIPS 140-3, assess it independently. FIPS validation and PQC adoption are related security considerations, but one does not automatically prove the other.

Business value: Turn quantum risk into measurable security progress

This program yields outcomes that security and technology leaders can govern:

  • Reduced long-term exposure: high-value traffic gains a post-quantum key-establishment component.
  • Lower outage risk: compatibility is measured before policy is enforced.
  • Audit-ready evidence: provider status, TLS 1.3 validation, certificate identity checks, client test results, and negotiated key-exchange evidence support defensible control claims.
  • Cryptographic agility: the organization builds a repeatable method for adapting to standards and threat changes.

Avoid overclaiming. A successful TCPS login proves secure transport for that session, but not necessarily ML-KEM negotiation. A TLS cipher-suite result does not identify the key-exchange group. Retain supported diagnostic, tracing, or packet-capture evidence when a hybrid ML-KEM claim is required.

Call to action: Choose one high-value path and start now

Do not wait for quantum computing to become an operational emergency. Select one production-like, high-value database connection path. Confirm its TLS 1.3 baseline, verify certificate validation, inventory every client, and test hybrid ML-KEM under controlled change management.

The memorable takeaway is simple: patching protects the database you run today; quantum-safe TLS helps protect the confidential data that adversaries may keep for tomorrow.

References