This chapter covers Microsoft Entra Internet Access and Microsoft Entra Private Access, two key components of the Microsoft Entra Suite that secure access to external and internal resources. For the SC-900 exam, expect approximately 5-10% of questions to touch on these topics under objective 2.5, focusing on their roles, capabilities, and how they differ from traditional VPNs and web proxies. Understanding these services is crucial for implementing a Zero Trust security model in hybrid and remote work environments.
Jump to a section
Imagine a large company with multiple branch offices and remote employees. The company wants to control which packages (traffic) enter and leave, and ensure that sensitive documents are only delivered via a secure, private courier service. The mailroom (Entra Internet Access) sits at the main entrance, screening all incoming and outgoing packages against a list of allowed addresses and content types. It can block packages from known malicious senders or with prohibited content. For sensitive internal documents that must go between branches or to remote workers, the company uses a dedicated, armored courier service (Entra Private Access). This courier only picks up from and delivers to authorized locations, and the packages are encrypted and tracked end-to-end. The mailroom and courier service are managed by a single logistics coordinator (Microsoft Entra admin center), who sets policies for both. Without the mailroom, the company would have no control over external packages; without the secure courier, sensitive documents would have to travel through public mail, risking interception. The mailroom's screening is analogous to conditional access and web content filtering in Entra Internet Access, while the secure courier mirrors the zero-trust network access (ZTNA) capabilities of Entra Private Access, ensuring that only authorized users and devices can access private corporate resources, regardless of location.
What are Entra Internet Access and Private Access?
Microsoft Entra Internet Access and Microsoft Entra Private Access are cloud-delivered security services that form part of the Microsoft Entra Suite. They extend identity-centric security to network traffic, enabling organizations to secure access to both internet (SaaS) and private (corporate) applications without requiring a traditional VPN or on-premises proxy.
Entra Internet Access is a Secure Web Gateway (SWG) that filters outbound internet traffic from managed devices. It enforces conditional access policies based on user identity, device health, and application context, and provides web content filtering, threat protection, and data loss prevention (DLP) for web traffic.
Entra Private Access is a Zero Trust Network Access (ZTNA) solution that replaces traditional VPNs. It allows authorized users and devices to connect to private corporate resources (on-premises or cloud-hosted) based on identity and device compliance, not network location. It uses a lightweight client to establish per-application, encrypted tunnels.
Both services are integrated with Microsoft Entra ID (formerly Azure AD) for identity and conditional access, and with Microsoft 365 Defender for threat intelligence.
How They Work Internally
#### Entra Internet Access Mechanism
Entra Internet Access operates as a reverse proxy or forward proxy, depending on the traffic direction. For outbound internet traffic, it uses a client-side agent installed on Windows and macOS devices. The agent intercepts HTTP/HTTPS requests and forwards them to the Entra Internet Access cloud service, which then evaluates the request against policies.
1. Traffic Interception: The client agent captures outbound web traffic (ports 80 and 443) and redirects it to the nearest Microsoft edge node using a secure tunnel (TLS 1.2/1.3). The agent uses a virtual network interface to intercept traffic, similar to a VPN but only for web protocols. 2. Policy Evaluation: The cloud service inspects the request—including URL, SNI header, and user identity—and checks against policies defined in the Microsoft Entra admin center. Policies include: - Conditional Access: User must be authenticated, device must be compliant, location must be allowed, etc. - Web Content Filtering: Block categories like malware, phishing, adult content, or custom URL lists. - Threat Protection: Integration with Microsoft Defender for Cloud Apps (MDA) to detect and block malicious traffic. 3. Forwarding or Blocking: If the request is allowed, the cloud service forwards it to the internet destination, acting as a proxy. The destination sees the request coming from Microsoft's IP range, not the user's. The response is inspected before being returned to the client. 4. Logging: All traffic is logged and can be viewed in the Microsoft 365 Defender portal for investigation and reporting.
#### Entra Private Access Mechanism
Entra Private Access uses the same client agent but handles traffic to private IP ranges (RFC 1918) or designated private domains. It implements a Zero Trust model where no implicit trust is granted based on network location.
Client Connection: The user authenticates to Entra ID via the client agent. The agent then establishes a secure, mutually authenticated TLS tunnel to the Microsoft Entra Private Access cloud service. This tunnel is persistent and uses certificate-based authentication.
Application Discovery: The cloud service maintains a list of private applications (defined as Quick Access apps) with their internal IP addresses and ports. The client agent receives a routing table that maps these applications to the tunnel.
Per-Application Tunnels: When the user attempts to access a private application (e.g., by IP or FQDN), the agent creates a separate encrypted channel (DTLS or TLS) to the cloud service, which then forwards traffic to the application's connector installed on-premises. This ensures that the user only accesses specified applications, not the entire network.
Connector: An on-premises connector (lightweight service running on Windows Server) establishes outbound connections to the cloud service. It receives traffic and forwards it to the internal application. The connector never listens on a port, reducing the attack surface.
Continuous Access Evaluation (CAE): If the user's identity or device compliance changes during a session, the cloud service can revoke access in near real-time (within minutes).
Key Components and Defaults
Client Agent: Available for Windows 10/11 and macOS. It consumes approximately 50-100 MB RAM and uses minimal CPU. Default tunnel protocol is DTLS (UDP 443) with fallback to TLS (TCP 443).
Connector: Requires Windows Server 2016 or later. One connector can handle up to 1000 concurrent connections. For high availability, deploy at least two connectors per site.
Quick Access: A feature in Private Access that groups applications by domain or IP range. Up to 500 Quick Access apps per tenant.
Conditional Access Policies: Use the "Require compliant device" condition; default session control is "Use app enforced restrictions."
Web Content Filtering Categories: Over 60 categories, including Malware, Phishing, Adult, Social Networking, etc. Default action is to alert but allow; can be changed to block.
Log Retention: 30 days for free; up to 90 days with add-on licensing.
Configuration and Verification
Configuration is done via the Microsoft Entra admin center under Identity > Security > Internet Access and Private Access. Key steps:
Enable the services in the tenant (requires appropriate license: Microsoft Entra Suite license or standalone add-ons).
Install the client agent on user devices via Intune or manual download.
Configure Quick Access apps for Private Access (define FQDNs or IP ranges).
Set up Conditional Access policies targeting the Entra Internet Access or Private Access app.
Deploy connectors for Private Access on-premises.
Verification can be done using: - Test connectivity: From a client device, browse to a blocked site to confirm filtering. - Logs: In Microsoft 365 Defender > Cloud Apps > Activity logs, filter by 'Entra Internet Access'. - Client status: In the client agent UI, check connection status ('Connected' vs 'Disconnected'). - Connector health: In admin center under Private Access > Connectors, verify status is 'Active'.
Interaction with Related Technologies
Microsoft Entra ID: Both services rely on Entra ID for authentication and conditional access. Policies are applied per user/group.
Microsoft Defender for Cloud Apps (MDA): Entra Internet Access feeds logs to MDA for advanced threat detection. MDA can also enforce session controls (e.g., block download) for SaaS apps.
Microsoft Intune: Used to deploy the client agent and enforce device compliance policies.
Azure AD Application Proxy: Both provide remote access to private apps, but App Proxy uses a reverse proxy without a client agent, while Private Access uses a client-based ZTNA approach. Private Access is newer and more aligned with Zero Trust.
Traditional VPN: Unlike VPN, Private Access does not place the user on the corporate network; it only allows access to specific applications. This reduces lateral movement risk.
Exam-Relevant Numbers and Details
Ports: Client uses UDP 443 (DTLS) or TCP 443 (TLS). Connector uses outbound TCP 443 to Azure.
Protocols: HTTP/HTTPS for Internet Access; TCP/UDP for Private Access (any port defined in Quick Access).
Licensing: Entra Internet Access and Private Access are included in Microsoft Entra Suite (E5 equivalent) or as standalone add-ons (Entra Internet Access P1/P2, etc.).
Client OS: Windows 10 20H2+, macOS 11+.
Connector: Windows Server 2016+, .NET Framework 4.7.2+, 4 GB RAM recommended.
Maximum Quick Access apps: 500 per tenant.
Concurrent sessions per connector: ~1000.
Latency: Typically <20 ms added to internet traffic.
Step-by-Step Traffic Flow for Private Access
User on a managed Windows device launches a client application that tries to connect to an internal server at 10.0.1.50:3389 (RDP).
The Entra Private Access client agent intercepts the connection attempt because the destination IP matches a Quick Access app defined in the tenant.
The agent checks if an existing secure tunnel to the cloud service exists; if not, it authenticates the user via Entra ID using device certificate.
The agent establishes a DTLS tunnel to the nearest Microsoft Entra Private Access edge node.
The cloud service verifies the user and device meet Conditional Access policies (e.g., MFA required, device compliant).
The cloud service looks up the Quick Access app and finds the associated connector (on-premises server) that can reach 10.0.1.50.
The cloud service forwards the traffic to the connector over an outbound TLS connection initiated by the connector.
The connector forwards the traffic to the internal server 10.0.1.50:3389.
The response follows the reverse path: connector -> cloud service -> client agent -> user.
If the user's device becomes non-compliant (e.g., antivirus disabled), CAE triggers and the cloud service terminates the session within minutes.
User Authentication and Tunnel Setup
The user initiates a connection to a private resource. The client agent, already running on the device, detects the destination IP matches a Quick Access app. The agent prompts the user to authenticate via Entra ID (if not already authenticated). Authentication uses OAuth 2.0 device authorization grant. Once authenticated, the agent establishes a DTLS tunnel to the nearest Microsoft edge node. The tunnel is mutually authenticated using client and server certificates issued by Microsoft. The tunnel uses UDP 443, but falls back to TCP 443 if UDP is blocked. This process takes approximately 2-5 seconds under normal conditions.
Policy Evaluation by Cloud Service
The cloud service receives the tunneled traffic and extracts the user identity, device ID, and destination IP:port. It evaluates Conditional Access policies that target the 'Entra Private Access' cloud app. Policies may require multi-factor authentication, device compliance (e.g., BitLocker enabled), and allowed locations. If any policy is not satisfied, the cloud service sends a block response to the agent, and the user sees an access denied message. The evaluation is done in real-time, typically under 1 second. The cloud service also checks if the user has been assigned to the Quick Access app.
Connector Selection and Traffic Forwarding
If policies are satisfied, the cloud service selects an available connector that can reach the target application. Connectors are grouped by site (e.g., 'New York HQ') and the cloud service uses a round-robin algorithm to distribute load. The connector must have an active outbound TLS connection to the cloud service (established at startup). The cloud service forwards the encrypted traffic to the selected connector. The connector decrypts the traffic (using its private key) and forwards the original TCP/UDP packets to the internal application. If the target is unreachable, the connector returns an error to the cloud service, which then tries another connector or fails the connection.
Application Response and Return Path
The internal application sends its response back to the connector. The connector encrypts the response using the session keys and sends it back to the cloud service over the same TLS connection. The cloud service forwards the encrypted response to the client agent via the DTLS tunnel. The agent decrypts the response and delivers it to the user's application. The entire round-trip adds approximately 10-30 ms of latency, depending on geographic distance. The connector maintains a mapping of user sessions to internal connections, allowing it to handle multiple concurrent sessions.
Session Monitoring and Termination
While the session is active, the cloud service monitors for changes in user risk or device compliance via Continuous Access Evaluation (CAE). If the user's risk level rises (e.g., detected as compromised) or the device becomes non-compliant, the cloud service sends a terminate command to both the client agent and the connector. The agent closes the DTLS tunnel, and the connector drops the internal connection. The user is forced to re-authenticate if they try to reconnect. Idle sessions are terminated after a configurable timeout (default 60 minutes). The cloud service logs all session events to the Microsoft 365 Defender portal.
Scenario 1: Securing Remote Access for a Healthcare Organization
A hospital network with 5,000 employees needs to provide remote access to an electronic health records (EHR) system hosted on-premises. Previously, they used a legacy VPN that gave remote users full network access, leading to several ransomware incidents via lateral movement. They deploy Entra Private Access with the following configuration:
Quick Access app: Define the EHR server's IP (10.10.10.50) and port 443 (HTTPS).
Conditional Access: Require MFA and device compliance (device must be managed by Intune, with disk encryption enabled).
Connectors: Two Windows Server 2019 VMs in the hospital's DMZ, each with 4 vCPUs and 8 GB RAM, handling up to 1000 concurrent sessions each.
Client Agent: Deployed via Intune to all Windows 11 laptops.
Outcome: Remote users can access the EHR application without being placed on the hospital's internal network. The hospital's security team can monitor all access attempts in the Microsoft 365 Defender portal. During a phishing attack, one user's device was flagged as high risk; CAE terminated the session within 2 minutes, preventing potential data exfiltration.
Common Pitfall: Initially, the connectors were placed behind a NAT firewall that blocked outbound UDP 443, causing frequent tunnel drops. The team switched to TCP 443 fallback and opened the necessary ports.
Scenario 2: Enforcing Internet Access Policies for a Financial Firm
A financial services firm with 2,000 users wants to block access to high-risk websites and enforce DLP for cloud storage apps. They deploy Entra Internet Access:
Policies: Enable web content filtering to block categories like 'Malware', 'Phishing', 'Adult', and 'Social Networking'. Create custom URL lists to block known gambling sites.
Conditional Access: Require that all internet traffic from non-corporate devices be routed through Entra Internet Access (using the client agent).
Integration: Logs are fed to Microsoft Defender for Cloud Apps to detect anomalous behavior.
Outcome: The firm reduces malware infections by 60% within three months. Users attempting to access blocked sites see a branded block page. The security team receives alerts when a user tries to upload sensitive data to unauthorized cloud apps.
Common Pitfall: Some users bypassed the client agent by using personal devices. The firm enforced device compliance via Intune and blocked access to corporate resources from non-compliant devices.
Scenario 3: Merging Two Companies with Different Network Infrastructures
After a merger, Company A (using traditional VPN) and Company B (using Entra Private Access) need to provide employees with access to both networks. They deploy Entra Private Access across both companies:
Quick Access apps: Define all internal applications from both companies (e.g., SAP, HR portal, file servers).
Connectors: Deploy connectors in both on-premises data centers.
Conditional Access: Apply the same policies to all users, regardless of which company they were from.
Outcome: Users from Company A can access Company B's applications without needing a separate VPN. The merged IT team manages access centrally. The migration from Company A's VPN is phased over six months.
Common Pitfall: IP address conflicts between the two companies' internal networks (e.g., both use 10.0.0.0/8). They resolved this by using FQDNs instead of IPs in Quick Access apps and ensuring DNS resolution worked correctly.
What SC-900 Tests on Entra Internet Access and Private Access (Objective 2.5)
The exam focuses on conceptual understanding rather than deep technical configuration. Key areas:
Differentiate between Entra Internet Access and Entra Private Access: Know that Internet Access secures outbound web traffic (SWG), while Private Access secures inbound traffic to private apps (ZTNA).
Understand the Zero Trust principle: Both services enforce 'never trust, always verify' by requiring authentication and authorization for every request, regardless of network location.
Identify the benefits over traditional VPNs: Private Access provides per-application access, reduces lateral movement, and integrates with Conditional Access.
Know the licensing requirements: Entra Internet Access and Private Access are part of Microsoft Entra Suite (E5 equivalent) or available as add-ons.
Recognize the client agent and connector roles: Client agent is on user devices; connector is on-premises.
Understand integration with Conditional Access: Policies can target these services as cloud apps.
Common Wrong Answers and Why Candidates Choose Them
"Entra Internet Access replaces the need for a firewall." – Wrong. It secures outbound web traffic but does not replace a network firewall for inbound traffic or non-web protocols. Candidates mistake it for a full NGFW.
"Entra Private Access is a traditional VPN replacement that gives full network access." – Wrong. It provides per-application access, not full network access. Candidates assume it works like a VPN.
"Both services require on-premises connectors." – Wrong. Only Private Access requires connectors. Internet Access is fully cloud-based. Candidates confuse the two.
"Entra Internet Access can block all internet traffic." – Wrong. It only blocks web traffic (HTTP/HTTPS). Other protocols (e.g., SMTP, FTP) are not filtered. Candidates overestimate its scope.
Specific Numbers and Terms That Appear on the Exam
Ports: UDP 443 (DTLS) and TCP 443 (TLS) for client; TCP 443 for connector outbound.
Client OS: Windows 10/11, macOS 11+.
Connector OS: Windows Server 2016+.
Maximum Quick Access apps: 500 per tenant.
Concurrent sessions per connector: ~1000.
Log retention: 30 days (free), up to 90 days (paid).
Terms: 'Quick Access', 'Connector', 'Client Agent', 'Continuous Access Evaluation (CAE)'.
Edge Cases and Exceptions the Exam Loves to Test
What happens if the client cannot establish a DTLS tunnel? It falls back to TLS (TCP 443).
Can Entra Internet Access filter non-web traffic? No, only HTTP/HTTPS.
Does Private Access require the client to be on the corporate network? No, it works from any internet connection.
Can multiple connectors be used for load balancing? Yes, the cloud service distributes connections across available connectors.
What happens if a connector goes offline? The cloud service routes traffic to other connectors; if none are available, connections fail.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If an answer mentions 'full network access' or 'network-level tunnel', it's likely wrong for Private Access (which is per-app).
If an answer says 'blocks all internet protocols', it's wrong for Internet Access (only web).
If an answer claims 'no client software needed', it's wrong for both (client agent required).
If an answer says 'replaces VPN entirely', it's partially true but remember that Private Access is a ZTNA replacement, not a full VPN replacement (some legacy apps may still require VPN).
Entra Internet Access is a cloud-delivered Secure Web Gateway for outbound web traffic; it filters HTTP/HTTPS based on identity and content policies.
Entra Private Access is a Zero Trust Network Access solution that provides per-application access to private resources without placing users on the network.
Both services require a client agent on Windows or macOS devices; only Private Access needs on-premises connectors.
Private Access uses DTLS on UDP 443 with fallback to TLS on TCP 443; connectors use outbound TCP 443.
Conditional Access policies can target both services as cloud apps, enabling MFA, device compliance, and location-based controls.
Continuous Access Evaluation (CAE) can revoke access in near real-time when risk changes.
Quick Access in Private Access defines the set of private applications, with a maximum of 500 per tenant.
Each connector can handle approximately 1000 concurrent sessions; deploy at least two for high availability.
Entra Internet Access logs are retained for 30 days (free) and up to 90 days with add-on licensing.
These services are part of the Microsoft Entra Suite, requiring appropriate licensing (E5 or standalone add-ons).
These come up on the exam all the time. Here's how to tell them apart.
Entra Internet Access
Secures outbound web traffic (HTTP/HTTPS) from managed devices.
Acts as a Secure Web Gateway (SWG) with web content filtering and threat protection.
No on-premises components; fully cloud-based.
Policies control which websites users can visit and block malicious content.
Integrates with Microsoft Defender for Cloud Apps for DLP and session control.
Entra Private Access
Secures inbound access to private corporate applications (any TCP/UDP port).
Acts as a Zero Trust Network Access (ZTNA) solution, replacing VPNs.
Requires on-premises connectors to route traffic to internal apps.
Policies grant per-application access based on identity and device compliance.
Integrates with Conditional Access and Continuous Access Evaluation for real-time enforcement.
Mistake
Entra Internet Access can filter all internet traffic, including non-web protocols.
Correct
Entra Internet Access only inspects HTTP and HTTPS traffic (ports 80 and 443). Non-web protocols like SMTP, FTP, or custom TCP/UDP traffic are not filtered. For full traffic inspection, a traditional firewall or NGFW is required.
Mistake
Entra Private Access gives users full network access like a VPN.
Correct
Private Access uses a Zero Trust model that grants access only to specific applications defined in Quick Access. Users cannot access any other IP on the network. This prevents lateral movement, unlike a VPN that places the user on the network.
Mistake
Both Entra Internet Access and Private Access require on-premises connectors.
Correct
Only Entra Private Access requires on-premises connectors to reach private applications. Entra Internet Access is fully cloud-based and does not use connectors. The client agent is required for both.
Mistake
Entra Internet Access and Private Access are the same service with different names.
Correct
They are separate services with different purposes. Internet Access is a Secure Web Gateway for outbound web traffic; Private Access is a ZTNA solution for inbound access to private apps. They share the same client agent but have different configurations and policies.
Mistake
The client agent works on any operating system.
Correct
The client agent is currently supported only on Windows 10/11 and macOS 11+. Linux, iOS, and Android are not supported. Devices without the agent must use a different method (e.g., browser-based access) or are not protected.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Entra Internet Access is a cloud-based Secure Web Gateway that integrates with identity and conditional access, whereas a traditional web proxy is often on-premises and does not inherently consider user identity or device health. Entra Internet Access provides per-user policies, threat intelligence from Microsoft, and DLP capabilities, making it more aligned with Zero Trust. Traditional proxies typically require manual configuration and lack integration with modern identity providers.
Entra Private Access can handle any TCP or UDP application, including legacy applications that use non-web protocols. However, it works best for applications that can be accessed via IP address or FQDN. For web applications, it can also be used, but Microsoft also offers Azure AD Application Proxy for browser-based access without a client agent. Private Access requires the client agent to be installed on the device.
No, the client agent is required to intercept and redirect web traffic to the Entra Internet Access cloud service. Without the agent, the device's traffic goes directly to the internet, bypassing policies. For unmanaged devices, you can use conditional access to block access or require browser-based protection via Microsoft Defender for Cloud Apps, but full filtering requires the agent.
If a connector fails, the cloud service will attempt to route traffic to other available connectors in the same site. If no connectors are available, new connections will fail. Existing sessions through the failed connector will be terminated. To avoid this, deploy at least two connectors per site for high availability. Connectors should be on different physical servers to prevent single points of failure.
No, Entra Internet Access is not a replacement for a network firewall. It only filters outbound web traffic (HTTP/HTTPS). A firewall provides network-layer filtering for all protocols, inbound and outbound, and can block traffic based on IP addresses and ports. Entra Internet Access complements a firewall by adding identity-aware web filtering and threat protection.
Entra Private Access does not provide DNS resolution for private domains. The client device must be able to resolve the private application's FQDN to its internal IP address. This can be done via a corporate DNS server accessible from the client (e.g., via a DNS connector) or by using a split-DNS configuration. Alternatively, you can define Quick Access apps using IP addresses instead of FQDNs.
Both services are included in the Microsoft Entra Suite license, which is part of Microsoft 365 E5. They are also available as standalone add-ons: Entra Internet Access P1 (basic filtering) and P2 (advanced threat protection), and Entra Private Access P1 and P2. Check Microsoft's licensing documentation for specific features per license.
You've just covered Entra Internet Access and Private Access — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?