Do you still need a site VPN when the app uses mTLS and SSO?
Walk the channels your app login never covers, then decide whether private network access is redundant or still the only path to the host.
You sign in over mTLS, the dashboard loads, and the claim that the site VPN is now redundant sounds reasonable for about as long as it takes to need a database restore at two in the morning. The application's TLS boundary describes one channel. The host, the database, the backup target and the cloud account each carry their own entry path, their own identity and their own approver, and none of them is exercised by a successful login.
Walk outward from the login screen
Sign in the way an ordinary user does and write down every hop the request touches: browser, edge, application listener, session store, backend API. Each hop has an owner and an authentication decision. Now repeat the walk for the person who patches the host, and for the job that writes the nightly backup. Those walks usually diverge at the first hop.
The divergence is the question worth answering. A site tunnel is redundant only when every channel in that second walk has an entry and authorization policy that stands on its own.
Five channels the application login never covers
The table below is an inventory template, not a deployment checklist. Fill the second column with what your own environment actually enforces today.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Sharing an identity provider does not merge these authorizations. A user who may submit an API request is not thereby allowed to replace a VM disk or restore a database over the application's credentials. NIST's zero-trust architecture abstract keeps resource authentication and authorization separate from network location for exactly this reason.
A support engineer who can read a ticket is not, by that fact, allowed to open a console on the host behind it.
A path is only real if the alternate stays closed
Restricting reachability to private administrative listeners is a legitimate replacement for a site tunnel, provided the restriction is enforced and not merely drawn. The usual failure is an alternate listener that nobody remembered: a service still bound to all interfaces, a security group rule opened for a contractor, a management port reachable from the internet.
Check listeners rather than diagrams. On the host, list what is actually bound with ss -ltnp and confirm the administrative ports sit on a private address. In the cloud console, read the inbound rules for the workload subnet and look for 0.0.0.0/0 on anything administrative. Then try the connection from outside the private path, because that test is the one that answers the question.
A single world-open rule on SSH undoes every argument the tunnel design made.
Write the map before you compare designs
For each row of the inventory, record who approves identities, who updates the access rules, who removes credentials when someone leaves, and who handles recovery when the path itself breaks. Four names per row is enough to expose the rows where the answer is a shared account and a wiki page from three years ago.
Then validate one allowance and one denial per channel. An allowance proves the intended identity can reach the resource through the intended path. A denial proves a similar identity cannot, and it is the test people skip, which is why alternate listeners survive audits. Compare the proposed design against these results, not against the application's TLS configuration, which never exercised any of them.
Where a site tunnel still earns its place
A tunnel or a narrow gateway is the right answer when a resource has no per-request authentication of its own: database maintenance ports, backup targets, hypervisor consoles, out-of-band management. Those listeners trust the network, so the network has to be the thing that authenticates the caller.
It is not the only answer. A gateway that terminates per-resource authorization can be narrower than a subnet-wide tunnel, and it leaves a better audit trail than a shared jump host.
Order of work: complete the inventory, close the alternates, validate one denial per row, and only then retire the tunnel. If a row cannot produce a denial, keep the private path until it can.