Every encrypted packet crossing a battlefield network today is a potential input to a future quantum computer. Adversaries with the resources to sustain long-term signals collection operations — and with a credible path to a cryptographically relevant quantum computer (CRQC) before 2035 — are already harvesting tactical IP traffic, C2 session keys, and ISR video streams. They store that ciphertext now and will decrypt it later, once they have a machine large enough to run Shor's algorithm against the ECDH and RSA key exchanges that protect it. This is not a speculative scenario. It is a known attack strategy with a known name — harvest now, decrypt later (HNDL) — and it makes battlefield communications a primary target right now, not in 2035.

The asymmetry is stark: collection is cheap (bulk passive interception over radio or optical tap), storage is cheap (commodity disk at less than $20 per terabyte), but the strategic value of what is collected is extremely high. A year's worth of operational orders, ISR tasking, source identifications, and capability disclosures, decrypted retroactively, constitutes a comprehensive intelligence harvest of the theatre. Quantum-resilient battlefield communications are therefore not a forward-looking compliance exercise — they are an active operational security requirement.

This article maps the attack surface across tactical communication channels, walks through the concrete implementation steps for each layer (link, application, and streaming), addresses the tactical radio path, and proposes a priority order for migration based on risk and feasibility.

Why battlefield communications are the primary HNDL target

Tactical communications carry data with unusually long classification lives. Operational plans may remain classified for 25 years. Intelligence sources and methods may remain sensitive indefinitely. Capability disclosures — which systems were in theatre, what their performance parameters were, what vulnerabilities were exploited — remain sensitive long after the specific operation they describe. Compare this to commercial HNDL targets, where the classification equivalent (commercially sensitive data) typically has a useful lifetime measured in months or a few years. The long classification window means that even a CRQC emerging in 2032 or 2035 will be able to decrypt communications collected today that are still meaningfully sensitive.

Battlefield networks also have structural characteristics that make them attractive collection targets. IP-over-radio links transmit at fixed frequencies that are identifiable and monitorable. VPN gateways at forward operating bases aggregate traffic from many endpoints onto a single encrypted trunk — one collection point yields traffic from dozens of end-users. C2 API sessions are persistent and long-lived, creating stable targets for sustained collection. ISR video and telemetry streams are high-volume and continuous, making them easy to identify in collected traffic even before decryption.

Attack surface mapping: which channels are at risk

Not every communication channel is equally exposed. The channels at quantum risk are specifically those that use public-key cryptography for session key establishment — because Shor's algorithm attacks the key exchange, not the symmetric cipher. AES-256 symmetric encryption is already quantum-resistant (Grover's algorithm halves its effective key length to 128 bits, still computationally infeasible). The vulnerabilities are in the key exchange mechanisms that establish the AES session key:

IP-over-radio VPN tunnels. Tactical IP backhaul over SATCOM, HF, or UHF/VHF radio typically uses WireGuard or IPsec VPN to provide a secure IP overlay. WireGuard's handshake uses X25519 ECDH for key agreement. IPsec IKEv2 uses ECDHE or DH groups. Both are vulnerable to Shor's algorithm. Every WireGuard session established over tactical radio today is recorded and will be decryptable retrospectively.

C2 REST and WebSocket APIs. Command-and-control systems expose REST APIs and WebSocket connections to operator clients and automated consumers. These connections use TLS 1.3, which uses ECDHE for key exchange. The session establishment handshake is the attack target: once the session key is recovered, all application-layer traffic — operational orders, status reports, geo data, authentication tokens — is exposed.

ISR video streams. Full-motion video from UAV and other ISR platforms is carried over RTSP, RTP/SRTP, or WebRTC. SRTP key exchange uses DTLS, which uses the same ECDHE mechanisms as TLS. High-resolution video identifying target locations, patterns of life, and operational activities has very long classification periods and is a high-value HNDL target.

Telemetry and event streaming pipelines. Sensor telemetry, battlefield state updates, and tactical data link feeds increasingly flow through Apache Kafka or NATS clusters. Broker-to-client connections use TLS 1.3. In multi-site architectures, inter-cluster replication uses TLS. These pipelines carry continuous, high-fidelity operational pictures that are valuable both individually and as a historical record.

Encrypted voice over IP. VOIP calls using SDES-SRTP or ZRTP key exchange share the same ECDH vulnerability as video streams. Voice traffic is lower bandwidth but carries human-intelligence-quality information — commander intent, source conversations, technical discussions — that has very high strategic value per byte.

Link layer hardening: post-quantum WireGuard with ML-KEM

The VPN gateway aggregating IP-over-radio links is the highest-leverage single point for post-quantum hardening. A single deployment at the gateway protects all downstream radio-attached clients without requiring firmware or configuration changes on individual radio endpoints.

WireGuard's handshake protocol is elegantly minimal, which makes adding post-quantum key encapsulation straightforward. The Open Quantum Safe project (liboqs) provides a production-capable C library implementing NIST PQC algorithms including ML-KEM (FIPS 203, CRYSTALS-Kyber). The OQS-WireGuard fork patches WireGuard-Linux to add a hybrid post-quantum handshake: alongside the standard X25519 ECDH key exchange, each peer also runs ML-KEM-768. The session key is derived from the output of both KEMs using a combined HKDF. This hybrid construction means the session is protected as long as either X25519 or ML-KEM remains computationally secure — it does not weaken classical security while adding quantum resistance.

The implementation path for a tactical VPN gateway: build the OQS-WireGuard kernel module against your gateway OS kernel; configure WireGuard peers with the hybrid handshake enabled; set ML-KEM-768 as the post-quantum KEM (the CNSA 2.0 compliant choice — ML-KEM-1024 is also available if CNSA 2.0 strict compliance is required); verify that packet captures of the handshake show the extended key_share fields. The per-session handshake overhead of ML-KEM-768 is approximately 2.3 KB in added key exchange material — negligible compared to the data transferred during even short sessions.

For IPsec IKEv2 deployments using StrongSwan or similar, the strongSwan project has PQC plugin support for ML-KEM via liboqs. The configuration pattern is similar: add a post-quantum KEM proposal to the IKE SA proposal list alongside the existing ECDHE group.

Application layer: post-quantum TLS 1.3 for C2 REST and WebSocket APIs

Post-quantum TLS 1.3 is the most mature post-quantum deployment path and the one with the most library support. The IETF hybrid key exchange group X25519MLKEM768 (formerly known as X25519Kyber768Draft00 during standardisation) combines X25519 ECDH with ML-KEM-768 in a single TLS key_share extension. This group is supported in OpenSSL 3.x with liboqs, in BoringSSL, and in the Rustls post-quantum branch. Cloudflare, Google, and other major TLS operators have already deployed this hybrid in production at scale — the algorithm is proven at high traffic volumes.

For C2 backends written in Go, Java, or Python, the migration path is: upgrade the TLS library to a version with liboqs integration; set the preferred cipher suite list to include X25519MLKEM768 before the classical ECDHE groups; configure the server to advertise the hybrid group in its ServerHello; update CI to run an OQS test client against the server to confirm hybrid negotiation. For Java C2 applications using the JCA/JCE cryptographic framework, the Open Quantum Safe Java provider (oqs-provider) plugs into the standard JCA interface, minimising application-level changes.

Certificate authentication — the TLS client and server certificate validation — uses ECDSA or RSA signatures today. Migrating certificate signatures to ML-DSA (FIPS 204, CRYSTALS-Dilithium) is a larger change that requires updating the PKI. During the transition period, you can run a dual-algorithm configuration: the TLS key exchange is post-quantum (via hybrid ML-KEM), while certificate signatures remain ECDSA. This gives you HNDL protection immediately — since it is the key exchange, not the certificate signature, that is targeted in HNDL attacks — while the PKI migration proceeds in parallel.

Implementation note: The TLS key exchange is the HNDL target, not the certificate signature. Migrating to hybrid ML-KEM in your TLS cipher suite provides immediate HNDL protection even before your PKI migrates to post-quantum signatures. Do not wait for complete PKI migration before deploying post-quantum TLS — they are independent mitigations on different timelines.

Streaming layer: post-quantum telemetry and ISR pipelines

Event streaming infrastructure — Apache Kafka clusters, NATS JetStream deployments — carries continuous battlefield state data that has both immediate tactical value and long-term intelligence value as a historical record. Post-quantum hardening at the streaming layer follows the same TLS upgrade path as C2 APIs, but with some operational considerations specific to high-throughput streaming.

For Kafka, TLS is configured separately on broker listener, inter-broker replication, and Kafka Connect worker connections. Each must be individually upgraded. On the broker side, set ssl.cipher.suites to include the hybrid ML-KEM cipher suite and configure the JVM with the OQS provider. On the producer and consumer side, apply the same cipher suite configuration in the Kafka client properties. In multi-datacenter deployments with MirrorMaker 2 replication, upgrade the MirrorMaker2 connector's TLS configuration as well — inter-site replication tunnels carry the complete topic data and are equally exposed.

For ISR video, the DTLS handshake in WebRTC and RTSP/SRTP carries the SRTP master secret that protects the media stream. Upgrading the DTLS stack of the media relay or TURN server to use hybrid ML-KEM closes the HNDL exposure on the key exchange. For very high-assurance scenarios, wrap the entire SRTP stream inside the post-quantum VPN tunnel — defence in depth that protects even if the DTLS upgrade has not yet been applied to a specific endpoint.

Read more about securing the streaming layer in our article on post-quantum cryptography for defense and CNSA 2.0, which covers algorithm selection and parameter requirements for NSS-grade streaming infrastructure.

Tactical radio path: current waveforms and the path forward

The tactical radio path presents a different challenge. Radio waveforms — SINCGARS, MUOS, SATURN, Link 16, and STANAG variants — embed cryptographic primitives in hardware security modules or waveform firmware that cannot be upgraded via software patch. The NSA Type 1 encryption devices used in these waveforms implement NSA-approved classical algorithms in hardware. Migrating these to post-quantum cryptography requires either a new waveform version certified under the NSA Type 1 process, or hardware refresh with new devices.

Both paths have multi-year lead times. The NSA waveform certification process for a new algorithm is not a matter of months. Hardware refresh programmes for deployed tactical radio fleets span years and require programme-of-record budget. For the current planning horizon, the practical approach is not to wait for post-quantum radio waveforms but to ensure that classified data carried over the radio path is encrypted before it enters the radio at a higher layer. The post-quantum VPN gateway approach from the link-layer section implements this correctly: the IP payload is post-quantum-protected before the radio link encrypts it with classical Type 1 encryption. The radio link's classical encryption is an additional layer of protection, not the primary protection.

Programmes should record the tactical radio path as a known quantum-vulnerable segment in the system's risk register, with a planned hardware-refresh date and a dependency on NSA waveform certification. This is not a gap to be resolved immediately — it is a structured technical debt item with a known remediation path.

For new programme acquisitions, require that radio terminals support software-defined radio (SDR) architectures capable of in-field waveform update, and specify post-quantum waveform support as a programme requirement from the outset.

Priority order: maximum risk reduction with available tools

Given the implementation complexity and lead times involved, programmes should prioritise quantum-resilient battlefield communications in this order:

1. C2 REST/WebSocket APIs. Highest strategic value per byte of traffic, easiest to migrate (software-only change on both server and client), fastest time to deployment. The session key material from C2 APIs is the most valuable HNDL target — operational orders, authentication tokens, position data. Migrate first.

2. VPN gateways aggregating IP-over-radio links. Single chokepoint, strong leverage — one deployment protects many downstream endpoints. Deploy the hybrid WireGuard gateway immediately.

3. Event streaming pipelines (Kafka, NATS). High data volume, high collective intelligence value as a historical record. TLS upgrade applies uniformly across the cluster.

4. ISR video and SRTP streams. High classification lifetime, large per-stream data volume. DTLS upgrade plus VPN-wrapping as defence in depth.

5. Encrypted voice over IP. Lower data volume than video but high intelligence density. Upgrade DTLS/SRTP key exchange on VOIP infrastructure.

6. Tactical radio waveforms. Longest lead time, requires hardware/programme-of-record action. Address through VPN-layer pre-encryption now and plan hardware refresh for the medium term.

For a broader view of how zero-trust architecture integrates with post-quantum cryptography at the network perimeter, see our article on zero-trust architecture for military networks. For deployment patterns in air-gapped tactical environments, see air-gapped deployment for defense software.

Corvus.Quantum: post-quantum streaming for tactical networks

Corvus.Quantum is the streaming-layer component that Corvus Intelligence deploys in tactical and near-edge environments requiring post-quantum event streaming. It provides a hardened Kafka-compatible event bus with hybrid ML-KEM TLS configured out of the box, operator-controlled key rotation, and support for disconnected and intermittently connected network segments — a common operational requirement in forward-deployed configurations.

The streaming layer is often the last component considered in a post-quantum migration and the first to accumulate HNDL exposure, because telemetry and event streams run continuously and at high volume. Corvus.Quantum closes this gap by delivering a streaming broker that is post-quantum by default — TLS cipher suite, inter-broker replication, and Kafka Connect worker connections all negotiate hybrid ML-KEM rather than classical ECDHE, without requiring individual tuning of each component.

Corvus.Quantum has been validated in active operational environments in Ukraine, where post-quantum streaming resilience is not a compliance requirement but an operational necessity. Adversary signals collection capabilities in that theatre are sustained and technically sophisticated — the HNDL threat model is not hypothetical for programmes operating in or preparing for high-end peer competition.

Corvus.Quantum delivers post-quantum event streaming for tactical and near-edge environments — hybrid ML-KEM TLS configured by default, validated in active high-threat operational contexts. If your battlefield communications programme is scoping a post-quantum migration for telemetry and ISR streaming pipelines, we can walk through the deployment architecture and integration path with your existing C2 and sensor stack.

Explore Corvus.Quantum →

Related articles