Quantum ready is not quantum resistant
There is a question every security team should be able to answer and almost none can: what is the shelf life of your data?
Not the retention policy. The real shelf life. The number of years the things you encrypt today must remain secret. Health records, ten to fifty years. Identity documents, a lifetime. Land registries and legal contracts, longer than that. State secrets, decades by law.
Now put that number next to this one: most estimates place a cryptographically relevant quantum computer somewhere between ten and twenty years away. Some say sooner. Nobody serious says never.
If your data must stay secret for thirty years and the algorithm protecting it falls in fifteen, you are already late. And there is a whole discipline built on exactly that arithmetic: harvest now, decrypt later. Record the encrypted traffic today, store it cheap, open it when the hardware arrives. The attack on your 2026 data may have already happened. You will find out in 2040.
This is the backdrop for a strange moment we are living through, and the reason I want to draw a line between two phrases that sound identical and are not.
Are we quantum ready? Yes. Are we quantum resistant? No.
What “ready” looks like
In August 2024, NIST finalized the post-quantum standards: FIPS 203 (ML-KEM, for key exchange) and FIPS 204 (ML-DSA, for signatures). Lattice mathematics instead of the factoring and discrete-log problems that a quantum computer eats for breakfast. That was the starting gun.
What happened next went mostly unnoticed outside a small circle.
In September 2025, iOS 26 shipped with ML-DSA support inside the Secure Enclave. Not as a software library. Inside the security chip. CryptoKit now offers SecureEnclave.MLDSA65 with the same API shape developers have used for years with P-256 keys.
Android followed in June 2026: Android 17, released on the 16th, exposes ML-DSA to applications through the Keystore, backed by KeyMint in the device’s secure hardware, through the same Java crypto APIs developers already use. As I write this, that release is one month old.
Read that again: the phone in your pocket, if it is recent, already has NIST-standardized post-quantum cryptography implemented in silicon. Not a lab prototype. A shipping consumer product. That is what quantum ready means, and by that measure we arrived faster than almost anyone predicted.
Why the chip matters more than the algorithm
The detail that makes this genuinely new is not the algorithm. It is where the key lives.
When an ML-DSA key is generated inside the Secure Enclave, the private key never exists in the phone’s memory. Not during generation, not during signing, not ever. What the app stores is an opaque encrypted blob that only that specific chip can reload. Dump the entire memory of the process and you get nothing. Steal the blob and you get nothing, because it is useless outside the enclave that created it.
And the biometric check is not an if-statement in application code, the kind of check malware hooks and skips. The chip itself refuses to sign without a fresh Face ID or fingerprint, enforced below the operating system.
For thirty years, the weakest point of cryptography has not been the math. It has been custody: keys in files, keys in memory, keys in backups, keys in the hands of whoever compromised the process. The combination of post-quantum algorithms with hardware custody closes both doors at once. That combination became possible on consumer devices about a year ago.
Why “resistant” is still far away
So why do I insist we are not quantum resistant? Because primitives are not systems.
The operating system offering an algorithm is chapter one. Everything above it still has to migrate: TLS stacks, certificate authorities and the entire PKI chain, code signing, document signatures, messaging protocols, database encryption, backend HSMs, and every application that today calls an RSA or ECDSA function without knowing it.
The platforms themselves are half-finished. Android exposes ML-DSA to apps but, for now, not ML-KEM: the algorithm is already present in KeyMint, used for attestation and TLS, just without an app-facing API yet. That door will most likely open in a future Android release, but “most likely” and “future” are doing real work in that sentence. iOS decapsulates ML-KEM inside the enclave today; Android does not. Anyone building cross-platform right now has to engineer around that asymmetry, and most teams have not started.
The hardware floor is high. Post-quantum in the Secure Enclave needs an iPhone 15 Pro or later. Fleet turnover takes years. Governments and enterprises run device populations that are five, seven, ten years old.
Get J Caso’s stories in your inbox
Join Medium for free to get updates from this writer.
And there is a quieter gap, one I know firsthand: the distance between claims and verification. I have verified post-quantum signing on physical iOS hardware. On Android I have only verified it on an emulator, where the secure hardware is simulated, because real Android 17 devices are only now appearing. The code is correct. The hardware guarantee is not yet demonstrated. Those are different statements, and an industry that confuses them is building on sand.
The price, in bytes
Migration has a cost you can see with your own eyes. These are real numbers from a production identity wallet (Veridian ID) that I work on, comparing the classical signature suite with the post-quantum one:
An Ed25519 public key is 32 bytes. An ML-DSA-65 public key is 1,952. An Ed25519 signature is 64 bytes. An ML-DSA-65 signature is 3,309. Step up to ML-DSA-87 and the signature reaches 4,627 bytes.
Roughly fifty times larger. That sounds alarming until you put it in context: 3 KB rides inside a single network packet’s neighborhood, phones sign it in milliseconds, and the enclave does it without breaking a sweat.
Where it does hurt is anywhere bytes are priced or protocol-constrained. Blockchains pay per byte of on-chain data, so a 50x signature is a 50x fee and a 50x block footprint. TLS handshakes carry certificate chains, and chains of 2 KB keys add up. Constrained IoT devices feel every kilobyte.
The honest summary: for most systems the overhead is acceptable and the engineering is routine. For byte-priced systems it forces real design decisions. Either way it is a known, bounded cost, which is more than can be said for the alternative.
What migration actually looks like
If you run security for an organization, “install the update” is not the plan. The plan looks like this, and the order matters.
First, inventory. You cannot migrate cryptography you cannot list. Most organizations discover they do not know where their keys are, what algorithms sign what, or which vendor products embed which primitives. This step is unglamorous and takes the longest.
Second, classify by shelf life. Data that must remain secret past 2035 gets migrated first. That is why health systems, identity providers, land registries and governments are not spectators in this: they hold precisely the data whose lifetime exceeds the algorithm’s.
Third, build crypto-agility before building crypto. If your system can only swap algorithms by rewriting applications, the next transition will be as painful as this one. Abstract the primitive. Identity systems designed around key rotation, like KERI, migrate by rotating to a post-quantum key. Systems that welded one key to one identity for eternity, like classic certificate hierarchies, have a much harder decade ahead.
Fourth, go hybrid first. Classical plus post-quantum together, so a break of either leaves you standing. Browsers already do this for TLS key exchange. Signatures can follow the same pattern.
Fifth, put the new keys in hardware from day one. The migration is a rare chance to fix custody at the same time as the algorithm. A post-quantum key in a file on disk repeats the oldest mistake in the field with a newer algorithm.
The deadlines are not hypothetical. NIST’s transition guidance points at deprecating today’s public-key cryptography around 2030 and disallowing it by 2035. For national security systems the schedules are already mandatory. 2035 sounds far away until you remember that the average enterprise cryptographic migration, historically, takes about a decade. The window is not future. It is now, and it is barely wide enough.
If you want the whole landscape on one page, this is the map I keep coming back to:
Where I got my hands dirty
Theory convinces nobody. To understand the real state of this, I built the missing piece I needed: an open-source plugin that gives hybrid mobile apps (Capacitor) post-quantum signing and key encapsulation with the private keys held in the iOS Secure Enclave and the Android Keystore, biometric-gated per operation. MIT licensed.
Building it is how I learned everything above. The iOS half was almost boring, which is the highest compliment a security API can receive. The Android half taught me why we are further from resistance than the announcements suggest, including a subtle biometric-bypass pattern (GHSA-vx5f-vmr6–32wf) that a surprising amount of shipping code gets wrong.
The technical deep-dive, including the code and the honest list of what I have and have not been able to verify on hardware, is here:
Technical writeup: https://dev.to/jcaso/post-quantum-signing-keys-that-never-leave-the-secure-enclave-1g88
Open Source: https://github.com/jimcase/capacitor-pq-secure-storage
NPM Package: https://www.npmjs.com/package/capacitor-pq-secure-storage
The question to take home
Quantum ready happened quietly, in a chip inside your phone, while nobody was watching. Quantum resistant will not happen quietly. It will take inventories, budgets, vendor pressure, protocol redesigns and a decade of unglamorous work, and the organizations that start while it is cheap will be indistinguishable, in 2035, from the ones that started too late. Except in one way: whose secrets are still secret.
So, one question for your next security review: what is the shelf life of your data, and does it end before 2035?
If the answer is no, the migration is not a future project. It is a current one.
