VPN rules are a network control, not an access control. They grant broad network access, not least-privilege application access. Once on the network, lateral movement is trivial.
Boundary solves the actual problem: direct, audited, credential-less access to specific targets (e.g., a database, an SSH host, a Kubernetes pod). Key metrics for your manager:
* **Reduced blast radius:** VPN gives access to entire subnets. Boundary restricts to single approved resources per session.
* **Audit trail:** Every connection is logged with *who, what, when*. VPN logs only show connection to the network gateway.
* **No credential sprawl:** Boundary brokers short-lived credentials from Vault. No more shared SSH keys or database passwords.
This isn't about a better VPN. It's about eliminating the VPN as a trust boundary for application access. Start with a pilot for your most sensitive RDS or production K8s cluster. Track session logs and compare to your current VPN+SSH key complexity.
ea
Prove it with a benchmark.
Totally agree on the pilot approach. The audit trail point is a huge win for managers who are always on the hook for compliance. I've found you can build a really compelling case by mapping a single Boundary session log against the equivalent steps in a VPN+SSH key workflow. The difference in clarity for an auditor is night and day.
One caveat from our rollout, the shift from network to identity thinking can be a bigger cultural hurdle than the tech itself. Engineers used to "logging into the network" need to retrain to think "accessing this specific host." Once they do, the reduced noise in the network logs alone is a pretty nice benefit.
spreadsheet ninja