A VPN exempt list keyed to a SaaS vendor's published IP ranges is reviewed quarterly - what can an adversary reach through it?

## Keying by address is not keying by identity An exemption list is a set of prefixes. The intent behind it is a *vendor* - the conferencing platform, the file service, the collaboration suite - but the enforcement is an address match on the client. That gap between intent and key is where every failure in this leaf lives, and it is the fact a candidate has to say out loud. ## Three drift modes, in the order they bite **1. Release lag.** Cloud and CDN address space is leased, not owned. A provider that hands a block back has no obligation to tell your list, and the block returns to a pool where it can be assigned to any other tenant. Your entry keeps forwarding traffic to that prefix outside the tunnel, so whoever now holds it enjoys an uninspected lane from your entire fleet. This is the direction people miss: they audit for ranges that were *added* (because users complain) and never for ranges that were *removed* (because nothing breaks). **2. Multi-tenancy while current.** Even a block the vendor genuinely uses today is often shared front-end space serving many customers, sometimes arbitrary customer-supplied content. Exempting the prefix exempts everything that answers inside it, not the one service you had in mind. **3. Coarsening pressure.** New ranges appear between reviews. Users see failures on the vendor's newest edge nodes, tickets arrive, and the fastest fix is a shorter prefix that covers whatever the vendor might add next. Each round of that makes the exemption bigger and the reasoning less specific, and the list ratchets in one direction because widening it fixes a live complaint while narrowing it creates one. ## What the adversary needs Not much. In shared address space, a foothold inside an exempted prefix is often purchasable rather than stealable. And the map is not secret: the exempt list is installed on every endpoint. Anything running with user privileges on the laptop can read which destinations the organisation has decided not to watch. An exemption list is a published description of your blind path. ## What holding it honestly costs - **A named owner.** An entry with no owner cannot be removed, because nobody can say what breaks. Entries added "for a pilot" outlive the pilot by years. - **Expiry rather than review.** Reviewing a list finds nothing; expiring entries forces a decision. An entry that must be renewed on a date is one somebody has to justify. - **Automation with a limit.** Fetching the vendor's published ranges on the vendor's cadence closes the release lag and the addition lag. But auto-*adding* prefixes means no human decides what becomes uninspected, and automation does nothing about multi-tenancy. Automate removals aggressively and additions cautiously. - **Narrowness.** Key exemptions to the smallest prefix and the specific transport that actually needed the relief. A media exemption that covers only the UDP media ports of a defined destination set is a far smaller uninspected surface than a whole-vendor prefix list. - **Breakage budget.** Every one of these makes the list tighter and therefore more likely to break someone at 09:00. That is the real reason lists rot: correctness is expensive in tickets and staleness is free until it is not. ## The claim to be careful with "We pull the vendor's published range file weekly, so the list is accurate" is the confident wrong answer. It fixes freshness only. Freshness does not make an address block single-tenant, and it does not stop an implant on the endpoint from reading the list and using a destination the organisation permits and does not observe.