Entra Private Access - Replacing Your VPN

6 min read

I’ve spent more years than I’d like to admit wrestling with VPN infrastructure. Split tunnelling nightmares, capacity planning spreadsheets, client compatibility dramas — you name it, I’ve dealt with it. And then there’s the bigger problem: once someone’s on the VPN, they usually have way more network access than they actually need. It’s always bugged me.

So when Microsoft put Entra Private Access forward as a proper VPN replacement — part of the Global Secure Access suite, now GA — I wanted to get hands on with it and see whether it actually delivers. Here’s what I found.

How It Works

At its core, Entra Private Access gives you Zero Trust Network Access (ZTNA) to your private apps and resources. Rather than connecting a user to your whole network through a VPN tunnel, it connects them only to the specific applications they need. Nothing more.

The architecture is pretty easy to follow:

Global Secure Access client sits on the user’s device (Windows primarily, with macOS and mobile at various stages of support)
Private Network connectors get deployed into your on-prem or IaaS environment — if you’ve used the old App Proxy connectors, you’ll find these familiar
Traffic goes from the client, through Microsoft’s global network, to the connectors, and those connectors access the private resources on the user’s behalf

The big difference from a traditional VPN? The user never gets direct network access. Everything’s proxied through the connectors, and you decide exactly which apps and network segments each person can reach. That’s a fundamentally different security posture.

Per-App Access vs Quick Access

Two main approaches to setting things up:

Per-App Access is the granular route. You define individual application segments — FQDN or IP address and port for each app you want to publish. Users only get access to the specific apps assigned to them. This is proper Zero Trust. Least privilege at the app level.

Quick Access is broader and designed to make the migration path from VPN less painful. You define network segments (IP ranges and ports) and users can access those. It’s basically giving them access to a chunk of your network, similar to VPN but with identity-based controls sitting on top.

The way I see it: start with Quick Access. Get your users off VPN quickly, keep things moving. Then over time, work towards per-app access as you map out your application segments. Trying to jump straight to per-app for everything when you’ve got hundreds of internal apps — that’s a massive undertaking and I’ve seen it stall projects.

The Global Secure Access Client

The client experience on Windows is decent. It installs as a system service and handles traffic routing without the user needing to think about it. Authentication goes through Entra ID, and Conditional Access policies apply to Private Access connections the same way they would to any other cloud app. No messing about.

That’s actually one of the strongest selling points. You can require compliant devices, demand specific authentication strengths, limit access based on user risk — all through the Conditional Access framework you’re already using. No separate policy engine to learn and maintain.

Here’s what tripped me up though. If you’re running other security agents that inspect or route network traffic — and let’s be honest, who isn’t — you need to test for conflicts. I hit a couple of issues with third-party endpoint protection during my deployment that needed exclusion rules to sort out. Budget time for that.

Conditional Access Integration

This bit deserves its own section because it’s where the product really stands apart. When you set up Private Access, it registers as an enterprise application in Entra ID. So you can target it with Conditional Access policies exactly like you would Microsoft 365 or any other cloud app.

A few examples of what you can do:

Demand phishing-resistant MFA before anyone touches critical internal apps
Block access from non-compliant devices outright
Set up a specific authentication context for sensitive application segments
Use Continuous Access Evaluation to yank access in near real-time if a user’s risk level changes

This is miles ahead of what most VPN products offer. Traditional VPN: authenticate once, you’re in, off you go. Private Access: access is continuously evaluated. Someone’s risk level goes up mid-session? Their access can be revoked right then and there.

What’s Working Well

Conditional Access integration is the headline feature, and rightly so. Identity-based, risk-aware access control for on-prem apps — that’s been a long time coming
Quick Access gives you a realistic migration path without needing to catalogue every single internal app before you start
Connector deployment is straightforward, especially if you’ve done App Proxy before. Connectors are lightweight and happy sitting on existing servers
User experience is mostly invisible once the client’s installed. No “connect to VPN” step, which users love

Where It Gets Tricky

Non-Windows support still has catching up to do. Mixed estate with macOS and Linux? Expect some gaps and plan around them
UDP traffic has improved but can still cause headaches with certain apps. If you’ve got UDP-heavy applications, test them thoroughly before cutting over
DNS resolution needs proper planning. Complex internal DNS setups can cause real problems — the client has to resolve internal FQDNs correctly for per-app access to work, and I spent a frustrating afternoon on one deployment sorting out split-horizon DNS issues
Troubleshooting tooling is still maturing. When things go wrong, working out whether it’s the client, the connector, or the config takes more effort than it should

Is It Ready to Replace Your VPN?

For a lot of organisations, yes — with caveats. If your workforce is mostly on Windows and you’re already invested in the Entra ecosystem, Private Access is a credible replacement. The Conditional Access integration alone makes it worth a serious look.

That said, I wouldn’t rip and replace overnight. Run Private Access alongside your existing VPN for a while. Move users and apps across progressively. Retire the VPN once you’re confident everything’s covered and your support team knows how to troubleshoot the new setup.

If you want to get started, my suggestion is simple: deploy a couple of connectors, publish a few non-critical apps through Quick Access, and get comfortable with how it all works before you go anywhere near your critical stuff.