# Using hybrid post-quantum TLS
AWS Payment Cryptography and many other services supports a hybrid post-quantum key exchange option for the Transport Layer Security (TLS) network encryption protocol. You can use this TLS option when you connect to API endpoints or when using the AWS SDKs. These optional hybrid post-quantum key exchange features are at least as secure as the TLS encryption we use today and are likely to provide additional long-term security benefits.
The data that you send to enabled services is protected in transit by the encryption provided by a Transport Layer Security (TLS) connection. The classic cipher suites based on RSA and ECC that AWS Payment Cryptography supports for TLS sessions make brute force attacks on the key exchange mechanisms infeasible with current technology. However, if large scale or cryptographically relevant quantum computers (CRQC) becomes practical in the future, the existing TLS key exchange mechanisms will be susceptible to these attacks. It is possible that adversaries may begin harvesting encrypted data now with the hope that they can decrypt it in the future (harvest now, decrypt later). If you’re developing applications that rely on the long-term confidentiality of the data passed over a TLS connection, you should consider a plan to migrate to post-quantum cryptography before large-scale quantum computers become available for use. AWS is working to prepare for this future, and we want you to be well-prepared, too.
![\[An adversary who has previously recorded a TLS session. Years later, when the adversary has a CRQC, the adversary can first recover the session key by breaking the classical key exchange using the CRQC. The adversary can then decrypt the data using the discovered session key. The previously transmitted data, if still valuable, is now compromised.\]](http://docs.aws.amazon.com/payment-cryptography/latest/userguide/images/pqtls-risk2.png)
To protect data encrypted today against potential future attacks, AWS is participating with the cryptographic community in the development of quantum-resistant or *post-quantum* algorithms. AWS has implemented *hybrid* post-quantum key exchange cipher suites that combine classic and post-quantum elements to ensure that your TLS connection is at least as strong as it would be with classic cipher suites.
These hybrid cipher suites are available for use on your production workloads when using recent versions of the AWS SDKs. For more information about how to enable/disable this behavior, please see [Enabling hybrid post-quantum TLS](pqtls-details.md)
![\[A TLS session that is secured both using classical key agreement and post-quantum key agreement. An adversary today cannot break the classical part of the key agreement. If the adversary records the data and tries to decrypt it in the future with a CRQC, the post-quantum key agreement keeps the session key safe. Thus, today’s transmitted data remains safe against discovery even in the future. This is why hybrid post-quantum TLS is important today.\]](http://docs.aws.amazon.com/payment-cryptography/latest/userguide/images/pqtls-mitigation.png)
## About hybrid post-quantum key exchange in TLS
The algorithms that AWS uses are a *hybrid* that combines [Elliptic Curve Diffie-Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) (ECDH), a classic key exchange algorithm used today in TLS, with [Module-Lattice-Based Key-Encapsulation Mechanism](https://csrc.nist.gov/pubs/fips/203/final) (ML-KEM), a public-key encryption and key-establishment algorithm that the National Institute for Standards and Technology (NIST) [ has designated as its first standard](https://csrc.nist.gov/pubs/fips/203/final) post-quantum key-agreement algorithm. This hybrid uses each of the algorithms independently to generate a key. Then it combines the two keys cryptographically.
## Learn more about PQC
For information about the post-quantum cryptography project at the National Institute for Standards and Technology (NIST), see [Post-Quantum Cryptography](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography).
For information about NIST post-quantum cryptography standardization, see [Post-Quantum Cryptography Standardization](https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization).
# Enabling hybrid post-quantum TLS
AWS SDKs and tools have cryptographic capabilities and configuration that differ across language and runtime. There are three ways that an AWS SDK or tool currently provides PQ TLS support:
**Topics**
+ [SDKs with PQ TLS enabled by default](#pq-tls-default)
+ [Opt-in PQ TLS support](#pq-tls-opt-in)
+ [SDKs that rely on System OpenSSL](#pq-tls-open-ssl)
+ [AWS SDKs and tools not planning to support PQ TLS](#pq-tls-nosupport)
## SDKs with PQ TLS enabled by default
**Note**
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.
### AWS SDK for Go
The AWS SDK for Go uses Golang’s own TLS implementation provided by its standard library. Golang supports and prefers PQ TLS as of v1.24, so AWS SDK for Go users can enable PQ TLS by simply upgrading Golang to v1.24
### AWS SDK for JavaScript (browser)
The AWS SDK for JavaScript (browser) uses the browser’s TLS stack, so the SDK will negotiate PQ TLS if the browser runtime supports and prefers it. Firefox launched support for PQ TLS in v132.0. Chrome announced support for PQ TLS in v131. Edge supports opt-in PQ TLS in v120 for desktop and 140 for Android.
### AWS SDK for Node.js
As of Node.js v22.20 (LTS) and v24.9.0, Node.js statically links and bundles OpenSSL 3.5. This means that PQ TLS is enabled and preferred by default for those and subsequent versions.
### AWS SDK for Kotlin
The Kotlin SDK supports and prefers PQ TLS on Linux as of v1.5.78. Because AWS SDK for Kotlin’s CRT-based client relies on system libraries for TLS on MacOS and Windows, support for PQ TLS will depend on those underlying system libraries.
### AWS SDK for Rust
The AWS SDK for Rust distributes distinct packages (known as “crates” in the Rust ecosystem) for each service client. These are all managed in a consolidated GitHub repository, but each service client follows its own version and release cadence. The consolidated SDK released PQ TLS preference on 8/29/25, so any individual service client version released after that date will support and prefer PQ TLS by default.
You can determine the minimum version supporting PQ TLS for a particular service client by navigating to the relevant crates.io version URL (for example, AWS Payment Cryptography's is [here](https://crates.io/crates/aws-sdk-paymentcryptography/versions)) and finding the first version published after 29-Aug-25. Any service client version published after 29-Aug-25 will have PQ TLS enabled and preferred by default.
## Opt-in PQ TLS support
### AWS SDK for C\$1\$1
By default, the C\$1\$1 SDK uses platform-native clients like libcurl and WinHttp. Libcurl generally relies on system OpenSSL for TLS, so PQ TLS is only enabled by default if system OpenSSL is ≥ v3.5. You can override this default in C\$1\$1 SDK v1.11.673 or later, and opt-in to the AwsCrtHttpClient which supports and enables PQ TLS by default.
Notes on Building for Opt-In PQ TLS You can fetch the SDK’s CRT dependencies with [this script](https://github.com/aws/aws-sdk-cpp/blob/main/prefetch_crt_dependency.sh). Building the SDK from source is described [here](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/sdk-from-source.html) and [here](https://github.com/aws/aws-sdk-cpp/tree/main?tab=readme-ov-file#building-from-source), but note that you may need a few additional CMake flags:
```
-DUSE_CRT_HTTP_CLIENT=ON \
-DUSE_TLS_V1_2=OFF \
-DUSE_TLS_V1_3=ON \
-DUSE_OPENSSL=OFF \
```
### AWS SDK for Java
As of v2, AWS SDK for Java provides an AWS Common Runtime (AWS CRT) HTTP Client that can be configured to perform PQ TLS. As of v2.35.11, the AwsCrtHttpClient enables and prefers PQ TLS by default wherever it’s used.
## SDKs that rely on System OpenSSL
Several AWS SDKs and tools depend on the system's libcrypto/libssl library for TLS. The system library most often used is OpenSSL. OpenSSL enabled PQ TLS support in version 3.5, so the easiest way to configure these SDKs and tools for PQ TLS is to use it on an operating system distribution that has at least OpenSSL 3.5 installed.
You can also configure a Docker container to use OpenSSL 3.5 to enable PQ TLS on any system that supports Docker. See Post-quantum TLS in Python for an example of setting this up for Python.
### AWS CLI
PQ TLS support with the [AWS CLI installer](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) is coming soon. To enable immediately, you can use alternative installers for the AWS CLI, which varies by operating system, and can enable PQ TLS.
For MacOS, install the AWS CLI via [Homebrew](https://brew.sh/) and ensure that your Homebrew-vended OpenSSL is upgraded to version 3.5\$1. You can do this with “brew install openssl@3.6” and validate with “brew list \$1 grep openssl”.
For Ubuntu or Debian Linux: ensure the Linux distribution you are using has OpenSSL 3.5\$1 installed as system OpenSSL. Then, install the AWS CLI using apt or [PyPI](https://pypi.org/project/awscliv2/). With these prerequisites, the AWS CLI vended by apt or PyPI will be configured to negotiate PQ-TLS. For step-by-step instructions to validate the installation, see [github repository](https://github.com/aws-samples/sample-post-quantum-tls-python/) and accompanying [blog post](https://aws.amazon.com/blogs/security/post-quantum-tls-in-python/).
### AWS SDK for PHP
The AWS SDK for PHP relies on system libssl/libcrypto. To use PQ TLS, use this SDK on an operating system distribution that has at least OpenSSL 3.5 installed.
### AWS SDK for Python (Boto3)
The AWS SDK for Python (Boto3) relies on system libssl/libcrypto. To use PQ TLS, use this SDK on an operating system distribution that has at least OpenSSL 3.5 installed.
### AWS SDK for Ruby
The AWS SDK for Ruby relies on system libssl/libcrypto. To use PQ TLS, use this SDK on an operating system distribution that has at least OpenSSL 3.5 installed.
### AWS SDK for .NET
On Linux, AWS SDK for .NET relies on system libssl/libcrypto. To use PQ TLS, use this SDK on an operating system distribution that has at least OpenSSL 3.5 installed. On Windows and MacOS, PQ TLS is available starting in [.NET 10](https://devblogs.microsoft.com/dotnet/post-quantum-cryptography-in-dotnet/) and [Windows 11](https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-apis-now-generally-available-on-microsoft-platforms/4469093). On MacOS, TLS 1.3 support (a prerequisite for PQ TLS) can be enabled by opting-in to Apple's Network.framework as described [here](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/libraries#tls-13-for-macos-client). Assuming a minimum .NET version of 10, PQ TLS should then be enabled.
## AWS SDKs and tools not planning to support PQ TLS
There are currently no plans to support the following language SDKs and tools:
+ AWS SDK for SAP
+ AWS SDK for Swift
+ AWS Tools for Windows PowerShell