Login
CrowdStrike Expands Real-Time Cloud Detection and Response to Google Cloud
22 April 2026 at 07:00
As outlined in the AWS post-quantum cryptography (PQC) migration plan, addressing the risk of harvest now, decrypt later (HNDL) attack is an important part of your post-quantum plan. Upgrading the client-side of your workloads to support quantum-resistant confidentiality is an important aspect of your side of the PQC shared responsibility model. Timelines to plan and execute your PQC upgrades vary by region and by industry and will depend on your own business risk profile. To learn more, see the AWS PQC frequently asked questions.
AWS Secrets Manager uses SSL/TLS to communicate with AWS resources, currently supporting TLS 1.2 and 1.3 in all AWS Regions. The service supports using TLS 1.3 with hybrid post-quantum key exchange for clients that support this capability. The hybrid post-quantum approach establishes TLS connections by combining traditional cryptography (such as X25519) with post-quantum algorithms (ML-KEM), and helps to protect your secrets against both current classical attacks and future quantum computer threats. Regardless of how your workload accesses Secrets Manager, this client-side software upgrade is the only action you need to take to address risk to secrets from HNDL. Your secrets at rest are already encrypted using keys managed by AWS Key Management Service (AWS KMS). Properly implemented symmetric encryption is considered quantum-resistant; asymmetric cryptography faces quantum threats. To learn more, watch AWS re:Inforce 2025 – Post-Quantum Cryptography Demystified.
To reduce builder effort for client-side upgrades, we’re pleased to announce the following Secrets Manager clients now enable and prefer post-quantum TLS when initiating connections to Secrets Manager: Secrets Manager Agent (v2.0.0 or later), the AWS Lambda extension (v19 or later) and the Secrets Manager CSI Driver (v2.0.0 or later). For SDK-based clients, hybrid post-quantum key exchange is available in supported AWS SDKs. Enablement requirements vary by language, version, and operating system. See the following table for your SDK client.
This launch is part of the ongoing commitment AWS has made to migrate systems to post-quantum cryptography and making it straightforward for our customers to do the same. See Post-Quantum Cryptography to learn more.
Client hybrid post-quantum key exchange requirements
The following table summarizes the behavior for each client. When the client is upgraded to support hybrid post-quantum key exchange, the Secrets Manager service endpoint automatically selects it during the TLS handshake. Upgrading to the versions listed in the table is the only action you need to take for your workload to begin using hybrid post-quantum key exchange when calling Secrets Manager APIs.
| Client | Requirements |
| Secrets Manager Agent | Hybrid PQ key exchange in TLS preferred by default (v2.0.0 and later) |
| AWS Lambda extension | Hybrid PQ key exchange in TLS preferred by default (Version 19 and later) |
| Secrets Manager CSI Driver | Hybrid PQ key exchange in TLS preferred by default (v2.0.0 and later) |
| AWS SDK for Rust | Hybrid PQ key exchange in TLS preferred by default (releases after August 29, 2025) |
| AWS SDK for Go | Hybrid PQ key exchange in TLS preferred by default (Go v1.24 and later) |
| AWS SDK for Node.js | Hybrid PQ key exchange in TLS preferred by default (Node.js v22.20 and v24.9.0 and later) |
| AWS SDK for Kotlin | Hybrid PQ key exchange in TLS preferred by default on Linux (v1.5.78 and later) |
| AWS SDK for Python | The AWS SDK for Python (boto3) uses the OS-provided OpenSSL for TLS. Hybrid PQ key exchange in TLS requires running on a system with OpenSSL 3.5 or later installed. |
| AWS SDK for Java v2 | AWS SDK for Java v2 requires an AWS CRT HTTP client that supports PQ TLS when configured using postQuantumTlsEnabled. |
| Secrets Manager caching clients | The Secrets Manager caching libraries are built on the AWS SDKs and inherit their TLS behavior. Note for Java: The JDBC driver flag and Java Caching flag must be set to enable Hybrid PQ key exchange in TLS. |
If you’re using the Secrets Manager Agent, the Lambda extension, or the CSI Driver, upgrade to the listed version to use hybrid post-quantum key exchange in TLS as the default. Customers using the AWS SDK for Rust, Go, or Node.js at the versions listed in the table are already upgraded and no additional action is required. The SDK will select the hybrid post-quantum key exchange for API calls. For customers using the AWS SDK for Python, hybrid post-quantum key exchange in TLS requires OpenSSL 3.5 or later to be present on the host system. Guidance on verifying and enabling this is available in the AWS Secrets Manager documentation. For customers using the AWS SDK for Java v2, hybrid post-quantum key exchange in TLS requires using the AWS CRT HTTP client. The postQuantumTlsEnabled(true) must be set on the CRT client to enable hybrid post-quantum key exchange in TLS.
After your client versions meet the requirements listed in the table, you can verify that your connections are actively using hybrid post-quantum key exchange.
How to verify your connection uses hybrid post-quantum key exchange
With hybrid post-quantum key exchange using ML-KEM now enabled by default for Secrets Manager clients (see the preceding table), most customers will not need ongoing monitoring to verify correct behavior or detect regressions. However, security teams and compliance officers might want to confirm that their Secrets Manager API calls are negotiating the hybrid key exchange. On the server side, you can confirm hybrid post-quantum key exchange in TLS by using AWS CloudTrail. On the client side, you can inspect TLS handshake details using a utility like Wireshark or by using developer tools built into major web browsers.
Verification is a two-step process: first, fetch a secret using your Secrets Manager client to generate a GetSecretValue API call, then confirm in AWS CloudTrail that the call negotiated hybrid post-quantum key exchange.
Fetch your secret using your Secrets Manager client
The following examples show how to retrieve your secret using the Secrets Manager Agent, Lambda extension, and CSI Driver—each of which will automatically negotiate hybrid post-quantum key exchange when calling the GetSecretValue API.
To verify hybrid post-quantum TLS with Secrets Manager Agent on EC2 instance:
Install the agent on your Amazon Elastic Compute Cloud (Amazon EC2) instance and use it as a client to fetch your secret.
- Follow the instructions for AWS Secrets Manager Agent.
- Ensure that your EC2 instance profile has the permission for
secretsmanager:GetSecretValueto fetch the secret. - Connect to your private EC2 instance.
- Install the agent on your EC2 instance.
- Use the agent to fetch your secret.
curl -H “X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)” localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN> - Wait for about 5 minutes for CloudTrail to deliver the logs.
- Go to the CloudTrail event history and search for the event
GetSecretValue.
To verify hybrid post-quantum TLS with Lambda extension:
Use the AWS parameters and Secrets Manager Lambda extension to create a Lambda function that will consume your secrets from Secrets Manager using direct API calls.
- Follow Using the AWS parameters and secrets Lambda extension to create the Lambda layer and the Lambda function.
- Select the latest extension version.
- Wait for about 5 minutes for CloudTrail to deliver the logs.
- Go to the CloudTrail event history and search for the event
GetSecretValue.
To verify hybrid post-quantum TLS with CSI driver on Amazon EKS:
On your Amazon Elastic Kubernetes Service (Amazon EKS) cluster, use the AWS Secrets Store CSI Driver provider to fetch secrets from Secrets Manager in Kubernetes pods:
- Confirm the installed add-on version is 2.0.0 or later.
eksctl get addon --cluster <CLUSTER-NAME> --name aws-secrets-store-csi-driver-provider - Trigger a secret retrieval by restarting a pod that mounts a secret, or deploying a new one.
- Wait for about 5 minutes for CloudTrail to deliver the logs.
- Go to the CloudTrail event history and search for the event
GetSecretValue.
Confirm hybrid post-quantum key exchange using CloudTrail
CloudTrail logs include a tlsDetails field for Secrets Manager API calls. When hybrid post-quantum key exchange in TLS is active, the keyExchange field in tlsDetails will show X25519MLKEM768. Each CloudTrail record includes a tlsDetails field that contains the cipher suite and, where available, the key exchange group negotiated during the TLS handshake.
You can work with CloudTrail event history using the AWS Management Console for CloudTrail or the AWS Command Line Interface (AWS CLI).
To look up CloudTrail events using the console:
- Verify you are in the correct AWS Region.
- Open the CloudTrail console and select Event History.
- Under Lookup attributes filter, select Event name and GetSecretValue.
Figure 1: Search CloudTrail event history by event name
- Select your event.
Figure 2: Select the event
- View the output in the Event Record section of the page.
Figure 3: CloudTrail – GetSecretValue event
To look up CloudTrail events using AWS CLI :
Using AWS CLI, select the last events and look at the output.
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
--max-results 5 \
--region <YOUR-REGION> \
--query 'Events[0].CloudTrailEvent' \
--output textExample of CloudTrail Event for GetSecretValue API call:
In the following example, the userAgent field reflects what it used as a client to connect to Secrets Manager.
Note: The
userAgentvalue depends on the client you use.
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89",
"arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89",
"accountId": "111122223333",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE",
"accountId": "111122223333",
"userName": "YOUR-EC2-INSTANCE-PROFILE"
},
"attributes": {
"creationDate": "2026-03-27T17:08:37Z",
"mfaAuthenticated": "false"
},
"ec2RoleDelivery": "2.0"
},
"inScopeOf": {
"issuerType": "AWS::EC2::Instance",
"credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89"
}
},
"eventTime": "2026-03-27T17:12:54Z",
"eventSource": "secretsmanager.amazonaws.com",
"eventName": "GetSecretValue",
"awsRegion": "eu-west-2",
"sourceIPAddress": "1.2.3.4",
"userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0",
"requestParameters": {
"secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
},
"responseElements": null,
"requestID": "027507ea-f377-43d9-bf2f-646d4dc19223",
"eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73",
"readOnly": true,
"resources": [
{
"accountId": "111122223333",
"type": "AWS::SecretsManager::Secret",
"ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com",
"keyExchange": "X25519MLKEM768"
}
}
If the keyExchange field shows X25519MLKEM768, then hybrid post-quantum key exchange in TLS is active. If it shows a traditional algorithm such as X25519, the client is not advertising ML-KEM support, and you should check the client version and configuration.
Troubleshooting
If your Secrets Manager API calls aren’t negotiating X25519MLKEM768 after updating your clients, check your SDK version, OpenSSL version (Python), and firewall or proxy configuration as shown in the Client Hybrid Post-Quantum Key Exchange Requirements section near the beginning of this post.
What’s next
This launch is one step in a broader migration. AWS is continuing to roll out ML-KEM support across AWS service HTTPS endpoints as part of Workstream 2 of the AWS PQC Migration Plan, with a target of full coverage across public AWS endpoints.
Support for CRYSTALS-Kyber, the pre-standardization predecessor to ML-KEM, is phasing out across AWS endpoints in 2026. Customers on older SDK versions that advertise only CRYSTALS-Kyber support will fall back gracefully to traditional TLS rather than negotiate the deprecated algorithm. To avoid this fallback, upgrade to the SDK versions listed in this post.
The journey of PQC migration extends beyond confidentiality of data in transit. To stay informed about the latest developments in the AWS PQC journey and your side of shared responsibility, follow the AWS Post-Quantum Cryptography page.
Conclusion
AWS Secrets Manager now enables hybrid post-quantum key exchange using ML-KEM by default to help protect your secrets and support your compliance efforts. This update requires no code changes or configuration updates for customers using the latest client versions.
This post covered how AWS Secrets Manager uses hybrid post-quantum cryptography to secure TLS connections, which clients support this capability, and how to verify that your connections are protected against harvest now, decrypt later attacks.
To benefit from this announcement today:
- Upgrade your Secrets Manager client (Agent, Lambda extension, or CSI Driver) to the latest available versions to enable hybrid post-quantum key exchange using ML-KEM
- If your workload uses the AWS SDK instead of a caching client, upgrade your AWS SDK and underlying dependencies to the minimum versions listed in this post
- Verify hybrid post-quantum key exchange in TLS is active by checking the
keyExchangefield in CloudTrailtlsDetailsfor your Secrets Manager API calls - Test end-to-end hybrid post-quantum key exchange TLS connectivity in your environment, including network paths that traverse corporate firewalls or proxies
AWS will continue rolling out post-quantum cryptography support. For information about the broader migration effort, see the AWS PQC Migration Plan. Keep an updated cryptographic inventory of your broader environment to identify other uses of traditional public-key cryptography that will require migration. The CISA Quantum-Readiness guidance and the AWS PQC Migration Plan are good starting points.
Additional resources
If you have feedback about this post, submit comments in the Comments section below.
