Post-Quantum Crypto Is Here — What It Means on AWS

This is Part 3 of the “Whiteboard to Cloud” series, where I take an academic explainer and trace it to what you can actually do on AWS. The earlier parts covered vector search and why compression behaves like intelligence. This one starts at a whiteboard about quantum computers and ends at a KMS key spec.

A while back I sat through an internal talk on cryptography in the quantum age and wrote up the gist [8]. The short version held up: this is an old problem with new urgency. What has changed since is that the standards are finalized and the cloud building blocks are shipping, so the conversation moves from “should we worry” to “what do we turn on first.”

Why post-quantum, why now

The cleanest explainer I have seen of the threat model is Computerphile’s whiteboard walkthrough of post-quantum cryptography [1]. You do not need lattice math to get the point. Most of the public-key cryptography protecting data in transit today (the key exchange that sets up a TLS session, the signatures that prove who you are talking to) rests on problems that are hard for classical computers but would fall to a sufficiently large quantum computer running Shor’s algorithm.

The part people miss is the timeline. You might assume the risk arrives only when the quantum computer does. It arrives earlier. The threat is called “harvest-now, decrypt-later”: an adversary captures your encrypted traffic today, stores it, and waits. When a cryptographically relevant quantum computer exists, they decrypt the archive. So the real question is not “when will quantum computers break RSA,” it is “how long does this data need to stay secret.” If the answer is ten or fifteen years, the clock is already running.

That reframing is what makes this practical rather than alarmist. You are not defending against a machine that exists today. You are deciding which of your secrets have a long enough shelf life to be worth recording now.

What NIST actually standardized

For years post-quantum cryptography lived in competition drafts. That ended in August 2024, when NIST published the first three finalized post-quantum standards [2]:

• FIPS 203, ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, formerly Kyber): the key exchange that replaces or augments classical key agreement.
• FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Algorithm, formerly Dilithium): the general-purpose signature scheme.
• FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature, formerly SPHINCS+): a hash-based signature alternative with different trade-offs.

A fourth signature standard, FIPS 206 (FN-DSA, from FALCON), is still in development [2]. The significance of finalized FIPS numbers is procurement and compliance: once an algorithm is a standard, vendors can implement it against a fixed target and regulated industries can adopt it without betting on a draft.

The standard migration shape looks like this:

Hybrid is the middle rung on purpose. Running a classical algorithm and a post-quantum one together means the connection stays at least as strong as the classical one if the new algorithm has an undiscovered weakness, while already protecting against harvest-now-decrypt-later. It is the low-regret step.

Where AWS already supports post-quantum today

Here is the concrete part, and the part to keep scoped. The clearest place AWS post-quantum support shows up today is AWS KMS, in two distinct ways [3].

Hybrid post-quantum TLS for connections

You can make your calls to AWS KMS over hybrid post-quantum TLS, which uses ML-KEM through the s2n-tls library for the key exchange [4]. Two scoping details matter and you should not gloss them: the hybrid cipher suites in s2n-tls are currently supported only on Linux systems, and only in SDKs built on the AWS Common Runtime, such as the AWS SDK for Java 2.x [4]. KMS supports hybrid post-quantum TLS on all of its endpoints, including the FIPS 140-3 validated endpoints [4]. Importantly, this protects data in transit; it is exactly the harvest-now-decrypt-later defense for traffic to KMS.

Post-quantum signatures

AWS KMS supports ML-DSA (FIPS 204) for post-quantum digital signatures, generally available since June 2025 [5] [6]. You create and use ML-DSA keys through the same KMS APIs you already use for signing (CreateKey, Sign, Verify), the private keys are generated and held in FIPS 140-3 Security Level 3 validated hardware security modules, and three security levels are offered as key specs: ML_DSA_44, ML_DSA_65, and ML_DSA_87 [5]. This is the piece you reach for when you need to sign code, artifacts, or documents that must stay verifiable for many years, including after a quantum computer exists [6].

Data at rest is already in good shape

When KMS encrypts data under a KMS key it uses AES-256-GCM, symmetric cryptography that is already considered quantum-resistant [4]. The best known quantum attack (Grover’s algorithm) roughly halves the effective key strength, so 256-bit AES retains about 128 bits of effective security, which keeps brute force infeasible [4]. So the symmetric, at-rest side of the story needs no new algorithm; the urgency is on the public-key, in-transit and signing side.

One caveat worth stating plainly: “AWS supports post-quantum cryptography” is true and specific, not blanket. The support above is in KMS, and the hybrid TLS path carries the Linux-plus-Common-Runtime constraint. Service-by-service post-quantum coverage is expanding, so treat the official documentation as the source of truth for what is available in the service and runtime you actually use [3] [7].

Crypto-agility: the thing to do today

If a full migration is not the action item, what is? Crypto-agility. The goal is to be able to change cryptographic algorithms without re-architecting the system around them. That is the strategic response that holds regardless of exactly when quantum computers arrive, and it is how I would frame the first conversation with a customer today.

Three steps, highest-impact first:

1. Inventory your long-lived secrets. You cannot protect what you have not located. Find the data and the keys whose secrecy has to outlast a decade: archival backups, legal and health records, root keys, anything with a long retention obligation. These are the harvest-now-decrypt-later targets, and they set your priority.
2. Prioritize by secrecy lifetime, not by fear. Short-lived session data that is worthless in two years is low priority. Long-retention data flowing over the public internet is high priority. Rank the inventory by how long it must stay secret, and start at the top.
3. Turn on hybrid post-quantum TLS where it is available, and exercise the signing path. For traffic to services that support it (KMS today, on the supported runtimes), enabling hybrid PQ TLS is the low-regret move that immediately addresses recorded-traffic risk [4]. In parallel, try an ML-DSA key for a signing use case that needs long-term verifiability, so the operational path is familiar before you depend on it [5].

None of this requires a quantum computer to exist, and none of it is a rip-and-replace. It is inventory, prioritization, and using building blocks that are already there. Crypto-agility also pays off beyond quantum: the team that can swap an algorithm cleanly is the team that handles the next deprecation, the next compliance change, and the next weakness disclosure without a fire drill.

If You’re Running This on AWS

Concrete starting points, all from official documentation:

Create and use an ML-DSA signing key (FIPS 204)

ML-DSA keys are first-class asymmetric KMS keys; you pick a security level via the key spec [5]:

Creating a post-quantum signing key with the AWS CLI:

# Create an ML-DSA-65 key for post-quantum signatures
aws kms create-key \
  --key-spec ML_DSA_65 \
  --key-usage SIGN_VERIFY \
  --description "Post-quantum signing key (FIPS 204 / ML-DSA)"

# Sign a message (RAW message type, up to 4 KB)
aws kms sign \
  --key-id <key-id> \
  --message fileb://payload.bin \
  --message-type RAW \
  --signing-algorithm ML_DSA_SHAKE_256

Enable hybrid post-quantum TLS to KMS

This lives in the SDK/runtime configuration, not in your application logic, and it is constrained to Linux and AWS Common Runtime SDKs such as the AWS SDK for Java 2.x; KMS accepts it on all endpoints including FIPS 140-3 [4]. Follow the KMS guide’s “Configure hybrid post-quantum TLS” example for the exact client setup [4].

Documentation to bookmark

• AWS KMS features, post-quantum cryptography section [3]
• Using hybrid post-quantum TLS with AWS KMS [4]
• ML-DSA keys in AWS KMS [5]
• AWS post-quantum cryptography program [7]

Frame this as a capability you can adopt incrementally, not a deadline you are behind on. The pieces are in the service; the work is knowing where to point them first.

The honest closing

Post-quantum cryptography is here in the sense that matters for planning: the standards are finalized, the recorded-traffic threat is real for long-lived secrets, and the cloud building blocks are shipping. It is not here in the sense of a quantum computer breaking RSA tomorrow, and writing as if it were would be the wrong tone. The measured move is crypto-agility: inventory, prioritize, and adopt the post-quantum building blocks that already exist, starting with the data whose secrets have the longest to live. That is a plan you can start this quarter, on infrastructure you already run.

Sources

• [1] Computerphile: Post-Quantum Cryptography
• [2] NIST Post-Quantum Cryptography standardization (FIPS 203/204/205; FIPS 206 in development)
• [3] AWS Key Management Service features, post-quantum cryptography
• [4] Using hybrid post-quantum TLS with AWS KMS
• [5] ML-DSA keys in AWS KMS
• [6] How to create post-quantum signatures using AWS KMS and ML-DSA (AWS Security Blog)
• [7] AWS Post-Quantum Cryptography
• [8] Cryptography in the Quantum Age: Starting Now (my earlier post)
• [9] Security Is Job Zero (my earlier post)
• [10] The 732-Byte Wake-Up Call (my earlier post)
• [11] The Agent Security Stack Nobody Is Building (my earlier post)

#Security #Cryptography #PostQuantumCryptography #AWSKMS #CryptoAgility

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

• Security
• Cryptography
• PostQuantumCryptography
• AWSKMS
• NIST