I Thought Upgrading to Post-Quantum Encryption Would Cover Us. It Doesn’t.

Two years ago I got pulled into a project scoping our company's move to post-quantum cryptography. I assumed that once we swapped out the key exchange algorithm, we'd be done — box checked, quantum threat handled. A security audit later, I found out how wrong that assumption was, and it's the reason I keep writing about this instead of moving on to the next thing on my list.

What Post-Quantum Actually Upgrades

Post-quantum cryptography (PQC) is encryption designed to keep working even once quantum computers get powerful enough to break the math behind today's standards. It runs on ordinary computers, but it relies on problems that a quantum computer can't shortcut the way it can shortcut RSA or elliptic-curve Diffie-Hellman (ECDH), the two methods most systems currently use to agree on an encryption key.

Here's the part that took me longer to internalize than it should have: encryption for data-in-transit is really two separate jobs. One job is agreeing on a shared secret key between two parties who've never met — that's the asymmetric, RSA/ECDH piece, done once per session. The other job is actually encrypting the data with that key, continuously, for every byte that flows afterward — that's AES, a symmetric cipher, and at 256-bit key lengths it's already considered quantum-resistant. Quantum computers threaten the first job, not the second. Post-quantum cryptography, specifically NIST's ML-KEM standard (FIPS 203), replaces that key-agreement step. It doesn't touch AES at all.

The Standards Are No Longer a Theoretical Problem

NIST finalized its first three post-quantum standards in August 2024. ML-KEM (FIPS 203) covers key exchange — the piece most relevant to data-in-transit. FIPS 204 and FIPS 205 cover digital signatures, which verify that data actually came from where it claims to.

What changed the urgency for me wasn't the standards themselves, it was the 2026 U.S. Executive Orders on quantum technologies. They turned "you should probably get on this eventually" into actual dates: federal key establishment has to be on post-quantum cryptography by December 31, 2030, and high-impact federal systems need post-quantum digital signatures by December 31, 2031. NIST plans to retire the old RSA/ECDH-based methods entirely by 2035. If you work with, sell to, or sit anywhere in the supply chain of a federal agency or critical infrastructure operator, those dates aren't abstract anymore.

How the Rollout Actually Happens on the Ground

Nobody flips a switch on this. From what I've seen and read across a handful of migration projects, it goes in three stages. First, an inventory: mapping out where sensitive data actually flows and which systems currently handle the encryption. Second, hybrid mode — running the old and new algorithms side by side for a while, so if a flaw ever surfaces in the new post-quantum math, the connection still falls back to the proven method. Third, a gradual rollout through normal certificate and software update cycles rather than a rip-and-replace.

Most organizations right now have only gotten through the key-exchange piece. Digital-signature support is still catching up across vendors, though for high-impact federal systems that catch-up now has a hard deadline attached to it.

Do you know the fiber security question almost nobody asks during a security review? It's worth reading if your team's threat model stops at "is it encrypted."

The Gap Nobody's Migration Plan Covers

Here's what the audit actually flagged, and what I hadn't thought through: post-quantum cryptography protects future decryption. It does nothing about someone who taps your fiber today, copies the encrypted stream — including the key-exchange handshake — and just sits on it. That's called harvest-now-decrypt-later, and it's not theoretical. Once a quantum computer can eventually break the recorded RSA or ECDH exchange, whoever's holding that recording recovers the session key and decrypts everything they saved. Upgrading to ML-KEM closes that path going forward, but it does nothing for a copy already sitting on someone's drive. And fiber tapping — trunk lines, submarine cables, street cabinets — isn't a hypothetical; security researchers have documented it repeatedly.

Curious what it actually takes to make a fiber signal unrecordable in the first place, tap or no tap? Hear how one platform gets tested against that exact scenario, including a lab run where a carrier tried to break it on purpose.

About CyberRidge

The piece that closes this gap isn't cryptographic at all — it's physical. CyberRidge's Carmel platform works at the optical layer instead of the software layer: it spreads the transmitted signal across a wide spectral band, applies a constantly changing optical key, and buries the result under a layer of engineered optical noise. The upshot is that there's no coherent waveform to record in the first place, tap the fiber or don't. That's a genuinely different approach from post-quantum cryptography and quantum key distribution, both of which secure how the keys get exchanged but leave the actual encrypted payload sitting on the wire as a recordable signal. Carmel installs as a drop-in replacement for a standard transmission line card, adds no measurable latency, and CyberRidge reports typical deployments measured in weeks rather than the months or years a full protocol migration takes.

What I'd Tell My Past Self

Treat post-quantum migration and physical-layer protection as two separate projects running in parallel, not one project with two names. Get your PQC rollout moving now — inventory your data flows, start the hybrid-mode transition, and keep the federal deadlines on your calendar even if you're not a federal contractor, because vendor timelines tend to follow them anyway. Then separately, figure out which of your links actually carry data that needs to stay confidential for years or decades — financial records, health data, anything with a long shelf life — because that's the traffic already exposed to harvest-now-decrypt-later collection, regardless of how far along your cryptography upgrade is.

FAQ

Q: If I've already upgraded to post-quantum encryption, am I protected from harvest-now-decrypt-later?

A: Not fully. Post-quantum cryptography protects the key exchange going forward, but it doesn't stop someone from having already recorded your encrypted traffic before the upgrade — or from recording it today if the physical signal itself is still capturable. The recorded data stays exposed until whatever's protecting the physical transmission catches up.

Q: What's the actual difference between ML-KEM and AES?

A: ML-KEM (FIPS 203) is the new post-quantum method for agreeing on a shared encryption key between two systems — it replaces RSA and ECDH. AES is the cipher that encrypts the actual data using that key, and at 256-bit lengths it's already considered safe against quantum attacks. PQC upgrades don't touch AES; they only replace how the key gets agreed on.

Q: Does CyberRidge replace the need for post-quantum cryptography?

A: No. CyberRidge's Carmel platform operates at the physical, optical layer and is built to complement post-quantum cryptography, not substitute for it. PQC protects the keys and signatures against future quantum attacks; Carmel protects the transmitted signal itself against being recorded and stored today.

Q: How long does CyberRidge take to deploy compared to a full PQC migration?

A: CyberRidge reports that Carmel typically deploys in weeks, since it installs as a substitute for existing transmission line-card hardware rather than requiring changes across the surrounding network. A full post-quantum cryptography migration, by contrast, tends to unfold over months to years as certificates, protocols, and vendor support catch up.