You cannot retire a weak VPN proposal for a year. What compensates for it meanwhile?

## The premise: the cipher is not yours to fix this year The endpoints negotiate what their firmware shipped with, the support contract forbids you changing them, replacement is a capital programme, and the change freeze means the migration is measured in quarters. Everything below assumes that is true and asks a different question: given that the tunnel is weak and stays weak, what stops the weakness from mattering? The framing that gets you through the interview is: **the tunnel gives you transport, not trust.** Every compensating measure follows from refusing to let a weak tunnel be the thing that makes a peer trusted. ## Narrow what the group may originate The legacy peers should terminate into their own policy, not into the same place as authenticated staff laptops. From there, allow only what those devices actually need — typically a vendor management server, an imaging or results store, a time source, perhaps a licence check — and deny the rest: lateral traffic to other estate, general outbound to the internet, and anything toward administrative interfaces. This is the measure that changes the consequence. If a weak tunnel is broken, or if somebody dials in holding a group secret pulled from a device in a corridor, what they inherit is a narrow set of destinations rather than a foothold with the reach of a corporate VPN session. You have not fixed the crypto; you have made the crypto matter less. **The cost is where this gets real.** Nobody documented those flows. The only honest way to build the allowed set is to observe: run the terminating policy permissively with logging for a full operational cycle, derive the set from what actually flowed, review it with the cohort's owner to separate requirements from accidents, then enforce cohort by cohort with a rollback ready. A wrong deny here does not annoy an analyst; it stops imaging in a ward or halts a production line, and that consequence is exactly why this is enforced in stages rather than in one change window. ## Make the exception observable Two signals are worth building, and neither is high-volume: - **The legacy proposal selected by a peer identity not on the inventory.** By construction this should never occur. It is therefore a clean detection rather than a tuning problem, and it is the one that fires if someone external has worked out that the weak option is still on offer. - **A legacy identity originating a flow outside its allowed set.** This catches a compromised or tampered device and, just as usefully, an inventory entry you got wrong. Alerting on *every* legacy session is the beginner's version and it drowns you, because the whole point is that hundreds of them happen every day. Trend that volume instead: it is your migration burn-down, and it is what you show when asked whether the programme is moving. ## Time-box it, or it becomes permanent The uncomfortable truth about good compensating controls is that they remove the pressure that would have finished the job. Once the exception is contained and quiet, the capital case for replacing four hundred devices loses its urgency, and the arrangement outlives everyone who understood it. So the arrangement needs three things recorded together: | Element | What it is | | --- | --- | | Owner | A named person who can authorise the cohort's outage, not a team mailbox | | Expiry | A date at which the exception is re-argued rather than silently renewed | | Retirement condition | Evidence-based: no peer on the legacy set across a full operational cycle | The retirement condition matters more than the date, because a date alone gets extended. Tying it to the inventory means the exception ends when the evidence says it can, and the same records that justified keeping it are what close it. ## What this is not It is not a claim that the risk is gone. The legacy tunnels remain weak, the group secret remains extractable, and anyone recording that traffic is still accumulating something. What you have done is bound the consequence, made abuse visible, and put a clock on the whole arrangement. Say that plainly in the interview — a candidate who claims the compensating controls have solved the problem has misunderstood what compensating means. ## What an interviewer is listening for That you separate transport from trust, that your first instinct is to narrow the terminating policy rather than to argue about ciphers you cannot change, that you observe before you deny because the failure lands on a ward, that your detection is scoped to the anomalous case rather than the routine one, and that the arrangement carries an owner, an expiry and an evidence-based retirement condition.