AWS Builder Center

Builder Center

Quantum Won't Break Your AWS Account Tomorrow. Your Old Traffic Is Another Story.

Quantum Won't Break Your AWS Account Tomorrow. Your Old Traffic Is Another Story.

Harvest-now-decrypt-later is already happening. Here's what post-quantum crypto means for AWS workloads, plus a 15-minute lab to check whether your TLS handshakes are quantum-resistant today.

Shivaji Rathod

Cybersecurity Enthusiast | Aspiring Cloud Security Engineer

Let's start with a question

Pick one:
A) "Quantum computers will break the internet next year."
B) "Quantum is a 2040 problem. Ignore it."
C) "Someone may be recording my encrypted traffic right now, and I'll only find out in 10 years."
If you picked C, you're ahead of most teams. That's the real threat, and it has a name: Harvest Now, Decrypt Later (HNDL).

The threat in 60 seconds

A large enough quantum computer running Shor's algorithm breaks the math behind RSA, Diffie-Hellman, and elliptic curves (ECDH/ECDSA). That's the crypto behind almost every TLS handshake, SSH key, and code-signing cert you use.
It doesn't need to exist today. An attacker only needs to:
  1. Record your encrypted traffic now
  2. Store it cheaply
  3. Decrypt it when the hardware arrives
So the question isn't "when will quantum computers arrive?" It's "how long does my data need to stay secret?" Medical records, financial data, and government or IP-heavy workloads have shelf lives of 10-25 years. That's the problem.
PrimitiveQuantum impactAction
RSA, ECDH, ECDSABroken (Shor)Migrate to PQC
AES-128Weakened (Grover)Prefer AES-256
AES-256Still fineKeep it
SHA-256/384Still fineKeep it
Only asymmetric crypto is on fire. Symmetric crypto is fine.

What's actually standardized

In August 2024, NIST finalized the first post-quantum standards:
  • ML-KEM (FIPS 203): key exchange (formerly Kyber)
  • ML-DSA (FIPS 204): digital signatures (formerly Dilithium)
  • SLH-DSA (FIPS 205): hash-based signatures (formerly SPHINCS+)
Real-world deployments use hybrid mode: a classical algorithm (X25519) plus a PQ algorithm (ML-KEM) in the same handshake. An attacker has to break both. That's why you'll see X25519MLKEM768 in the wild.

Where this hits AWS

Think in terms of your attack surface:
  • TLS to AWS API endpoints (KMS, ACM, Secrets Manager): hybrid PQ key exchange is supported on these endpoints
  • AWS KMS: supports ML-DSA keys for signing
  • Your own load balancers and CloudFront: PQ TLS policies are rolling out, so check your current security policy
  • Everything you sign: container images, artifacts, JWTs. If it's RSA/ECDSA today, it's on the migration list
HNDL is a confidentiality problem (key exchange). Forged signatures are an integrity problem that only matters once quantum hardware exists. Prioritize key exchange first.

🧪 Lab: Is your handshake quantum-resistant?

You need OpenSSL 3.5+ (it ships ML-KEM hybrid groups).
1
2
3
4
5
6
7
8
9
openssl version

# Force a hybrid PQ group against an AWS endpoint
openssl s_client -connect kms.us-east-1.amazonaws.com:443 \
-groups X25519MLKEM768 -brief </dev/null

# Compare against classical-only
openssl s_client -connect kms.us-east-1.amazonaws.com:443 \
-groups X25519 -brief </dev/null
Look for Negotiated TLS1.3 group: in the output. If the first command negotiates the hybrid group, the endpoint supports PQ key exchange. Now point the same test at your own ALB or CloudFront domain. Different result? That's your first finding.

🧪 Lab 2: Build a crypto inventory with boto3

You can't migrate what you can't see. Start with KMS:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
import boto3
from collections import Counter

kms = boto3.client("kms")
specs = Counter()

for page in kms.get_paginator("list_keys").paginate():
for k in page["Keys"]:
meta = kms.describe_key(KeyId=k["KeyId"])["KeyMetadata"]
if meta["KeyManager"] == "CUSTOMER":
specs[(meta["KeyUsage"], meta["KeySpec"])] += 1

for (usage, spec), n in specs.most_common():
print(f"{n:>4} {usage:<16} {spec}")
Anything SIGN_VERIFY with RSA_* or ECC_* is a future migration candidate. Anything ENCRYPT_DECRYPT with SYMMETRIC_DEFAULT (AES-256) is fine.

Attacker view vs defender view

Attacker: passive collection of long-lived, high-value traffic (VPN tunnels, inter-region links, backups in transit). They don't need to touch your account. They just need your traffic to cross a network they can tap.
Defender checklist:
  • [ ] Inventory every place you use RSA/ECC (TLS, signing, SSH, VPN, JWT)
  • [ ] Classify data by how long it must stay confidential
  • [ ] Use AES-256 for data at rest (you probably do already)
  • [ ] Check load balancer and CloudFront TLS policies for PQ support
  • [ ] Find legacy TLS clients (CloudTrail tlsDetails shows TLS version and cipher suite)
  • [ ] Build crypto agility: algorithms should be config, not hardcoded
  • [ ] Track vendor roadmaps (VPN, HSM, CA, IdP)

The mistake to avoid

Don't go hunting for "quantum-safe" products. The winning move is crypto agility: being able to swap algorithms without rewriting your app. Teams that hardcoded RSA-2048 everywhere will suffer. Teams with an inventory and a config-driven crypto layer will update a setting.

Your turn

Run the OpenSSL test against your own endpoint and tell me in the comments: did it negotiate a hybrid group? If not, what's your TLS policy set to?
Which of your workloads holds data that must stay secret for 10+ years? That's where you start.
# aws-community-builders# aws-community# security-group# cybersecurity# network-security
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article