Filippo Valsorda argued last week that AES-128 holds up against quantum computers. The same point appeared as a footnote in our hybrid signature split post: the quantum threat is on signatures and key exchange, not on the block cipher.
Our scan data adds a surprise. The operators who doubled their AES key are not the operators who fixed the part Shor actually breaks. Across a rolling 30-day window of [PQ]probe TLS scans:
| AES profile | Share of hosts | PQC key exchange | A-grade rate |
|---|---|---|---|
| AES-128 only | 44% | 48% | 43% |
| AES-256 only | 32% | 6% | 6% |
| Both | 13% | 0% | 0% |
| Neither (ChaCha20 only) | 12% | 1% | 1% |
AES-128-only hosts negotiate hybrid PQC key exchange 8 times as often as AES-256-only hosts (48% vs 6%). Hosts that accept either cipher fall to 0%. ChaCha20-only sits at 1%, close to AES-256-only. Methodology is at the end of the post.
The reason is configuration, not cryptography. Stock OpenSSL and rustls open their TLS 1.3 default suite list with TLS_AES_256_GCM_SHA384, so a host that takes the defaults negotiates AES-256-GCM. The hosts that negotiate AES-128-GCM are mostly the ones that override that default. Cloudflare and the other large edge fleets are the obvious examples, and those are the same fleets that deployed X25519MLKEM768 in 2024. AES-128 in a TLS 1.3 handshake is the marker of an edge config that someone has been maintaining.
TLS 1.2 hosts arrive at AES-256 from the other direction. Cipher selection is server-driven in TLS 1.2, and these hosts are usually pinned to an ECDHE-AES256-GCM suite by a preference list copied from a hardening guide written before quantum was on the agenda. The same list pinned X25519, P-256, or RSA for key exchange. The cipher got upgraded. The key exchange did not.
Standards bodies agree that AES-128 needs no further change. BSI TR-02102-1 recommends AES-128, AES-192, and AES-256 equally for new systems, as covered in the BSI expiration date post. NIST IR 8547 places every NIST-approved symmetric primitive with at least 128 bits of classical security in PQC Category 1, and the NIST PQC FAQ is more direct: applications can keep using AES-128, AES-192, or AES-256.
CNSA 2.0 does mandate AES-256, but for uniform protection of National Security Systems at Top Secret, not for Grover resistance. The same rationale drives its requirement for ML-KEM-1024 and ML-DSA-87 over the more common ML-KEM-768 and ML-DSA-65. Outside of NSS work, no compliance regime requires moving off AES-128.
What this means for audits and procurement
[PQ]probe grades the key exchange, not the cipher. A host negotiating hybrid PQC key exchange is quantum-safe whether its cipher is AES-128-GCM or AES-256-GCM. A host pinned to a classical key exchange is not, whichever cipher it picks.
Audit tools that downgrade AES-128 on quantum-resistance grounds check the cipher when the quantum threat is on the key exchange. Procurement requirements that demand AES-256 push operators toward exactly the configurations the data above shows are stalled, the column where PQC adoption sits at 6%, not 48%.
Post-quantum migration takes years, and the work is in legacy systems and vendor dependencies. Operators who chose AES-128 have mostly already moved to hybrid key exchange. Operators on AES-256-only have not. Spend the next two years on the key exchange, not on doubling the symmetric one. The handshake size calculator estimates what the asymmetric upgrade costs for a given algorithm mix.
Methodology
Each host contributes its most recent successful TLS scan from the last 30 days. The AES profile column reflects which AES key sizes appear in the host's negotiated cipher suites; hosts that negotiate only ChaCha20 sit in the “Neither” row. PQC key exchange adoption counts hosts that advertise or negotiate an ML-KEM group, in practice X25519MLKEM768 or SecP256r1MLKEM768. Percentages are rounded to whole numbers.