DEV Community: Michael Carter

Your Code Is More Cryptographic Than You Think: Designing Applications for Algorithm Agility

Michael Carter — Sun, 23 Aug 2026 14:10:00 +0000

It is usually encountered through a library call, a TLS configuration, an authentication framework, a certificate, or a cloud service. The implementation works, the tests pass, and the application moves toward production.

The problem appears later.

An algorithm needs to be replaced. A certificate hierarchy changes. A cryptographic library reaches end of life. A vulnerability affects a primitive. A vendor introduces a new security requirement. Or the organization begins preparing for post-quantum cryptography.

Suddenly, something that looked like a small security change becomes an application modernization project.

This happens because cryptography is often more deeply coupled to software than developers realize.

The solution is not to predict which algorithm will remain dominant for the next several decades.

It is to design applications so that cryptographic mechanisms can be replaced without rewriting the application around them.

That is the core idea behind cryptographic agility.

Cryptography Doesn't Stay Inside the Crypto Module

A traditional architecture might make cryptography look like a small component:

Application
    |
    v
Crypto Library
    |
    v
Encryption / Signing

Modern applications are rarely that simple.

A cloud-native application could have:

                    Internet
                       |
                       v
                      CDN
                       |
                       v
                 Load Balancer
                       |
                       v
                  API Gateway
                       |
                       v
                  Service Mesh
                       |
            +----------+----------+
            |          |          |
            v          v          v
         Service A  Service B  Service C
            |          |          |
            +----------+----------+
                       |
                       v
                    Database

Cryptography can appear at nearly every layer.

TLS protects network connections.

mTLS authenticates services.

Certificates establish machine identities.

Tokens may be digitally signed.

Databases may encrypt stored information.

KMS platforms manage encryption keys.

HSMs may protect high-value private keys.

CI/CD systems may use signing credentials.

Container registries may depend on cryptographic verification.

The application may therefore depend on dozens of cryptographic mechanisms without having a single component named cryptography.

That is the first problem developers need to understand.

The Hidden Dependency Problem

Consider a simple requirement:

"We need to replace RSA with a different cryptographic mechanism."

At first glance, the task might appear straightforward.

Search the codebase for RSA.

Replace the relevant library calls.

Run the tests.

Deploy.

But what if RSA is also being used by:

A TLS termination layer
An internal certificate authority
A Java dependency
A container image
A signing service
A third-party SDK
A deployment platform
An HSM
An identity provider

The application source code may contain only a small portion of the actual dependency.

This is why a source-code search is not a complete cryptographic inventory.

A useful inventory needs to connect:

Application → Protocol → Certificate → Key → Algorithm → Library → Provider → Infrastructure

Without those relationships, developers may know what cryptography exists but not what depends on it.

Hard-Coded Algorithms Create Long-Term Coupling

Hard-coded algorithms are not necessarily insecure.

The problem is that they create change resistance.

Imagine an application with this architecture:

Application
     |
     v
RSA
     |
     v
Specific Crypto Library
     |
     v
Specific Key Format
     |
     v
Certificate

The application has effectively made several assumptions:

Which algorithm is used
Which library implements it
Which key type is expected
Which certificate format is accepted
Which provider handles cryptographic operations

Changing the algorithm may therefore require changing multiple layers.

A more flexible architecture looks different:

Application
     |
     v
Cryptographic Interface
     |
     v
Policy / Configuration
     |
     +----------+
     |          |
     v          v
Provider A   Provider B
     |          |
     v          v
Algorithm X  Algorithm Y

Now the business logic does not need to understand every cryptographic implementation.

The application asks for an operation.

The cryptographic layer determines how that operation should be performed.

This separation is one of the foundations of cryptographic agility.

Don't Build an "Algorithm Abstraction" That Isn't Actually Agile

Developers sometimes create an abstraction that simply wraps one algorithm.

For example:

encrypt(data)

may internally always call:

AES-256-GCM

That is an API abstraction, but it does not necessarily provide cryptographic agility.

A genuinely adaptable design needs to separate the operation from the cryptographic policy.

For example:

encrypt(data, policy)

where the policy determines:

Algorithm
Key Type
Key Source
Provider
Parameters
Rotation Policy

The exact implementation depends on the language and framework, but the architectural principle remains the same.

The application should not have to know why a particular cryptographic implementation was selected.

Post-Quantum Cryptography Makes This More Important

Post-quantum cryptography provides a practical example of why cryptographic agility matters.

NIST has standardized ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. These algorithms are designed to address cryptographic threats posed by sufficiently capable quantum computers.

But migrating an application is not equivalent to replacing a class name in a dependency file.

A developer needs to know what the cryptographic operation actually does.

For example:

Key establishment and digital signatures are different problems.

ML-KEM is designed for key establishment.

ML-DSA and SLH-DSA are designed for digital signatures.

An application that currently uses RSA may use it for signatures, key transport, or other operations. An application using elliptic curve cryptography may use different mechanisms for signatures and key agreement.

The migration path therefore depends on how the existing cryptography is being used, not simply which algorithm name appears in the code.

Certificates Add Another Layer

Application developers often treat certificates as infrastructure.

From an application architecture perspective, however, certificates can be hard dependencies.

Consider:

Application
    |
    v
TLS Library
    |
    v
Leaf Certificate
    |
    v
Intermediate CA
    |
    v
Root CA
    |
    v
Trust Store

Changing the certificate can affect every layer below it.

A new certificate may require a new key type.

A new certificate chain may require updated trust.

A new signature algorithm may require newer TLS or X.509 implementations.

A legacy client may not understand the new chain.

This is why certificate management and application architecture cannot be completely separated during a large cryptographic migration.

The modern web already depends heavily on certificate-based encrypted communication. Recent HTTPS adoption statistics show how deeply TLS has become embedded into Internet infrastructure.

For developers, the takeaway is simple:

Certificates are dependencies, not just deployment artifacts.

Libraries Are Part of Your Cryptographic Supply Chain

A developer may never directly implement RSA, ECDSA or AES.

Instead, the application might depend on:

Application
   ↓
Framework
   ↓
HTTP Client
   ↓
TLS Library
   ↓
Operating System
   ↓
Cryptographic Provider

The cryptographic implementation is several abstraction layers away.

This is why dependency management becomes particularly important during cryptographic migration.

An application may need to evaluate:

Which crypto library is being used?
Which version?
Which algorithms does it support?
Which providers does it rely on?
Is the implementation maintained?
Does the platform support newer cryptography?
Can the library support multiple algorithms simultaneously?
What happens when the dependency is upgraded?

A software bill of materials can help identify software dependencies.

A Cryptography Bill of Materials (CBOM) extends that thinking toward cryptographic components and relationships. IBM Research has discussed CBOM as a way to identify and manage cryptographic assets as organizations prepare for quantum-safe migration.

For large applications, that additional visibility can become extremely valuable.

Crypto Agility Should Be a Developer Requirement

Cryptographic agility should not live exclusively inside the security team's documentation.

It should influence application design.

Developers can ask several questions during architecture reviews:

Can the algorithm be changed without changing business logic?

If changing the cryptographic primitive requires rewriting application workflows, the abstraction boundary may be too low.

Can keys be replaced without redeploying the entire application?

Key lifecycle should ideally be separated from application lifecycle where practical.

Can the cryptographic provider change?

Applications tightly coupled to one provider can become difficult to migrate.

Can certificates be rotated automatically?

Manual certificate replacement becomes increasingly difficult as environments scale.

Can cryptographic policy be changed centrally?

Centralized policy can reduce inconsistent configurations across services.

These questions are more valuable than simply asking whether an application "uses strong encryption."

Avoid Cryptographic Configuration Scattered Across the Codebase

One of the easiest ways to accumulate cryptographic debt is to distribute cryptographic configuration throughout the application.

For example:

Service A → RSA
Service B → ECDSA
Service C → RSA
Service D → hard-coded AES configuration
Service E → library default

Now imagine introducing a new organization-wide cryptographic policy.

Every service becomes a separate migration project.

A better architecture centralizes policy where appropriate:

                    CRYPTO POLICY
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
       Service A      Service B      Service C
          |              |              |
          +--------------+--------------+
                         |
                         v
                CRYPTO PROVIDER

This doesn't mean every cryptographic operation should be centrally controlled.

Some applications require specialized behavior.

The important principle is to avoid unnecessary duplication of cryptographic decisions.

Key Management Should Be Separated From Application Logic

Another common architectural mistake is allowing applications to manage sensitive keys directly.

Instead of:

Application
    |
    v
Private Key
    |
    v
Cryptographic Operation

a stronger architecture often looks like:

Application
    |
    v
KMS / HSM Interface
    |
    v
Protected Key

The application requests a cryptographic operation without necessarily handling the underlying private key.

This architecture can make key rotation, access control, auditing and future migration easier.

It also reduces the number of systems that directly handle sensitive key material.

What Developers Should Inventory

A practical developer-focused cryptographic inventory can start with seven categories:

Category	Examples
Algorithms	RSA, ECDSA, AES, SHA-2
Protocols	TLS, mTLS, SSH, IPsec
Keys	Private keys, symmetric keys, signing keys
Certificates	TLS, client authentication, code signing
Libraries	OpenSSL, BoringSSL, language crypto APIs
Providers	KMS, HSM, cloud cryptographic services
Applications	APIs, services, workloads, devices

The goal is not to create documentation that nobody maintains.

The goal is to make cryptographic dependencies discoverable and actionable.

Automation should eventually feed this inventory.

Build for Replacement, Not Prediction

One mistake organizations can make is trying to predict exactly which cryptographic algorithm they will use decades from now.

That is difficult.

Cryptography changes.

Standards evolve.

Implementation vulnerabilities appear.

Hardware capabilities change.

New algorithms emerge.

Instead of trying to predict the final destination, application architecture should make the journey easier.

That means designing systems around replaceable cryptographic components.

Think:

Crypto Interface

rather than:

RSA Interface

Think:

Key Management Service

rather than:

Private Key File

Think:

Certificate Policy

rather than:

Certificate Embedded in Configuration

Think:

Algorithm Configuration

rather than:

Algorithm Hard-Coded in Business Logic

These small architectural decisions can have a significant impact years later.

A Practical Crypto-Agility Checklist

Before introducing a new cryptographic dependency, developers should consider:

Is the algorithm configurable?
Is the implementation isolated behind an interface?
Can keys be rotated independently?
Can certificates be replaced without application changes?
Can the cryptographic provider be changed?
Is the dependency actively maintained?
Can the application support multiple cryptographic configurations?
Is the cryptographic configuration observable?
Can the dependency be discovered automatically?
Is there a migration path if the algorithm becomes deprecated?

These questions turn cryptographic agility from a theoretical concept into an engineering practice.

The Biggest Mistake Is Waiting for the Migration

Cryptographic agility is easiest to introduce before it is urgently required.

Trying to redesign cryptographic dependencies during a security incident or mandatory migration is much more expensive.

The organization then has to discover dependencies, design an abstraction, test new implementations, replace certificates, coordinate infrastructure and maintain production availability at the same time.

Doing the architectural work earlier changes the problem.

Instead of:

"How do we replace everything?"

the question becomes:

"Which cryptographic provider and policy should we deploy next?"

That is a much more manageable engineering problem.

Cryptographic Agility Is Part of Modern Software Architecture

The next generation of applications will not be defined only by how strong their encryption is.

They will also be defined by how adaptable their cryptographic architecture is.

Post-quantum migration is making this increasingly obvious.

RSA and ECC will not simply disappear overnight. Applications will operate through a period where classical and post-quantum mechanisms coexist, infrastructure will evolve at different speeds, and compatibility will remain an important engineering constraint.

The applications that handle this transition most effectively will be the ones that have already separated business logic from cryptographic implementation.

Cryptography should therefore be treated like any other infrastructure dependency that can evolve.

Make it observable.

Make it configurable.

Make it replaceable.

Automate its lifecycle.

And most importantly, don't assume today's cryptographic implementation will still be the right implementation tomorrow.

The best time to design for cryptographic agility is before the next cryptographic migration becomes mandatory.

Post Quantum TLS: What Hybrid Key Exchange Actually Changes

Michael Carter — Sun, 16 Aug 2026 11:17:21 +0000

Post quantum cryptography is no longer something security teams can leave entirely to research departments. NIST finalized ML-KEM as a post quantum key encapsulation mechanism in 2024, and the IETF is actively standardizing hybrid key agreement for TLS 1.3. The practical transition is already visible in modern TLS implementations and large internet infrastructure.

For engineering teams, however, the important question is not simply what ML-KEM does. The bigger question is what actually changes when a TLS connection moves from a traditional exchange such as X25519 to a hybrid mechanism such as X25519MLKEM768.

The answer is more specific than "TLS becomes quantum safe." Hybrid key exchange changes how the session secret is established while leaving most of the application-facing TLS architecture intact. It also introduces larger handshake messages, new compatibility considerations, different implementation dependencies, and a much greater need to understand which cryptographic mechanism is actually being negotiated.

Why TLS Needs Hybrid Key Exchange

TLS 1.3 commonly uses ephemeral elliptic-curve key exchange such as X25519. This provides strong protection against currently practical classical attacks, but a sufficiently capable quantum computer could threaten the mathematical assumptions behind elliptic-curve cryptography.

That creates a long-term confidentiality problem. An attacker can potentially capture encrypted traffic today and retain it for future decryption if quantum computing eventually makes the underlying key exchange vulnerable. This is commonly described as a harvest-now, decrypt-later risk.

Hybrid key exchange addresses that problem without requiring the internet to abandon established cryptography overnight. Instead of replacing X25519 immediately, the TLS handshake combines a classical exchange with a post quantum mechanism.

The current IETF draft defines hybrid TLS 1.3 mechanisms including X25519MLKEM768, which combines X25519 with ML-KEM-768. (IETF Datatracker)

This approach gives organizations a practical transition path because the classical and post quantum components both contribute to establishing the session secret.

What Changes Inside a TLS 1.3 Handshake?

The overall TLS 1.3 handshake remains recognizable. Clients still send a ClientHello, servers respond with a ServerHello, certificates are used for authentication, and the connection eventually transitions to encrypted application traffic.

The major change occurs in the key exchange information.

A traditional connection might negotiate X25519, while a hybrid connection can negotiate X25519MLKEM768. The latter combines the X25519 ECDH exchange with ML-KEM-768. The current IETF specification defines the resulting shared secret for X25519MLKEM768 as the combination of the ML-KEM and X25519 shared secrets. (IETF Datatracker)

Area	Traditional TLS 1.3	Hybrid TLS 1.3
Key exchange	X25519 or another classical group	X25519 + ML-KEM-768
TLS version	TLS 1.3	TLS 1.3
Authentication	RSA, ECDSA, etc.	Can initially remain classical
Application protocol	HTTP, HTTP/2, HTTP/3, APIs	No fundamental change
Session encryption	Symmetric encryption	Symmetric encryption
Key exchange size	Relatively small	Significantly larger
Quantum protection	Classical security assumptions	Adds post quantum key establishment

This distinction matters because hybrid TLS is not a new application protocol. It is a change to the cryptographic machinery underneath the connection.

If you want to understand where this key exchange occurs in the broader TLS flow, this TLS handshake packet-level breakdown provides useful context on ClientHello, key shares, certificates, and TLS 1.3 message flow.

What ML-KEM Adds to X25519

ML-KEM is a key encapsulation mechanism standardized by NIST under FIPS 203. NIST defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 parameter sets, with ML-KEM-768 being the post quantum component used in X25519MLKEM768. (NIST Computer Security Resource Center)

The fundamental difference is the mathematical assumption behind each mechanism.

X25519 relies on elliptic-curve Diffie-Hellman. ML-KEM is based on lattice cryptography and the Module Learning with Errors problem.

A hybrid handshake uses both rather than betting the future of the connection on one algorithm.

This is why Cloudflare describes X25519MLKEM768 as a hybrid key agreement that maintains the security provided by X25519 while adding the post quantum component. Cloudflare currently recommends this hybrid mechanism in its deployed PQC support. (Cloudflare Docs)

The design is therefore less about replacing something that already works and more about reducing dependence on a single cryptographic assumption during the transition to post quantum cryptography.

The Handshake Gets Much Larger

One of the most visible practical changes is the size of the key exchange.

The current IETF draft specifies a 1,216-byte client key exchange value for X25519MLKEM768. That consists of 1,184 bytes for the ML-KEM-768 portion and 32 bytes for X25519. (IETF Datatracker)

That is considerably larger than the compact key exchange material engineers are accustomed to seeing with X25519 alone.

The larger handshake can affect infrastructure in ways that are easy to overlook, particularly when TLS traffic passes through multiple network components.

Engineering teams should test:

ClientHello and ServerHello sizes
Packet fragmentation and MTU behavior
TLS termination performance
Reverse proxies and load balancers
Firewalls and TLS inspection appliances
Mobile and high-latency networks
Connection establishment latency
CPU and memory consumption
Failure and fallback behavior

The impact depends heavily on the workload. A service using long-lived HTTP/2 connections may barely notice the additional handshake overhead, while an API creating huge numbers of short-lived connections can be much more sensitive to it.

Hybrid TLS Does Not Automatically Replace Your Certificate

This is one of the most important distinctions in post quantum migration.

Key exchange and authentication are different cryptographic functions.

A TLS certificate authenticates the server. The ephemeral key exchange establishes the shared secret from which the session's symmetric encryption keys are derived.

Therefore, enabling X25519MLKEM768 does not automatically mean an organization must replace every RSA or ECDSA certificate.

That does not make certificates irrelevant to post quantum migration. Digital signatures are themselves an important part of the longer-term transition. NIST has separately standardized post quantum signature algorithms including ML-DSA and SLH-DSA. (NIST Computer Security Resource Center)

A sensible migration strategy should therefore treat these as related but separate workstreams:

Migration area	Main concern
Hybrid key exchange	Protecting session establishment against future quantum attacks
Digital signatures	Maintaining quantum-resistant authentication
Certificates	Delivering and validating public-key authentication
Software signing	Protecting code and update integrity
VPNs	Protecting long-lived private communications
Stored encryption	Protecting information whose confidentiality must survive for years

Hybrid TLS is an important first step, but it is not the entire post quantum migration.

Supporting PQC Is Not the Same as Negotiating PQC

A common deployment mistake is to check whether a TLS library supports ML-KEM and assume that every connection is therefore protected by hybrid key exchange.

That assumption is wrong.

A client may support X25519MLKEM768 while a particular server only supports X25519. In that situation, the connection can continue using a classical key exchange.

The important question is therefore not:

Does my system support PQC?

The more useful question is:

What key exchange group did this connection actually negotiate?

Recent DEV Community testing demonstrates this distinction clearly. A .NET application can report ML-KEM support while the negotiated connection still needs to be checked separately for a group such as X25519MLKEM768. (DEV Community)

For infrastructure teams, the validation process should include:

Confirming TLS library capability
Confirming client supported groups
Confirming server supported groups
Inspecting the negotiated group
Testing classical fallback
Monitoring third-party connections
Recording results across environments

This turns PQC readiness from a configuration claim into something measurable.

TLS Libraries Become a Critical Migration Dependency

Application teams may not need to change application code, but they may need to change the cryptographic stack underneath that code.

This is particularly important for runtimes that bundle their own TLS libraries.

For example, recent DEV Community testing of Node.js demonstrated how the bundled OpenSSL version can determine whether a connection negotiates X25519 or X25519MLKEM768. The same application code can therefore produce different TLS behavior depending on the runtime and cryptographic library underneath it. (DEV Community)

That means teams should inventory:

Operating system TLS libraries
Language runtimes
OpenSSL versions
Reverse proxies
Load balancers
Service meshes
API gateways
Container base images
Cloud-managed TLS services

The application source code may be unchanged while its cryptographic behavior changes significantly because one underlying dependency has been upgraded.

What Hybrid TLS Changes for Developers

For most developers, hybrid TLS should remain below the application layer.

There is no need to redesign a REST API simply because the underlying TLS connection uses ML-KEM. HTTP requests, JSON payloads, authentication logic, database queries, and application business logic do not fundamentally change.

The relevant dependency chain looks more like:

Application → Runtime → TLS Library → Operating System → TLS Endpoint

That makes crypto-library and runtime visibility more important than application-level rewrites.

Developers working with Python, Node.js, .NET, Rust, or other ecosystems should therefore verify which TLS implementation their runtime actually uses and whether that implementation supports the required hybrid groups.

For example, checking the negotiated post quantum TLS group from Python illustrates the difference between assuming PQC is enabled and inspecting what was actually negotiated on the connection. (DEV Community)

Crypto Agility Becomes the Bigger Goal

Hybrid TLS highlights a broader problem: many organizations do not have a complete inventory of where cryptography is being used.

That makes future algorithm changes difficult.

A company should be able to identify:

Which systems terminate TLS
Which algorithms they negotiate
Which certificates they use
Which cryptographic libraries they depend on
Which vendors control those libraries
Which third-party services still use classical-only key exchange
Which data requires long-term confidentiality
Which systems cannot be upgraded easily

This is the foundation of crypto agility, the ability to change cryptographic mechanisms without rebuilding an organization's entire technology estate.

The post quantum transition will reward organizations that already have this visibility.

A Practical Hybrid TLS Migration Strategy

Organizations do not need to migrate every endpoint simultaneously. A controlled rollout makes it easier to identify compatibility and performance problems.

Start with cryptographic inventory. Identify TLS termination points, libraries, runtimes, certificates, network appliances, APIs, and third-party services.

Prioritize long-lived sensitive data. Systems protecting intellectual property, financial information, confidential communications, and other information with long confidentiality requirements deserve earlier attention.

Upgrade the TLS foundation. Move toward standardized ML-KEM implementations rather than relying indefinitely on experimental pre-standard Kyber variants. The current IETF draft specifically references the finalized NIST ML-KEM standard. (IETF Datatracker)

Test actual negotiation. Confirm that connections really negotiate X25519MLKEM768 instead of merely confirming that the software claims to support ML-KEM.

Test the complete network path. Include proxies, firewalls, load balancers, CDNs, TLS inspection systems, and other intermediaries.

Measure production-like performance. Compare handshake latency, CPU consumption, connection rates, memory use, and failure rates.

Monitor fallback. Identify clients and services that continue using classical key exchange and determine why.

Expand gradually. Once compatibility is established, increase hybrid coverage across internet-facing and internal TLS connections.

What Hybrid TLS Does Not Solve

Hybrid key exchange is an important security improvement, but it should not be confused with complete post quantum readiness.

A company could have X25519MLKEM768 enabled for browser traffic while still using classical cryptography for its origin connections, VPNs, software signing, certificates, internal APIs, or stored encryption.

Cloudflare's current documentation makes this distinction clear by separating hybrid key agreement from post quantum signatures and other aspects of its broader PQC deployment. (Cloudflare Docs)

A useful way to think about the migration is therefore:

Hybrid TLS protects one important part of the cryptographic lifecycle. Crypto agility prepares the organization to change everything else when required.

Why Organizations Should Start Before Quantum Computers Arrive

The case for migration does not depend on quantum computers being capable of breaking TLS today.

The challenge is the combination of long migration timelines and long-lived confidential information.

A large enterprise may have thousands of applications, APIs, devices, network appliances, certificates, vendors, and cryptographic dependencies. Discovering those dependencies and replacing incompatible components can take years.

At the same time, encrypted traffic can potentially be collected today and retained for future analysis.

Organizations should therefore begin by answering three practical questions:

Question	Why it matters
Where is classical public-key cryptography still used?	Establishes the migration scope
Which endpoints can negotiate hybrid TLS today?	Identifies immediate opportunities
How quickly can cryptographic algorithms be changed?	Measures crypto agility

The goal is not to predict exactly when a cryptographically relevant quantum computer will arrive. The goal is to ensure that the infrastructure can adapt before that arrival becomes an operational emergency.

The Real Change Is Bigger Than ML-KEM

Hybrid TLS is often presented as an algorithm upgrade, but the more significant change is operational.

TLS key establishment is evolving from a classical-only model toward a hybrid model that combines X25519 with ML-KEM. The handshake becomes larger, TLS libraries become a more important dependency, compatibility testing becomes essential, and security teams need visibility into actual negotiated groups.

At the same time, certificates and digital signatures remain separate migration concerns.

The current IETF work gives this transition a concrete shape through mechanisms such as X25519MLKEM768, while NIST's FIPS 203 provides the standardized ML-KEM foundation. (NIST Computer Security Resource Center)

For developers, the transition should mostly remain invisible at the application layer. For infrastructure and security teams, however, it represents a significant shift in how TLS deployments need to be measured and managed.

The organizations that begin building cryptographic inventory, testing hybrid negotiation, upgrading TLS dependencies, and monitoring fallback now will have a much easier path when post quantum cryptography becomes a standard infrastructure requirement.

Hybrid TLS is therefore not the final destination.

It is the mechanism that helps the internet move from today's cryptographic assumptions toward a more crypto-agile future.

Frequently Asked Questions

What is hybrid key exchange in TLS?

Hybrid key exchange combines a traditional key exchange mechanism with a post quantum mechanism during TLS session establishment. In the current IETF design, X25519MLKEM768 combines X25519 ECDH with ML-KEM-768. (IETF Datatracker)

What does X25519MLKEM768 actually combine?

It combines X25519, a classical elliptic-curve Diffie-Hellman mechanism, with ML-KEM-768, a post quantum key encapsulation mechanism. Both contribute to the resulting TLS shared secret. (IETF Datatracker)

Does hybrid TLS require a new SSL certificate?

Not necessarily. Key exchange and certificate-based authentication are separate functions. Existing RSA or ECDSA certificates can continue to be used while an organization introduces hybrid key exchange.

Is ML-KEM the same as Kyber?

ML-KEM is the NIST-standardized mechanism derived from the CRYSTALS-Kyber submission. Current standards use the name ML-KEM, and NIST standardized it in FIPS 203. (NIST Computer Security Resource Center)

Does TLS 1.3 automatically provide post quantum protection?

No. TLS 1.3 provides the protocol framework, but both endpoints and their TLS implementations need to support and negotiate a compatible hybrid key exchange group.

How can I verify that a TLS connection actually uses PQC?

Inspect the negotiated TLS supported group. A value such as X25519MLKEM768 indicates that the connection negotiated the hybrid mechanism. Checking whether a library merely supports ML-KEM is not enough. (DEV Community)

Will hybrid TLS make HTTPS slower?

It can increase handshake size and may affect CPU, latency, bandwidth, and connection establishment performance. The practical effect depends on the implementation, network path, and workload, so production-like benchmarking is important.

Does hybrid TLS make an entire application post quantum secure?

No. It protects the key establishment of the relevant TLS connection. Certificates, digital signatures, VPNs, software signing, stored encryption, and other cryptographic systems may require separate post quantum migration.

Should companies wait until quantum computers become practical?

Organizations handling information that must remain confidential for many years should begin preparing now. Cryptographic inventory, dependency upgrades, vendor migration, and interoperability testing can take years, making preparation more practical than waiting for a future quantum event.