Shrinking VPN pool reach needs app-by-app discovery nobody will staff - what do you deliver and who signs?

## The trap in the obvious plan Asked to reduce what a remote-access pool reaches, the natural plan is: enumerate what every application needs, write the allow list, apply it. In an estate of a few hundred applications that plan never finishes. Owners can describe their own front door but not the outbound calls their service makes; documentation reflects a design from years ago; and half the dependencies belong to teams in another part of the business. Meanwhile every wrong deny is a stopped business process with a name attached, so nobody is willing to move without complete information that will never arrive. The result is a flat pool and an annual risk finding that is re-raised and never closed. **The inversion is the whole answer: you do not need to know what remote users need in order to know what they never need.** ## Tranche one: remove what needs no discovery Some destinations have no legitimate remote-user case at all, and their exposure is the reason the finding exists: - hypervisor and infrastructure management planes - backup control and restore infrastructure - directory and certificate services beyond the specific ports clients require - out-of-band and console networks - database listeners that only application tiers should reach Denying those to the pool requires no application enumeration and no owner interview. It is the largest single reduction in consequence available and it can be scheduled in weeks rather than years. If an exception surfaces, it is genuinely interesting and belongs in a queue with an owner and an expiry. ## Tranche two: split the population A single pool forces one policy on everyone. Splitting by population converts an unknowable problem into several knowable ones. Third-party and contractor access is the natural first split: the population is small, the need is usually a named application or two, and the entitlement is contractual, so somebody can actually answer the question. Privileged administration is the second: it should reach the management estate that tranche one just removed from everyone else, and it should be a distinct pool so that reach is explicit rather than accidental. ## Tranche three: the residual, held honestly What is left is the general staff pool reaching a broad internal estate. Do not pretend it is solved. Write the residual down: which destinations remain reachable, what an abused staff account therefore reaches, what would be required to shrink it, and an expiry date on the acceptance so the decision is revisited rather than inherited. The adversary case is stated plainly - one phished account with an approved factor lands here and reaches this list - because that sentence is what makes the acceptance a real decision rather than a formality. ## The number that moves Governance arguments stall when the deliverable is a policy statement. Replace it with a measurement: the count of subnets and listening services reachable from each pool, computed the same way each quarter. It goes down after each tranche, it is not affected by adding another authentication factor, and it lets a risk officer see progress without reading a rule base. It also disarms the standing misconception directly: the count is unchanged by MFA, because authenticated means routed, not authorised. ## Who signs what This is the part a principal answer must be explicit about, and the failure mode is the engineer quietly absorbing everyone else's decision. | Decision | Owner | | --- | --- | | Removing destinations no remote user needs | Security, with an announced window | | Discovering an application's real dependencies | That application's owner, funded from their budget | | Accepting the residual reach of the staff pool | The named risk owner, with an expiry date | | Granting an exception to a deny | Requestor plus risk owner, expiry mandatory | Exceptions without an expiry become the permanent shape of the policy, so the expiry is not administrative decoration - it is the mechanism that stops tranche one being undone over eighteen months. ## What to say when asked for a completion date Be honest that there isn't one for full enumeration, and offer the alternative: a committed date for each consequence-ordered tranche, a measured count after each, and a standing exception process with owners. That is a fundable programme. "We will document every application's dependencies" is not, and promising it is how this finding survived the last three audits.