AWS Key Management Service is the encryption-at-rest backbone for the AWS cloud. Every S3 object encrypted with SSE-KMS, every EBS volume with default encryption, every Secrets Manager secret, every Lambda environment variable encrypted at rest, eventually traces back to a KMS key. That centralization made KMS one of the highest-value targets imaginable for a future quantum adversary, and Amazon was correspondingly aggressive in shipping post-quantum protection earlier than most cloud providers.
This article walks through the specific way AWS KMS got post-quantum cryptography wired in: hybrid TLS to KMS endpoints, FIPS-validated TLS modules, the underlying AWS-LC implementation, and the migration story for customers. The information here is based on AWS's public security blog posts, AWS documentation at aws.amazon.com/security, and the open-source AWS-LC repository.
What AWS Did First
The first piece of post-quantum infrastructure Amazon shipped was hybrid TLS for connections to KMS endpoints. As early as 2020-2021, AWS provided experimental hybrid post-quantum TLS support in the AWS SDK, allowing clients to negotiate hybrid key exchange (classical + post-quantum) when connecting to KMS regional endpoints.
The implementation went through several iterations:
- Early experimental hybrid groups (BIKE, SIKE) that AWS deprecated as the algorithms fell out of NIST consideration
- Migration to Kyber-768-based hybrid groups during the NIST standardization process
- Final migration to ML-KEM-768 (FIPS 203) once NIST standardized the algorithm
Each iteration appeared in AWS-LC, the cryptographic library that AWS uses across its services. AWS-LC is Amazon's BoringSSL-derived library, with FIPS-validated builds and a focus on the algorithms AWS services need.
For background on AWS-LC's parent project, see BoringSSL PQ status.
What KMS Supports for Post-Quantum
The picture for 2026:
| Feature | Status in AWS KMS |
|---|---|
| Hybrid TLS to KMS endpoints | Available (X25519MLKEM768) |
| ML-KEM TLS via SDK opt-in | Available across modern AWS SDKs |
| KMS-managed PQ-protected keys (PQ KEM keys you can import) | Roadmap, not yet GA |
| KMS-managed PQ signing keys (ML-DSA) | Roadmap |
| Hybrid signature schemes for IAM | Not yet |
| FIPS-validated PQC at the TLS layer | In progress |
The story is therefore: today, your TLS connection to KMS can be post-quantum protected, which means an attacker harvesting traffic now cannot later decrypt your KMS API requests when they have a quantum computer. Your KMS-managed keys themselves remain RSA, ECDSA, and AES, and signing/encryption operations within KMS still use classical primitives.
The next phase, ongoing through 2026 and 2027, is the introduction of PQ-backed KMS keys. AWS has signaled this in several Security Blog posts.
Why TLS First, Then Keys
The asymmetry between hybrid TLS (already deployed) and PQ-backed keys (still coming) is intentional. The threat model is "harvest now, decrypt later." For that threat model, the urgent piece is the network: an adversary who records encrypted traffic today and cracks it later with a quantum computer.
Locked-down KMS keys, used only inside Amazon's HSMs and never wire-transmitted in clear, are not at the same risk. Secret material flowing through KMS APIs is wrapped under TLS-protected sessions, and if those sessions used post-quantum hybrid groups, the harvested ciphertext is not crackable by a future quantum computer regardless of what cryptography sits behind KMS endpoints.
This is why customers should care about AWS's hybrid TLS rollout before worrying about whether KMS keys are RSA or ML-KEM. The TLS pipe is the one that protects against the harvest-now-decrypt-later attacker.
For background on the threat, see harvest now decrypt later.
How to Enable Hybrid TLS in AWS SDKs
AWS SDKs for Java, Python (boto3), Go, JavaScript (Node.js), Rust, and others have provided opt-in hybrid TLS for KMS clients. The exact API differs by SDK but the pattern is:
- Configure the HTTPS client with a TLS context that prefers hybrid groups
- Point the client at a KMS endpoint that supports hybrid groups
- Verify negotiation logs to confirm hybrid TLS was used
For most SDKs, this is a one-liner in the client configuration. AWS publishes documentation at docs.aws.amazon.com that covers the specific opt-in for each SDK version.
In some SDKs, hybrid TLS is the default for KMS clients in supported regions. Others require explicit opt-in. The trend is toward default-on as the IETF X25519MLKEM768 group becomes ubiquitous.
What AWS-LC Provides
AWS-LC is the cryptographic library at github.com/aws/aws-lc. It is a fork of BoringSSL maintained by Amazon's cryptography team. Its post-quantum coverage includes:
- ML-KEM-512, 768, 1024 with constant-time, well-tested implementations
- ML-DSA-44, 65, 87 (per FIPS 204, in active integration)
- Hybrid TLS group support matching the IETF drafts
- FIPS-validated builds going through CMVP
AWS services use AWS-LC across their fleet. KMS endpoints, ALB, CloudFront, NLB, and many other services run AWS-LC under the hood. When the library is updated, the services pick up the changes during AWS's regular deployment cycles.
For more on the underlying algorithm, see ML-KEM explained.
The Customer Migration Story
For AWS customers, the practical migration plan to use PQ-protected KMS connections has several steps.
- Use a current AWS SDK (Java SDK 2.x, boto3 1.34+, Go SDK v2 v1.30+, etc.). Older SDK versions may not have hybrid TLS support.
- Configure your SDK clients to opt into hybrid TLS for KMS. The exact configuration depends on the SDK.
- Verify the negotiation by inspecting TLS handshake logs or by running a tool that shows the negotiated TLS group.
- Plan for KMS API call latency. Hybrid TLS handshakes are slightly larger than classical, which can affect cold-start latency in highly latency-sensitive workloads.
- For data already encrypted with KMS keys: re-encryption is not required immediately, because the data ciphertext itself is AES-GCM (symmetric, not vulnerable to Shor's algorithm). The vulnerable piece is the wrapping of data keys, but that wrapping is happening through TLS, which is now hybrid.
For a broader migration plan, see AWS KMS quantum migration.
How AWS Communicates the Roadmap
AWS publishes post-quantum updates in several places:
- AWS Security Blog at aws.amazon.com/blogs/security: feature announcements and explanations
- AWS What's New: feature releases tagged with PQC-related keywords
- AWS re:Inforce talks: annual security conference often features PQC progress
- AWS Cryptography blog within the Security blog: deeper technical explanations
- aws-lc release notes: granular changes at the library level
The cadence has been: a major announcement when a new TLS group becomes available, followed by SDK updates that expose the option. Customer-visible changes typically have a 6-12 month gap from announcement to default behavior.
How AWS KMS Compares to Other Clouds
AWS shipped hybrid TLS to KMS endpoints earlier than Microsoft Azure or Google Cloud. By 2026, all three providers have substantial PQC story. The differences are subtle:
- AWS's hybrid TLS is well-documented in the Security Blog and SDK release notes
- Azure Key Vault's PQC story is documented at learn.microsoft.com and tied to Microsoft's SymCrypt library
- Google Cloud's KMS story leverages BoringSSL's PQC work
For the parallel stories, see Azure Key Vault PQC implementation and Google Cloud KMS PQC.
Key Generation Inside KMS
AWS KMS generates keys inside HSMs. The HSMs are FIPS 140-3 (or FIPS 140-2 in some regions) validated devices that produce, store, and use cryptographic keys without ever exposing them outside the HSM boundary.
For PQ-backed KMS keys, the HSM firmware needs to support PQ key generation, signing, and KEM operations. AWS has been working with HSM vendors to add this capability. The progression has been:
- Existing HSMs do RSA, ECDSA, ECDH, AES
- Updated HSM firmware adds ML-KEM and ML-DSA support
- AWS qualifies the firmware in its environment
- KMS exposes new key types backed by the upgraded HSMs
This sequence is naturally slower than software-only changes. The estimated timeline for general availability of PQ-backed KMS keys is 2026-2027, depending on HSM vendor delivery.
Cross-Region Replication and PQC
KMS keys can be replicated across AWS regions. Cross-region replication uses internal AWS networks but still benefits from TLS protection on the customer-facing API. PQ-protected TLS at KMS endpoints means cross-region operations are also PQ-protected at the customer-facing layer.
Internal AWS network traffic between data centers uses its own protections, including post-quantum-aware ones in some cases, as documented in AWS's internal security model.
How Other AWS Services Inherit PQC
KMS is not the only AWS service that benefits from hybrid TLS. AWS-LC underpins:
- ALB (Application Load Balancer): TLS termination for customer traffic
- NLB (Network Load Balancer): TLS pass-through with optional inspection
- CloudFront: edge TLS termination
- API Gateway: customer-facing API TLS
- Internal AWS service-to-service communication
As AWS-LC ships PQC algorithms, these services inherit them on AWS's deployment cadence. Customers connecting to ALB, CloudFront, or API Gateway through SDKs that support hybrid TLS get end-to-end post-quantum protection at the network layer.
For the parallel cloud story, see Google Cloud KMS PQC.
AWS Nitro and PQC
AWS Nitro is the hardware/hypervisor platform underpinning EC2 instances. The Nitro Security Chip and Nitro Hypervisor provide cryptographic isolation for customer workloads. As AWS extends Nitro's cryptographic primitives to support post-quantum algorithms, customer workloads running on EC2 benefit from hardware-rooted PQ protection.
This is forward-looking work. The current Nitro generation supports classical algorithms. Future generations and firmware updates are expected to extend this to PQ. AWS has discussed the broader cryptographic strategy at re:Inforce talks.
Customer Audit and Compliance Implications
For customers in regulated industries (financial services, healthcare, government), the PQC posture of AWS KMS matters for compliance reasons:
- HIPAA-covered entities are increasingly asked about quantum-safe posture in BAAs
- PCI DSS 4.0 includes considerations for cryptographic agility
- FedRAMP requirements are evolving to include quantum-readiness assessments
- Banking regulations in multiple countries are starting to require PQC migration plans
AWS KMS's hybrid TLS support gives customers a documentable answer: "AWS provides hybrid post-quantum TLS for KMS API connections, and our SDKs use it." This is a compliance-relevant statement that auditors will increasingly expect.
For broader regulatory context, see AWS KMS quantum migration.
Best Practices for AWS Customers
For organizations using AWS KMS:
- Audit your AWS SDK versions across all services. Older SDKs may not negotiate hybrid TLS.
- Enable hybrid TLS in your KMS clients. Verify with handshake inspection.
- For high-value, long-retention data (think: medical records, classified information, sensitive PII), prioritize PQC TLS protection now. Plan for PQ-backed KMS keys when AWS releases them.
- For ephemeral or short-retention data, the migration is less urgent but still worthwhile.
- Track AWS Security Blog and What's New for PQC announcements. The roadmap moves; staying current matters.
For broader migration patterns, see AWS KMS quantum migration.
Frequently Asked Questions
Is my KMS data already protected against quantum attacks?
The data encrypted by KMS is AES-GCM, which is not directly broken by quantum algorithms (only Grover's algorithm halves AES key strength, and AES-256 has 128 bits of post-quantum strength). The KMS API connections that wrap data keys are protected by TLS; if your SDK uses hybrid TLS, that TLS is post-quantum protected.
Can I create a PQ-backed KMS key today?
Not yet for general availability. AWS has signaled this is on the roadmap. Track AWS announcements for general availability.
Does FIPS-validated KMS support hybrid TLS?
AWS has FIPS-validated TLS modules in its FIPS endpoint regions. The progression of hybrid TLS through FIPS validation is following CMVP timelines, with expanded coverage through 2026.
Will I need to re-encrypt my data when PQ KMS keys ship?
Re-encryption is generally not required for the symmetric layer (AES-GCM is post-quantum acceptable). The key wrapping migration may benefit from re-keying with PQ-backed keys for highest-value data, on a customer schedule.
Where can I find AWS's PQC announcements?
AWS Security Blog at aws.amazon.com/blogs/security, AWS What's New, and the AWS-LC release notes at github.com/aws/aws-lc.
Sources
- AWS Security Blog post-quantum announcements, aws.amazon.com/blogs/security
- AWS-LC repository, github.com/aws/aws-lc
- NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism), August 2024
- AWS KMS documentation, docs.aws.amazon.com/kms
- IETF draft-kwiatkowski-tls-ecdhe-mlkem
- AWS re:Inforce conference talks on PQC, aws.amazon.com/events/reinforce
Related Articles
- What is post-quantum cryptography
- AWS KMS quantum migration
- Hybrid encryption
- Harvest now decrypt later
- Azure Key Vault post-quantum
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.