Why Software Encryption Can’t Keep Up With Contested, Connected Missions
September 17, 2026 | Defence, Encryption
Every mission depends on trust before it depends on speed.
The data starts moving long before people or platforms do, across the contested edge, through legacy systems built decades ago, into the hands of allies running entirely different systems. Whether that connectivity is happening isn’t the question. It already is. Whether it’s controlled, is.
The edge doesn’t wait for connectivity, and neither can the mission
Mission environments are shifting toward disconnected, compute-at-the-edge operations, a trend accelerated by lessons from recent conflicts. Distributed compute, often running on disposable, person-portable platforms, needs sub-second latency under jamming and drone-swarm conditions. That’s a demanding bar before security enters the picture at all. Add post-quantum cryptography’s packet overhead on top of a software stack that was never built for it, and the result is exactly the wrong trade-off: security that costs the mission it’s meant to protect.
This is where general-purpose software encryption runs out of road. It adds latency and becomes a bottleneck under load. It carries a large, complex attack surface that’s hard to secure and harder to audit. It wasn’t built for denial or intermittent connectivity: the default condition at the tactical edge, not the exception. And critically, it can’t be upgraded to post-quantum cryptography without a forklift replacement of the infrastructure running it.
Deterministic, not just fast
Security has traditionally meant a trade-off: stronger encryption for more latency, lower throughput, or changed application behaviour. In defence, that trade-off isn’t acceptable.
Whether protecting a radar system, a command network or an autonomous platform, operators need confidence that stronger security won’t alter timing, packet flow or system performance. That’s a different bar than “fast.” It’s deterministic performance: security that’s effectively invisible to the application, so the network behaves exactly as it always has, only with stronger protection wrapped around every packet.
Why the hardware boundary matters
Hardware-enforced Layer 3 IPsec runs at line rate with sub-millisecond latency, across any complex Layer 3 network: internet, MPLS, 5G/LTE, satellite or Starlink. Rather than routing sensitive traffic through multiple software layers, cryptographic operations are isolated inside dedicated hardware, while management and configuration functions stay separate from customer data. That separation gives security teams something software architectures rarely can: certainty about exactly where encryption happens, what protects it, and where the cryptographic boundary sits: a boundary that can be audited, not just asserted.
The crypto agility that matters here isn’t a marketing term either. The same physical appliance can move from classical algorithms, through a hybrid state, to fully post-quantum algorithms as standards mature, without replacing infrastructure or needing an engineer at the edge to do it.
Interoperable with the network you already have
None of this requires a flat, single-vendor architecture. Segmentation capabilities proven at commercial telecom scale (isolating millions of customers across multinational networks) translate directly into isolating users, systems and operational domains within defence and coalition environments. Instead of a compromise spreading laterally across a flat network, it’s contained to the segment it started in. That interoperability across coalition partners, legacy platforms and mixed Layer 3 networks is what lets hardware-enforced security sit underneath an existing estate rather than requiring a new one.
That difference compounds under contested conditions. Operators keep secure reach-back and a trustworthy operating picture even when conditions are jammed, denied or intermittent, because the security layer was built for those conditions from the start, not adapted to tolerate them.
The comparison that matters to an evaluator
| Software VPNs & firewalls | Hardware-enforced conduit | |
| Performance under load | Adds latency, becomes a bottleneck | Line-rate, sub-millisecond |
| Attack surface | Large, complex software stack | Purpose-built hardware, minimal surface |
| Denied/intermittent conditions | Not built for it | Designed for it |
| Data / management plane | Mixed together in one software stack | Physically separated, auditable boundary |
| Post-quantum readiness | Can’t be upgraded without replacement | Crypto-agile, no infrastructure swap |
| Integrity | Vulnerable to credential theft, residential proxies | Tamper-proof, attested, secure boot |
The mission moves at the speed of trust
Software encryption was never built to keep pace with a contested, connected battlespace, and retrofitting it after the fact costs more than building on hardware designed for exactly this problem from day one.
See how this plays out across coalition networks, legacy platforms and the supply chain that feeds them: download the PQC Migration Readiness Guide, orĀ Book a Sitehop demo to see how end-to-end encryption keeps data safe.
Or call us: +44 (0)114 478 2366
Sitehop. Engineered for resilience. Built for the life.

