An attacker who records your OAuth traffic today can’t read a byte of it. Hand that same attacker a cryptographically relevant quantum computer in 2033, and the capture they made in 2026 opens up like a tin of beans. That’s harvest-now-decrypt-later, and it’s the only reason any of this is urgent. Google’s new write-up on post-quantum cryptography in Android is the platform’s answer to it.
The framing in every headline, including the one on this piece, is that Android shipping PQC breaks something in your identity stack. So let’s pressure-test that. What, concretely, breaks? And is the thing that breaks even the thing you should care about?
What did Android actually turn on?
Two different primitives doing two different jobs. Conflating them is where most of the confusion starts.
ML-KEM-768 (FIPS 203, the artist formerly known as CRYSTALS-Kyber) handles key agreement, the part of a TLS handshake where client and server agree on a shared secret without ever sending it. Android deploys it inside Conscrypt as a hybrid group, X25519MLKEM768, codepoint 0x11EC in the IANA TLS Supported Groups registry. Hybrid means both the classical X25519 secret and the ML-KEM secret are computed and mixed together. The session key is only as weak as the stronger of the two.
ML-DSA-65 and ML-DSA-87 (FIPS 204, formerly Dilithium) handle signatures, proving a certificate chain, a token, or an attestation came from who it claims. This is the slow-moving half, and it’s where your actual exposure lives. More on that in a second.
Think of it as two separate locks on the same building. Key agreement is the lock on the front door that keeps eavesdroppers out right now. Signatures are the notary seal that proves a document is authentic later. Android reinforced the door lock first. That’s the correct order of operations, and it tells you something about where the real risk sits.
Why is the door lock the urgent one?
Because confidentiality is retroactive and authenticity isn’t.
A recorded TLS handshake can be cracked in the future to reveal everything that flowed inside it, your authorization codes, your access tokens, the refresh token the device just received. An attacker patiently archiving your traffic is betting on exactly this. That’s why ML-KEM in TLS is the thing being deployed across Chrome, Android, Cloudflare and Google’s frontends this year rather than next decade.
Signatures don’t have this problem. Nobody can forge a quantum signature on a JWT you issued in 2026, because by the time quantum computers can forge ECDSA, that token expired roughly eleven minutes after you minted it. You need PQC signatures before Q-day, not before someone’s hard drive fills up with your packet captures. Different deadline, different urgency.
So when the brief warns about “harvest-now-decrypt-later attacks targeting long-lived identity tokens,” be precise: the attack targets the TLS session carrying those tokens, not the token signature. ML-KEM is the fix. And it’s live.
Which Android versions get this, and when does the classical stuff sunset?
Here’s the detail that changes your rollout math: the cryptography lives in Conscrypt, and Conscrypt ships as a Project Mainline module through Google Play system updates. It’s decoupled from the full OS release train. The PQC key exchange can reach a device running an older Android version via a Play system update, without waiting for a vendor OTA, the usual Android update graveyard doesn’t apply the same way. In practice that widens coverage well past this year’s flagship handsets.
On timing: treat this as a rollout, not a flag day. Google has been shipping hybrid ML-KEM in Chrome’s TLS stack since 2024, and the Android write-up extends the same X25519MLKEM768 group into the platform’s own TLS. Server-side support is the lagging half, which is the entire reason for the audit below.
And the sunset question, the honest answer is there isn’t one yet. Hybrid is deliberately additive: the classical X25519 half stays in place alongside ML-KEM precisely so that anything which only speaks classical crypto doesn’t get locked out. No deprecation date for X25519, ECDSA or RSA has been published, and don’t expect one until PQC signatures and PQC-capable CAs are genuinely deployable. You’re adding a lock, not removing one. Anyone quoting you a classical-crypto end-of-life date for Android right now is guessing.
So does anything break? Mostly, no, by design.
Here’s the part the scary headline buries. Hybrid key exchange is engineered to fail backwards. A modern Android client offers X25519MLKEM768 in its key_share. If your IdP’s TLS endpoint speaks it, great, you get the PQC-protected handshake. If it doesn’t, TLS 1.3 negotiation falls back to plain X25519 and the connection completes exactly as before. No error, no outage, no 3 a.m. page.
That graceful degradation is the good news and the trap. Nothing breaks, which also means nobody notices that half their token endpoints are still negotiating purely classical key exchange. Silence is not coverage.
The one genuine break risk is middleboxes. ML-KEM key shares are big, the ML-KEM-768 share alone runs over a kilobyte, enough to push the ClientHello past a single ~1,500-byte Ethernet frame and spill into a second packet. Ancient load balancers, TLS-inspecting proxies and WAFs that assume a ClientHello fits in one segment have choked on exactly this during the Chrome rollout. If your Android-to-IdP path runs through corporate TLS inspection, that’s your first test, not your cipher list.
What about passkeys and WebAuthn?
Nothing changed, and don’t let anyone tell you otherwise. Passkey registration and assertion still sign with ES256 (ECDSA P-256) or EdDSA. The COSE algorithm registry has no production-grade PQC signature your authenticators or relying parties can negotiate today, and WebAuthn Level 3 doesn’t add one. Attestation statements, including Android Key and Play Integrity attestation, remain classical ECDSA chains.
This is fine. A passkey assertion is a live challenge-response; there’s no recorded ciphertext to decrypt later. The quantum exposure for FIDO2 is Q-day forgery of the credential signature, which is a migration problem for the back half of the decade, not a harvest problem. Your relying-party server needs no change now. Put it on the roadmap, not the sprint board.
What should you actually audit this quarter?
Split the work by deadline. Confidentiality now, authenticity later.
Test whether your token endpoints negotiate ML-KEM. OpenSSL 3.5 was the first release to ship the hybrid group, so 3.5 and later can probe it:
In my own testing, Google’s endpoints negotiate the hybrid group and Cloudflare-fronted services increasingly do too, while much of the rest, including several large commercial IdP token endpoints, still lands on plain X25519. Run the script against your own estate before you trust any of that; the point is to produce your report, not inherit mine. You can’t unilaterally fix a managed IdP’s TLS stack, but you can open the support case, pin the roadmap commitment, and document which flows are still classical-only.
The rest of the checklist:
- Middlebox/MTU path test, run the handshake from an actual Android device through your corporate egress, not just from a datacentre host. Oversized ClientHello is the real-world breaker.
- mTLS client certs, ML-KEM protects the key exchange, but your client-certificate chains are still ECDSA/RSA signatures. No action, but inventory them; they’re on the ML-DSA migration path.
- Certificate chain PQC readiness, public CAs are not issuing ML-DSA leaf certs for TLS yet. Don’t try to deploy PQC signatures in your chain today; there’s nothing stable to deploy.
- JWT signing roadmap, keep issuing ES256/RS256. Track when your IdP exposes an ML-DSA
alg. Confirm your resource servers’ JWT libraries won’t hard-fail on an unknownalgvalue when that day comes, defensive parsing now saves a migration outage later.
The honest verdict
The headline oversells. Android turning on post-quantum crypto breaks almost nothing in a correctly built identity stack, hybrid key exchange was designed so it couldn’t, and because it ships through a Mainline module it arrives quietly, on its own schedule, without a sunset date hanging over your classical config. What it does is draw a bright line through your architecture: the key-agreement path just got a free, backward-compatible upgrade on the client side, and now you can see exactly which of your server endpoints refuse to accept it. The signature path, certificates, JWTs, passkey attestation, didn’t move, isn’t harvestable, and belongs on a multi-year plan.
Fix the door lock this quarter. Schedule the notary seal. And ignore anyone selling you an emergency.