Skip to content

PATTERN Cited by 1 source

Tunnel-first, inventory-later

Pattern

When facing a large-scale cryptographic migration (particularly PQC), wrap traffic in PQ-encrypted tunnels immediately rather than waiting for a complete system-by-system inventory before taking any action.

Problem

Organizations face HNDL risk today — every day of unprotected internet-facing traffic is captured data that can be decrypted post-Q-Day. But a full cryptographic inventory (or CBOM) takes months or years to produce. Sequential approach (inventory → plan → deploy) leaves systems exposed during the entire discovery phase.

Solution

  1. Deploy PQ-encrypted transport infrastructure as an outer envelope — route internet-facing traffic through PQ-capable tunnels (TLS 1.3 with X25519MLKEM768, IPsec with ML-KEM, MASQUE).
  2. Accept that individual applications inside remain classical — the tunnel provides bulk confidentiality protection against HNDL even though per-application crypto hasn't been upgraded.
  3. Concurrently run a quantum impact inventory to prioritize per-system upgrades, but don't gate the tunnel deployment on its completion.

Trade-offs

Pro Con
Immediate HNDL protection for internet-facing traffic Doesn't address internal-only traffic
Decouples protection from per-app migration timelines Creates dependency on tunnel provider's PQ implementation
Politically unblocks action without waiting for inventory Tunnel termination points remain classical-auth vulnerable until PQ auth ships

When to use

  • Organization has internet-facing traffic at HNDL risk
  • Internal crypto inventory is not complete
  • A PQ-capable network provider or tunnel infrastructure is available

Seen in

Last updated · 559 distilled / 1,651 read