Prepare cloud workloads for hybrid post-quantum TLS

Find every TLS connection in the application path

A hybrid post-quantum TLS rollout is complete only for the connection boundaries whose negotiated groups have been verified under the intended policy. Library support, an enabled edge feature and a successful HTTPS request are different observations. Map each TLS termination point, identify the implementation on both sides and test what the connection actually negotiates. Keep key agreement separate from the certificate authentication that tells a client which server it reached. ^[1][3][8]

A hypothetical edge-and-origin path makes the distinction concrete. A browser establishes a hybrid connection to an edge service, which terminates TLS and opens another connection to the origin. The origin connection may negotiate a different group. Evidence from the browser-facing hop cannot establish the origin's configuration, even when the application request succeeds. Cloudflare's documentation explicitly distinguishes visitor, internal and origin connections when describing post-quantum cryptography. ^[8]

Inventory the connection path before changing preferences. Include client libraries, public edge services, load balancers, service proxies and origins where they terminate or initiate TLS. Record who controls each endpoint and where its configuration is managed. A transparent network hop and a TLS terminator play different roles; do not add an independent handshake to the diagram merely because traffic passes through another appliance.

For each actual connection, distinguish the groups supported by the implementation, the groups enabled by configuration and the group observed in a test. Support is a capability. Configuration expresses a policy or preference. Negotiation is the result for a particular pair of endpoints and connection conditions. The rollout record needs all three where they differ, rather than one broad field labeled post-quantum enabled.

Define the migration objective at this scope. An organization may initially target the public client-to-edge connection, a set of internal service connections or a complete controlled path. Those are different projects with different compatibility constraints. State the covered hops and the remaining classical or unobserved hops explicitly. The goal is an accurate account of negotiated protection, not a label applied to the entire application because one boundary changed.

What the new hybrid groups actually specify

RFC 10024, published in August 2026, specifies three hybrid key-agreement groups for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. These combine an ephemeral elliptic-curve exchange with ML-KEM under the specified construction. Treat this as a published standards reference, not an unfinished draft. The implementation must still support the relevant group and follow its encoding and validation requirements. ^[1]

ML-KEM is the module-lattice-based key-encapsulation mechanism standardized in NIST FIPS 203 on August 13, 2024. Its role here is key establishment. RFC 9954 provides the hybrid TLS design framework used by RFC 10024, combining traditional and next-generation key-exchange components. The intended security properties depend on the construction and its assumptions; the word hybrid is not permission to concatenate arbitrary cryptographic outputs in application code. ^[2][3]

Use maintained TLS implementations rather than implementing the combiner yourself. RFC 10024 defines the order and encoding of component values, including details that cannot be inferred safely from a group name. It also specifies checks for the encapsulation key, ciphertext length and elliptic-curve component. A home-grown translation from a diagram to cryptographic code risks changing the protocol rather than enabling the standardized group. ^[1]

The traditional component has its own specification. RFC 7748 describes X25519 and its encoding and shared-secret considerations. FIPS 203 defines the ML-KEM parameter sets and sizes. These references explain the ingredients, while RFC 10024 defines how the selected ingredients appear in the TLS groups. Keep those roles distinct when reviewing an implementation claim or interpreting a packet capture. A supported ML-KEM primitive alone does not prove support for a particular TLS group. ^[1][2][4]

Certificate authentication remains a separate workstream. A connection can use a hybrid key-agreement group while its server certificate chain uses a traditional signature algorithm. The negotiated group does not establish that the certificate signature or every related authentication mechanism is post-quantum. Avoid describing the entire handshake as fully migrated when the evidence covers only key agreement. The deployment record should identify which cryptographic function was changed. ^[1][3]

Standards publication also does not prove that every deployed library, provider mode or managed service supports the same behavior. Record the actual build and its configuration constraints, especially where a provider or validated cryptographic module limits available algorithms. The RFC's regulatory discussion concerns how mechanisms may be implemented; it does not certify an organization's deployed endpoint simply because a named algorithm appears in a configuration file. ^[1][5]

Retain exact group identifiers in configuration and evidence. A product's description of hybrid support can refer to a particular group, library release or earlier experimental deployment. Do not normalize all such descriptions into the same completed state without checking the documented wire-format and negotiation support. RFC 10024 includes registered groups and an explicit discussion of obsoleted supported groups, so the current standards name matters when reconciling older runbooks with a new rollout. The implementation record should identify the group actually configured and observed, rather than only the broad label post-quantum. ^[1][5]

Budget the specified key-share bytes without predicting latency

The key-share sizes are useful planning data because they are defined by the protocol, not estimated from a vendor benchmark. RFC 10024 specifies a 1,216-byte client share and a 1,120-byte server share for X25519MLKEM768. SecP256r1MLKEM768 uses 1,249 and 1,153 bytes respectively. SecP384r1MLKEM1024 uses 1,665 bytes on both sides. The chart transcribes those values directly from sections 4.1 and 4.2. ^[1]

These values describe the encoded key-exchange data for the selected group. They do not describe a complete ClientHello, a full handshake, a certificate chain or transport overhead. A client can offer information beyond the selected share, and the complete exchange depends on the actual protocol and implementation behavior. Do not label the bars handshake size or use them as a direct prediction of packets sent. The scope is deliberately narrower. ^[1]

FIPS 203 Table 3 helps verify the component sizes behind the construction. For example, ML-KEM-768 has a 1,184-byte encapsulation key and a 1,088-byte ciphertext; RFC 10024 combines those with the appropriate traditional component. Those component facts explain why client and server shares can differ. The chart uses the RFC's final group values unchanged, rather than deriving an unsupported full-handshake model from the component table. ^[1][2]

Use the size information to choose tests. Larger protocol messages may interact with network paths, intermediary behavior or implementation limits, but the resulting latency and reliability must be observed in the relevant environment. No latency or throughput dataset is presented here. The article does not claim that a particular byte increase causes a fixed percentage slowdown, nor that a successful small laboratory exchange establishes production compatibility.

Measure performance only when the rollout needs that evidence, using a declared setup and comparison. Record client and server builds, negotiated groups, connection reuse behavior, network conditions and the work included in the timing. Reused application connections and fresh TLS handshakes answer different performance questions. A test plan that mixes them can conceal a handshake regression or invent one from unrelated application work.

Preserve the source date and unit with the chart when it is exported or reused. The values come from the August 2026 RFC and are measured in bytes of key-share encoding. They are not cryptographic strength scores, adoption statistics or a ranking of providers. The useful conclusion is that the chosen group has a specific wire-format cost that the rollout should accommodate and test within the actual connection path.

Source. RFC 10024 hybrid key agreement ^[1]. Sources checked August 28, 2026. RFC 10024, published August 2026, specifies these client and server key-share lengths in bytes. The values exclude TLS framing, certificates and transport overhead, and do not predict latency.

Method. Original grouped-bar visualization of sections 4.1 and 4.2, checked August 28, 2026. Values are transcribed without normalization or estimation. A group may be specified but unsupported by a particular client, library, service or provider mode. These values do not show an entire ClientHello or completed handshake. No cryptographic-strength or performance ranking is implied.

Accessible table and figure data

Figure 1 accessible table

Negotiated group	Client key-share bytes	Server key-share bytes
X25519MLKEM768	1216	1120
SecP256r1MLKEM768	1249	1153
SecP384r1MLKEM1024	1665	1665

Figure 1 accessible table

Negotiated group	Client key-share bytes	Server key-share bytes
X25519MLKEM768	1216	1120
SecP256r1MLKEM768	1249	1153
SecP384r1MLKEM1024	1665	1665

Download imageDownload table CSV

Separate supported, configured and negotiated

Begin implementation review with the installed library and build. OpenSSL 3.5 documentation describes supported-group configuration and tools for listing available capabilities. That documentation is relevant only when the endpoint uses the corresponding implementation and supported configuration. An operating system's command named openssl may identify another version or distribution. Record the actual version before interpreting a group-listing result or copying a configuration example. ^[5][6]

A capability listing answers whether the implementation exposes a group under the current build and provider configuration. It does not establish that an application enabled the group, that the peer supports it or that a connection selected it. Keep the listing as one evidence item and inspect the application's effective TLS configuration separately. This distinction is particularly important when a service embeds a TLS library rather than using the system command-line binary.

Use the implementation's supported connection diagnostics for an authorized endpoint. OpenSSL's s_client documentation describes options for examining a TLS connection and controlling relevant negotiation inputs. The concrete command and output fields should be checked against the exact version used for the test. This guide does not claim that a command was executed against the reader's service or that a sample transcript represents an observed production handshake. ^[7]

Record the negotiated group and connection outcome through a supported observation point. Depending on the system, that may be a diagnostic client, endpoint telemetry or another approved handshake inspection method. State which side supplied the observation and what hop it describes. A setting in an edge dashboard is evidence about intended configuration, while a connection result is evidence about the tested exchange. Neither should silently stand in for the other.

Test the expected fallback behavior. A peer that cannot negotiate the intended hybrid group may fail or select another allowed group depending on the configuration. Decide which result is acceptable for the rollout stage and which requires investigation. A successful connection that falls back can preserve availability while leaving the migration objective unmet for that client. Report both availability and negotiated coverage, rather than counting every successful HTTPS request as a hybrid success.

Keep diagnostic collection proportionate. The rollout usually needs protocol and endpoint metadata, not private keys, session secrets or decrypted application traffic. Use the organization's approved tooling and retention rules. A detailed evidence record should explain the negotiation without creating unnecessary access to sensitive traffic. If an observation method cannot distinguish the relevant group, mark that hop unverified and choose another supported method.

Use staged evidence to make fallback decisions

Choose initial cohorts that expose different connection behavior rather than selecting an arbitrary percentage of traffic. A browser, a maintained service client, an older embedded client and a proxy-mediated connection may have different capabilities. These are example categories for planning, not a claim that any particular cohort will fail. The inventory should identify the actual client classes the organization supports and who can validate them.

For each cohort, define the intended group policy, the acceptable fallback and the evidence required before expanding coverage. The acceptance record should distinguish a successful hybrid negotiation, an allowed classical fallback, a failed handshake and an unobserved result. Those categories answer different questions. Keeping them separate prevents a green application-health indicator from masking the fact that the intended cryptographic change was not negotiated.

Test each owned termination boundary in the path. In the hypothetical edge-and-origin deployment, observe client-to-edge and edge-to-origin independently. If a service proxy creates another TLS session, include that session too. Cloudflare's documentation provides a concrete example of why connection scopes must be distinguished, but the same inventory method should follow the actual architecture rather than assuming every application uses that provider. ^[8]

When a failure appears, preserve enough context to classify it. Record the endpoints, implementation versions, intended group policy and observed failure stage before changing configuration. A certificate validation failure, a group negotiation issue and an application error after a successful handshake require different investigations. Do not disable certificate verification or broadly relax unrelated TLS settings simply to make the test return a response.

Plan rollback as a configuration and coverage decision. The organization may temporarily restore a previously supported group policy to recover compatibility, while keeping the affected cohort outside the migration's completed scope. Record what was changed and why. A rollback that restores service does not erase the evidence that the hybrid objective remains unresolved for that connection path.

If latency or resource impact influences expansion, gather it from a declared representative test or an authorized controlled rollout. Compare like-for-like connection behavior and retain the observations. The RFC's key-share sizes can motivate this work, but they cannot supply its result. Avoid presenting an expected improvement or penalty as a benchmark without an original measurement and a method that supports the comparison.

The architecture figure uses evidence boxes for each hop rather than filling them with invented negotiated values. Populate those boxes only from actual observations in the deployment record. That makes the diagram useful during a review: it shows which connection was verified, which is using an accepted fallback and which still lacks evidence, without turning a provider feature announcement into a claim about the reader's environment.

Source. OpenSSL3.5 s_client ^[7]; Cloudflare PQC documentation ^[8]. Sources checked August 28, 2026.

Method. Original conceptual model synthesized from the cited documentation. The relationships and proposed tests explain design choices; they are not measured results or a claim about a deployed environment.

Accessible table and figure data

Figure 2 accessible table

TLS hop	Implementation owner	Evidence to collect	Unresolved scope
Client to edge	Client and edge owners	Actual negotiated group and result	Does not describe origin TLS
Edge to service proxy	Edge and platform owners	Actual negotiated group and fallback	Independent termination boundary
Proxy to origin	Platform and application owners	Actual negotiated group and result	Certificate authentication remains separate

Figure 2 accessible table

TLS hop	Implementation owner	Evidence to collect	Unresolved scope
Client to edge	Client and edge owners	Actual negotiated group and result	Does not describe origin TLS
Edge to service proxy	Edge and platform owners	Actual negotiated group and fallback	Independent termination boundary
Proxy to origin	Platform and application owners	Actual negotiated group and result	Certificate authentication remains separate

Download imageDownload table CSV

Keep the remaining cryptographic work visible

Close the rollout stage with a scope statement. Name the verified connections, accepted client cohorts, configured policy and remaining fallback or unobserved paths. Retain the source and implementation versions used for the decision. Because RFC 10024 is newly published in August 2026, implementation support, documentation and operational guidance deserve a near-term review rather than an assumption that the initial compatibility picture is permanent.

Keep certificate renewal and signature-algorithm migration on their own records. A hybrid key-agreement result does not establish certificate lifecycle health or post-quantum authentication. Those workstreams can share endpoint owners and testing infrastructure, but they have different evidence and failure conditions. Connecting them through explicit ownership is more useful than labeling the entire application post-quantum without describing the functions covered. ^[1][3]

The practical migration question is specific: which group did this connection negotiate under this configuration, and what happens when that negotiation is unavailable? Standards-defined byte counts, implementation capability checks and per-hop observations support that answer. They let the organization expand coverage while keeping compatibility, fallback and the remaining cryptographic boundaries visible.