AWS Key Management Service, AWS Certificate Manager, and AWS Secrets Manager now support ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) for hybrid post-quantum key agreement, across every AWS region in the standard partition. All three were chosen specifically because they sit at the most security-critical layer of AWS's own infrastructure — the services other services depend on for secrets and certificates in the first place.
Why "hybrid," not pure post-quantum
None of this replaces classical key exchange outright. ML-KEM runs alongside existing elliptic-curve key agreement, not instead of it — the connection is only as vulnerable as the weaker of the two algorithms, and only if both are eventually broken. This hybrid approach is the industry's near-universal pattern right now, not an AWS-specific choice; it's the same design Chrome and Cloudflare have been running in production since 2024.
What this replaces
AWS had previously supported CRYSTALS-Kyber, ML-KEM's pre-standardization predecessor, across these same services. That support continues through the rest of 2025, but AWS has confirmed it will be phased out during 2026 in favor of the now-finalized ML-KEM standard (FIPS 203). If you're on an older AWS SDK version still negotiating Kyber specifically, this is the actual deadline that matters, not a vague "post-quantum migration" timeline.
Where this fits in the bigger picture
Recent internet-wide measurement studies suggest something close to half of TLS 1.3 handshakes now negotiate some form of hybrid post-quantum key exchange, largely driven by Chrome and Cloudflare defaults — see our State of HTTPS page for the adoption numbers. AWS extending the same support into KMS, ACM, and Secrets Manager specifically closes a gap: these services sit upstream of a huge amount of TLS traffic that wouldn't otherwise benefit just because the browser-to-edge hop already does.
What to actually do about it
For most users, nothing changes today — hybrid key exchange is opt-in and backward compatible. If you're running a recent AWS SDK version, no code changes are needed to benefit once you opt in. The more relevant action item is checking whether anything in your own stack still hardcodes the older Kyber draft algorithm identifiers specifically, since those are what's actually being retired. For the bigger picture on where this transition is headed — and where informed speculation ends — see our Future of Encryption page.
This is our own summary and analysis of publicly reported news, written independently — not a reproduction of any single source's article. Where we reference a specific announcement, we link to it or name the organization directly.