Start with the question that decides it
Before evaluating options, answer one question about the tunnel: how long must the data crossing it stay confidential?
That single answer does most of the work. A tunnel carrying operational telemetry with a useful life of days does not justify a hardware refresh. A tunnel carrying personal data, contract terms or clinical records with a thirty-year confidentiality requirement justifies a great deal, because an adversary recording that traffic today has decades in which to decrypt it.
Deciding by device age or by vendor is how estates end up replacing hardware that did not need replacing while leaving the genuinely exposed connection in place.
The seven options
1. Firmware or software upgrade
The cheapest real fix when it is available. The constraint is usually not whether a supporting release exists but whether this hardware model can run it, and whether the estate's change governance permits the upgrade inside the migration window.
Cost: change window plus regression risk. Watch for: a train upgrade changes behaviour on every other tunnel on that device, not only the one being migrated.
2. Licence change
Some vendors gate cryptographic capability behind a licence tier. Where that is the case the fix is commercial rather than technical, and it is fast.
Cost: licence spend, usually annual. Watch for: confirm the licence actually unlocks the specific mechanism on this release before purchasing.
3. Hardware refresh
The device cannot run any release that carries the capability. This is a capital decision, and it should be presented as one — with the tunnel's data sensitivity as the justification rather than the device's age.
Cost: capital plus a migration project. Watch for: refresh cycles often already exist. Aligning the post-quantum requirement with a planned refresh converts a new capital request into a specification change on an approved one, which is a materially easier conversation.
4. Overlay gateway
Stand up a gateway you control — commonly a software IKEv2 implementation on Linux — and terminate a migrated tunnel on it, with the legacy device confined behind it or bypassed for the affected flows.
This is the most under-used option and often the best one. It converts a hardware problem into a software problem, it can be delivered without touching the legacy device's configuration, and it works when the constraint is a counterparty's device rather than your own.
Cost: a host, an IP address, a routing change, and ongoing ownership of one more thing. Watch for: the overlay must not become an undocumented single point of failure. Give it the same HA treatment as the device it is fronting.
5. Compensating control
Where the tunnel cannot migrate, reduce what an adversary gains from recording it. Application-layer encryption inside the tunnel is the usual answer, and where the payload is a single well-defined protocol it can be very effective.
Cost: application change, usually owned by a different team. Watch for: this moves the problem rather than solving it. The application-layer cryptography needs its own post-quantum position, or the exposure has simply relocated.
6. Reduce what the tunnel carries
If the exposure comes from one specific flow, move that flow. A tunnel that no longer carries long-lived sensitive data no longer needs the same urgency.
Cost: usually low technically, higher organisationally. Watch for: verify what the tunnel actually carries rather than what the documentation claims, or the flow gets moved and the exposure stays.
7. Documented deferral
A named risk owner, a stated reason, a compensating control where one exists, and a review date.
This is a legitimate outcome and it should not be treated as a failure. What makes it legitimate is that it is explicit. An unclassified tunnel is a risk nobody owns; a deferred tunnel with an owner and a date is a managed one.
Cost: none directly. Watch for: deferrals with no review date become permanent. Put the date in the same system that tracks everything else with a date.
Interim mechanisms on older platforms
Where a device supports RFC 8784 preshared key mixing but not RFC 9370 additional key exchanges, that is a real option and it is worth taking seriously.
The caveat is scale. RFC 8784 requires a distinct high-entropy key per peer pair, distributed out of band and rotated. For a handful of tunnels this is entirely manageable. Across a large peer set it is a key management programme, and if it is not resourced as one it degrades into a set of keys that were installed once and never rotated — which is worse than not deploying it, because the estate believes it is protected.
Deploy RFC 8784 where the peer count is small or where the tunnel matters enough to justify the process. Do not deploy it broadly as a shortcut around the upgrade programme.
Making the decision defensible
Record, per blocked tunnel: what it carries, the confidentiality horizon of that data, the specific blocking reason with model and release, every option considered, the option chosen, the cost, the owner and the review date.
That record is what turns "we could not migrate forty tunnels" into a set of deliberate, individually justified decisions. It is also what an auditor, a customer's security questionnaire or a regulator will ask for, and reconstructing it eighteen months later is considerably harder than writing it down at the time.
Common mistakes
- Deciding by device age rather than by data sensitivity. The oldest device is frequently not the most exposed connection.
- Treating replacement as the only alternative to upgrade. The overlay option resolves a large share of these cases at a fraction of the cost.
- Deploying RFC 8784 broadly without funding key management. It decays silently.
- Deferring without an owner or a date. That is not a decision; it is an omission with paperwork.
- Missing the refresh cycle already in the budget. Aligning with a planned refresh is far easier than requesting new capital.
Limitations
This guide covers decision structure, not product capability. Whether a specific model and release can reach the target is recorded per product in the compatibility matrix. Cost figures are deliberately absent because they are entirely estate-specific.