Normal view

Protecting your secrets from tomorrow’s quantum risks

24 April 2026 at 20:53

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.

  1. Follow the instructions for AWS Secrets Manager Agent.
  2. Ensure that your EC2 instance profile has the permission for secretsmanager:GetSecretValue to fetch the secret.
  3. Connect to your private EC2 instance.
  4. Install the agent on your EC2 instance.
  5. Use the agent to fetch your secret.
    curl -H “X-Aws-Parameters-Secrets-Token: $(</tmp/awssmatoken)” localhost:2773/secretsmanager/get?secretId=<YOUR-SECRET-ARN>
  6. Wait for about 5 minutes for CloudTrail to deliver the logs.
  7. 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.

  1. Follow Using the AWS parameters and secrets Lambda extension to create the Lambda layer and the Lambda function.
  2. Select the latest extension version.
  3. Wait for about 5 minutes for CloudTrail to deliver the logs.
  4. 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:

  1. 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
  2. Trigger a secret retrieval by restarting a pod that mounts a secret, or deploying a new one.
  3. Wait for about 5 minutes for CloudTrail to deliver the logs.
  4. 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:

  1. Verify you are in the correct AWS Region.
  2. Open the CloudTrail console and select Event History.
  3. Under Lookup attributes filter, select Event name and GetSecretValue.
    Figure 1: Search CloudTrail event history by event name

    Figure 1: Search CloudTrail event history by event name

  4. Select your event.
    Figure 2: Select the event

    Figure 2: Select the event

  5. View the output in the Event Record section of the page.
    Figure 3: CloudTrail - GetSecretValue event

    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 text

Example 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 userAgent value 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 keyExchange field in CloudTrail tlsDetails for 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.

P. Stéphanie Mbappe

P. Stéphanie Mbappe

Stéphanie is a Security Consultant with Amazon Web Services. She delights in assisting her customers at any step of their security journey. Stéphanie enjoys learning, designing new solutions, and sharing her knowledge with others.

Tobias Nickl

Tobias Nickl

Tobias is a Security Consultant at Amazon Web Services, specializing in security architecture and cloud transformation. He partners with AWS customers to design and implement security architectures that address both current and emerging threats. Through his work, he helps organizations build security strategies that evolve with their cloud maturity.

From Overwhelmed to Autonomous: Rethinking Threat Intelligence in 2026

24 April 2026 at 02:00

Key Takeaways

  • The real challenge in cybersecurity isn’t intelligence or visibility, it’s speed. Attackers operate at machine speed, while most organizations are still constrained by manual, human-driven workflows.
  • Traditional threat intelligence falls short because it stops at insight. To reduce risk effectively, intelligence must not only inform decisions but also actively drive response.
  • Fragmentation across cyber, fraud, and third-party risk creates exploitable gaps. A unified, intelligence-driven approach is essential to understanding and addressing modern threats holistically.
  • Autonomous defense is the path forward. By enabling continuous, real-time action across the attack surface, organizations can close the speed gap and move from reactive security to proactive risk reduction.

For most security teams today, volume and access to intelligence isn’t the problem. It’s the speed at which they can turn that intelligence into action.

Over the last decade, organizations have invested heavily in threat intelligence and cybersecurity. Global security spending has surged past $200 billion annually, growing double digits year over year, while security’s share of IT budgets has climbed from under 9% to more than 13%. Most CISOs report continued budget increases, and enterprises are making billion-dollar investments in intelligence capabilities.

And yet, breaches still happen. Fraud still slips through. Third-party risk still catches teams off guard. The issue isn’t visibility. It’s the growing gap between how fast threats move and how fast organizations can respond.

Attackers now operate at machine speed, leveraging automation and AI to identify vulnerabilities, launch campaigns, and exploit opportunities in real time. Most security teams, however, are still constrained by manual workflows, fragmented systems, and processes that require human intervention at every step. That mismatch is where risk can accumulate—and where even well-resourced teams fall behind.

What many organizations are discovering is that the problem isn’t a lack of intelligence. The problem is their inability to turn the insights into contextualized, intelligence-led actions.

The Hidden Cost of Human-Speed Security

For many organizations, this gap shows up in subtle but compounding ways. Analysts spend hours triaging alerts, trying to determine which signals actually matter. Security teams often discover incidents after damage has already occurred, not because the data wasn’t there, but because it couldn’t be acted on quickly enough. Across the organization, teams responsible for cyber operations, fraud, and third-party risk operate in silos, each with their own tools and workflows, rarely sharing a unified view of risk.

At the same time, expectations from leadership have shifted. Executives and boards no longer want activity metrics—they want clear evidence that security investments are reducing business risk. But when intelligence is not clearly connected to action from security teams, that proof becomes difficult to deliver.

Traditional threat intelligence was designed to inform decisions made by humans, at human speed. In today’s environment, that model introduces delay. And delay, in cybersecurity, is increasingly indistinguishable from exposure.

Intelligence That Acts, Not Just Informs

Closing the speed gap requires more than incremental improvements. It requires a shift in how organizations think about intelligence altogether. Moving forward, the future of cybersecurity must be more than just intelligence-led—it must be intelligence-acted.

In this model, intelligence doesn’t sit in dashboards waiting for analysts to interpret it. It continuously correlates signals, prioritizes what matters, and drives action across the security environment automatically. Instead of asking teams to move faster, it enables the entire system to operate at the speed of the threat.

This is the foundation of autonomous defense, and it’s the future of effective, machine-speed cybersecurity.

From Reactive to Autonomous: A New Operating Model

Autonomous defense fundamentally changes the role of the security team. Rather than serving as the bottleneck between detection and response, analysts become decision-makers operating on top of continuously running intelligence.

Recorded Future’s Autonomous Threat Operations brings this model to life by eliminating the manual steps that slow teams down. It ingests and correlates intelligence from multiple sources, applies context in real time, and triggers actions across existing security tools—all without requiring constant human input.

The impact of such a dramatic shift is immediate and measurable. Threat hunting becomes continuous instead of periodic. Alerts arrive enriched with context, reducing the time needed to investigate and respond. Detection and remediation workflows execute automatically, freeing analysts to focus on strategic threats rather than routine triage.

Just as importantly, this approach transforms how organizations measure success. Instead of tracking activity—alerts processed, queries written, incidents reviewed—teams can demonstrate real outcomes: faster response times, reduced exposure, and a clearer connection between intelligence and risk reduction; the latter of which is becoming increasingly necessary for organizational buy-in.

This is so much more than just adding another tool to the stack. Instead, it’s about making every existing control smarter, faster, and more effective. And it’s paying off. On average, security teams using Recorded Future save up to 100 hours per week through improved analyst productivity, allowing teams to redirect effort toward threat hunting and proactive defense instead of repetitive manual analysis.

The Bigger Challenge: Fragmented Visibility Across the Attack Surface

Speed alone, however, is only part of the equation. Many organizations are also limited by how they view risk. Threats today don’t respect organizational boundaries. A phishing campaign can lead to credential theft, which can then be used to access systems, exploit third-party relationships, or enable fraudulent transactions. These events are connected, but still far too many organizations manage them in isolation.

Cyber operations teams focus on internal threats. Fraud teams monitor transactions. Risk teams assess vendors. Each group has visibility into part of the problem, but no one has a complete picture. This fragmentation creates blind spots, and attackers are increasingly skilled at navigating between them.

A Unified Approach to Risk

To effectively reduce risk, organizations need more than faster response times. They need a connected understanding of their entire attack surface, along with the ability to act across it in a coordinated way.

Recorded Future addresses this through four core solution areas—Cyber Operations, Digital Risk Protection, Third-Party Risk, and Payment Fraud Intelligence—all built on a single, integrated intelligence foundation.

In cyber operations, this means moving beyond alert overload to real-time prioritization. Instead of forcing analysts to sift through volumes of data, intelligence surfaces the threats that are most relevant to the organization’s environment and enables immediate action. The combination of prioritization and automation allows teams to reduce noise while improving both detection speed and response quality.

In digital risk protection, the focus shifts beyond the traditional perimeter. Today’s attackers target brands, customers, and executives just as frequently as they target infrastructure. By monitoring the open, deep, and dark web, Recorded Future provides visibility into impersonation campaigns, credential exposure, and emerging threats long before they impact the organization. More importantly, it enables rapid response, whether that means taking down fraudulent domains or preventing account takeover attempts.

Third-party risk represents another growing challenge. As organizations expand their ecosystems, they inherit risk from vendors and partners, often without real-time visibility. Third-party involvement in breaches has reached a staggering 30%, up from just 15% a year ago. Static assessments and periodic reviews can’t keep pace with how quickly vendor risk evolves today. Continuous monitoring, grounded in real-world intelligence, allows organizations to detect issues earlier, respond faster, and maintain a more accurate understanding of their exposure.

Threat intelligence-driven security is vital. It’s the eyes and ears of a security team. You can’t protect yourself against what you don’t know. A couple times now, Recorded Future has alerted us to something prior to the third-party vendor. That’s huge when we’re trying to protect our data.

Natalie Salisbury

Strategic Threat Intelligence Analyst, Novavax

In the realm of payment fraud intelligence, the shift is equally significant. There were some 269 million records posted across dark and clear web platforms in 2024, and a tripling of certain e-skimmer infections. It’s important to keep in mind that fraud doesn’t begin at the moment of transaction. Rather, it begins much earlier, in the environments where stolen data is exchanged and tested. Recorded Future provides comprehensive coverage across the complete payment fraud lifecycle. Sophisticated cleanup and normalization techniques result in better data quality and richer data sets, reducing manual research and enabling high confidence mitigation actions. By identifying these signals upstream and intervening, organizations can stop fraud before it’s executed, reducing both financial loss and customer impact.

One Intelligence Foundation. Total Visibility.

What makes this approach fundamentally different is that these capabilities are not delivered as isolated solutions. They are unified through the Recorded Future Intelligence Platform, which correlates data across millions of sources and billions of entities to provide a single, coherent view of risk.

This unified foundation enables organizations to connect signals that would otherwise remain siloed. Threat actors, infrastructure, vulnerabilities, and campaigns are all linked, allowing teams to understand not just what is happening, but what is likely to happen next.

That level of visibility is what makes autonomous defense possible. And not just within a single domain, but across the entire attack surface.

The urgency behind this shift cannot be overstated. Attackers are already operating at machine speed, using automation to scale their efforts and reduce the time between discovery and exploitation. At the same time, organizations that rely on manual processes are finding it increasingly difficult to keep up.

The consequences of this gap are significant. Longer dwell times allow attackers to entrench themselves more deeply. Delayed responses increase the cost and impact of incidents. And as breaches and fraud events become more visible, customer trust becomes harder to maintain.

This is no longer a question of optimization. It’s a question of whether existing operating models can keep pace with the reality of modern threats.

Rethinking What Threat Intelligence Should Do

As organizations evaluate their approach to cybersecurity, the role of threat intelligence needs to be reconsidered. It is no longer enough for intelligence to provide visibility. It must enable action. It must operate in real time. And it must extend across the full scope of organizational risk—not just one domain at a time.

Equally important, it must deliver outcomes that matter to the business. Faster detection, reduced exposure, and measurable risk reduction are no longer aspirational. They are essential for enterprise security in the modern, AI-powered threat landscape.

The goal for most organizations isn’t to replace their security stack. It’s to make it work better. By enabling intelligence to act autonomously, connecting visibility across domains, and aligning security operations with the speed of modern threats, organizations can close the gap that has long existed between insight and action. Recorded Future is built to make that possible.

If your team is still struggling with alert fatigue, delayed responses, or fragmented visibility, the issue may not be a lack of resources. It may be a limitation in how intelligence is being applied.

Now is the time to rethink that model.

Connect with Recorded Future to see how autonomous defense can help your organization move at the speed of today’s threats—and stay ahead of what comes next.

Contact us

❌