Reaching internal apps without a VPN: application proxy, Private Access and a migration plan

What is wrong with the VPN

A VPN relies on a perimeter model: once authenticated, the user is "inside". Unless there is fine-grained segmentation, which is rarely maintained, they can reach servers, domain controllers and admin interfaces unrelated to their work. A compromised device connected to the VPN becomes a beachhead on the internal network. In addition, internet-facing VPN concentrators regularly suffer critical vulnerabilities exploited at scale.

The aim is not to remove the VPN on principle, but to steadily reduce what depends on it, until access is granted application by application, to a verified identity on an assessed device.

Entra application proxy

Application proxy publishes internal web applications through Entra ID. Connectors installed on the internal network only make outbound connections to the service: no inbound port is opened. The user authenticates against Entra ID before any request reaches the application, which puts it under Conditional Access (MFA, compliant device, risk).

It suits web applications well, including those using Integrated Windows Authentication via Kerberos constrained delegation, or header-based authentication. It is included in some Entra ID licences; check the applicable terms.

Global Secure Access and Private Access

Private Access, part of Global Secure Access, extends this model beyond the web. A client installed on the device routes traffic destined for defined private applications to the Microsoft service, which forwards it to internal connectors. It supports protocols other than HTTP, such as RDP, SMB or SSH, within the current capabilities of the service, which we encourage you to check.

Two publishing modes coexist:

• Quick Access: you declare broad address or name ranges, which quickly reproduces the VPN perimeter; useful to get started, but with no segmentation gain;
• Per-app access: each application is declared with its names, ports and authorised users, and can have its own Conditional Access policies.

Bringing in Conditional Access

The value of these services lies in Conditional Access. For each published application you can require a strong authentication method, a compliant or joined device, or block certain risks. Administration applications (consoles, RDP access to servers) deserve stronger requirements than everyday business apps, ideally a dedicated admin workstation.

The servers hosting the connectors also need attention: they relay traffic into the internal network and, when they use Kerberos delegation, hold impersonation rights. They must be hardened, patched and classified at the tier of the applications they serve.

A staged migration plan

1. Inventory VPN usage from its logs and network flows: who reaches what, over which protocol.
2. Publish the most used web applications first through application proxy or Private Access.
3. Pilot Private Access with a small group, possibly starting with Quick Access.
4. Split Quick Access into separate applications with their own policies.
5. Shrink the VPN to the identified residual uses, then to the users concerned only.
6. Retire the concentrator once the last uses have been dealt with.

What an audit checks

• The exposure and patch level of remaining VPN gateways.
• The network scope actually reachable by VPN users.
• Published applications and their Conditional Access coverage.
• Use of Quick Access and the plan to split it into applications.
• Hardening and Kerberos delegation of connector servers.
• Stronger requirements for administration applications.