Migrating tunnels whose far end belongs to someone else

Why these tunnels set the programme timeline

Key establishment is negotiated between two peers. Whatever your gateway is capable of, the tunnel will use a method both ends offer. If the far end belongs to a supplier, a customer, a clearing house or a regulator, then their change process is inside your critical path.

That is why partner-controlled tunnels are identified in the first days of an assessment rather than at the end. The technical work on your own estate can be compressed by adding engineers. The time it takes another organisation to schedule a change cannot.

Identify them precisely

"External" is not one category. Distinguish:

• Supplier peers, where you hold commercial leverage and a contract that may already oblige them to maintain current security standards.
• Customer peers, where they hold the leverage and the request has to be framed as service continuity.
• Regulated counterparties, where a common deadline may already exist and can be cited.
• Cloud provider endpoints, where there is no counterparty to negotiate with — the service exposes what it exposes, on its own timeline.
• Legacy peers with no clear owner, which are surprisingly common and are usually the hardest to move because nobody on either side is accountable for them.

Record, per external tunnel: the counterparty, a named technical contact, the commercial relationship, what the tunnel carries, and any contractual security obligations already in force. That last field is often the most useful lever available and is rarely checked.

Make a specific request

A vague request produces a vague answer six weeks later. A specific one produces a usable answer or a clear refusal.

The request should name:

1. The mechanism. Not "post-quantum support" but the specific target — for example, IKEv2 additional key exchange per RFC 9370, with a named parameter set.
2. Your side's readiness. State that your gateway is already capable and confirm the date from which you can test.
3. A proposed test window. Two or three concrete options, in their business hours.
4. The fallback. What you will do if the change cannot be made — usually maintaining the current configuration under a documented exception with a review date.
5. A named technical contact on your side who can answer a follow-up question the same day.

Send it to a technical contact, not to an account manager. The account manager will forward it, which adds two weeks and loses the detail.

Sequence them realistically

Partner-dependent tunnels belong in late waves, but the coordination belongs in week one. These are different activities and conflating them is the most common scheduling error in these programmes.

A workable pattern:

• Week 1. Identify, classify and send the initial requests.
• Weeks 2–8. Run your internal waves. Track counterparty responses as they arrive.
• As responses land. Schedule a joint test per counterparty. Test before the change window rather than during it, where the counterparty will permit it.
• Ongoing. Chase non-responders on a defined cadence, escalating through the commercial relationship rather than the technical one after the second unanswered request.

When the peer will not move

Some will not. Plan for it rather than treating it as a failure.

The options, roughly in order of preference:

1. Terminate an overlay gateway. Stand up a gateway you control that terminates a migrated tunnel, with the legacy tunnel confined behind it. This converts a counterparty problem into an internal one. See legacy VPN gateway options.
2. Reduce what the tunnel carries. If the exposure is driven by long-lived sensitive data, moving that specific data flow to a different transport can resolve the risk without resolving the tunnel.
3. Contractual escalation. Where an existing security schedule obliges them to maintain current standards, use it. This is slow but it works, and it works better the earlier it starts.
4. Documented exception. A named risk owner, a stated reason, a review date and a compensating control. This is a legitimate outcome, and recording it properly is materially better than leaving the tunnel unclassified.
5. Plan for replacement of the relationship. Rare, but where the counterparty is replaceable and the data is sensitive enough, it belongs on the list.

What is not an option is recording the tunnel as migrated because your side is configured correctly. Verification is bilateral — see verifying a post-quantum VPN migration.

Common mistakes

• Leaving coordination until the internal work is finished. It has the longest lead time and it can start immediately.
• Sending a generic security-uplift notice. It will be filed. Name the mechanism and the date.
• Assuming a cloud endpoint is a counterparty. There is nobody to negotiate with; the service capability is the constraint.
• Treating a verbal confirmation as evidence. Get the negotiated SA, or record explicitly that you could not.
• Not tracking non-responders. The tunnel nobody answered about is the one still running classical key establishment in two years.

Limitations

This guide covers the coordination problem. It does not cover the technical target, which depends on both peers' exact capability — see the compatibility matrix — nor the contractual specifics, which vary by jurisdiction and by agreement and should be reviewed by your legal function before being cited to a counterparty.