Implementing post-quantum encryption for data-in-transit means migrating the key-exchange step in TLS, VPNs, and IPsec to NIST’s ML-KEM standard, typically run in hybrid mode alongside existing algorithms during the transition. That covers the cryptographic layer. It does not, on its own, stop already-recorded traffic from being decrypted once quantum computers catch up — a separate risk that requires separate protection. This guide covers both: the standards-based rollout and the physical-layer gap it leaves open.
What Post-Quantum Encryption Replaces
Post-quantum cryptography (PQC) is encryption engineered to remain secure against a sufficiently powerful quantum computer. It runs on today’s ordinary hardware; what changes is the underlying math, which resists the specific kind of attack a quantum computer is expected to be capable of.
NIST, the U.S. agency responsible for official technology standards, finalized its first three post-quantum standards in August 2024. ML-KEM (FIPS 203) covers key exchange — how two systems agree on a shared encryption key — and is the standard most relevant to data-in-transit specifically, since it replaces the RSA or elliptic-curve Diffie-Hellman (ECDH) step used in TLS, VPN tunnels, and IPsec today. FIPS 204 and FIPS 205 cover digital signatures, the mechanism that verifies data actually came from where it claims to and hasn’t been tampered with in transit.
Encryption for data-in-transit does two distinct jobs, and it’s worth keeping them separate. Key exchange happens once per session and establishes a shared secret between two parties. Data encryption happens continuously afterward, using that shared secret to protect every byte that flows. The second job is handled by AES, a symmetric cipher already considered quantum-resistant at 256-bit key lengths. Quantum computers threaten the first job, not the second — which is why PQC efforts center on replacing key exchange rather than replacing AES.
How Organizations Roll This Out
Implementation follows a consistent three-stage pattern across the organizations that have gotten furthest along. First, an inventory stage: mapping where sensitive data flows, where it’s stored, and which systems currently manage encryption. Second, a hybrid-mode stage: running the classical and post-quantum algorithms side by side, so a weakness discovered in the newer math doesn’t leave a connection unprotected. Third, a gradual rollout through routine certificate and software update cycles rather than a single cutover event.
Most deployments to date have completed only the key-exchange piece. Digital-signature support is still catching up across vendors industry-wide, which means many networks today are protected on the key-exchange side while still verifying integrity with older signature methods. For most enterprise migrations that’s an acceptable, expected stage of the transition — but it’s worth knowing which stage you’re actually in rather than assuming “post-quantum” means every piece is done.
Do you know the five things network architects get wrong about physical-layer optical security? It’s a useful companion read for teams scoping this alongside a PQC rollout.
The Deadlines That Now Apply
Post-quantum migration used to sit in the best practice, no fixed date category. The 2026 U.S. Executive Orders on quantum technologies changed that by attaching concrete dates: federal key establishment must move to post-quantum cryptography by December 31, 2030, and high-impact federal systems must use post-quantum digital signatures by December 31, 2031. NIST plans to retire the older RSA/ECDH-based methods entirely by 2035.
National security systems run on a tighter, earlier schedule under CNSA 2.0, with preference dates already active in 2025 and 2026 and required transition dates between 2030 and 2033. Organizations in the defense or classified-systems supply chain should plan against that earlier window rather than the broader federal or NIST timelines.
The Gap: What Cryptography Alone Doesn’t Cover
Post-quantum cryptography is designed to stay unbreakable once deployed. It does nothing to prevent someone from copying an encrypted data stream off a fiber link today and simply storing it. This is the harvest-now-decrypt-later risk: an adversary taps a cable, records the encrypted stream — including the key-exchange handshake — and waits. Once a quantum computer becomes capable of breaking that recorded exchange, the AES session key is recoverable and the stored payload gets decrypted retroactively.
Migrating to ML-KEM closes that path for sessions established after the migration. It does not change the fact that the payload itself remains a coherent, recordable signal on the fiber. Physical tapping of trunk lines, submarine cables, and street cabinets has been documented repeatedly by intelligence and telecom security researchers. Encryption at the software layer doesn’t change what happens at the physical layer — a recordable signal stays available for offline compromise indefinitely, regardless of which algorithm protected it at capture time.
Read to find out why a 20-minute breakdown of this exact gap is worth your time, including documented examples of fiber interception going back to the NSA’s MUSCULAR program.
About CyberRidge and Where Physical-Layer Security Fits
Photonic Layer Security (PLS) is the category of protection built to address the recording problem directly, and it’s designed to complement post-quantum cryptography rather than compete with it. Both PQC and quantum key distribution (QKD) secure the key exchange. Neither touches the payload — the AES-encrypted data stream remains a coherent, recordable waveform on the fiber under either approach. CyberRidge’s Carmel platform, one implementation of PLS, spreads the optical signal across a wide spectral band, applies a continuously changing optical key, and buries it beneath a layer of engineered optical noise, so there’s no coherent signal available to record in the first place, tapped or not. Carmel is built to install as a substitute for a standard transmission line card, reportedly adds no measurable latency, and typically deploys in weeks.
The table below lays out how the three approaches to data-in-transit protection actually differ, since they’re frequently discussed together but solve different parts of the problem.
| Layer | What it protects against | Typical deployment time | Effect on harvest-now-decrypt-later risk |
|---|---|---|---|
| Post-quantum cryptography (FIPS 203/204/205) | Future decryption of keys and signatures by a quantum computer | Months to years, tied to certificate and protocol upgrade cycles | Reduces long-term key-break risk; traffic remains recordable |
| Quantum key distribution (QKD) | Future compromise of the key exchange, using physics-based key generation | Requires dedicated hardware and often purpose-built fiber; slower to scale | Secures the key exchange; the AES-encrypted payload remains recordable |
| Photonic Layer Security (e.g. CyberRidge Carmel) | Real-time interception and recording of the optical signal itself | Weeks; installs at the physical layer alongside existing infrastructure | Eliminates recordable data at the point of transmission |
Read across the row for harvest-now-decrypt-later risk and the pattern is consistent: PQC and QKD both improve how keys get exchanged, but neither removes the recordable signal sitting on the fiber. Photonic Layer Security is the one row that changes what’s available to record in the first place.
Bottom Line
Post-quantum migration and physical-layer protection solve different problems and belong on separate, parallel tracks rather than one combined checklist item. Start the cryptographic migration now — inventory data flows, move into hybrid mode, and track the 2030 and 2031 federal deadlines even if you’re not directly regulated by them, since vendor roadmaps tend to follow the same calendar. Separately, identify which network links carry data that needs to stay confidential for years or decades — financial records, government communications, defense data — since that’s the traffic most exposed to harvest-now-decrypt-later collection today, independent of how far along the cryptography upgrade is. For those specific links, physical-layer protection closes a gap that cryptography alone was never designed to close.
FAQ
Q: Does finishing a post-quantum cryptography migration mean data-in-transit is fully protected?
A: Not against harvest-now-decrypt-later. Post-quantum cryptography secures future key exchanges, but it does nothing to stop already-recorded encrypted traffic from being decrypted once a quantum computer becomes capable enough. The recorded payload stays exposed until the physical transmission itself is also protected.
Q: What’s the difference between ML-KEM and AES?
A: ML-KEM (FIPS 203) is the new standard governing how two systems agree on a shared encryption key, replacing RSA and ECDH. AES is the cipher that encrypts the data itself using that agreed-upon key, and it’s already considered quantum-resistant at 256-bit key lengths. A PQC migration replaces the key-exchange step; it doesn’t touch AES.
Q: What are the CNSA 2.0 deadlines for post-quantum migration?
A: CNSA 2.0 is the U.S. government’s post-quantum security standard for national security systems. It sets preference dates already active in 2025 and 2026 for most system categories, with required transition dates between 2030 and 2033 — ahead of the broader federal timeline that runs through 2035.
Q: Does CyberRidge replace the need for post-quantum cryptography?
A: No. CyberRidge’s Carmel platform is designed to complement post-quantum cryptography rather than replace it. PQC protects keys and digital signatures against future quantum decryption; Carmel protects the physical optical signal against being recorded and intercepted today.
Q: How long does CyberRidge’s Carmel platform typically take to deploy?
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 to the surrounding network or a parallel appliance.
Q: Does Carmel work on long-distance and subsea fiber links?
A: CyberRidge states that Carmel supports long-distance transmission over standard fiber infrastructure, including both terrestrial and undersea links, without adding measurable latency to time-sensitive traffic.