Your Browser Went Post-Quantum. Your VPN Did Not.

The connection that loaded this page probably used a post-quantum key exchange. Your VPN client probably did not, and neither did the code signing certificate on the installer you shipped last quarter.

That gap is the story of the transition. The browser vendors did the hard part for web traffic, and they did it quietly enough that a lot of security teams now believe the migration is underway. It is underway for one protocol. The rest of your cryptography is exactly where it was.

What actually shipped

NIST published three post-quantum standards (opens in a new tab) in August 2024. FIPS 203 standardizes ML-KEM for key establishment, FIPS 204 standardizes ML-DSA for signatures, and FIPS 205 standardizes SLH-DSA, a hash-based signature scheme kept as a conservative alternative.

The browsers did not wait for a clean cutover, and they were right not to. Chrome and Firefox ship a hybrid key exchange that combines the classical X25519 exchange with ML-KEM, so a session survives an attack on either half. If the new algorithm turns out to have a flaw, the classical half still protects the traffic. If a quantum computer arrives, the new half protects it.

That design choice is the template for everything else. Hybrid first, because the cost of being wrong in either direction is unacceptable and the cost of doing both is a few hundred extra bytes.

Which brings up the part engineers notice.

The sizes are the engineering problem

A classical key exchange is small. X25519 public keys are 32 bytes. ML-KEM-768 encapsulation keys are 1,184 bytes, and the ciphertext is 1,088.

Signatures are worse. An Ed25519 signature is 64 bytes. An ML-DSA-65 signature is 3,309 bytes, and the public key behind it is 1,952.

For a browser that is fine. For a certificate chain, a firmware image, a smart card, or a satellite link with a tight budget, it is a redesign. A TLS handshake that now carries a few kilobytes of key material is not a problem on a data center link. It is a problem on a tactical radio, and it is a real problem for devices that were specified years before anyone in the room had heard of ML-KEM.

The algorithms are settled. The plumbing is not.

What the browser upgrade does not touch

Here is the list I would put in front of any security lead who tells me the transition is handled because Chrome updated.

Data at rest. Encrypted backups, archived records, and anything with a retention requirement past 2035. This is the harvest-now-decrypt-later problem, and it is the reason the timeline is not as long as it looks. An adversary who records your encrypted traffic today gets to decrypt it whenever the hardware arrives. The data that matters is the data that will still matter then.

Code signing. Every artifact you ship carries a signature, and every signature has a verifier that has to learn a new algorithm. This is where the long tail lives, because your verifier might be inside a customer's air-gapped environment on a build from 2019.

Authentication infrastructure. VPN concentrators, hardware security modules, certificate authorities, and the smart cards that hold credentials for people who work in facilities without phones.

Embedded and operational technology. Devices with ten-year lifecycles, no update path, and a vendor that has moved on.

None of these are affected by a browser release. All of them have to be inventoried, tested, and migrated by somebody whose name is on a schedule.

Inventory is the project, not the cryptography

You cannot migrate what you have not found, and most organizations cannot produce a list of where public key cryptography is doing work.

The federal government told agencies to build that list in 2022, in OMB memorandum M-23-02, with a submission deadline inside a year. Contractors were not handed the same instruction in a single document, but the question arrives anyway, through security assessments and through customers who have done their own inventory and now want to know about yours.

The inventory has to answer four questions per system. What algorithm is in use. Where the key material lives and who can read it. How long the protected data has to stay confidential. What the migration path is, including the vendor's roadmap if the cryptography is embedded in something you bought.

Sort by the third question, not the first. A system using RSA-2048 to protect data that is deleted after a week is a low priority. A system using the same algorithm to sign records that must be verifiable in 2040 is the reason you are doing this work.

The deadlines are closer than the phrase fifteen years suggests

NIST's transition guidance (opens in a new tab), published as a draft in November 2024, puts RSA-2048 and elliptic curve cryptography on a deprecation path after 2030 and disallows them after 2035. The National Security Agency's CNSA 2.0 guidance sets 2035 for full transition of national security systems, with earlier milestones for new acquisitions.

2035 sounds like a long time. It is one procurement cycle, one accreditation cycle, and one hardware refresh, in that order. If your refresh cycle is five years, you have two of them to get this right, and the second one has to be done before the first one's equipment is retired.

Organizations that start in 2030 will be doing an emergency migration on hardware they cannot patch, with auditors asking for a plan they do not have.

Pick one system that protects long-lived data and run the migration end to end. Not a lab. A real system, with real certificate chains, real performance measurements, and a real rollback plan. The purpose is not to migrate that system. It is to discover the four things that will go wrong at scale, while the blast radius is one system.

Then write the inventory, badly and quickly, and improve it. A rough list this quarter beats a perfect one in 2028.

Then put the requirement in contracts. Any new purchase that involves cryptography should require a documented post-quantum path and a date. That is the only lever that reaches the vendors who will otherwise ship you RSA for another decade.

The browser did its part. The rest of the estate is yours.