In [Part 2 of this series], I looked at replacing traditional VPN access with Microsoft Entra Private Access.

That solves an important problem. Users no longer need to establish a traditional VPN connection just to reach a private application, and access can become part of the same identity-led security architecture as the rest of Microsoft Entra.

But removing the VPN client does not necessarily mean you have removed the VPN architecture.

If the first thing you do with Entra Private Access is publish half of the corporate network through Quick Access, assign it broadly and call the job finished, you have certainly changed the technology.

You may not have changed the access model very much at all.

A traditional VPN commonly gives a user network reachability first and relies on controls elsewhere to determine what they can actually do once they are connected.

Private Access gives us the opportunity to turn that around.

Give users access to applications, not networks.

That is where Entra Private Access becomes much more interesting.

Quick Access Is Not the Problem

Let’s get one thing out of the way first.

Quick Access is useful.

Very useful, in fact.

Microsoft provides Quick Access specifically as a way of publishing broader sets of private resources using FQDNs, IP addresses and network ranges. It gives organisations a relatively straightforward route away from traditional VPN connectivity and is an excellent way to get started with Private Access.

The problem is not using Quick Access.

The problem is treating the first Quick Access configuration as the finished architecture.

There is a very natural migration path here:

Quick Access → Discover → Understand → Segment → Assign → Apply Conditional Access → Validate → Reduce broad access

That is a very different mindset from trying to redesign every private application before the first user can move away from the VPN.

Quick Access can be the bridge.

It does not have to be the destination.

Changing the Tunnel Is Not the Same as Changing the Access Model

Imagine the existing VPN provides access to:

10.20.0.0/16

We replace the VPN with Private Access and create a Quick Access segment for:

10.20.0.0/16

The user experience has changed. The traffic path has changed. The authentication and access capabilities available to us have changed.

But from an access-scope perspective, we may still be saying:

Here is a large network. You can reach it.

That is the model we should be trying to move away from.

Instead, perhaps the user actually needs:

finance.contoso.internal : TCP 443

and:

files.contoso.internal : TCP 445

while a small infrastructure team also needs:

server-admin.contoso.internal : TCP 3389

Those are different requirements.

They have different users.

They may have different authentication requirements.

They may have different device requirements.

And they almost certainly have different risk.

Treating all of them as one large network because they happen to live inside the same RFC1918 address range throws away much of the value that Private Access can give us.

designing-entra-private-access-properly-don-t-rebuild-your-vpn-in-the-cloud

Start Broad Enough to Move, Then Discover

One of the problems with application segmentation is that the diagram is always easier than the environment.

You can sit in a design workshop and say:

We will simply identify every application dependency and publish each one individually.

Then reality arrives.

There are applications nobody owns anymore.

There are services that have quietly depended on another server for eight years.

There are users connecting to things nobody realised they still used.

There are old DNS names, hard-coded IP addresses, unusual ports and dependencies that only appear at month end.

This is where the newer Application Discovery capability in Global Secure Access becomes particularly useful.

Microsoft’s current Private Access guidance describes using Quick Access to onboard broad private access, then using Application Discovery to understand the application segments users are actually accessing before moving them into separate enterprise applications.

Application Discovery can report the destination FQDN or IP address, port and protocol being accessed through Quick Access, together with usage information such as users and devices.

That changes the conversation.

Instead of:

What do we think users need?

we can start asking:

What are they actually using?

That does not mean telemetry should automatically become policy. A connection being observed does not prove that everybody who made it should retain access forever.

But it gives us evidence.

And evidence is a much better starting point than an old VPN ACL, a spreadsheet nobody has updated since 2021 or somebody saying, “I think Finance needs that subnet.”

Discover the Requirement, Not Just the Destination

Application Discovery is useful, but I would not treat it as an automatic application generator.

The technical destination is only part of the requirement.

If we discover:

10.20.40.15 : TCP 443

we still need to understand:

  • What application is this?
  • Who owns it?
  • Who genuinely needs it?
  • Does it have additional dependencies?
  • Is access the same for every user?
  • Does it require stronger authentication?
  • Should it only be accessible from a compliant device?
  • Is it administrative access?
  • What happens if it becomes unavailable?
  • Does the application use other protocols that have not appeared in the discovery window yet?

This is the same principle I used in the SWG migration article:

Migrate the requirement, not the legacy configuration.

With Private Access, I would extend that slightly:

Discover the traffic. Understand the requirement. Then design the access.

Move Towards Application Segmentation

Per-app access is where the architecture starts becoming much more deliberate.

A Global Secure Access enterprise application can contain application segments based on a destination, port and protocol. Users and groups can then be assigned to that application and Conditional Access can be applied to it.

That means the security boundary can start looking like the business service rather than the network it happens to live on.

For example:

Finance Application - finance.contoso.internal - TCP 443 - Finance users - Compliant device required

File Services - files.contoso.internal - TCP 445 - Relevant business groups - Managed device requirement

Server Administration - Defined management destinations - Required management ports only - Infrastructure administrators - Stronger Conditional Access controls

The examples are deliberately simple. Real applications frequently consist of several segments and dependencies.

The point is the model.

The user is not being given access to a network because that network contains something they need.

They are being given access to the application they need.

Quick Access and Per-App Access Can Help You Migrate Gradually

One of the nicest parts of the current design is that this does not need to be a big-bang migration.

Microsoft documents that where a Global Secure Access enterprise application’s network segment overlaps a Quick Access segment, the individually defined enterprise application takes precedence.

That is extremely useful.

Imagine Quick Access currently contains:

10.20.0.0/16

Within it sits:

10.20.40.15 : TCP 443

We create a dedicated enterprise application for that service.

The more specific application can now become the access path for that resource, including its own assignment scope and Conditional Access requirements, while other resources can remain available through Quick Access during the transition.

We can carve applications out gradually.

That gives us a much safer pattern:

Broad access for migration

↓

Observe real usage

↓

Identify an application

↓

Create application segments

↓

Assign the correct users/groups

↓

Apply the required Conditional Access

↓

Validate

↓

Reduce the broad dependency

Then repeat.

designing-entra-private-access-properly-don-t-rebuild-your-vpn-in-the-cloud

Assignment Is Part of the Security Boundary

This is another important difference from thinking in traditional network terms.

Creating a segment is not enough.

Who is assigned to the application matters just as much as the FQDN, IP address or port definition.

If a Finance application is only required by 40 people, why should 4,000 users have a route to it?

That sounds obvious when written down.

It has not always been obvious in network design.

Networks were frequently built around reachability, and identity controls were added somewhere higher in the application stack. Private Access lets us bring identity into the connectivity decision itself.

This is why I would avoid creating enormous generic assignment groups unless the application genuinely has an organisation-wide requirement.

The goal is not to produce hundreds of groups for the sake of appearing granular either.

The goal is understandable access:

Application → Business requirement → Appropriate group → Appropriate access policy

If nobody can explain why a group has access to an application, the design needs more work.

Conditional Access Is Where the Model Really Changes

This is the part that makes Private Access more than a replacement tunnel.

With a traditional VPN, the important decision is often:

Can this user establish the VPN?

Once connected, network controls and the applications themselves have to deal with much of what follows.

With per-app Private Access, the question can become:

Can this user, from this device, under these conditions, access this application?

That means two private applications do not need to have identical access requirements simply because they sit in the same datacentre.

A relatively low-risk internal application may have one policy.

A finance system may require a compliant device and stronger authentication controls.

An administrative interface may have substantially higher requirements again.

This is where Private Access begins to align private connectivity with the same Zero Trust principles we have been applying to cloud applications for years.

It is also why Part 9 of this series will look specifically at Global Secure Access and privileged access.

Privileged access is where the difference between network reachability and explicit access to a particular administrative resource becomes especially important.

Do Not Forget the Connector Fabric

There is another side to Private Access architecture that is easy to overlook.

The connectors.

Private Network Connectors are the bridge between Microsoft’s Global Secure Access service and the private resources we are publishing. They establish outbound connectivity to the service, so we do not need to expose inbound access simply to make an internal application available through Private Access.

But installing one connector somewhere and forgetting about it is not an architecture.

Connector groups let us associate applications with appropriate sets of connectors.

Microsoft documents several reasons for doing this, including locality, isolated networks, multiple datacentres, IaaS environments, separate forests and disaster-recovery scenarios.

Connectors within the same group operate together for availability and traffic distribution.

That means we should think about connector placement in the same way we think about other infrastructure dependencies.

Where are the applications?

Where are the connectors?

What happens when a connector is patched?

What happens when a server fails?

What happens when a site is unavailable?

Are we unnecessarily hauling application traffic between datacentres before it ever reaches the application?

For a small environment, the answer may genuinely be simple.

For a larger environment, one enormous default connector group serving everything is unlikely to be the design I would want to finish with.

Design Connector Groups Around Failure and Locality

A sensible pattern might look something like:

Datacentre A - Connector A1 - Connector A2 - Applications hosted in Datacentre A

Datacentre B - Connector B1 - Connector B2 - Applications hosted in Datacentre B

Azure-hosted private workloads - Appropriate connector placement close to those workloads - Applications associated with that connector group

The exact topology depends on the environment.

The principle is more important:

Connector design should reflect application location, resilience requirements and failure domains.

Do not create connector groups purely because a diagram looks tidier.

Create them because they give you meaningful control over how applications reach their private resources.

And test failure.

A highly available design that has never had a connector deliberately taken out of service is still partly theoretical.

designing-entra-private-access-properly-don-t-rebuild-your-vpn-in-the-cloud

DNS Is Part of the Architecture

DNS deserves its own section because it is very easy to draw Private Access without it.

The diagram normally looks like:

User → Global Secure Access → Private Application

Simple.

Then somebody tries to reach an internal FQDN and the troubleshooting starts.

Private applications frequently depend on private DNS, internal namespaces and service discovery. Kerberos-based applications can add another set of dependencies around domain controller discovery and service principal names.

So when something does not work, I would avoid jumping immediately to:

The connector is broken.

Work through the path.

Can the client resolve the name as expected?

Does the Private Access configuration contain the destination?

Which application or Quick Access definition owns it?

Which connector group is associated with that application?

Can the connector reach the backend resource?

Are the required ports and protocols actually defined?

Does the user have an assignment?

Is Conditional Access allowing the connection?

The Global Secure Access client diagnostics are valuable here because we need to distinguish name resolution, traffic acquisition, policy, routing and backend reachability.

They are not the same problem.

Be Careful With Overlapping Definitions

The precedence behaviour between per-app access and Quick Access is useful for migration.

It can also surprise you if you do not understand it.

If Quick Access broadly covers a network and you then create a specific enterprise application inside that range, traffic matching that enterprise application follows the application’s configuration and assignment.

That is exactly what we want when deliberately carving applications out of broad access.

It is less enjoyable if somebody creates the application without understanding the effect.

So I would treat application creation as a controlled change.

Before introducing an overlapping segment:

  1. Identify the existing Quick Access coverage.
  2. Confirm the application’s complete dependency set.
  3. Confirm the users/groups that require access.
  4. Configure the new application.
  5. Apply the intended Conditional Access policy.
  6. Test with users who should have access.
  7. Test with users who should not.
  8. Validate the client traffic path.
  9. Monitor after the change.

Least privilege is only useful if the right people can still do their jobs.

What About Users on the Corporate Network?

There is another assumption worth challenging.

If a user is sitting in the office, should their application access automatically fall back to the old trusted-network model?

Not necessarily.

Microsoft now provides Intelligent Local Access for Private Access scenarios. It can allow configured application traffic to use a local path when the client determines that it is on the appropriate corporate network, avoiding unnecessary cloud traversal.

The important architectural point is that local path optimisation does not have to mean abandoning the access model.

Microsoft’s current guidance states that Conditional Access policies for the Private Access application can continue to apply when Intelligent Local Access is being used.

That is a much better way to think about office connectivity.

Location can influence the path without automatically becoming the trust decision.

I would still treat Intelligent Local Access as something to design and test deliberately rather than enabling it everywhere because local must be faster.

Measure the requirement.

Understand the traffic.

Then optimise where it makes sense.

Not Everything Needs to Become a Tiny Application

There is a danger of taking least privilege so literally that the design becomes impossible to operate.

If you create an enterprise application for every IP address and every individual port without considering how the business service actually works, you can end up with hundreds or thousands of objects nobody understands.

That is not least privilege.

That is administrative entropy.

An application boundary should make sense.

A service might legitimately contain several servers, ports or dependencies.

Infrastructure services may need a different approach from a simple internal web application.

There will also be resources where broader Quick Access remains appropriate.

The goal is not:

Quick Access must eventually contain nothing.

The goal is:

Broad access should exist because we deliberately decided it was appropriate, not because we never finished the migration.

That distinction matters.

Define Ownership

As Private Access becomes part of the production access architecture, somebody needs to own it.

And I do not mean merely owning the Entra role that can configure it.

Who owns the application definition?

Who approves new segments?

Who owns connector health?

Who decides which Conditional Access policy applies?

Who investigates when an application is reachable through Quick Access but should have been segmented?

Who reviews assignments?

Who removes access when the business requirement disappears?

Who monitors whether broad access is growing again?

A Zero Trust design can still accumulate technical debt.

It just accumulates different technical debt.

Governance is what stops today’s carefully segmented architecture becoming tomorrow’s enormous collection of undocumented exceptions.

A Practical Private Access Maturity Model

I think of Private Access adoption in roughly five stages.

Stage 1 --- VPN Replacement

Broad private resources are published through Quick Access.

Users can reach what they need without the traditional VPN.

That is already useful.

But it is the beginning.

Stage 2 --- Discovery

Observe what is actually being accessed.

Use Application Discovery, existing network knowledge, application ownership and operational evidence to understand the environment.

Do not assume the old VPN configuration accurately represents the current requirement.

Stage 3 --- Segmentation

Move suitable resources into individual Global Secure Access enterprise applications.

Define meaningful application segments.

Associate them with appropriate connector groups.

Assign the users and groups who genuinely need them.

Stage 4 --- Identity-Aware Access

Apply application-specific Conditional Access.

Different applications can have different access requirements based on their risk.

Connectivity is now becoming part of the identity control plane rather than merely a route onto a network.

Stage 5 --- Least Privilege by Design

Per-app access becomes the normal pattern.

Quick Access remains where broad access is genuinely justified rather than as the place everything was put during the original migration.

Connector placement, assignments, Conditional Access and application definitions are reviewed as part of the service lifecycle.

At this point, we have done more than replace a VPN product.

We have changed the access model.

What Good Looks Like

A good Entra Private Access deployment is not the one with the most application segments.

It is the one where the access model is understandable.

For any important private application, we should be able to answer:

What is being published?

Which connectors can reach it?

Who is allowed to access it?

What conditions must they satisfy?

Why do they need it?

How do we know the path is working?

What happens if a connector or site fails?

Who owns the application and its access policy?

If those answers are clear, the architecture is probably moving in the right direction.

If the answer is still:

Everyone gets 10.0.0.0/8 because that is what the VPN used to do.

then we have some work left.

Replacing the VPN Mindset

Entra Private Access gives us a relatively easy way to remove traditional VPN dependency.

That alone can improve the user experience and simplify remote connectivity.

But I think stopping there misses the bigger opportunity.

Quick Access gives us a practical starting point.

Application Discovery gives us evidence.

Per-app access gives us segmentation.

Assignments give us identity scope.

Conditional Access gives us contextual access decisions.

Connector groups give us control over how private resources are reached.

Together, those capabilities let us move from:

User → Network → Find the application

towards:

User + Device + Context → Authorised Application

That is a much more interesting architectural change than replacing one tunnel with another.

Replacing the VPN is easy. Replacing the VPN mindset is the real architecture work.

What’s Next?

In the next part of the series, I want to take this model into one of the areas where access scope matters most:

Global Secure Access and Privileged Access.

If Private Access allows us to expose an individual application instead of an entire network, what does that mean for administrative interfaces, management services, privileged workstations and highly privileged identities?

That is where the distinction between being able to reach a network and being explicitly authorised to reach an administrative resource becomes much more important.

Microsoft Learn references

Documentation checked on 21 September 2026. The application-segmentation, connector-topology and migration recommendations in this article are architectural judgements based on the capabilities described in Microsoft’s documentation below.