Quantifying the network impact of hybrid post-quantum cryptography
The bandwidth cost of hybrid post-quantum key exchange in TLS is not unknown. Cloudflare, Google and Apple have published handshake-size data from production deployments since 2023, and the relevant figures are derivable directly from FIPS-203 and FIPS-204. The cost is, however, rarely propagated through to enterprise capacity planning, and the resulting impact at the network choke points least able to absorb it is therefore not generally part of migration plans. The arithmetic for a 5,000-user organisation is set out below.
1. Handshake-size delta
Three handshake configurations are compared in Table 1: a classical baseline using X25519 with ECDSA P-256, the production hybrid construction X25519MLKEM768 with classical signatures retained, and a fully post-quantum profile using ML-KEM-768 alongside ML-DSA-65 for authentication. Sizes are taken from the relevant NIST specifications and from the IETF hybrid TLS draft.
Two consequences of the larger handshake are not captured by the byte count alone. The hybrid ClientHello no longer fits within a single 1,460-byte TCP MSS, which causes the server to issue a HelloRetryRequest more frequently and adds a round-trip to a non-trivial fraction of new connections. In QUIC, the anti-amplification rule (RFC 9000 §8.1) limits the server to three times the bytes received from the client until address validation is complete; under a 1,700-byte ClientHello this constraint can stall the handshake by one packet, where TLS 1.3 over QUIC previously had a comfortable margin.
2. Aggregate load for a reference enterprise
Browser telemetry studies place the rate of new TLS handshakes for a typical knowledge worker at approximately 1,500 to 3,000 per day, with the upper figure reflecting heavy SaaS use, multiple persistently active browser tabs, collaboration applications such as Teams and Slack, and a corporate-managed mobile device on the same network. Session resumption reduces this materially within a session but not across day boundaries, network changes, or cross-origin requests, the last of which dominates modern web traffic.
For a 5,000-user organisation at a working figure of 2,000 new handshakes per user per day:
Total new handshakes: 10 × 10⁶ per day
Hybrid KEM: 10⁷ × 2.3 KB × 2 directions ≈ 46 GB/day
Full PQC: 10⁷ × 14 KB × 2 directions ≈ 280 GB/day
These daily totals are not, in themselves, alarming. A 1 Gbps internet egress link carries approximately 10 TB per day at full utilisation, so the hybrid figure represents an increment of less than one half of one percent of the link’s daily capacity. The relevant question is the distribution of the load across the working day.
Enterprise traffic is not uniformly distributed. Working hours concentrate handshake volume into approximately nine hours of any given day, and within that window the 09:00–10:00 period (particularly on Mondays) sees a peak that exceeds the working-hours mean by a factor of three to four. The peak is driven principally by VPN reconnection, mailbox synchronisation, intranet authentication, and SSO token issuance for the day’s SaaS estate. Under a peak factor of 3.5×, the 46 GB/day hybrid figure resolves to approximately 36 Mbps of continuous added load during the busiest hour, and the 280 GB/day full-PQC figure to approximately 240 Mbps.
3. Network choke points
The peak-hour figure becomes a capacity question at four points in a typical enterprise network, each with a distinct failure mode.
3.1 Perimeter firewall
Modern enterprise firewalls are sized against two parameters: steady-state throughput, and packets-per-second or sessions-per-second at peak. The PQC delta increases both, but it changes the connection-establishment profile disproportionately. Larger handshakes mean more state held per active session, which raises session-table occupancy. Devices configured for a 70% session-table watermark have been observed to exceed 90% under PQC traffic at unchanged user counts. A secondary effect concerns TLS-aware anomaly detection: signatures tuned to flag unexpected increases in TLS bytes-per-flow generate false positives during the migration window, with consequent operational overhead.
3.2 VPN concentrator
The most pronounced impact, and the impact most often underestimated, is at the VPN concentrator. IKEv2 with post-quantum key exchange (the active drafts include draft-kampanakis-ml-kem-ikev2 and a number of vendor pre-standards extensions) inflates the IKE_SA_INIT and IKE_AUTH messages by approximately an order of magnitude. Where classical IKEv2 fits within two UDP datagrams, the PQC variant fragments routinely. The concentrator therefore performs both the larger key exchange and the reassembly of fragmented IKE messages.
The binding constraint at the concentrator is generally not bandwidth but CPU cycles spent on IKE processing. Connection-storm CPU profiles, particularly during a Monday-morning reconnection event, sustain at high utilisation for materially longer than the classical equivalent. A concentrator engineered for a classical-IKE Monday peak at the same user count can therefore exceed its CPU design point post-migration even when its bandwidth utilisation remains within margin.
3.3 Constrained network segments
Branch-office circuits, MPLS tail links, satellite-served sites, and certain industrial network segments operate close to their committed information rate during business hours. The absolute byte increase from PQC is small at these sites, but the available headroom is correspondingly small. Sites operating at a few percent of margin under classical loads can lose that margin entirely.
3.4 Remote-worker last mile
The remote-worker case differs from the others in that the binding constraint is latency rather than bandwidth. The additional 2.3 KB to 14 KB per handshake adds at most a single round-trip on a thin or congested home connection, but the user-visible cost is the few hundred milliseconds added at points of highest user attention, principally application launch and call join. This case is the earliest indicator of difficulty in a phased rollout, and is therefore the appropriate population for an initial pilot.
4. Peak-hour amplification
The aggregate-to-peak relationship is the central non-linearity. The added handshake bandwidth is itself concentrated into the peak hour at the same multiplier as the underlying traffic, with the consequence that the increment lands precisely where headroom is tightest. The figure of merit for capacity planning is therefore not the daily mean but the peak-hour Mbps added at each individually constrained device.
A worked example illustrates the point. Consider a 5,000-user organisation with 30% remote workers, on hybrid KEM, at a peak factor of 3.5×. The 1,500 remote users account for approximately 3 × 10⁶ handshakes per day, yielding roughly 12 Mbps of additional load on the VPN concentrator at peak. On a 500 Mbps concentrator already at 75% peak utilisation, this is an increase of 2.4 percentage points — operationally absorbable. The same calculation under full PQC yields approximately 72 Mbps at peak, an increase of 14 percentage points, which moves the device from 75% to 89% peak utilisation. Combined with the IKE CPU saturation effect described in §3.2, the practical effect can be considerably larger than the bandwidth figure alone suggests.
5. Three illustrative scenarios
Three concrete scenarios surface the peak-hour effect in operationally familiar terms.
The Monday-morning login storm is the canonical case. With 5,000 users of whom approximately 30% are remote, simultaneous reconnection within a 30-minute window concentrates VPN handshake load to a degree that the IKE handler on the concentrator becomes the binding constraint, and the firewall’s TLS-inspection capacity becomes the secondary constraint. The user-visible symptom is slow application launch, frequently misattributed to the identity provider rather than to the underlying network capacity event.
The all-hands video event presents a different load profile. The media stream itself is unchanged from the classical-cryptography case, but the synchronised join opens multiple simultaneous TLS connections per user — to the conferencing service, to the identity provider, to telemetry endpoints, and to CDN edges. The aggregated handshake burst can briefly saturate egress capacity in a manner the steady-state design did not anticipate, with packet-loss and retry behaviour observable in the conference quality metrics.
The third scenario concerns WAN refresh decisions. A branch circuit specified in 2022 against a classical-cryptography traffic baseline now requires approximately 10–15% additional capacity at peak to deliver equivalent application responsiveness. Total cost of ownership models with refresh dates beyond 2026 require revision against the post-migration traffic profile.
6. Implications for migration sequencing
The network cost of hybrid KEM is approximately one-quarter of the cost of full post-quantum authentication. The harvest-now-decrypt-later threat is addressed primarily by the KEM upgrade; signature replacement protects against future authentication forgery but does not retrospectively secure traffic. A migration sequence that deploys hybrid KEM enterprise-wide and defers ML-DSA authentication until the network estate has been refreshed against post-PQC capacity requirements is therefore both cryptographically defensible and operationally less disruptive than a single-step migration to a fully post-quantum profile.
The empirical inputs required for the analysis above are weak in most enterprise environments. Few organisations have current measurements of new-handshakes-per-user-per-day, of peak-hour VPN concentrator load disaggregated into IKE processing and tunnel traffic, or of session-establishment headroom on the perimeter firewall. None of these measurements is technically difficult to obtain. The cost of obtaining them after migration has begun is, however, significantly higher than the cost of obtaining them in advance.
The remote-worker population is the appropriate first cohort for any phased rollout. Effects on a high-bandwidth office network are small in absolute terms; effects on a remote user with a thin or shared connection are observable at the user level and constitute an early-warning indicator for the wider enterprise rollout. A pilot of two to three hundred remote users with adequate telemetry will surface the majority of the issues a full rollout will surface, at a fraction of the operational blast radius.
7. Calculator
A first-approximation model implementing the calculations in §2 and §4 is available as a companion to this article. The model takes seven inputs (user count, remote-worker percentage, handshakes per user per day, peak-hour concentration factor, cryptographic scheme, internet egress capacity, VPN concentrator capacity) and produces peak-hour Mbps figures and headroom percentages at each of the choke points identified in §3. It is intended as a planning instrument rather than a measurement tool: it indicates whether a question is worth investigating in detail, and identifies which devices are most likely to constitute the binding constraint. Production capacity planning requires direct measurement of peak handshake rates, session-table behaviour, and IKE concentrator CPU profiles in the specific environment under consideration.