Skip to main content

Microsoft Entra Private Access Guide: Architecture, Use Cases, and Best Practices

For decades, the corporate network was the security perimeter. Remote employees connected via a VPN, and once inside, they had broad access to internal applications. This model is broken. VPN concentrators are expensive, complex, and, once breached, expose the entire network to lateral movement. Modern workforces are distributed, applications have moved to the cloud and on‑premises data centers, and the idea of “inside the network” is no longer a meaningful security boundary.

Microsoft Entra Private Access is a Zero Trust Network Access (ZTNA) service that replaces legacy VPNs. It grants users access to private, self‑hosted applications—whether in Azure, on‑premises, or in another cloud—based on identity and device compliance, not network location. It is a core component of the Microsoft Global Secure Access platform, which converges identity and networking into a unified Security Service Edge (SSE). This guide explains the architecture, design principles, and practical deployment patterns for Entra Private Access from an engineering perspective.

What Is Zero Trust Network Access (ZTNA)?​

ZTNA is a security architecture that shifts access control from the network perimeter to the individual application and user session. Traditional VPNs grant network‑layer access. Once a device is on the corporate subnet, it can often scan ports, discover services, and probe applications even if the user is not authorized for them. This implicit trust is the root of many security incidents.

ZTNA operates on three principles:

  1. Application‑level access: Users connect to a specific application, not a network segment. A finance user is authorized only for the finance application; they cannot see or attempt to connect to the HR system.
  2. Identity‑ and device‑centric policies: Access decisions are based on the user’s identity, group membership, device compliance status, and real‑time risk signals, not on an IP address or a network zone.
  3. Continuous verification: Trust is never static. A session that began on a compliant device can be terminated if the device’s health degrades, the user’s risk level increases, or the access policy changes.

ZTNA eliminates the need to expose private applications to the internet, avoids the management of complex firewall rules for remote access, and dramatically reduces the attack surface by making applications “dark” to unauthorized users.

Microsoft Global Secure Access Overview​

Entra Private Access is one of two main services within Microsoft Global Secure Access, alongside Microsoft Entra Internet Access. Together they form Microsoft’s SSE solution.

  • Microsoft Entra Internet Access secures connections to the public internet and SaaS applications via a cloud‑native Secure Web Gateway.
  • Microsoft Entra Private Access secures access to internal, self‑hosted applications through identity‑aware, per‑app tunnels.

Both services share a common architecture: a lightweight client on the user’s device steers traffic to the nearest Microsoft edge point of presence (POP), where identity, Conditional Access, and security policies are enforced. The integration with Microsoft Entra ID, Conditional Access, and Microsoft Intune ensures that every access request is explicitly verified based on real‑time identity and device posture.

Microsoft Entra Private Access at a Glance​

Entra Private Access provides the following key capabilities:

  • Identity‑aware private application access: Applications are published to Entra ID. Users authenticate via Entra ID and are connected through an encrypted tunnel only after passing Conditional Access checks.
  • Client‑based connectivity: The Global Secure Access Client on the user’s device intercepts traffic destined for published applications and tunnels it to Microsoft’s edge. No legacy VPN client is required.
  • Connector‑based architecture: Lightweight software connectors deployed inside the private network (Azure, on‑premises, or other cloud) establish outbound connections to Microsoft’s edge. These connectors proxy traffic to the target application without requiring inbound firewall rules.
  • Continuous verification: Even after the initial connection, Conditional Access policies are evaluated continuously. If the device becomes non‑compliant or the user session is deemed risky, access is terminated.
  • Hybrid connectivity: Applications can be hosted anywhere—on‑premises VMware, an Azure virtual machine, a Kubernetes cluster in another cloud—as long as a connector can reach them.

Core Architecture​

The architecture of Entra Private Access separates the control plane (identity, policy, and management) from the data plane (the encrypted tunnel that carries application traffic). This separation is key to its security and scalability.

  • Global Secure Access Client: A lightweight agent installed on Windows or macOS. It authenticates the user, evaluates device compliance, and establishes a TLS‑encrypted tunnel to the nearest Microsoft POP. For published private applications, it intercepts DNS lookups and routes traffic to the POP rather than the local network.
  • Microsoft Edge POP: The entry point into Microsoft’s global network. The POP terminates the client tunnel, enforces Conditional Access policies, and proxies the request to the appropriate connector.
  • Private Access Connector: A small Windows service that you deploy inside your private network (e.g., on a VM). The connector initiates an outbound connection to Microsoft’s edge over port 443, forming a secure, reverse‑connectivity channel. It receives requests from the POP and forwards them to the internal application. Critically, the connector makes outbound connections only; no inbound firewall ports need to be opened.
  • Policy Engine: Integrated with Entra ID and Conditional Access. It evaluates user identity, device compliance, location, and sign‑in risk before allowing the connection to be proxied. This evaluation happens at the POP, before any traffic reaches your network.

Traffic Flow​

Consider a user accessing a legacy HR application hosted on an internal server (hr.internal.corp).

  1. User Authentication: The user signs in to their device with their Entra ID credentials. The Global Secure Access Client is already running and authenticated.
  2. Device Validation: The client sends device posture information (e.g., compliance state from Intune) to the Microsoft edge.
  3. Conditional Access: Entra ID evaluates the active Conditional Access policies. A policy might require the device to be compliant, the user’s sign‑in risk to be low, and the session to be protected by multi‑factor authentication (MFA).
  4. Identity Verification: The POP verifies that the user is authorized for the specific application (hr.internal.corp). This is a per‑application authorization, not a network‑level grant.
  5. Connector Selection: Microsoft’s edge selects the healthiest, least‑loaded connector in the connector group associated with the application.
  6. Application Authorization: The connector receives the request from the POP. It resolves the internal hostname (hr.internal.corp) and forwards the traffic over the internal network.
  7. Encrypted Tunnel: The entire path—from the client to the POP and from the POP to the connector—is encrypted. The HR application sees a source IP from the connector, not from the remote user.
  8. Private Application: The application processes the request and returns the response, which is relayed back to the user through the same secure channels.

Core Components​

Global Secure Access Client​

The client is the user’s endpoint for the SSE platform. It manages the local DNS interception and tunneling. For internet access, it steers web traffic; for private access, it steers traffic destined for configured private FQDNs and IP ranges. It is configured via Intune or manually.

Private Access Connector​

The connector is the linchpin of the architecture. It is a Windows service that you install on a domain‑joined or non‑domain‑joined server. Key architectural attributes:

  • Outbound‑only communication: It connects to Microsoft’s edge via outbound HTTPS (TCP 443). This eliminates the need for perimeter firewall rule changes, a major advantage over site‑to‑site VPNs.
  • Connector groups: You can organize connectors into logical groups and assign applications to specific groups. This provides geographic affinity, load balancing, and isolation between application tiers (e.g., a connector group for finance apps and another for engineering apps).
  • High availability: Deploy at least two connectors per group for redundancy. The edge automatically load‑balances and fails over between them. Connectors report their health continuously.

Application Publishing​

Applications are defined in the Global Secure Access portal by specifying their internal FQDN, IP address, and port. You then associate the application with a connector group. The system generates a unique application ID, which is used to create an enterprise application object in Entra ID. This enables you to assign users and groups and to apply Conditional Access policies to that specific application.

Identity‑Aware Access​

The core security value of Entra Private Access is its deep integration with the Microsoft identity stack. Access is not binary (connected to the VPN or not); it is conditional and granular.

  • User identity: Only users explicitly assigned to the application (or a group with access) can connect. Guest users from external organizations can be authorized in the same way.
  • Device compliance: Conditional Access can require that the connecting device is managed by Intune and marked as compliant with configuration and security policies.
  • Risk‑based policies: If a user’s sign‑in is flagged as risky (e.g., impossible travel, leaked credentials), access can be blocked, even if their credentials are valid.
  • Location and network: Policies can be scoped to allow access only from specific countries or trusted IP ranges.

Supported Applications​

Any application that communicates over TCP can theoretically be published. Common use cases include:

  • Web applications: Internal legacy portals (HTTP/HTTPS) that are not exposed to the internet.
  • Remote Desktop and SSH: RDP (port 3389) and SSH (port 22) for secure administrative access to servers without a jump host or bastion.
  • File shares: SMB (port 445) access to internal file servers.
  • Enterprise applications: ERP systems, HR platforms, and financial applications hosted on‑premises or in a private cloud.
  • Kubernetes dashboards: Securely exposing internal monitoring and management consoles for developers.
  • Internal APIs: Publishing REST or gRPC APIs that are consumed by other internal services or client applications.

Integration with Microsoft Entra ID​

Entra Private Access is an extension of the Entra ID identity platform, not a replacement for it. The authentication and authorization flow is:

  1. Entra ID authenticates the user and issues a primary refresh token (PRT).
  2. Conditional Access evaluates policies and enforces controls (MFA, compliant device).
  3. Private Access enforces per‑application authorization based on the application’s user/group assignments in Entra ID.

This integration means you manage access for private applications in the same console, with the same tools, as you do for SaaS applications like Microsoft 365 or Salesforce.

Integration with Networking​

Entra Private Access does not replace all of Azure’s networking services; it complements them.

  • Azure VPN Gateway / ExpressRoute: These are network‑level connectivity solutions. Use them for site‑to‑site connectivity between entire networks. Use Private Access for user‑to‑application connectivity without network‑wide access.
  • Azure Bastion: Provides secure, browser‑based RDP/SSH access to Azure VMs without a public IP. Private Access also secures RDP/SSH, but over the Global Secure Access client, and can be extended to on‑premises machines. Bastion is purpose‑built for VM admin access; Private Access covers a broader set of applications.
  • Azure Private Link: Secures access to Azure PaaS services (e.g., Azure SQL, Storage) over a private endpoint in your VNet. Private Access is for self‑hosted applications running on VMs, containers, or on‑premises servers.
  • Azure Firewall / NSGs: These provide network‑layer filtering. Private Access adds identity‑aware, application‑layer access. Use them together: NSGs restrict the connector’s access to only the applications it should proxy, and Private Access enforces identity and device compliance.

Zero Trust Architecture​

Entra Private Access directly implements the core Zero Trust principles:

  • Explicit verification: Every connection is authenticated against Entra ID and authorized against a specific application. Implicit network trust is eliminated.
  • Least privilege access: Users gain access only to the specific applications they need, not to a network segment. Lateral movement is impossible through the access platform itself.
  • Assume breach: The architecture assumes the internal network is hostile. The connector creates an outbound‑only, reverse tunnel, preventing external attackers from scanning for it. If a connector is compromised, its blast radius is limited to the applications in its connector group.
  • Continuous evaluation: The client and edge continuously monitor device health and user risk, terminating access immediately if a security condition changes.

Enterprise Deployment Models​

  • Remote workforce replacement for VPN: Deploy the client to all managed user devices. Publish key internal applications. Decommission the legacy VPN infrastructure for user remote access. This is the primary use case.
  • Hybrid workforce: For employees in the office, the client can operate in a mode where it only captures traffic for published applications, allowing local network resources to be accessed directly. This is a split‑tunnel approach at the application level.
  • Contractor and partner access: Invite external users as guests in your Entra ID tenant. Assign them to only the specific private applications they need. No need to issue managed devices or complex VPN profiles.
  • Developer and platform engineer access: Expose internal CI/CD dashboards, Kubernetes API servers, and private package registries through identity‑aware tunnels, without exposing these tools to the internet.

Microsoft Entra Private Access for AI Workloads​

AI workloads, particularly those involving fine‑tuning or retrieval‑augmented generation (RAG), often use private, sensitive data stores. Exposing these data stores to a public endpoint for AI services to access is a security risk. Entra Private Access provides a secure connectivity pattern:

  • Private model endpoints: Deploy your model inference server on a private VNet. Publish it via Private Access. Only authorized AI applications (which can use a managed identity or a service principal to authenticate through the client) can reach the inference endpoint.
  • Private training clusters: Data scientists working remotely can access internal GPU clusters and JupyterHub notebooks via Private Access, without a VPN.
  • Secure RAG infrastructure: A RAG application running on a container in a private VNet can use Private Access to reach an internal knowledge base, while its user‑facing components use Entra ID for authentication. This creates an identity‑bound, end‑to‑end secure data pipeline.

Common Architecture Patterns​

Hybrid Enterprise ZTNA Replacement​

A large enterprise with a mix of Azure and on‑premises data centers deploys connector groups in each location. All user‑facing private applications are published through Private Access. VPNs are decommissioned for user access, with site‑to‑site links retained only for backend data replication.

Cloud‑first Developer Platform​

A tech company runs all its applications in Azure. The platform team deploys two connectors in the production VNet and two in the non‑production VNet. Developers access internal dashboards, CI/CD tools, and staging environments via Private Access, with Conditional Access policies enforcing MFA and device compliance.

Secure Admin Access (Bastion Replacement)​

Instead of maintaining Azure Bastion hosts for every VM, IT publishes RDP and SSH profiles for critical servers through Private Access. Access is gated behind a Conditional Access policy that requires a phishing‑resistant MFA method and a privileged access workstation.

Partner Extranet Portal​

A pharmaceutical company needs to give external researchers access to a single, sensitive web application. The application is published via Private Access, and the researchers are invited as B2B guests. They access the application through the Global Secure Access Client, never touching the corporate network.

Microsoft Entra Private Access vs Traditional VPN​

FeatureTraditional VPNMicrosoft Entra Private Access
Access modelNetwork‑level (IP/subnet)Application‑level (FQDN/port)
Identity integrationTypically bolted‑on (RADIUS, SAML)Native, deep integration with Entra ID
Device complianceOften missing or a separate posture checkContinuous, integrated with Conditional Access and Intune
Lateral movement riskHigh (user is “on the network”)None (user can only see the specific application proxy)
Firewall portsRequires open inbound ports on the VPN gatewayOutbound‑only (TCP 443) from connectors; no inbound changes needed
User experienceFull tunnel, often forces all traffic through the corporate networkApplication‑split tunneling; only traffic for private apps is captured

Microsoft Entra Private Access vs Azure VPN Gateway​

FeatureAzure VPN GatewayMicrosoft Entra Private Access
Primary use caseSite‑to‑site and point‑to‑site network connectivityUser‑to‑application secure access
Identity awarenessPoint‑to‑site supports Entra ID auth; policies are limitedFully identity‑aware, per‑app Conditional Access
Network accessGrants IP connectivity to the VNetProxies specific TCP connections to applications
Typical userIT admins managing a VNet, legacy app connectivityKnowledge workers accessing specific internal apps
When to chooseYou need to connect entire networks (e.g., for data sync)You need to provide secure, identity‑based access to specific apps for remote users

Microsoft Entra Private Access vs Azure Bastion​

FeatureAzure BastionMicrosoft Entra Private Access
Primary use caseSecure, browser‑based RDP/SSH to Azure VMsIdentity‑based access to a wide range of private applications (RDP, SSH, web, SMB, etc.)
ScopeIndividual Azure VMsAny application reachable by a connector (Azure, on‑prem, other cloud)
Identity modelEntra ID integration for RDP/SSHDeep Entra ID integration with Conditional Access, device compliance, and per‑app assignment
Typical userAdministrators managing VMsAdministrators, knowledge workers, developers

Microsoft Entra Private Access vs Zscaler Private Access (ZPA)​

Zscaler’s ZPA is a well‑established ZTNA solution. The core architecture is similar: a client, a cloud edge, and an on‑premises connector. Zscaler has a broader global network, deeper experience with advanced threat inspection, and a more mature feature set for very large enterprises. Entra Private Access’s primary advantage is its seamless integration with the Microsoft identity and endpoint management stack. For an organization deeply committed to Microsoft 365, Intune, and Entra ID, Private Access can dramatically simplify policy management and reduce the number of security consoles. Zscaler remains a stronger choice for multi‑cloud, heterogeneous environments with complex security requirements beyond Microsoft’s ecosystem.

Microsoft Entra Private Access vs Cloudflare Access​

Cloudflare Access is another leading ZTNA solution. It is built on Cloudflare’s global network, which is one of the largest and fastest. Cloudflare Access offers a very strong developer experience, with deep integrations into identity providers, including Entra ID. Entra Private Access competes by offering a more tightly coupled experience for the Microsoft ecosystem, particularly around device compliance and Conditional Access, which are native rather than relying on third‑party integrations. For a Microsoft‑centric organization, this native integration can be more reliable and easier to troubleshoot.

Best Practices​

  • Publish applications at the most granular FQDN level possible. Instead of publishing a wildcard like *.internal.corp, publish finance.internal.corp and hr.internal.corp separately. This allows you to apply distinct access policies and connector groups.
  • Deploy connectors in pairs for high availability. A single connector is a single point of failure. Use connector groups to manage them.
  • Segment applications using connector groups. Place connectors for sensitive applications (e.g., finance, HR) on dedicated VMs in separate network segments. This provides defense in depth.
  • Enforce device compliance via Conditional Access. The strongest security posture requires that the connecting device is known, managed, and compliant. Use this as a prerequisite for all sensitive applications.
  • Monitor connector health and capacity. Connectors are the data plane. Set up alerts for connector failures and high CPU or memory, which can indicate that you need to scale out.
  • Treat private access as part of your Zero Trust journey. Start with a pilot, publish a few non‑critical applications, and learn the operational model before replacing your entire VPN. This is a cultural and process shift, not just a technology swap.

Common Mistakes​

  • Treating it as a VPN and publishing a broad IP range. This defeats the purpose of ZTNA. Only publish specific application endpoints. Granting access to a /24 subnet gives users network access, not application access.
  • Publishing applications with no Conditional Access policies. An identity‑aware proxy without policy enforcement is just a tunnel. MFA and device compliance are essential.
  • Placing connectors in a network segment without egress rules. The connector must be able to reach the target application on its specific port. Ensure internal firewalls allow this traffic.
  • Deploying a single connector for production workloads. If that connector fails, all access to the associated applications is lost. Always use at least two per connector group.
  • Ignoring the user experience. Moving from a full‑tunnel VPN to per‑app access changes how users work. Clear communication and training are critical to prevent shadow IT.

Practical Learning Path​

  1. Establish a strong foundation in networking fundamentals: DNS, TLS, routing, and proxies.
  2. Study the principles of Zero Trust Architecture and identity‑centric security.
  3. Become proficient with Microsoft Entra ID, Conditional Access, and Microsoft Intune device compliance.
  4. Understand the Microsoft Global Secure Access platform overview and its client.
  5. Deploy a test instance of Entra Private Access. Install a connector in a sandbox environment and publish a simple internal web application.
  6. Configure a Conditional Access policy for the published application that requires MFA and a compliant device.
  7. Observe the traffic flow using network traces and the client logs to internalize the proxy path.
  8. Design a pilot deployment plan to replace a non‑critical VPN use case, starting with a single connector group and a small set of users.

Key Takeaways​

  • Microsoft Entra Private Access is a ZTNA service that provides identity‑aware, application‑level access to private, self‑hosted applications.
  • It replaces legacy VPNs by shifting access control from the network perimeter to the user and device identity, integrated with Microsoft Entra ID and Conditional Access.
  • The architecture is based on an outbound‑only connector model, eliminating inbound firewall rules and reducing the external attack surface.
  • It is part of the Microsoft Global Secure Access platform, working alongside Internet Access to provide a unified SSE solution.
  • For Microsoft‑centric enterprises, it offers a streamlined path to Zero Trust, leveraging existing investments in identity and device management.
  • Successful adoption requires a shift in mindset from network‑level access to granular, per‑application policies and continuous verification.

Further Reading​

Official Documentation​