How Do You Defend Neo4j Against Quantum Computers?

How would you protect a Neo4j deployment against an advanced quantum computer that does not exist yet, but that could one day decrypt encrypted traffic captured today?

That question is no longer theoretical for many security teams. Customers are increasingly asking whether the systems they adopt have a post-quantum cryptography story. Their concern is not only about some future attack after large-scale quantum computers arrive. It is also about what is known as Harvest Now, Decrypt Later, or HNDL. In this attack model, an adversary records encrypted network traffic today, stores it, and waits until a future cryptographically relevant quantum computer can break the public-key cryptography that protected the session key exchange. Google recently set a 2029 timeline for its own post-quantum cryptography migration, specifically noting that the threat to encryption is relevant today because of store-now-decrypt-later attacks.

Well, we are excited to announce that Neo4j now supports post-quantum hybrid key exchange for SSL/TLS encrypted Bolt connections.

This capability is supported from the Neo4j 2025.01 release and later, provided Neo4j is configured to use the OpenSSL provider and OpenSSL 3.5 or later is installed on the machine running Neo4j. With this configuration, Neo4j can negotiate post-quantum hybrid key exchange with clients that support it, while optionally maintaining compatibility with clients that do not.

The Problem: Encrypted Today, Decrypted Tomorrow

Most modern encrypted communications rely on a handshake. During that handshake, the client and server agree on secret material that is then used to protect the actual data flowing over the connection.

For decades, algorithms such as RSA, Diffie-Hellman, and elliptic curve cryptography have been the backbone of that process. They are strong against classical computers when deployed correctly. The problem is that a sufficiently powerful quantum computer running the right algorithms could break the mathematical assumptions behind many of these public-key systems.

For a database platform, this matters because network traffic can include sensitive information: authentication exchanges, queries, application data, metadata, and business-critical graph data moving between clients and servers. Even if the attacker cannot decrypt that traffic today, they may still find value in capturing it now and saving it for later.

That is the key point behind HNDL. The threat begins before the quantum computer exists.

Introducing Post-Quantum Hybrid Key Exchange in Neo4j

When people talk about “post-quantum encryption” in TLS, the most urgent place to start is usually the key exchange. This part of the TLS connection is at most risk to quantum computers as the algorithm uses asymmetric encryption. The shared secret utilized after the key-exchange is using symmetric encryption and not at the same risk.

Neo4j now supports the standard industry approach known as X25519MLKEM768 for SSL/TLS encrypted Bolt connections via the OpenSSL provider. The IETF TLS work defines X25519MLKEM768 as a hybrid key agreement mechanism for TLS 1.3 that combines post-quantum ML-KEM with traditional elliptic curve Diffie-Hellman.

The name looks intimidating, but the idea is straightforward:

X25519MLKEM768 combines two different key exchange mechanisms into one hybrid exchange.

X25519 is the classical part. It is a widely used elliptic curve Diffie-Hellman key exchange mechanism, already trusted and deployed across modern TLS stacks.

ML-KEM-768 is the post-quantum part. ML-KEM stands for Module-Lattice-Based Key-Encapsulation Mechanism. It is standardized by NIST in FIPS 203, and NIST describes ML-KEM as a key-encapsulation mechanism for establishing a shared secret key over a public channel, with ML-KEM-768 as one of the defined parameter sets.

This hybrid design is important. We are not asking customers to throw away today’s cryptography and bet everything on a new algorithm. Instead, the session key material is protected by both the traditional and post-quantum components. The design preserves the security properties we rely on today while adding resilience against future quantum attacks.

In simple terms, the connection remains protected as long as at least one side of the hybrid construction remains secure. That is exactly the kind of cautious transition strategy security teams want when adopting new cryptographic primitives.

Why OpenSSL 3.5+ Is Required

This feature depends on OpenSSL 3.5 or later because that is where the required post-quantum cryptographic support became available in OpenSSL. OpenSSL 3.5 added support for PQC algorithms including ML-KEM, ML-DSA, and SLH-DSA, and changed the default TLS supported groups to include and prefer hybrid PQC KEM groups. It also changed the default TLS key shares to offer X25519MLKEM768 and X25519.

Neo4j runs on the JVM, and the default Java TLS provider has not historically exposed the TLS post-quantum hybrid key exchange support needed for this capability in the Neo4j-supported runtime paths. For that reason, Neo4j currently requires the OpenSSL provider for post-quantum hybrid key exchange. In Neo4j Enterprise Edition, this means configuring Neo4j to use OpenSSL by installing the appropriate netty-tcnative dependency and setting dbms.netty.ssl.provider=OPENSSL.

There is good news on the Java side. OpenJDK JEP 527 adds post-quantum hybrid key exchange for TLS 1.3 in JDK 27, including X25519MLKEM768 as the most preferred default hybrid scheme. Early access builds already include this work. As this becomes available in Java versions supported by Neo4j, we will support post-quantum hybrid key exchange through the Java TLS provider as well.

What Neo4j Supports Today

Starting with Neo4j 2025.01, you can use post-quantum hybrid key exchange for Bolt when:

1. You are running Neo4j 2025.01 or later.
2. OpenSSL 3.5 or later is installed on the machine running Neo4j.
3. You configure Neo4j to use the OpenSSL provider.
4. The client connecting to Neo4j also supports X25519MLKEM768.

When these conditions are met, Neo4j can negotiate the hybrid post-quantum key exchange automatically with capable clients. If the client does not support it, Neo4j can optionally fall back to other key exchange algorithms, which helps preserve compatibility during migration but it does remove the quantum protection.

For teams that want to require post-quantum hybrid key exchange, OpenSSL can be configured so that only X25519MLKEM768 is allowed as the TLS group. For example, the Neo4j documentation shows how this can be set in the OpenSSL configuration file using Groups = X25519MLKEM768.

Here’s how I would deploy a configuration with a container as an example.

First I’d generate TLS certs for bolt in $HOME/neo4j/certificates and create a OpenSSL configuration in a file such as $HOME/neo4j/conf/openssl.cnf to only allow post-quantum hybrid key exchange.

openssl_conf = default_conf 

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Groups = X25519MLKEM768

Containers that use Debian 13 (Trixie) already include the correct version of OpenSSL. I provide the custom OpenSSL configuration as part of the Neo4j container deployment.

docker run \
    --publish=7474:7474 --publish=7687:7687 \
    --publish=7473:7473 \
    --volume=$HOME/neo4j/data:/data \
    --user="$(id -u):$(id -g)" \
    -v $HOME/neo4j/certificates:/var/lib/neo4j/certificates \
    -v $HOME/neo4j/conf/openssl.cnf:/etc/ssl/custom-openssl.cnf \
    -e OPENSSL_CONF=/etc/ssl/custom-openssl.cnf \
    -e NEO4J_server_https_enabled=true \
    -e NEO4J_dbms_ssl_policy_https_enabled=true \
    -e NEO4J_dbms_ssl_policy_bolt_enabled=true \
    -e NEO4J_server_bolt_tls__level=REQUIRED \
    -e NEO4J_dbms_ssl_policy_bolt_tls__versions=TLSv1.3 \
    -e NEO4J_dbms_ssl_policy_bolt_ciphers=TLS_AES_256_GCM_SHA384 \
    -e NEO4J_dbms_netty_ssl_provider=OPENSSL \
    -e NEO4J_ACCEPT_LICENSE_AGREEMENT=yes \
    neo4j:2026.05.0-enterprise

You can verify negotiation with openssl s_client:

openssl s_client -connect localhost:7687 -groups X25519MLKEM768

If you are using self-signed certificates, provide the certificate file as well:

openssl s_client -connect localhost:7687 -groups X25519MLKEM768 \
 -CAfile "path_to_self_signed_cert"

A successful connection should show that the negotiated TLS 1.3 group is X25519MLKEM768.

Current Scope: Bolt First

The initial support is focused where it can be delivered safely and effectively today: Bolt over SSL/TLS using the OpenSSL provider.

That means post-quantum hybrid key exchange is currently supported for Bolt connections. Other Neo4j interfaces that rely on native Java cryptographic libraries, such as the HTTP server, are not currently supported for post-quantum hybrid key exchange pending JVM support being available in the relevant Java runtimes.

This is a pragmatic first step. Bolt is the primary protocol used by Neo4j drivers and applications for database connectivity. Protecting Bolt traffic addresses a high-value path for application-to-database communication while allowing us to keep compatibility and operational risk under control.

Why This Protects Against HNDL

Harvest Now, Decrypt Later is a confidentiality problem.

An attacker records encrypted traffic now because they believe they may be able to derive the session secrets later. The traditional elliptic curve Diffie-Hellman is strong today, but it is not designed to withstand a future large-scale quantum computer. By adding ML-KEM-768 into the key exchange, X25519MLKEM768 gives the TLS session a post-quantum component.

This is why hybrid key exchange is the right first move. It targets the part of TLS that matters most for traffic captured today. If an attacker records a Neo4j Bolt session protected with hybrid post-quantum key exchange, they are no longer looking only at a classical key exchange problem. They must also defeat the post-quantum component.

That is a much better place to be for data that needs to remain confidential for years.

What About Post-Quantum Certificates?

Post-quantum key exchange is not the whole story. TLS also uses digital signatures for authentication. Certificates prove that the server is who it claims to be. Today, those certificates are commonly backed by classical signature algorithms such as RSA or ECDSA.

In a future release, we plan to add support for post-quantum authentication as well, using technologies such as ML-DSA or Merkle Tree Certificates.

ML-DSA is the Module-Lattice-Based Digital Signature Algorithm standardized by NIST in FIPS 204. NIST describes digital signatures as a way to detect unauthorized modification and authenticate the identity of the signatory, and ML-DSA is designed as a post-quantum digital signature scheme.

Merkle Tree Certificates, often abbreviated as MTCs, take a different approach. Instead of attaching large post-quantum signatures to every certificate in the same way as today’s certificate chains, MTCs use Merkle tree inclusion proofs and out-of-band trust information to reduce handshake size. Cloudflare describes MTCs as a next-generation Web PKI proposal where a sufficiently up-to-date client can authenticate with one signature, one public key, and one inclusion proof, even when using post-quantum algorithms.

This is important because post-quantum signatures can be much larger than classical signatures. Let’s Encrypt has described Merkle Tree Certificates as its planned path to a post-quantum-safe Web PKI, specifically because they add post-quantum authentication without sacrificing the speed and reliability that made TLS universal.

Why Certificates Are a Later Step

The reason we are starting with hybrid key exchange is that it addresses the most immediate risk: confidentiality of traffic captured today.

Certificate signatures are different. A quantum computer cannot usually go back in time and use a forged certificate to decrypt traffic it already recorded. To exploit classical certificate signatures, an attacker generally needs to forge authentication at the time of the connection. That is still very serious, but it is not the same urgent HNDL problem as encrypted traffic capture.

This is why the first release focuses on X25519MLKEM768. It gives Neo4j users a practical defense against the most pressing post-quantum TLS threat while the certificate ecosystem continues to mature. Then, as post-quantum signatures and Merkle Tree Certificate standards become more broadly available and operationally practical, we can add those capabilities for a more comprehensive quantum-resistant TLS posture.

Getting Started

To start using post-quantum hybrid key exchange with Neo4j:

• Upgrade to Neo4j 2025.01 or later, preferably with a Linux Operating System.
• Install OpenSSL 3.5 or later on the machine running Neo4j.
• Configure Neo4j to use the OpenSSL provider.
• Ensure Bolt SSL/TLS is configured for your environment.
• Decide whether to allow fallback for compatibility or require only the post-quantum hybrid group.
• Test negotiation with openssl s_client using the X25519MLKEM768 group.

We are really excited to bring this capability to Neo4j. Post-quantum cryptography is not a distant checkbox anymore. It is becoming a practical requirement for enterprises, governments, regulated industries, and any organization that handles data with a long confidentiality lifetime.

With support for X25519MLKEM768, Neo4j gives customers a way to begin that transition now, protecting modern encrypted database connections against the future quantum threat without abandoning the security properties they rely on today.

For detailed configuration steps, examples, verification commands, and current limitations, see the official Neo4j Operations Manual page on configuring SSL for post-quantum hybrid key exchange.

---

How Do You Defend Neo4j Against Quantum Computers? was originally published in Neo4j Developer Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.