When Does a Connection to an AWS Endpoint Actually Use ML-KEM? - Client Defaults, Server Policies, Each Hop, and How to Tell

First Published: 2026-11-05
Last Updated: 2026-11-05

From 2025 through 2026, AWS has announced, service by service, that ML-KEM can be used in the TLS key exchange. This applies to endpoints for AWS KMS, AWS Certificate Manager (ACM), AWS Secrets Manager, and Amazon S3, as well as viewer-side connections to Amazon CloudFront. Security policies incorporating ML-KEM have been added to Application Load Balancers, Network Load Balancers, and Amazon API Gateway. Connections to Amazon RDS and Amazon Aurora databases were added between August and November 2026. In August 2026, RFC 10024, defining three key exchanges that combine ML-KEM with elliptic curve Diffie-Hellman, was published as a Standards Track RFC.

However, a service’s support for ML-KEM and the actual use of ML-KEM in a single connection are not the same thing. AWS’s post-quantum cryptography page states that updated endpoints prioritize ML-KEM only when the client supports it. Key exchanges including ML-KEM are negotiated only with TLS 1.3. For load balancers and databases, whether ML-KEM is used depends on whether the policy or parameter that the user chooses includes it, and, depending on how the resource is created and on the service, the default does not include ML-KEM. Furthermore, a single request can traverse multiple hops. While ML-KEM might be used in the connection between a client and CloudFront, the connection between CloudFront and the origin is a separate TLS connection.

This article outlines the conditions that determine whether ML-KEM is used in a single connection, presented in four tables: Client, Server, Hop, and Observation Methods. Each table distinguishes between information explicitly documented, information not listed in the documentation, and information that the documentation states is not logged. The information presented was verified as of November 4, 2026.

This article is not a step-by-step guide for configuring post-quantum TLS. It is also not a comprehensive list of service-specific support. Pricing information is not included.

Related articles on this site:

1. Scope and Assumptions
2. Understanding the Tables
3. Only When All Three Conditions Hold
4. The Client Side — SDKs, the AWS CLI, and the OS
5. The Server Side — Endpoints AWS Accepts, Policies You Choose, and What Is Not Listed
6. Hop by Hop
7. Verifying Which Groups Were Negotiated
8. Where the Sources Disagree and Where No Statement Is Found
9. What a Test with Two Clients Showed
10. Frequently Asked Questions About AWS Connections and ML-KEM
11. Summary
12. References

1. Scope and Assumptions

This chapter defines the intended audience, the scope of this article, the relevant source materials, and any potentially ambiguous terminology.

1.1 Intended Audience

This article is intended for individuals who wish to report on the post-quantum readiness of their communications with AWS APIs, load balancers, CloudFront, and databases, or for those who are being asked to do so during an audit. Specifically, it is written for readers who are considering the following:

Both KMS and CloudFront have been announced as post-quantum ready, so they believe their communications are also post-quantum.
Application Load Balancers have post-quantum policies, and if created using Infrastructure as Code (IaC), the listeners will also be post-quantum.
By using TLS 1.3, they believe the key exchange will be post-quantum.
Because their database engine is post-quantum ready, they believe the connection from the application to the database is also post-quantum.

However, none of these assumptions hold true without further consideration. Chapters 3 through 7 will address the extent to which these claims can be substantiated based on available documentation.

1.2 Scope and Exclusions

This article addresses the use of TLS key exchange, specifically focusing on whether hybrid groups, including ML-KEM, are used. More precisely, it covers the following:

Three conditions required for ML-KEM to be used within a single connection, and the division of responsibilities as defined by AWS.
Client-side requirements, including versions of the AWS SDK and AWS CLI, operating systems, and TLS libraries.
Server-side requirements, including AWS-operated endpoints, the policies and parameters that you choose, items not listed in the documentation, and those explicitly stated as unsupported.
Differences between the hops that a request passes through.
Methods for verifying the negotiated group, and situations where verification is not possible.
Disagreements between sources, and statements that cannot be found in the documentation.

This article does not address the following.

Pricing
A list of support details for each service, along with a timeline of announcements. This is covered in this site's Post-Quantum Cryptography Standardization Timeline and Migration on AWS. Following the "Service Support Status" table in that article, there are two important notes: that even if a server supports ML-KEM, it will not be used unless the client offers it, and that the table covers only selected services, so a service missing from it should be checked on AWS's own page rather than judged by its absence. This article details what is behind the first note, broken down by condition and by hop.
Post-quantum signatures and certificates. Even though the key exchange method changes, the server's certificate does not. This topic is covered in this site's Post-Quantum Certificates for Public TLS Are Three Proposals That Disagree and Enforcing an ML-DSA Policy on AWS.
SSH key exchange. ML-KEM support for AWS Transfer Family's SFTP and Amazon Linux's OpenSSH is separate from TLS and is covered in this site's SSH Algorithms on AWS Endpoints.
ML-KEM keys for AWS KMS. As mentioned in Section 1.4, this is distinct from TLS key exchange.
NIST's migration deadlines and the standardization process. This is covered in the timeline article mentioned earlier.
Choosing a load balancer. This site's AWS Elastic Load Balancing Decision Guide provides guidance. Its Section 7.2 explains in one paragraph that post-quantum policies exist and that the default policy depends on how the listener is created. This article will detail group names, client-side conditions, and verification methods.
Procedures for forcing a connection down to an older key exchange. This article describes only where an older key exchange is used and how to check it.
OAuth for browser-based applications with Amazon Cognito, and the time validation of certificates, which the two other articles in this series cover: Browser-Based Apps and Cross-Device Flows on Amazon Cognito and Trusting the Clock When Certificates Expire Fast.

1.3 Date of Review and Materials Reviewed

This article is based on the following sources, read on November 4, 2026. Abbreviations enclosed in parentheses will be used throughout the text.

IETF's RFC 10024, Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 (RFC 10024).
IETF's Datatracker page for draft-ietf-tls-mlkem (the ML-KEM draft).
IANA's Transport Layer Security (TLS) Parameters, the table for TLS Supported Groups (the IANA table). The table's Last Updated date is October 28, 2026.
AWS's Post-Quantum Cryptography page (the AWS PQC page) and AWS Support for Post-Quantum Confidentiality page (the readiness page). Neither page includes a date.
AWS SDKs and Tools Reference Guide, the page on enabling hybrid post-quantum TLS (the SDK page).
AWS KMS Developer Guide, the pages on Using hybrid post-quantum TLS with AWS KMS and Configure hybrid post-quantum TLS (the KMS pages, the KMS Java pages).
AWS Secrets Manager User Guide, the page on Post-quantum TLS (the Secrets Manager page).
Amazon S3 User Guide, the page on Using hybrid post-quantum TLS with Amazon S3 (the S3 page).
Elastic Load Balancing, the pages for Application Load Balancer and Network Load Balancer Security policies (the ALB policy page, the NLB policy page), the ALB Connection logs page, the NLB Access logs page, and the page on How Elastic Load Balancing works with IAM (the ELB IAM page).
Amazon API Gateway Developer Guide, the page listing REST API security policies (the API Gateway policy page) and the page on security policies for HTTP API and WebSocket API.
Amazon CloudFront Developer Guide, the page on supported protocols and ciphers between viewers and CloudFront (the CloudFront viewer-side page), the page on supported protocols and ciphers between CloudFront and the origin (the CloudFront origin-side page), and the page on Add CloudFront request headers (the CloudFront header page).
Amazon Aurora User Guide, the page on Security with Amazon Aurora PostgreSQL (the Aurora PostgreSQL page) and the page in Amazon RDS User Guide on Using SSL with a PostgreSQL DB instance (the RDS for PostgreSQL page).
Amazon RDS User Guide, the pages on MySQL on Amazon RDS versions and MariaDB on Amazon RDS versions (the RDS for MySQL version page, the RDS for MariaDB version page), and the release notes for Aurora MySQL 3.14.0 (Aurora MySQL 3.14 release notes).
Amazon RDS User Guide, the page on RDS Proxy concepts and terminology (the RDS Proxy page).
Amazon MSK Developer Guide, the page on TLS security policies for Amazon MSK (the MSK policy page).
AWS CloudTrail User Guide, the page on CloudTrail record contents (the CloudTrail record page) and the page on Working with CloudTrail event history.
PostgreSQL 18 documentation, the section on pg_stat_ssl in the chapter on monitoring statistics (PostgreSQL documentation).
AWS What's New announcements and articles on the AWS Security Blog. Dates are the publication dates of the announcements, and the body names the announcement in the same sentence.

1.4 Terms, and Different Things with the Same Name

ML-KEM: A key encapsulation method as defined by NIST's FIPS 203. The introduction of RFC 10024 describes ML-KEM as designed to withstand cryptanalytic attacks from quantum computers.
Hybrid key exchange: RFC 10024 defines a hybrid as a method that combines outputs from multiple key exchange methods, ensuring security as long as at least one of them is secure. When this article says that ML-KEM is used, it means that a hybrid group combining ML-KEM with elliptic curve Diffie-Hellman was negotiated.
Named groups: In TLS 1.3, these are names used to specify the method used for key exchange between the client and server. This article sometimes simply refers to them as "groups." The groups defined in RFC 10024 are X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
Classical groups: Groups that do not include ML-KEM, such as x25519 and secp256r1. This article also calls this a classical key exchange.
Pure ML-KEM groups: These are groups that do not combine with elliptic curves, such as MLKEM768. These are defined in the ML-KEM draft, which is still in progress, and have not yet been formalized in an RFC as of November 4, 2026. The AWS documentation reviewed for this article does not list any names for pure ML-KEM groups.
AWS KMS ML-KEM keys: On October 26, 2026, AWS KMS announced ML-KEM key types and the Encapsulate and Decapsulate APIs in a What's New announcement. This refers to the ability within KMS to create shared secrets, and is distinct from the TLS key exchange used to connect to the KMS endpoint.
SSH ML-KEM: OpenSSH and Transfer Family's mlkem768x25519-sha256 is a key exchange method for SSH, and is distinct from the TLS groups.
CRT and FIPS: CRT is an abbreviation for AWS Common Runtime, a common library used by AWS SDKs. FIPS is an abbreviation for the U.S. Federal Information Processing Standard. FIPS endpoints are endpoints that services specifically provide for FIPS compliance; the KMS page states that these endpoints are validated for FIPS 140-3.
Endpoint: When this article refers to an endpoint, it means the entry point of an AWS service API that AWS operates, such as kms.us-east-1.amazonaws.com. Load balancers, API Gateway APIs, CloudFront distributions, and database instances created by users are called customer resources in this article.

2. Understanding the Tables

This chapter defines the columns of the summary table in Chapter 3 and the terms for the state of the sources used in all tables. The two other articles in this series use the same columns and terms.

2.1 Columns

The summary table in Chapter 3 has seven columns. The detailed tables in Chapters 4 through 7 each have columns tailored to their respective chapters.

Requirement or Guarantee: The conditions that a connection must meet, or what the documentation promises.
Source and Strength: The origin of the information and the strength of the statement.
AWS Setting or Endpoint: The name of the AWS setting, policy, or endpoint relevant to the condition.
Default: The value when no action is taken. When the default depends on how the resource is created, the default is given for each method.
What It Does Not Cover: The ranges or scenarios that this condition does not apply to.
How You Can Tell: Where you can verify whether this condition is met.
Where It Is Written: The page the row comes from.

2.2 Terms for the State of the Sources

The state of the sources is described with the following seven terms. Table cells use the same English terms.

Stated as not supported: The document explicitly states that a feature is not supported, is not yet supported, or that there are no plans to support it.
Documentation does not list: While a list or table exists, the specific item is not included. This does not necessarily indicate that the feature is unsupported or does not exist.
Not recorded (stated): The document states that the information is not included in logs or records.
No statement found: Searching the sources in Section 1.3 with different terms and in different kinds of documents finds no statement. This does not show that the thing does not exist or does not happen.
Sources disagree: Both statements and their sources are given. This article does not definitively identify either source as incorrect.
Inference: This is an inference made within this article, and is not a statement found in any of the documents. The same sentence says so.
Observation: This is based on testing performed in Chapter 9 and is not a statement from the documents. This article does not let an observation override a statement in the documents.

This article does not combine "Stated as not supported" and "Documentation does not list." The former refers to a statement in the documents, while the latter indicates that a specific item is missing from a document's list or table.

2.3 Strength of Sources

This article treats the sources as stronger in the following order:

RFCs and tables from IANA.
Text from each AWS service's User Guide or Developer Guide, and from the SDK page.
Text from the AWS PQC page and the readiness page. These pages do not represent documentation for individual services, but rather outline AWS's overall policies and current status.
What's New announcements and release notes.
Text from AWS blog posts. Within this article, blog posts will be explicitly identified as such in the same sentence.

3. Only When All Three Conditions Hold

This chapter outlines the three conditions under which ML-KEM can be used within a single TLS connection. It then shows, in AWS's own words, how AWS divides the responsibility.

3.1 The Client's Offer, the Server's Acceptance, and TLS 1.3

A hybrid group, including ML-KEM, is used in a single TLS connection only when the following three conditions are met:

The client offers a hybrid group that includes ML-KEM. The SDK and AWS CLI version, the HTTP client, the operating system and its cryptographic policy, and the TLS library decide the client side (see Chapter 4).
The server accepts that group. For AWS-operated endpoints, AWS decides; for customer resources, the policy or parameter that you choose decides (see Chapter 5).
The connection is negotiated using TLS 1.3. The three groups specified in RFC 10024 are intended for TLS 1.3. The CloudFront viewer-side page and the Aurora PostgreSQL page state explicitly that key exchange using a group that includes ML-KEM can only be used with TLS 1.3.

If any one of them is missing, the connection either uses a classical group without ML-KEM or is not established. In most cases, a classical group is used. The ALB policy page states that policies containing "PQ" in their name support both classical and ML-KEM key exchange for compatibility.

When both sides have both ML-KEM groups and classical groups, the server's priority order may determine which group is selected. The Aurora PostgreSQL documentation, regarding the ssl_groups parameter, states that the order in which the groups are listed determines the server's priority, and the first group in the list that the client also supports is used. For AWS-operated endpoints, the AWS PQC page and the readiness page state that if the client supports ML-KEM, the endpoint will use it (see Section 3.2).

Three Conditions for an ML-KEM Key Exchange

3.2 How AWS Divides the Responsibility

The AWS PQC page describes the endpoints for AWS services as follows:

For AWS service endpoints: We have begun deploying ML-KEM for hybrid post-quantum key exchange support to public service endpoints. Updated endpoints will automatically prefer post-quantum key exchange where supported by a client. Your side of the shared responsibility model is to update web browsers and clients that communicate with service endpoints.

The same page describes customer resources such as load balancers as follows:

For customer-owned network resources such as load balancers: Updated TLS policies that support ML-KEM for hybrid post-quantum key exchange are available for customer use. Updating resource configuration to a PQ-enabled TLS policy is on the customers' side of the shared responsibility model.

For AWS-operated endpoints, the readiness page has the following sentence:

The endpoints transparently enforce use of PQ key exchange for any client that advertises support for ML-KEM.

Two points follow from these three statements:

For AWS-operated endpoints, preparing the server side is AWS's job, and updating the client is the customer's job. An updated endpoint uses ML-KEM when the client supports ML-KEM.
For customer resources such as load balancers, choosing a policy that includes ML-KEM is also the customer's job.

The first statement on the AWS PQC page uses the phrase begun deploying, indicating that the deployment has started. It does not state that the deployment is complete across all endpoints. The readiness page provides a table detailing the status for each service. For a service that is not in the table, this article does not conclude that it lacks support (Documentation does not list). As of November 4, 2026, the readiness page's table did not include entries for AWS Lambda and Amazon EC2 APIs.

3.3 Summary Table

The following table lists the three conditions and the hops they do not reach, using the seven columns in Section 2.1.

Requirement or Guarantee	Source and Strength	AWS Setting or Endpoint	Default	What It Does Not Cover	How You Can Tell	Where It Is Written
Client offers an ML-KEM hybrid group	Text on the SDK page. It varies by language: default, opt-in, OS OpenSSL, or no plans.	SDK and AWS CLI versions, HTTP client, OS cryptographic policies	Varies by language and OS (Chapter 4)	AWS SDK for SAP, AWS SDK for Swift, and AWS Tools for Windows PowerShell are stated to have no plans for support (Stated as not supported).	`tlsDetails.keyExchange` in CloudTrail for some services. `openssl s_client` on the client side.	SDK page
AWS-operated endpoint accepts the group	Text on the AWS PQC page, the readiness page, and each service's page.	Endpoints such as `kms.us-east-1.amazonaws.com`	No user configuration	Three exceptions for S3. DynamoDB FIPS endpoints and DynamoDB Accelerator are stated as not yet supported (Stated as not supported).	The readiness page says CloudTrail records the key exchange for only seven services (Section 7.2).	Readiness page, KMS page, S3 page
Customer resource policy includes ML-KEM	Text on the ALB and NLB policy pages, the API Gateway policy page, and the Aurora PostgreSQL page.	ELB PQ policies, API Gateway PQ policies, `ssl_groups`	ELB uses a PQ policy when the listener is created in the console, and `ELBSecurityPolicy-2016-08` with any other method. API Gateway uses `TLS_1_0` or `TLS_1_2`. `ssl_groups` uses `prime256v1:X25519`.	Backend connections for ALB and NLB are determined by the listener policy, and users cannot choose. The HTTP API and WebSocket API pages for API Gateway do not list key exchange groups (Documentation does not list).	ALB connection logs, NLB access logs	Individual service pages
Connections negotiate TLS 1.3	Title of RFC 10024, text on the CloudFront viewer-side page and the Aurora PostgreSQL page.	Policies including TLS 1.3, `ssl_min_protocol_version`	Amazon MSK's default policy only supports TLS 1.2. API Gateway only supports TLS 1.2 for outbound connections.	Using TLS 1.3 alone does not guarantee that ML-KEM will be used.	`tlsVersion` in CloudTrail, TLS version fields in logs	RFC 10024, CloudFront viewer-side page, Aurora PostgreSQL page, MSK policy page, API Gateway policy page
Each hop is a separate connection	Text on the readiness page and the RDS Proxy page.	CloudFront origin, RDS Proxy	—	Connections from CloudFront to the origin are stated as not yet supported, and RDS Proxy is stated as not supported (Stated as not supported).	`CloudFront-Viewer-TLS-Details` only records viewer-side connections.	Readiness page, RDS Proxy page, CloudFront header page

4. The Client Side — SDKs, the AWS CLI, and the OS

This chapter lists, in the words of the SDK page, whether a client offers an ML-KEM group.

4.1 Sections of the SDK Page

The SDK page is written in prose, divided into four sections, rather than presented as a table. The first sentence of the page reads:

There are three ways that an AWS SDK or tool currently provides PQ TLS support:

The headings for the subsequent sections are as follows:

SDKs with PQ TLS enabled by default
Opt-in PQ TLS support
SDKs that rely on System OpenSSL
AWS SDKs and tools not planning to support PQ TLS

The first three are the three ways, and the fourth is the list of SDKs and tools with no plans for support. The first lists SDKs that offer ML-KEM by default, the second lists SDKs that offer ML-KEM if you opt in, and the third lists SDKs and tools that rely on an OS library such as OpenSSL. In the table, this article calls the four sections Default, Opt-in, OS OpenSSL, and No plans.

The conditions for each version are specified on a sentence-by-sentence basis, rather than by section. The following table is this article's arrangement of the SDK page's sentences by language. The page does not include a date.

4.2 The Client Table

Client	SDK Page Section	Version and OS Requirements	TLS Library	Status
AWS SDK for Go	Default	Go 1.24 and later	Go standard library	Supported and preferred
AWS SDK for JavaScript (Browser)	Default	Dependent on browser. Firefox added support in 132.0, Chrome announced support in 131, and Edge supports opt-in PQ TLS in 120 for desktop and 140 for Android.	Browser's TLS	Negotiates when the browser supports and prefers it.
AWS SDK for JavaScript (Node.js)	Default	Node.js v22.20 (LTS) and v24.9.0 and later	Node.js statically includes OpenSSL 3.5	Enabled by default and preferred.
AWS SDK for Kotlin	Default	Linux version 1.5.78 and later. macOS and Windows are dependent on the OS's libraries.	CRT. On macOS and Windows, dependent on the OS's libraries.	Supported and preferred on Linux.
AWS SDK for Rust	Default	Service client versions released after August 29, 2025	—	Supported and preferred by default.
AWS SDK for C++	Opt-in	With the default libcurl, enabled by default only if the OS OpenSSL is 3.5 or later. From 1.11.673, you can opt in to `AwsCrtHttpClient`.	libcurl and OS OpenSSL, or CRT	Enabled by default when `AwsCrtHttpClient` is selected.
AWS SDK for Java 2.x (CRT HTTP client)	Opt-in	Version 2.35.11 and later	CRT	Enabled by default and preferred when using `AwsCrtHttpClient`.
AWS SDK for Java (Default client on JDK 27 and later)	Opt-in	JDK 27 and later	JDK's TLS	Enabled and preferred when using JDK 27 or later.
AWS CLI (Linux)	OS OpenSSL	Version 2.34.54 and later. The Linux installer includes OpenSSL 3.5.6.	Bundled OpenSSL	Enabled by default and preferred on Linux.
AWS CLI (macOS)	OS OpenSSL	Install using Homebrew and ensure Homebrew's OpenSSL is version 3.5 or later.	Homebrew's OpenSSL	The page describes these steps.
AWS SDK for PHP	OS OpenSSL	OS with OpenSSL 3.5 or later	OS's libssl and libcrypto	Dependent on the OS.
AWS SDK for Python (python.org installer, Windows and macOS)	OS OpenSSL	Python 3.14.6 and later. Includes OpenSSL 3.5.7.	Bundled OpenSSL	Enabled by default and preferred.
AWS SDK for Python (macOS with Homebrew)	OS OpenSSL	Homebrew's OpenSSL version 3.5 or later	Homebrew's OpenSSL	Enabled by default and preferred.
AWS SDK for Python (Linux)	OS OpenSSL	OpenSSL 3.5 or later, plus the OS's cryptographic policy requires post-quantum groups.	OS's libssl	OpenSSL 3.5 alone is not sufficient (Section 4.4).
AWS SDK for Ruby	OS OpenSSL	OS with OpenSSL 3.5 or later	OS's libssl and libcrypto	Dependent on the OS.
AWS SDK for .NET (Linux)	OS OpenSSL	OS with OpenSSL 3.5 or later	OS's libssl and libcrypto	Dependent on the OS.
AWS SDK for .NET (Windows and macOS)	OS OpenSSL	From .NET 10 and Windows 11. On macOS, enable TLS 1.3 by opting in to Network.framework.	OS's TLS	Should be enabled with .NET 10 or later, as stated on this page.
AWS SDK for SAP	No plans	—	—	Stated as not supported.
AWS SDK for Swift	No plans	—	—	Stated as not supported.
AWS Tools for Windows PowerShell	No plans	—	—	Stated as not supported.

The Status cell in the .NET (Windows and macOS) row is a translation of the following sentence on the SDK page. The page uses the word should in this instance, rather than making a definitive statement.

Assuming a minimum .NET version of 10, PQ TLS should then be enabled.

Besides the SDK page, the What's New announcement of April 14, 2026 states that post-quantum key exchange is enabled automatically in three clients that retrieve secrets from Secrets Manager: Secrets Manager Agent version 2.0.0 and later, the AWS Lambda extension version 19 and later, and AWS Secrets and Configuration Provider version 2.0.0 and later.

4.3 On macOS and Windows, the OS Decides

At the beginning of the default section on the SDK page, the following note is included:

As of 6-Nov-2025, AWS SDK and its underlying CRT libraries for MacOS and Windows uses system libraries for TLS, so PQ TLS capabilities on those platforms is generally determined by system-level support.

This note applies to the languages in the Default section of the table. For example, the Kotlin SDK supports and prefers PQ TLS on Linux, while on macOS and Windows it depends on the OS libraries. Even with the same SDK version, the results may differ depending on the OS.

The AWS CLI is the same. As shown in the two lines for the AWS CLI in the table, it is enabled by default from v2.34.54 when installed with the Linux installer. For macOS, the page describes the process of installing it using Homebrew and ensuring that Homebrew's OpenSSL version is 3.5 or higher.

4.4 On Linux, OpenSSL 3.5 Alone Is Not Sufficient

The Python section for Linux on the SDK page states:

On Linux, Python dynamically links against the system's shared libssl. Having OpenSSL 3.5+ installed is necessary but not sufficient, as the system's cryptographic policy must also include post-quantum groups in its default TLS configuration.

For Amazon Linux 2023 (AL2023.12 and later), the same section provides the following command:

sudo update-crypto-policies --set DEFAULT:PQ

Regarding other Linux distributions, the page instructs users to consult the distribution's documentation for the default TLS group settings.

This sentence is in the Python section for Linux. The sections for PHP, Ruby, and .NET on Linux simply state that they should be used on operating systems with OpenSSL 3.5 or later, without mentioning the cryptographic policy. As an inference of this article (Inference), these SDKs also use the OS libssl and may therefore be affected by the same cryptographic policy. However, the SDK page does not explicitly state this.

The PQ subpolicy of the AL2023 cryptographic policy also applies to SSH. The aspects related to SSH are covered on this site in the SSH Algorithms on AWS Endpoints article. The timeline for different versions of AL2023 is available on this site in the Amazon Linux History and Timeline article.

4.5 Two Java Versions — the Generation You Opt In and the Generation Where It Is the Default

The KMS Java page states, about the AWS Common Runtime HTTP client:

Use version 2.30.22 or later to enable ML-KEM.

An example on the same page demonstrates creating an HTTP client with postQuantumTlsEnabled(true). The SDK page states that, from v2.35.11, the AwsCrtHttpClient defaults to enabling ML-KEM and prioritizes it. These two pieces of information do not contradict each other. They describe two generations: from 2.30.22, ML-KEM is used if you enable it explicitly, and from 2.35.11, it is enabled by default.

The S3 page also has a Java example of the same form. The 2.30.22 on the S3 page is presented as an example, but it is not explicitly stated as the minimum supported version. This article does not assume the version on the S3 page as a minimum version.

The SDK page states that, on JDK 27 and later, both the V1 and V2 default clients for the AWS SDK for Java support ML-KEM. However, AWS SDK for Java 1.x reached its end-of-support date on December 31, 2025 (as noted in the AWS SDK for Java 1.x Developer Guide). This article will use version 2.x for the Java examples.

According to the SDK page, Go 1.24 is the version that began supporting and prioritizing ML-KEM. The Go release page states that each major release is supported until there are two newer major releases. As of November 4, 2026, the latest versions are 1.27 (August 19, 2026) and 1.26 (February 10, 2026), meaning that 1.24 is no longer supported. The version 1.24 in the table should be interpreted as the lower limit for ML-KEM support. The timeline for Go versions is covered in this site's Go Release and Support Timeline.

4.6 SDKs and Tools with No Plans for Support

The final section of the SDK page states:

There are currently no plans to support the following language SDKs and tools:

Following this line are three items: AWS SDK for SAP, AWS SDK for Swift, and AWS Tools for Windows PowerShell. For requests that these three send to AWS endpoints, the SDK page gives no way to offer ML-KEM as of November 4, 2026.

4.7 Devices Along the Path

Even if a client offers an ML-KEM group, devices along the path may interrupt the connection. The KMS page states:

Depending on the network path your request takes, legacy intermediate hosts, proxies, or firewalls with deep packet inspection (DPI) might block the request.

The KMS page gives the causes as the new key exchange groups in the ClientHello and the larger key exchange messages. Section 4.1 of RFC 10024 specifies the size of the key exchange values sent by the client as follows: X25519MLKEM768 is 1216 bytes, SecP256r1MLKEM768 is 1249 bytes, and SecP384r1MLKEM1024 is 1665 bytes. According to the same section, in the 1216 bytes of X25519MLKEM768, the X25519 portion is 32 bytes.

When passing through a proxy that terminates and inspects TLS traffic, it is the proxy, not the client, that establishes the TLS connection to the AWS endpoint. As an inference of this article (Inference), whether ML-KEM is used in that case depends on the proxy's TLS library and configuration. No AWS statement on this point was found (No statement found).

5. The Server Side — Endpoints AWS Accepts, Policies You Choose, and What Is Not Listed

This chapter lists the server-side conditions in four categories.

5.1 Four Categories

On the server side, the documentation can be divided into four categories based on how the information is presented:

Operated by AWS, with nothing for you to configure: KMS endpoints, viewer-side connections to CloudFront, and so on. The readiness page refers to this category as Transparent.
Chosen by you: This includes listener policies for load balancers, REST API policies for API Gateway, PostgreSQL's ssl_groups, and the database engine version. The readiness page refers to this category as Opt-in.
Not listed in the documentation (Documentation does not list): a list of key exchange groups or curves exists, but ML-KEM is not in it.
Stated as not supported: the documentation states that a feature is not supported, is not yet supported, or has no planned support.

Sections 5.2 through 5.6 provide representative examples. They do not constitute a complete list of all services. The status of each service can be found on the readiness page and in the Post-Quantum Cryptography Standardization Timeline and Migration on AWS article, in its Service Support Status table (as of November 4, 2026).

5.2 Operated by AWS, with Nothing for You to Configure

Server	Scope	Key Points from Documentation	Source
AWS KMS Endpoints	All Regions where KMS is available, on all endpoints, including the FIPS 140-3 validated endpoints.	Nothing to configure on the server side (the readiness page says `Transparent`).	KMS page, readiness page
ACM, IAM, AWS STS, AWS Payment Cryptography Endpoints	Regions for commercial and US GovCloud, including both FIPS and non-FIPS endpoints.	`Transparent`. Customers must update their clients.	Readiness page
Secrets Manager Endpoints	All Regions except the China Regions (Secrets Manager page). The What's New announcement says all Regions where Secrets Manager is supported.	Section 8.2	Secrets Manager page, What's New announcement of April 14, 2026
Amazon S3 Endpoints	All S3 endpoints, except AWS PrivateLink for Amazon S3, Multi-Region Access Points, and S3 Vectors. All Regions.	Used on requests that use TLS 1.3.	S3 page
Amazon DynamoDB Endpoints	Regions for commercial and US GovCloud, specifically non-FIPS endpoints. FIPS endpoints and DynamoDB Accelerator are marked as `coming soon` and not yet supported.	`Transparent`.	Readiness page
CloudFront viewer-side connections	Enabled by default on all existing security policies. Only on TLS 1.3 connections.	Two groups are supported: `X25519MLKEM768` and `SecP256r1MLKEM768`.	CloudFront viewer-side page, readiness page

The readiness page lists many other services' API endpoints as Transparent. Many of these are described as being On the control plane, which refers to the control plane endpoints.

The S3 scope is written differently depending on the source and its date. The What's New announcement of November 19, 2025 listed regional, S3 Tables, and S3 Express One Zone endpoints. The S3 page, as read on November 4, 2026, says all S3 endpoints with three exceptions. The Service Support Status table in this site's timeline article also gives both. The text describing the three exceptions on the S3 page reads as follows:

Hybrid post-quantum TLS is supported for all S3 endpoints except for AWS PrivateLink for Amazon S3, Multi-Region Access Points, and S3 Vectors.

For endpoints in this category, there is nothing you can configure. Your side of the conditions is only the client conditions in Chapter 4 and TLS 1.3.

5.3 Load Balancers — Policy Names, and Defaults That Depend on How You Create the Listener

The ALB policy page and the NLB policy page both contain the same text regarding policies that include "PQ" in their names.

Security policies with PQ in their names offer hybrid post-quantum key exchange. For compatibility, they support both classical and post-quantum ML-KEM key exchange algorithms. Clients must support the ML-KEM key exchange to use hybrid post-quantum TLS for key exchange. The hybrid post-quantum policies support SecP256r1MLKEM768, SecP384r1MLKEM1024 and X25519MLKEM768 algorithms.

The load balancer policies support all three groups that RFC 10024 defines. The CloudFront viewer side and the databases support two, and do not include SecP384r1MLKEM1024 (see Section 5.7).

The default policy varies depending on how the listener is created. The text on the ALB policy page, regarding HTTPS listeners, is as follows. The NLB policy page also lists the same two policy names for TLS listeners.

Console – The default security policy is ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09.

Other methods (for example, the AWS CLI, AWS CloudFormation, and the AWS CDK) – The default security policy is ELBSecurityPolicy-2016-08.

ELBSecurityPolicy-2016-08 does not include "PQ" in its name. A listener created in the console and a listener created from a CloudFormation template get different policies if both are left at the default. When creating listeners using Infrastructure as Code (IaC), unless a policy name is explicitly specified, it will not include ML-KEM.

The ALB policy page recommends ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 or ELBSecurityPolicy-TLS13-1-2-Res-FIPS-PQ-2025-09. It gives the reason that these policies accept clients that support ML-KEM, clients that only support TLS 1.3, and clients that only support TLS 1.2.

There are also ways to restrict the choice of policy across an organization. The ELB IAM page indicates that the elasticloadbalancing:SecurityPolicy condition key can be used with operations such as CreateListener and ModifyListener. The AWS PQC page also states that IAM resource control policies can enforce the TLS policies you want on future resource creation and updates.

5.4 API Gateway — REST API Policies

The API Gateway policy page states the following regarding policies containing "PQ" in their names.

Policies that contain PQ in the title use Post-Quantum Cryptography (PQC) to implement hybrid key exchange algorithms for TLS to ensure traffic confidentiality against future quantum computing threats.

The policies listed on this page are: SecurityPolicy_TLS13_1_2_PQ_2025_09, SecurityPolicy_TLS13_1_2_PFS_PQ_2025_09, and SecurityPolicy_TLS13_1_2_FIPS_PFS_PQ_2025_09. All three are in the table for Regional and private APIs and custom domain names. The page's table for edge-optimized APIs and custom domain names has no policy with PQ in its name (Documentation does not list). The page also does not name the groups these policies use (Documentation does not list).

The default policies for newly created REST APIs and custom domains are as follows, according to the table on the same page.

Resource	Default Policy
Regional API	`TLS_1_0`
Edge-optimized API	`TLS_1_0`
Private API	`TLS_1_2`
Regional, Edge-optimized, Private Custom Domains	`TLS_1_2`

None of the default policies include "PQ" in their names.

For HTTP APIs, the HTTP API security policy page states that API Gateway enforces the TLS_1_2 policy for all HTTP API endpoints. This policy accepts both TLS 1.2 and TLS 1.3. The WebSocket API page also lists only the TLS_1_2 policy. Neither page says anything about key exchange groups (Documentation does not list). The API Gateway row on the readiness page lists only REST API endpoints.

5.5 Databases — PostgreSQL's `ssl_groups` and Engine Versions

In PostgreSQL, users select the value through a parameter. The Aurora PostgreSQL and RDS for PostgreSQL pages state that, with PostgreSQL 18 and later, the ssl_groups value can be changed. The table on the Aurora PostgreSQL page is as follows:

PostgreSQL Engine Version	Default `ssl_groups`	Allowed Values
18	`prime256v1:X25519`	`X25519MLKEM768`, `SecP256r1MLKEM768`, `X25519`, `prime256v1`, `secp384r1`

The default value does not include ML-KEM groups. Of the five allowed values, two are ML-KEM groups. The same page states that the order of the values determines the server's preference, and the first group in the list that the client also supports is used. By that rule, if X25519 is placed before the ML-KEM groups, connections with clients that support X25519 will use X25519. If you want ML-KEM groups to be used, put them first in the list. The page also notes that ssl_groups is a dynamic parameter and does not require a restart.

Regarding TLS 1.3, the same page states:

ML-KEM groups require TLS v1.3. To enforce that they are used, set ssl_min_protocol_version to TLSv1.3.

The page further explains that to enforce the use of specific groups, enable rds.force_ssl and either set ssl_min_protocol_version to TLSv1.3 or restrict TLS 1.2 cipher suites to those using ECDHE. As an inference of this article (Inference), even with ssl_min_protocol_version set to TLSv1.3, ML-KEM is not used if ssl_groups does not include an ML-KEM group or if the client does not offer one. All three conditions outlined in Section 3.1 are required.

In MySQL and MariaDB, the engine version decides.

Engine	Version	Key Highlights	Source
RDS for MySQL	8.4.11 and later	Supports `X25519MLKEM768` and `SecP256r1MLKEM768` for TLS 1.3 connections. Clients that support ML-KEM will automatically negotiate.	RDS for MySQL version page, What's New announcement of August 24, 2026
Aurora MySQL (MySQL 8.4 compatible)	8.4.8	Supports post-quantum key exchange.	What's New announcement of September 3, 2026, readiness page
Aurora MySQL (MySQL 8.0 compatible)	3.14.0	For TLS 1.3 connections, introduces `X25519MLKEM768` and `SecP256r1MLKEM768` alongside the classical groups. Clients that do not support ML-KEM keep using classical groups.	Aurora MySQL 3.14 release notes (October 26, 2026), What's New announcement of November 2, 2026
RDS for MariaDB	11.4.13, 11.8.9, 12.3.3	Supports `X25519MLKEM768` and `SecP256r1MLKEM768` for TLS 1.3 connections.	RDS for MariaDB version page, What's New announcement of September 8, 2026

For MySQL and MariaDB, no statement about a parameter for choosing the groups was found (No statement found). The version pages only state that supported clients will automatically negotiate.

5.6 Items Not Listed in the Documentation

Server	Items Listed in Documentation	ML-KEM Description
Amazon MSK broker	The MSK policy page lists three policies, along with the TLS versions and cipher suites each accepts. The default policy, `MSK-TLS1.2-Default-2026`, only accepts TLS 1.2.	The page body does not contain `ML-KEM`, `MLKEM`, or `quantum`. The readiness page does not list MSK (Documentation does not list).
API Gateway HTTP API and WebSocket API	Lists a `TLS_1_2` policy, along with the TLS versions and cipher suites.	No statement about key exchange groups (Documentation does not list).
API Gateway REST API PQ Policy	Lists the policy names, along with the TLS versions and cipher suites.	The groups used are not named (Documentation does not list).
API Gateway Edge-optimized API and Custom Domains	Lists three policies, along with the TLS versions and cipher suites.	There are no policies that include "PQ" in their names (Documentation does not list).

For MSK, the What's New announcement of October 30, 2026 announced TLS 1.3 support and states:

It is also one of the prerequisites for post-quantum cryptography for protecting data against attacks that collect encrypted traffic now with the intent to decrypt it later.

This statement indicates that TLS 1.3 is one of the prerequisites for post-quantum cryptography. It does not say that MSK brokers accept ML-KEM. This article states neither that MSK supports ML-KEM nor that it does not.

5.7 Stated as Not Supported

Item	Key Points from Documentation	Source
RDS Proxy	Does not support hybrid post-quantum named groups.	RDS Proxy page
Connections from CloudFront to Origin	Support is `coming soon`.	Readiness page
S3: AWS PrivateLink, Multi-Region Access Points, S3 Vectors	Excluded as exceptions.	S3 page
DynamoDB: FIPS endpoints and DynamoDB Accelerator	Support is `coming soon`.	Readiness page
Classic Load Balancer	`No PQC plan`. The page says that customers should migrate to Elastic Load Balancing (ALB or NLB).	Readiness page
AWS SDK for SAP, AWS SDK for Swift, AWS Tools for Windows PowerShell	No plans for support.	SDK page

The text on the RDS Proxy page reads:

RDS Proxy currently does not support hybrid post-quantum named groups. As a result, post-quantum key-exchange negotiation is not available for connections through RDS Proxy. It applies only to direct connections to your database.

The same page states that for connections through RDS Proxy, there are two scenarios. Clients that offer both classical and post-quantum groups negotiate with RDS Proxy using the classical group and establish a connection. However, clients that offer only post-quantum groups without a classical alternative will be unable to connect to RDS Proxy, resulting in a TLS handshake failure.

The number of supported groups varies depending on the server.

Server	ML-KEM Group	Source
ALB and NLB PQ Policies	Three values: `X25519MLKEM768`, `SecP256r1MLKEM768`, and `SecP384r1MLKEM1024`	ALB and NLB policy pages
CloudFront viewer side	Two: `X25519MLKEM768` and `SecP256r1MLKEM768`	CloudFront viewer-side page
Aurora and RDS PostgreSQL 18	Two out of five permitted values: `X25519MLKEM768` and `SecP256r1MLKEM768`	Aurora PostgreSQL page, RDS for PostgreSQL page
RDS for MySQL, Aurora MySQL 3.14.0, RDS for MariaDB	Two values: `X25519MLKEM768` and `SecP256r1MLKEM768`	Version pages, Aurora MySQL 3.14 release notes
AWS-operated endpoints	No per-page list of groups (Documentation does not list). The KMS page and the CloudTrail record page give `X25519MLKEM768` as an example.	KMS page, CloudTrail record page

The IANA table lists X25519MLKEM768 as Recommended (Y), and SecP256r1MLKEM768 and SecP384r1MLKEM1024 as N. The IANA table's note on N reads:

If the "Recommended" column is set to "N", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.

This article does not read N as meaning not recommended. Section 2 of RFC 10024 describes SecP256r1MLKEM768 as suitable for applications requiring FIPS-approved mechanisms for generating both shared secrets, and SecP384r1MLKEM1024 as intended for high-security environments that require FIPS-approved mechanisms with an increased security margin.

6. Hop by Hop

This chapter lists, for each hop that a request passes through, whether ML-KEM can be used. Each hop is a separate TLS connection with its own client and server.

6.1 The Hop Table

Hop	Client on This Hop	Server on This Hop	ML-KEM	Status
Viewer → CloudFront	Browser or application	CloudFront	Can be used if the client offers it and TLS 1.3 is used.	Stated on the CloudFront viewer-side page.
CloudFront → Origin	CloudFront	Origin	Not listed in the CloudFront origin-side page's list of curves. The readiness page says support is `coming soon`.	Documentation does not list. Stated as not supported.
Client → ALB or NLB	Client	Load Balancer Listener	Can be used if the listener policy is a PQ policy.	Stated on the ALB and NLB policy pages.
ALB or NLB → Target	Load Balancer	Target	The backend policy is determined by the listener's policy. No statement on what is actually negotiated with the target.	No statement found.
Client → API Gateway REST API (Regional and Private)	Client	API Gateway	Can be used if a PQ policy is selected.	Stated on the API Gateway policy page.
API Gateway → integration endpoint	API Gateway	Integration endpoint	Not used (Inference): outbound connections are TLS 1.2 only.	Inference.
Application → RDS Proxy	Application	RDS Proxy	Not supported.	Stated as not supported.
RDS Proxy → Database	RDS Proxy	Database	No statement found.	No statement found.
Application → Database (Direct)	Application	Database	Determined by the engine version and, for PostgreSQL, by `ssl_groups`.	Section 5.5.
Client → MSK broker	Kafka client	Broker	No mention of ML-KEM.	Documentation does not list.
Client → S3 (PrivateLink, Multi-Region Access Point, S3 Vectors)	Client	S3	Excluded as an exception.	Stated as not supported.
Client → Proxy (Terminating TLS) → AWS Endpoint	Proxy	AWS Endpoint	Determined by the proxy's TLS configuration.	Inference (Section 4.7).

6.2 CloudFront's Two Hops

The sentences on TLS 1.3 on the CloudFront viewer-side page read:

Quantum-safe key exchanges are only supported with TLS 1.3. TLS 1.2 and earlier versions do not support quantum-safe key exchanges.

The CloudFront entry on the readiness page includes the following note:

Note: For client-to-edge connections, PQC support is available on all existing security policies by default, requiring no re-configuration by customers. For connections to origin servers, support is coming soon.

For ciphers with elliptic curve key exchange, the CloudFront origin-side page lists three curves: prime256v1, secp384r1, and X25519. The term "ML-KEM" does not appear in the main body of this page. Even if ML-KEM is used between the viewer and CloudFront, treating the connection from CloudFront to the origin as a hop that does not use ML-KEM, as of November 4, 2026, is what the documentation supports.

Even if the origin is an Application Load Balancer (ALB) and its listener has a PQ (Post-Quantum) policy applied, the client on this hop is CloudFront. As an inference of this article (Inference), whether CloudFront offers ML-KEM in its connection to the origin decides whether ML-KEM is used on this hop; the origin's policy alone does not. The configuration of CloudFront's origin is covered in this site's Amazon CloudFront Origin Architecture Guide.

6.3 The Two ALB and NLB Hops

The ALB policy page describes backend connections as follows:

You can choose the security policy that is used for front-end connections, but not backend connections. The security policy for backend connections depends on the listener security policy.

According to the list on the same page, when a listener uses a post-quantum TLS policy, the backend connection uses ELBSecurityPolicy-TLS13-1-0-PQ-2025-09, and when a listener uses a FIPS post-quantum TLS policy, it uses ELBSecurityPolicy-TLS13-1-0-FIPS-PQ-2025-09. The NLB policy page gives the same mapping.

This article does not read this as saying that ML-KEM is used on the connection from the load balancer to the target. The server on this hop is the target, and if the target's TLS library and configuration do not accept ML-KEM groups, a classical group is used. This is an inference of this article (Inference), and no statement on which group is actually negotiated with the target was found (No statement found).

6.4 RDS Proxy and Direct Database Connections

As stated in Section 5.7, the RDS Proxy page explicitly notes that RDS Proxy does not support hybrid groups, and that post-quantum negotiation is only applicable to direct connections to the database. Even if you put ML-KEM groups in ssl_groups on RDS for PostgreSQL 18, the connection between the application and RDS Proxy will use classical groups if the application connects through RDS Proxy.

No statement on the group used between RDS Proxy and the database was found (No statement found).

6.5 API Gateway Integration Endpoints

The policy page for the API Gateway contains the following statement:

API Gateway only supports TLS 1.2 on egress.

Key exchange, including ML-KEM, can only be used with TLS 1.3 (see Section 3.1). Taken together, the two statements suggest that ML-KEM is not used on the connection from API Gateway to the integration endpoint. This is an inference of this article (Inference); the API Gateway page does not say so.

6.6 S3 Exceptions and DynamoDB FIPS Endpoints

Of the three exceptions for S3, AWS PrivateLink for Amazon S3 provides a path through VPC interface endpoints. For requests to the same S3 bucket, whether ML-KEM can be used depends on whether the request goes through a regular endpoint or an interface endpoint.

DynamoDB supports its regular endpoints, and its FIPS endpoints are coming soon (readiness page). As an inference of this article (Inference), a client configured to use the FIPS endpoints connects to DynamoDB with a classical group as of November 4, 2026. Regarding KMS, the KMS page states that all endpoints, including the FIPS endpoint, are supported. However, the handling of FIPS endpoints varies depending on the service.

7. Verifying Which Groups Were Negotiated

This chapter lists where you can check which group was negotiated on a connection. Places where you cannot check are in the same table.

7.1 Table of Observation Methods

Method	Hop	What You Can See	When You Cannot See It	Source
CloudTrail's `tlsDetails.keyExchange`	Client → AWS Endpoint	Negotiated key exchange. Examples: `X25519MLKEM768`, `x25519`, `secp256r1`.	Calls an AWS service makes on your behalf; some console calls; services whose readiness row says `Key exchange coming soon`	CloudTrail record page, readiness page
ALB Connection Logs	Client → ALB	The 13th item, `tls_keyexchange`. The 5th item indicates the TLS version.	If connection logging is not enabled.	ALB policy page, ALB Connection logs page.
NLB Access Logs	Client → NLB TLS Listener	The `tls_keyexchange` item.	If access logging is not enabled.	NLB policy page, NLB Access logs page.
`CloudFront-Viewer-TLS-Details` Header	Viewer → CloudFront	JSON containing `keyExchange`.	If forwarding to the origin is not configured; resumed TLS 1.2 sessions	CloudFront header page.
RDS for MySQL and RDS for MariaDB's `Ssl_named_group`	Application → Database	The group negotiated in the current session.	—	RDS for MySQL version page, RDS for MariaDB version page.
Aurora MySQL 3.14.0's `Aurora_ssl_named_group`	Application → Database	The group negotiated in the current session.	—	Aurora MySQL 3.14 release notes.
PostgreSQL's `pg_stat_ssl`	Application → Database	TLS version, cipher, bit count, and client certificate information.	No column for negotiated groups.	PostgreSQL documentation.
S3 CloudTrail and Server Access Logs	Client → S3	No key exchange details.	Always (as of November 4, 2026)	S3 page (Not recorded (stated))
Client-side logs (e.g., `openssl s_client`)	Client → Any Server	Lines such as `Negotiated TLS1.3 group`.	If not recorded on the client side.	Chapter 9 (Observation).

7.2 CloudTrail's `tlsDetails`

The CloudTrail record page describes keyExchange in tlsDetails as follows:

keyExchange - The key exchange method used in the TLS handshake. This field indicates whether the connection used classical cryptography or post-quantum cryptography. Example values include X25519MLKEM768 for post-quantum TLS 1.3, x25519 for classical TLS 1.3, and secp256r1 for TLS 1.2.

The same page also describes two scenarios where tlsDetails is not present in the log.

The tlsDetails field is not present if the API call was made by an AWS service on your behalf.

If sessionCredentialFromConsole is present with a value of true, tlsDetails is present in an event record only if an external client was used to make the API call.

The first scenario occurs when an AWS service makes a call on behalf of a user. In this case, the invokedBy field within userIdentity indicates the service that made the call. The second covers calls made with the credentials of a console session: tlsDetails is present only when an external client made the call.

Whether the keyExchange value is recorded varies depending on the service. The observability column of the readiness page lists seven services – ACM, IAM, IAM Roles Anywhere, KMS, AWS Payment Cryptography, Secrets Manager, and AWS STS – for which CloudTrail records the TLS version, cipher suite, and key exchange. Many other rows on the same page read as follows:

CloudTrail includes TLS version and cipher suite. Key exchange coming soon.

By this article's count, this sentence appears 60 times on the readiness page as of November 4, 2026. For the services in these rows, even a connection that uses an ML-KEM group cannot yet be confirmed from the CloudTrail record.

The KMS page provides an example of a CloudWatch metrics filter used to identify clients that call KMS without using ML-KEM.

{ ($.eventSource = "kms.amazonaws.com") && ($.userIdentity.invokedBy NOT EXISTS) && (($.tlsDetails.keyExchange != "*MLKEM*") || ($.tlsDetails.keyExchange NOT EXISTS)) }

This filter counts calls that either do not have a keyExchange value or do not include MLKEM, excluding calls that an AWS service makes on your behalf. According to the KMS page, using this filter requires sending CloudTrail logs to CloudWatch Logs. CloudTrail event history holds the past 90 days of management events. For services other than S3, no statement on tlsDetails in data events was found (No statement found).

7.3 Load Balancer Logs

The ALB policy page states:

To view the TLS protocol version (log field position 5) and key exchange (log field position 13) for connection requests to your load balancer, enable connection logging and examine the corresponding log entries.

The ALB Connection Logs page lists the 13th item as tls_keyexchange, describing it as the key exchange used during the TLS or PQ-TLS handshake. The NLB policy page states that the NLB access logs include the tls_protocol, tls_cipher, and tls_keyexchange fields, which allow you to see client connections.

Both logs cover the hop from the client to the load balancer. No field that records the group on the hop from the load balancer to the target was found (No statement found).

7.4 CloudFront's `CloudFront-Viewer-TLS-Details`

In the What's New announcement of October 30, 2026, CloudFront introduced the CloudFront-Viewer-TLS-Details header. According to the CloudFront header page, the header's value is a JSON object containing the following fields: tlsVersion, cipherSuite, handshakeType, keyExchange, signatureScheme, and signaturePublicKeyType. Examples of keyExchange values include x25519, secp256r1, and X25519MLKEM768. To receive this header at the origin, you must add the header to the origin request policy.

Regarding session resumption, the same page states the following two points:

For a resumed TLS 1.2 session, keyExchange, signatureScheme, and signaturePublicKeyType are NONE.

For a resumed TLS 1.3 session, keyExchange contains the negotiated key exchange group because TLS 1.3 performs a new key exchange when it resumes a session.

This header describes the connection between the viewer and CloudFront. It does not include the connections between CloudFront and the origin.

7.5 Databases

The RDS for MySQL version page states the following in its 8.4.11 entry. The RDS for MariaDB version page gives the same variable name.

To confirm which group the current session negotiated, query the Ssl_named_group status variable.

The release notes for Aurora MySQL 3.14 list a different variable name.

SHOW STATUS LIKE 'Aurora_ssl_named_group';

For RDS for MySQL and RDS for MariaDB, the variable is Ssl_named_group. For Aurora MySQL 3.14.0, it is Aurora_ssl_named_group. For Aurora MySQL 8.4.8, no statement on which variable to use was found (No statement found). The Aurora MySQL entry on the readiness page states that connection TLS information can be included in the database logs.

The pg_stat_ssl view in the PostgreSQL documentation lists eight columns: pid, ssl, version, cipher, bits, client_dn, client_serial, and issuer_dn. There is no column for negotiated groups. The PostgreSQL entry on the readiness page states the following:

At present, PostgreSQL logs TLS version and ciphersuite.

SHOW ssl_groups returns the server's configuration, not the groups negotiated in a specific connection. For Aurora and RDS PostgreSQL, no statement on a way to check the negotiated group on the server side was found (No statement found).

7.6 S3 Does Not Record It

The S3 page states:

PQ-TLS key exchange details for requests to Amazon S3 are not available in AWS CloudTrail events or S3 server access logs.

The S3 row on the readiness page states that the data plane logs include the TLS version and cipher suite. Regarding key exchange, it states coming soon. As of November 4, 2026, it is not possible to verify whether ML-KEM was used in requests to S3 from S3's own records (Not recorded (stated)). To verify this, records must be kept on the client side.

7.7 Checking on the Client Side

The Python section on the SDK page states that you can verify whether post-quantum TLS is functioning by confirming the X25519MLKEM768 key exchange during the TLS handshake. OpenSSL's s_client displays the negotiated group for a TLS 1.3 connection in the line labeled Negotiated TLS1.3 group. Chapter 9 details the results of testing using this method. Client-side logs reflect only the connection of that specific client and do not represent the connections of other clients.

8. Where the Sources Disagree and Where No Statement Is Found

This chapter gathers in one place the differences in timing, the disagreements between sources, the items not listed, and the statements not found in Chapters 3 through 7.

8.1 Differences in Timing

S3: The What's New announcement on November 19, 2025, listed regional, S3 Tables, and S3 Express One Zone endpoints. The S3 page, as read on November 4, 2026, says all S3 endpoints with three exceptions. This article does not merge the two.
Aurora MySQL's two lines: Version 8.4.8, compatible with MySQL 8.4, was announced in the What's New announcement of September 3, 2026. Version 3.14.0, compatible with MySQL 8.0, has a release notes title dated October 26, 2026, and a What's New announcement dated November 2, 2026. The Aurora MySQL row on the readiness page says to upgrade to MySQL 8.4.8 or later and does not mention 3.14.0.
CloudFront: The CloudFront row on the readiness page indicates that observability is Coming soon. The CloudFront header page details CloudFront-Viewer-TLS-Details, announced on October 30, 2026. Because the readiness page lacks a specific date, this article does not determine which announcement is more recent.
KMS Java Version: Versions 2.30.22 on the KMS Java page and 2.35.11 on the SDK page reflect the generation where you enable it explicitly and the generation where it is the default (Section 4.5).

8.2 Disagreements Between Sources

Secrets Manager Regions: The Secrets Manager page says all Regions except the China Regions. The What's New announcement of April 14, 2026 says all AWS Regions where Secrets Manager is supported (Sources disagree).
Introduction on the Secrets Manager Page: The introduction on the Secrets Manager page says that the feature is offered before post-quantum algorithms are standardized. ML-KEM was standardized under FIPS 203, and RFC 10024 was published in August 2026. This article interprets the introductory sentence as a description of the state of affairs at the time the page was written.
RDS for MariaDB versions: The readiness page says to upgrade to MariaDB 12.3.3 or later. The RDS for MariaDB version page lists three items – 11.4.13, 11.8.9, and 12.3.3 – and indicates support for post-quantum key exchange. The What's New announcement of September 8, 2026, says that all five minor versions it announces, including 10.6.28 and 10.11.19, introduce support for post-quantum TLS key exchange (Sources disagree). The table in Section 5.5 follows the version page.
Strength of Endpoint Statements: The AWS PQC page uses the term prefer, stating that updated endpoints will use post-quantum key exchange if the client supports it. The readiness page uses the term enforce, stating that endpoints will require clients to use post-quantum key exchange when they indicate support for ML-KEM. Both statements are contingent on the client supporting ML-KEM. This article does not interpret differences in the wording to indicate differences in endpoint behavior.

8.3 What the Documentation Does Not List

The list of groups accepted for each endpoint managed by AWS is not included in the documentation. The KMS and CloudTrail pages only provide X25519MLKEM768 as an example.
The names of the groups used by the PQ policies in API Gateway are not listed on the API Gateway policy page.
The tables for Edge-optimized APIs and custom domains in API Gateway do not include any policies with "PQ" in their names.
The pages for HTTP APIs and WebSocket APIs in API Gateway do not describe key exchange groups.
The MSK policy page does not describe key exchange groups. The readiness page also lacks any entries for MSK.
The list of curves on the origin-side pages in CloudFront does not include ML-KEM. However, the readiness page explicitly states that support for connecting to origins is coming soon.
No entries for AWS Lambda and Amazon EC2 APIs were found on the readiness page.

8.4 Statements Not Found

This article searched for the following items using the materials in Section 1.3, as well as searching the AWS documentation and What's New. The search terms used were: post-quantum, ML-KEM, MLKEM, named group, key exchange, ssl_groups, tls_groups, Ssl_named_group, and combinations of service names.

For RDS for MySQL, Aurora MySQL, and RDS for MariaDB, parameters allowing users to select groups: No statement found.
Groups used for connections from RDS Proxy to the database: No statement found.
Groups actually negotiated for connections from the load balancer to the target: No statement found.
tlsDetails in CloudTrail data events for services other than S3: No statement found.
For Aurora and RDS PostgreSQL, methods for verifying the negotiated group on the server side: No statement found.
The status variable for checking the negotiated group in Aurora MySQL 8.4.8: No statement found.
An AWS statement on proxies that terminate and inspect TLS: No statement found.
The update dates of the SDK page, the readiness page, and the AWS PQC page: the pages show no date.

9. What a Test with Two Clients Showed

This chapter describes what was tried on November 4, 2026 (Japan Standard Time) with two OpenSSL builds on hand and three clients of different versions. All of it is observation (Observation), not a promise made by the documentation. This article does not let an observation override a statement in the documentation. No AWS resources were created.

9.1 Tested Configurations

The Region used was us-east-1.
In Step A, s_client from OpenSSL 4.1.0 and from the LibreSSL 3.3.6 that ships with macOS performed TLS handshakes only. No HTTP requests were sent. The targets included endpoints for KMS, Secrets Manager, ACM, AWS STS, S3, DynamoDB (both standard and FIPS), AWS Lambda, and Amazon EC2, as well as this site (the CloudFront viewer side).
In Step B, three clients called the KMS ListKeys API, and the tlsDetails in CloudTrail event history were read. No trail was created.
Client 1 used a local Python 3.14.10 with boto3 1.43.123. The Python OpenSSL version was 4.1.0.
Client 2 was the local AWS CLI 2.39.3 (macOS). The SDK page's instructions for macOS use Homebrew; this test used the CLI already on the machine as it was.
Client 3 used Python 3.12.16 and boto3 1.43.123 within a Docker container using the python:3.12-slim-bookworm image. The OpenSSL version was 3.0.22.
The key list page of the KMS console was also opened in a browser.

9.2 Step A — Groups Negotiated on a Per-Destination Basis

The following table lists the group that the OpenSSL 4.1.0 s_client reported when the client offered different groups.

Destination	No Specification	`X25519MLKEM768` Only	`SecP256r1MLKEM768` Only	`X25519` Only
`kms.us-east-1.amazonaws.com`	`X25519MLKEM768`	`X25519MLKEM768`	`SecP256r1MLKEM768`	`X25519`
`secretsmanager.us-east-1.amazonaws.com`	`X25519MLKEM768`	`X25519MLKEM768`	`SecP256r1MLKEM768`	`X25519`
`acm.us-east-1.amazonaws.com`	`X25519MLKEM768`	`X25519MLKEM768`	`SecP256r1MLKEM768`	`X25519`
`s3.us-east-1.amazonaws.com`	`X25519MLKEM768`	`X25519MLKEM768`	`SecP256r1MLKEM768`	`X25519`
`dynamodb.us-east-1.amazonaws.com`	`X25519MLKEM768`	`X25519MLKEM768`	`SecP256r1MLKEM768`	`X25519`
`dynamodb-fips.us-east-1.amazonaws.com`	`secp384r1`	Handshake failure	Handshake failure	`X25519`
`lambda.us-east-1.amazonaws.com`	`X25519`	TLS 1.2 with RSA key exchange	—	`X25519`
`ec2.us-east-1.amazonaws.com`	`X25519MLKEM768`	`X25519MLKEM768`	`SecP256r1MLKEM768`	TLS 1.2 with RSA key exchange
This site (CloudFront viewer side)	`X25519MLKEM768`	`X25519MLKEM768`	`SecP256r1MLKEM768`	`X25519`

A dash (—) marks a combination whose result could not be determined from the record. The STS row was left out of the table because the attempt with only X25519 ended in TLS 1.2.

The table shows the following:

The regular endpoints of KMS, Secrets Manager, ACM, S3, and DynamoDB, and this site's CloudFront, negotiated X25519MLKEM768 with OpenSSL 4.1.0 and no group specified.
DynamoDB's FIPS endpoint failed to establish a handshake when only offering ML-KEM groups, which is consistent with the readiness page saying coming soon.
With only SecP384r1MLKEM1024 offered, only DynamoDB's regular endpoint negotiated that group. For this site's CloudFront, no negotiated group was recorded, which is consistent with the CloudFront viewer-side page not listing this group. KMS and Secrets Manager fell back to a TLS 1.2 key exchange.
The Lambda API endpoint negotiated the classical X25519 with OpenSSL 4.1.0 and no group specified.
EC2 API endpoints negotiated connections using X25519MLKEM768. There is no entry for EC2 API on the readiness page. This is an example of the line drawn in Section 2.2: not being listed does not show a lack of support. This article does not, however, turn this observation into a statement that the documentation says EC2 supports ML-KEM.
Connections using the default LibreSSL 3.3.6 negotiated a classical group (X25519, P-256, or P-384) with every destination.

In the attempts that offered only an ML-KEM group the server did not accept, the connections to KMS, Secrets Manager, and Lambda did not fail; they were established with TLS 1.2 and an RSA or DHE key exchange. As an inference of this article (Inference), if the client also allows TLS 1.2, limiting the offered groups to ML-KEM groups does not guarantee that the connection uses ML-KEM.

9.3 Step B — CloudTrail `tlsDetails`

Client	OpenSSL	CloudTrail `tlsVersion`	CloudTrail `keyExchange`
Local Python 3.14.10 with boto3 1.43.123	4.1.0	`TLSv1.3`	`X25519MLKEM768`
Local AWS CLI 2.39.3 (macOS)	—	`TLSv1.3`	`X25519MLKEM768`
Docker Python 3.12.16 with boto3 1.43.123	3.0.22	`TLSv1.3`	`x25519`
KMS Console (browser)	—	`TLSv1.3`	`X25519MLKEM768`

Even when using the same boto3 version to call the same KMS API over TLS 1.3, the client with OpenSSL 4.1.0 was recorded with X25519MLKEM768, and the client with OpenSSL 3.0.22 with x25519. The client's offer alone, the first condition in Section 3.1, made the results differ.

The KMS console's key listing page called ListAliases and DescribeKey instead of ListKeys. These records had sessionCredentialFromConsole set to true and included tlsDetails. This article does not judge, from these records, how they relate to the second condition in Section 7.2.

The local AWS CLI, even when installed using a method other than Homebrew, negotiated using X25519MLKEM768. The SDK page's instructions for macOS use Homebrew, and this article does not replace them with this observation.

9.4 What This Observation Does Not Show

This data reflects the results from November 4, 2026, in the us-east-1 Region, for these two OpenSSL builds and three clients. It does not show results for other Regions, other times, or other clients.
It does not show every group that an endpoint accepts. Besides no specification, only four single-group offers were tried.
Load balancers, API Gateway, databases, RDS Proxy, and the hop from CloudFront to the origin were not tested, because no resources were created.
Handshake speed was neither recorded nor compared.

10. Frequently Asked Questions About AWS Connections and ML-KEM

10.1 If KMS supports post-quantum TLS, do your application's KMS calls use ML-KEM?

Not necessarily. The KMS endpoints accept ML-KEM hybrid groups in all Regions, on all endpoints, including the FIPS endpoints. However, ML-KEM is only used when the application's SDK or HTTP client offers those groups. The SDK version, the HTTP client, and the operating system and its cryptographic policy decide this (see Chapter 4). You can verify KMS calls using CloudTrail's tlsDetails.keyExchange. However, records of AWS services calling KMS on behalf of the user will not include tlsDetails (see Section 7.2).

10.2 If you switch to TLS 1.3, does the key exchange use ML-KEM?

Not by itself. TLS 1.3 is one of the conditions; the client must also offer the group, and the server must accept it. In Aurora and RDS PostgreSQL 18, the default ssl_groups is prime256v1:X25519, which does not include an ML-KEM group. Even on a TLS 1.3 connection, a classical group is used with the default. When you add ML-KEM groups to ssl_groups, put them first in the list (Section 5.5).

10.3 Does an ALB listener created with CloudFormation use ML-KEM?

Not if you did not specify a policy. According to the ALB policy page, the default policy for HTTPS listeners created with the AWS CLI, CloudFormation, or AWS CDK is ELBSecurityPolicy-2016-08, which does not include ML-KEM. When created through the console, the default policy is ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09. In IaC, specify the name of a PQ policy explicitly.

10.4 If ML-KEM is used in front of CloudFront, is it used all the way to the origin?

No, as far as the documentation shows on November 4, 2026. ML-KEM is not in the list of curves on the CloudFront origin-side page. The readiness page indicates that support for connecting to the origin is coming soon. Furthermore, the CloudFront-Viewer-TLS-Details header only describes the connection between the viewer and CloudFront.

10.5 Can connections to a database through RDS Proxy use ML-KEM?

No. The RDS Proxy page explicitly states that RDS Proxy does not support hybrid post-quantum named groups. Post-quantum negotiation is only applicable to direct connections to the database. A client that offers only ML-KEM groups, with no classical fallback, cannot connect to RDS Proxy.

10.6 Can you check in CloudTrail whether ML-KEM was used on requests to S3?

No. The S3 page states that details of key exchanges for requests to S3 are not recorded in CloudTrail events or in S3 server access logs. To check, record it on the client side.

10.7 Are AWS KMS ML-KEM keys and ML-KEM in TLS the same thing?

No. The KMS ML-KEM keys announced on October 26, 2026 are a feature that creates a shared secret with a key inside KMS, through the Encapsulate and Decapsulate APIs. TLS's ML-KEM, on the other hand, is used for key exchange when connecting to AWS endpoints, including KMS. The SSH mlkem768x25519-sha256 is also a separate key exchange method.

10.8 Does Amazon MSK lack ML-KEM support?

The documentation does not say either way. The MSK policy page lists the TLS versions and cipher suites, but does not mention key exchange groups. There is no MSK row on the readiness page. The What's New announcement of October 30, 2026 states that TLS 1.3 is one of the prerequisites for post-quantum cryptography. This article states neither that MSK supports ML-KEM nor that it does not.

10.9 If you install OpenSSL 3.5 on Linux, does boto3 use ML-KEM?

That alone is not enough. The SDK page states that, for Python on Linux, OpenSSL 3.5 or later is necessary but not sufficient, and that the OS cryptographic policy must also include post-quantum groups in its default TLS configuration. For AL2023.12 and later, the page shows sudo update-crypto-policies --set DEFAULT:PQ.

11. Summary

ML-KEM is used in a single TLS connection only when the client offers an ML-KEM hybrid group, the server accepts it, and the connection is negotiated with TLS 1.3. For AWS-operated endpoints, AWS prepares the server side, and updating the client is the customer's job. For customer resources such as load balancers, API Gateway, and databases, choosing the policy, parameter, or engine version is also the customer's job, and these defaults often do not include ML-KEM.

A single request passes through several hops. The documentation states that connections from CloudFront to the origin, RDS Proxy connections, S3 PrivateLink, and FIPS endpoints for DynamoDB are not supported or are not yet supported. For Amazon MSK and for API Gateway HTTP APIs and WebSocket APIs, the documentation does not describe the key exchange groups. The ways to check are also incomplete. The readiness page says that CloudTrail records the key exchange for seven services, and the S3 page states that S3 does not record it.

When verifying your own configurations, consider the following for each component:

Client: Verify that the versions of the SDK and AWS CLI, the HTTP client, and the operating system and cryptographic policies meet the conditions outlined in Chapter 4. Are you using AWS SDK for SAP, AWS SDK for Swift, or AWS Tools for Windows PowerShell? Are there any proxies along the path that terminate TLS or any devices that prevent the use of new groups?
Load balancer: Does the listener policy name include PQ? Are listener configurations created using Infrastructure as Code (IaC) still set to ELBSecurityPolicy-2016-08? Have you considered the hop from the load balancer to the target separately?
API Gateway: Do the REST API and custom domain policies include PQ? Do you know that the hop to the integration endpoint is TLS 1.2?
CloudFront: Are you aware that even if ML-KEM is used on the viewer-side connection, it is separate from the connection to the origin?
Database: Is the engine version at or above the supported version? For PostgreSQL, have you placed the ML-KEM group at the beginning of the ssl_groups setting? Are you using RDS Proxy?
Observation: Have you decided which hop to check and how? For hops such as S3 that the records do not cover, will you record it on the client side?

12. References

IETF and IANA

AWS Post-Quantum Cryptography Pages

AWS SDKs and Tools, AWS KMS, AWS Secrets Manager, and Amazon S3

Elastic Load Balancing

Amazon API Gateway

Amazon CloudFront

Amazon Aurora, Amazon RDS, and PostgreSQL

Amazon MSK and AWS CloudTrail

AWS What's New

Related Articles on This Site

References:
Tech Blog with curated related content

Written by Hidekazu Konishi