Microsoft Entra Private Access: ZTNA VPN Replacement for Small Businesses in Berlin
Traditional VPNs were designed for an era when all resources lived inside a corporate perimeter and all users sat inside an office. That era is over. Berlin small businesses today have employees in home offices, coworking spaces, and client sites — accessing cloud applications, Azure-hosted resources, and on-premises systems through a single VPN tunnel that grants access to the entire network if compromised. Microsoft Entra Private Access replaces that model with Zero Trust Network Access (ZTNA): per-application access policies enforced at the identity layer, with no implicit network trust granted to any connected device.
This guide explains how Entra Private Access works, how it compares to a traditional VPN, how it integrates with Conditional Access and device compliance, and how Berlin businesses can deploy it without replacing their existing infrastructure.
What Is Entra Private Access?
Microsoft Entra Private Access is the ZTNA component of Microsoft Entra Global Secure Access — Microsoft’s Security Service Edge (SSE) platform. Where a VPN creates a network tunnel from device to corporate network, Entra Private Access creates an application-level proxy: the user authenticates through Entra ID and is granted access to a specific application or service, not to the network as a whole.
The architecture has three components:
- Global Secure Access client: a lightweight agent installed on managed Windows, macOS, iOS, and Android devices. It intercepts traffic destined for private resources and routes it through the Global Secure Access service
- Private Network Connector: a connector service installed on a Windows Server (on-premises or Azure-hosted) with line-of-sight to the private resources being published. Similar to Microsoft Entra application proxy connectors, these are outbound-only — no inbound firewall rules required
- Entra Private Access service: Microsoft’s cloud service that brokers connections between the client and the connector, enforcing Conditional Access policies at every access request
How It Differs from a VPN
| Dimension | Traditional VPN | Entra Private Access (ZTNA) |
|---|---|---|
| Access scope | Full network access after authentication | Per-application access only |
| Implicit trust | Any device on the tunnel can reach any resource | No implicit trust; every request verified against CA policy |
| Device compliance | Typically not enforced post-connection | Intune compliance checked on every access request |
| User identity | Username/password at tunnel establishment | Entra ID MFA + Conditional Access on every session |
| Lateral movement | Compromised device has full network access | Compromised device can access only explicitly granted apps |
| Infrastructure | VPN concentrators, firewall rules, split tunnelling config | Connector software on existing server; no perimeter changes |
| Monitoring | Network traffic logs, per-device | Per-user, per-application Entra sign-in log with full CA context |
The lateral movement row is the critical operational difference for small businesses. A single phished user with VPN access can pivot to any server, file share, or database on the network. The same phished user with Entra Private Access access can reach only the specific applications their policies permit — the blast radius of a compromise is contained at the policy layer before any lateral movement is possible.
Quick Access vs Application Segments
Entra Private Access provides two access modes:
Quick Access is the migration mode. You define the IP subnets and FQDN patterns that represent your private network, and the Global Secure Access client routes all traffic matching those patterns through the Entra Private Access broker. This replicates VPN behaviour but with Entra ID authentication and Conditional Access enforcement added. Quick Access is the fastest path to deploying Entra Private Access — it works with existing network segmentation without requiring per-application configuration.
Application Segments is the ZTNA end state. Each private application (an RDP host, an internal web application, a file server SMB share, a specific SQL Server) is defined as a Global Secure Access application with its own Conditional Access policy. Different applications can have different access requirements: the HR system might require Intune-compliant device + phishing-resistant MFA, while an internal wiki might require only standard MFA. Users are never on a “network” — they have access to named applications with explicitly scoped policies.
Conditional Access Integration
Every connection through Entra Private Access is governed by a Conditional Access policy. The same CA engine that controls access to Microsoft 365, Azure portal, and third-party SAML applications controls access to on-premises RDP, internal web applications, and file server shares. This is the architectural advantage over VPN: access policy is a single pane of glass in the Entra ID Conditional Access blade, not a combination of VPN ACLs, firewall rules, and AD group memberships spread across multiple systems.
Useful Conditional Access policies for Entra Private Access:
- Require Intune-compliant device for all private application access (blocks BYOD devices from accessing corporate resources)
- Require phishing-resistant MFA (FIDO2 or Windows Hello for Business) for privileged management applications like domain controller RDP
- Block access from outside Germany for applications handling GDPR-regulated personal data
- Require re-authentication every 4 hours for high-value applications (prevents session persistence after a device is compromised)
Private Network Connector Deployment
The Private Network Connector is a lightweight Windows service that acts as the outbound bridge from your network to the Global Secure Access service. Key deployment characteristics:
- Outbound-only: connectors initiate outbound HTTPS connections to Microsoft’s Global Secure Access service. No inbound firewall rules are required, and the connector does not expose any port to the internet
- High availability: deploy two or more connectors per connector group; the service load-balances across available connectors. If one fails, sessions fail over to the remaining connector automatically
- Placement: install on a Windows Server with network access to the resources being published. For Azure-hosted resources, a connector in the same VNet is optimal. For on-premises resources, a connector in the same datacenter or on the same LAN segment is preferred for latency
- Connector traffic: each connector forwards only the traffic from authorised user sessions — it does not forward any traffic by default. Only sessions matching a published application or Quick Access configuration are forwarded
Entra Internet Access: The Paired Service
Entra Private Access (ZTNA for private resources) is paired with Entra Internet Access (Secure Web Gateway for internet traffic) in the Global Secure Access platform. Together they provide a complete Security Service Edge: private resource access through ZTNA, internet access through an SWG with web content filtering, TLS inspection, and Microsoft 365 traffic optimisation.
For Berlin businesses currently using a proxy or firewall for web filtering, Entra Internet Access can replace that infrastructure for managed devices — routing all internet traffic through Microsoft’s global network with tenant-level web category filtering, malicious URL blocking, and detailed per-user traffic logs in the Entra admin centre.
GDPR Considerations
Entra Private Access sign-in logs — which include user identity, device, IP address, application accessed, and CA policy result — are stored in Entra ID audit logs with EU data residency when the tenant’s Entra ID data location is set to Germany. These logs contain personal data (user identity and IP address) and should be treated accordingly under GDPR Article 5 data minimisation: configure audit log retention policies to retain only as long as operationally necessary, typically 90–180 days for security monitoring purposes.
Deployment Steps for Berlin Small Businesses
- Entra admin centre → Global Secure Access → Get started → Activate Global Secure Access (requires Entra ID P1 or higher)
- Install the first Private Network Connector: Global Secure Access → Connect → Connectors → Download connector → install on a Windows Server with network access to your private resources
- Configure Quick Access: Global Secure Access → Applications → Quick Access → add the IP subnets and FQDNs of your private network
- Create a Conditional Access policy: Entra admin centre → CA → New policy → Assign to all users → Target resource: Global Secure Access (all private access traffic) → Grant: require MFA + require compliant device
- Deploy the Global Secure Access client to managed devices via Intune: Apps → Windows apps → add MSI → deploy to All Devices or a pilot group
- Verify connectivity: from a managed device, access a private resource (internal website, file share) and confirm the connection routes through the Global Secure Access service (visible in the system tray client)
- Gradually migrate from Quick Access to Application Segments: create individual application definitions with tailored CA policies for each resource
Entra Private Access is the network access enforcement layer in a Zero Trust architecture, removing implicit trust from the network layer and replacing it with explicit, identity-governed, per-application policies. For organisations already using Conditional Access to govern cloud application access, extending those same policies to on-premises resources through Entra Private Access creates a consistent access control posture across the entire application estate.