How Do You Implement Post-Quantum Encryption for Data-in-Transit?

A practical walkthrough of the standards, steps, and physical-layer options for protecting data-in-transit before quantum computers can break today's encryption - and where cryptographic upgrades alone fall short.

‍‍

‍

NIST, the U.S. government agency that sets official technology standards, finalized its first three post-quantum encryption standards in August 2024. The one most relevant to data-in-transit, FIPS 203, also known as ML-KEM, is what most vendors are now adopting to replace the methods currently used to securely exchange encryption keys online. NIST plans to retire them completely by 2035. The 2026 U.S. Executive Orders on quantum technologies made this concrete: by December 31, 2030, federal key establishment must move to PQC, and by December 31, 2031, high-impact federal systems must use PQC digital signatures. This turns what was guidance into a countdown for agencies, contractors, and critical infrastructure.

However, post-quantum encryption only protects against future decryption; it doesn't stop someone from recording your encrypted traffic today and holding onto it until they can break it, a risk known as harvest-now-decrypt-later. CyberRidge's Carmel platform closes that specific gap by encrypting data at the physical, optical layer: the transmitted signal itself becomes optical noise, so there is nothing coherent to record - unlike conventional Layer 1 encryption, which still leaves a recordable waveform on the fiber.

Post-quantum cryptography (PQC) refers to encryption designed to stay secure against future quantum computers. It runs on the regular computers we use today, but relies on new mathematical problems that a powerful quantum computer can't easily solve, replacing vulnerable standards like RSA and ECDH. Organizations implement post-quantum encryption for data-in-transit by adopting NIST's ML-KEM (FIPS 203) for key exchange in TLS 1.3, VPNs, and IPsec, typically run in hybrid mode alongside existing classical algorithms during the transition period. That covers the cryptographic layer. The important nuance is that PQC secures the keys and signatures, not the physical act of interception, so a full data-in-transit security strategy also has to account for traffic that gets tapped and stored today, before any algorithm is broken. The rest of this article covers both pieces: the standards-based rollout and the physical-layer protection that closes the recording gap.

‍

What Post-Quantum Encryption for Data-in-Transit Actually Means

Post-quantum cryptography (PQC) replaces algorithms like RSA and elliptic-curve Diffie-Hellman, the two methods most computers use today to securely agree on encryption keys online, with math that resists attacks from a sufficiently powerful quantum computer. NIST, the U.S. government agency responsible for setting official technology standards, finalized three post-quantum standards that cover the two basic jobs encryption needs to do. One standard, called ML-KEM (FIPS 203), handles how two computers securely agree on a shared encryption key. The other two, FIPS 204 and FIPS 205, cover digital signatures, the method used to verify that data really came from where it claims to and hasn't been altered.

For data-in-transit specifically, ML-KEM is the standard that matters most, since it replaces the key exchange step in TLS, VPN tunnels, and IPsec that today relies on RSA or ECDH. It helps to separate the two jobs encryption does for data-in-transit. The data payload itself is encrypted with AES, a symmetric cipher that is already considered quantum-resistant at 256-bit key lengths. What quantum computers threaten is the key exchange - the RSA or elliptic-curve step where both sides agree on that AES key. PQC (ML-KEM) and quantum key distribution (QKD) are both answers to the key-exchange problem, not replacements for AES. In other words, the industry's entire post-quantum effort upgrades how keys are agreed, the encrypted payload traveling on the fiber stays exactly as recordable as before

	Asymmetric Cryptography (Key Exchange)	Symmetric Cryptography (Data Encryption)
The role	Establish a secure channel between two parties who have never met. Authenticate identity. Exchange a shared secret key.	Encrypt the actual data flowing through the channel, using the shared secret key.
How it's used	Once per session — during the handshake.	Continuously — for every byte of data after the handshake.
Why it's needed	Two strangers can't share a secret over an open channel without it.	Asymmetric is far too slow to encrypt bulk data.
Example algorithms	RSA, ECDH, Diffie-Hellman	AES-256

How Organizations Actually Roll This Out

First, security and network teams take inventory: they map out where sensitive data flows, where it's stored, and which systems currently handle encryption. Second, most organizations run the old and new encryption methods side-by-side for a while, a practice called hybrid mode, so that if a problem ever turns up in the new post-quantum math, traffic is still protected by the older, proven method as a backup. Third, teams roll the new standard out gradually, through normal software and certificate updates, rather than replacing everything at once.

Right now, most organizations have only upgraded the key-exchange piece. Support for the new digital-signature standards is still catching up, though for high-impact U.S. federal systems, that catch-up now has a hard date: PQC digital signatures are required by December 31, 2031. Many networks today are only partly upgraded: protected by post-quantum key exchange but still using older methods to verify that data hasn't been tampered with.

The Limit: PQC Protects Future Keys, Not Today's Captured Traffic

Post-quantum cryptography is designed to stay unbreakable once deployed, but it does nothing to stop someone from copying encrypted traffic off a fiber link today and storing it. This is the harvest-now-decrypt-later threat: an adversary taps a cable, records the encrypted stream, including the key-exchange handshake, and waits. Once a quantum computer can break the recorded RSA or ECDH exchange, the adversary recovers the AES session key and decrypts the stored payload. Upgrading to ML-KEM is considered to close that path for future sessions, but the payload itself remains a recordable signal on the wire. 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 does not change what happens at the physical layer: if the signal can be recorded, it is indefinitely available for offline compromise, regardless of which algorithm protected it.

For a closer look at why PQC and quantum key distribution both still leave a recordable data stream on the wire, and what closing that gap actually requires at the physical layer, see Closing the Harvesting Gap.

Where Photonic Layer Security Fits Alongside PQC

Photonic Layer Security (PLS) is a category of physical-layer protection that addresses the recording problem directly, complementing PQC rather than replacing it. PQC and QKD both secure the key exchange. Neither touches the payload: the AES-encrypted data stream is still a coherent, recordable waveform on the fiber. PLS is the only layer that protects the payload transmission itself, which is why it complements either approach rather than competing with them.

Photonic Layer Security solutions such as CyberRidge's Carmel platform, address the recording problem directly; it complements PQC rather than replacing it. PQC and QKD both secure the key exchange. Neither touches the payload: the AES-encrypted data stream is still a coherent, recordable waveform on the fiber. Carmel is the only layer that protects the payload transmission itself, which is why it complements either approach rather than competing with them. Carmel spreads the optical signal across a wide spectral band, encodes it with a constantly changing optical key, and buries it below a controlled layer of amplified spontaneous emission noise. Harvested data becomes unrecoverable without the exact key at the exact moment of transmission. Furthermore, there is no raw data on the wire to harvest, quantum computer or not. Carmel installs as a drop-in replacement for the transmission line card, adds no latency, with typical deployment in weeks.

Layer	What it protects against	Deployment time	Effect on HNDL risk	Why it matters
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 but traffic remains recordable	Required baseline for standards compliance (NIST, CNSA 2.0)
Quantum key distribution (QKD)	Future compromise of the key exchange, using physics rather than complex algorithms to generate and share keys	Requires dedicated hardware and often purpose-built fiber; slower and costlier to deploy at scale than PQC	Secures the key exchange, but the AES-encrypted payload remains recordable	An alternative path to solving the key-exchange problem, not a payload-level fix
CyberRidge Carmel (Photonic Layer Security)	Real-time interception and recording of the optical signal itself	Weeks; installs at the physical layer, complementary to existing stack (CyberRidge reports this figure)	Eliminates recordable data at the point of transmission	Closes the harvest-now-decrypt-later gap that cryptography alone cannot

Practical Takeaways for Security Teams

Treat the two layers as complementary, not a choice between one or the other. Start your post-quantum migration now: find out where your sensitive data flows and start moving your systems over to the new encryption standards. Keeping the U.S. deadlines in mind - federal key establishment must be on PQC by December 31, 2030, high-impact federal systems need PQC signatures by December 31, 2031, NIST fully retires the old algorithms by 2035, and national security systems run on the even earlier CNSA 2.0 track. Alongside that, figure out 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. For those links, physical-layer protection like Carmel closes the recording gap that upgrading your encryption alone won't fix.

Have a network carrying data that needs to stay confidential for decades? Visit CyberRidge to see how Photonic Layer Security complements a post-quantum cryptography rollout.

‍

FAQs

Q: Is post-quantum encryption enough to stop hackers from reading my data later?

A: No. Post-quantum encryption protects the keys used to lock up your data, but it doesn't stop someone from copying the encrypted traffic as it travels and saving it. If your traffic gets captured and stored, it's still sitting there waiting to be cracked open later, no matter how strong the encryption algorithm. CyberRidge's Carmel closes that gap by making the signal itself impossible to record in the first place.

Q: What is ML-KEM?

A: ML-KEM is the new government-approved method (officially FIPS 203) for two computers to securely agree on an encryption key, replacing older methods like RSA and elliptic-curve Diffie-Hellman. It's the piece of post-quantum encryption most relevant to protecting data-in-transit, and most companies are currently rolling it out alongside their existing encryption rather than switching over all at once.

Q: How long does it take to deploy CyberRidge's Carmel?

A: Carmel typically deploys in weeks, since it installs as a drop-in replacement for existing transmission equipment without requiring changes to the surrounding network.

Q: Does CyberRidge replace post-quantum encryption, or work alongside it?

A: Carmel works alongside post-quantum encryption and other digital encryption methods, not in place of them. Post-quantum encryption protects your keys against future quantum attacks; Carmel protects the physical signal itself against being recorded and intercepted today.

Q: What is the CNSA 2.0 deadline 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 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 Carmel work on subsea and long-distance fiber links, not just short ones?

A: Yes. CyberRidge states that Carmel supports long-distance transmission over standard fiber infrastructure, including both land-based and undersea links.

Q: Does photonic layer security slow down my network?

A: CyberRidge reports zero added latency, since Carmel’s photonic layer security processes data in-line, in real time, without holding, queuing, or buffering it.

Q: What deadlines did the 2026 Executive Orders set?

A: By December 31, 2030, U.S. federal key establishment must move to post-quantum cryptography, and by December 31, 2031, high-impact federal systems must use PQC digital signatures. These are binding federal deadlines, ahead of NIST's broader 2035 retirement date."

‍