Microsoft Entra Internet Access and Microsoft Entra Private Access are the two core Security Service Edge capabilities inside Global Secure Access. The current SC-100 guide explicitly asks architects to evaluate both, while SC-300 supplies the identity and Conditional Access foundation. The key difference is destination: Internet Access secures public internet and SaaS traffic, while Private Access provides Zero Trust access to private applications and resources.
Together they converge identity, endpoint, and network access policy. They are not interchangeable VPN replacements. Internet Access behaves as an identity-aware secure web gateway for internet destinations. Private Access is a ZTNA service for internal resources over supported TCP and UDP paths. The ZTNA concept is therefore most directly aligned with Private Access, while Internet Access maps to the secure-web-gateway side of SSE.
Global Secure Access is the umbrella for both services
Global Secure Access is the Microsoft Entra admin-center experience that brings together Microsoft traffic, Internet Access, and Private Access traffic profiles. The Global Secure Access client or remote-network connectivity can acquire supported traffic and send it through Microsoft’s Security Service Edge infrastructure for policy enforcement.
Architects should design traffic acquisition first. The Windows, macOS, and mobile clients plus supported remote-network scenarios do not all acquire identical traffic in identical ways, so rollout plans should be platform-aware. Document which traffic profiles are expected on each device class and how users fall back when the client is unavailable. If the correct traffic profile is not enabled or the device or branch is not forwarding the intended flow, Conditional Access and security policy in Global Secure Access cannot protect that traffic. Policy design begins with understanding which packets the service will actually see.
Internet Access protects public internet and SaaS traffic
Microsoft Entra Internet Access provides an identity-centric Secure Web Gateway for web and internet destinations. It supports web content filtering, traffic logging, security profiles, Conditional Access integration, and controls for public destinations that do not necessarily federate with Microsoft Entra ID.
This makes Internet Access appropriate for browsing, SaaS applications, public APIs, and other internet traffic where the organization wants cloud-delivered web protection and user-aware policy. It can also support compliant-network checks and universal Conditional Access scenarios where the organization wants network location to become a continuously evaluated signal rather than a fixed office IP range. It is not the service for reaching a private RFC1918 application inside a data center.
Private Access protects internal apps and resources
Microsoft Entra Private Access provides Zero Trust Network Access to private corporate resources without requiring users to join a broad network-level VPN. Administrators define FQDNs, IP ranges, ports, and private applications, then use private network connectors and Conditional Access to broker access.
Private Access supports Quick Access for broader private-resource ranges and per-app access for more granular segmentation. Per-app definitions can specify FQDNs, IP addresses, ports, and protocols, which makes the policy closer to application identity than a traditional full-network VPN. Use named application containers and group assignments so access reviews remain understandable. Microsoft recommends Quick Access as a transition mechanism and per-app access for tighter Zero Trust segmentation as organizations mature.
Private network connectors are the bridge to internal resources
Private Access uses connectors or connector groups that maintain outbound connectivity from the private environment to the service. This avoids exposing an inbound VPN gateway or application listener directly to remote users. Connector placement, redundancy, DNS resolution, and reachability to the protected applications therefore become important architecture decisions.
Deploy multiple connectors where availability requires it and place them near the resources they serve. Connector groups can align with geography or application zones, and outbound connectivity requirements should be treated as production dependencies. Monitor connector health and DNS resolution because a private application can fail even when user authentication and Conditional Access succeed. A user can be fully authenticated and compliant while the application remains unreachable if connectors cannot resolve the name, reach the service, or handle the required port.
Conditional Access adds identity and device context to network access
Both Internet Access and Private Access integrate with Conditional Access so policy can consider user identity, device compliance, risk, location, and other supported signals. Keep device-compliance policy separate from network policy: Intune decides whether the device is compliant, Entra evaluates access conditions, and Global Secure Access acquires and enforces the relevant network path. This is the core architectural advantage over a network rule based only on source IP.
The deeper logic in Microsoft Entra Conditional Access still applies: test policies in report-only mode, exclude emergency accounts appropriately, and avoid building one massive rule that is impossible to troubleshoot. Global Secure Access extends those identity decisions to network traffic.
Internet Access policies focus on web destinations and categories
Internet Access can apply policy to web categories, FQDNs, and security profiles for public destinations. It can protect internet traffic even when the target application has no Entra federation because traffic is acquired at the network layer and associated with the user and device.
This creates a different policy model from SaaS application sign-in alone. Web-category policy can block a public destination even when the user would otherwise be allowed to authenticate to it, while Conditional Access can require stronger conditions for selected resources. Architects should define which layer owns acceptable-use filtering, threat blocking, and identity-based access. Architects should distinguish authentication policy for the SaaS application from network policy for reaching the destination. The two can complement each other, but one does not replace the other.
Private Access should reduce lateral reach, not recreate a full-tunnel VPN
The strongest Private Access design defines specific applications or resource groups and assigns only the users who need them. Include service accounts, administrators, and noninteractive workflows in the design if they need private connectivity; user-focused ZTNA does not automatically solve machine-to-machine application access. A legacy VPN often gives a remote user broad network reach after connection; ZTNA should narrow that access to the required destination and protocol.
Quick Access can help with migration, but treat it as a stepping stone. Over time, move important applications into per-app definitions, apply Conditional Access, and remove broad ranges that allow unnecessary east-west reachability.
Coexistence and migration should be planned in controlled waves
The Global Secure Access client can coexist with many other network-access technologies because traffic profiles determine what Microsoft acquires. This supports phased migration from VPN, DirectAccess, or another SSE platform rather than a one-day cutover.
Test route and tunnel conflicts, local DNS, proxy configuration, split-tunnel behavior, captive portals, and endpoint security clients. Use traffic logs and Conditional Access logs together during pilots so engineers can see whether failure happened before traffic reached Global Secure Access, during policy evaluation, at the private connector, or at the destination application. Migration should include fallback and telemetry so support teams can tell whether a failed connection is caused by client traffic acquisition, Conditional Access, the connector, DNS, or the application itself.
Choose Internet Access or Private Access from the resource boundary
Use Internet Access when the destination is public internet or SaaS and the goal is secure web gateway policy, visibility, and identity-aware access. Use Private Access when the destination is private and the goal is application-level Zero Trust access without broad VPN network presence. Use both when users need controlled access to both categories.
Global Secure Access is most effective when the identity, endpoint, and network teams agree on ownership. Add change control for traffic profiles, security profiles, connector groups, and per-app definitions because a network change can alter which Conditional Access policies are evaluated. The service converges control planes, so governance has to converge too. Define who manages traffic profiles, Conditional Access, web policy, private app definitions, connectors, and troubleshooting. SSE architecture becomes simpler when each service has a precise destination boundary and the control layers are documented.
A production rollout should define service-level monitoring for client health, traffic-profile acquisition, connector availability, DNS resolution, Conditional Access result, and destination reachability. Support teams need a troubleshooting flow that starts with the user’s resource type—public internet, Microsoft service, or private app—then follows the matching traffic profile. That prevents a Private Access connector problem from being misdiagnosed as an Internet Access policy issue, or a Conditional Access denial from being treated as a network outage.
Licensing and rollout scope also affect the architecture. Internet Access, Internet Access for Microsoft services, and Private Access have different entitlement paths and traffic profiles. Pilot with users in multiple locations and device types, then expand in rings. Validate coexistence with current VPN, proxy, DNS, endpoint protection, and branch-network technologies before enforcing compliant-network or universal Conditional Access conditions broadly.
Finally, design the transition with explicit rollback. If Global Secure Access causes an unexpected compatibility issue, support teams should know whether to disable a traffic profile, remove a pilot assignment, fall back to the existing VPN or proxy, or bypass one application temporarily. Controlled rollback prevents troubleshooting pressure from turning into ad-hoc broad exclusions that undermine the Zero Trust objective.
DNS is especially important for Private Access because users often address private applications by FQDN while the connector must resolve and reach the actual service. Validate split DNS, private zones, suffix search behavior, and application certificates during pilots. If name resolution differs between the endpoint, connector network, and application environment, the user can pass Conditional Access and still receive a connection failure that looks like a policy problem.
Build rollback into the migration design. If Global Secure Access causes an unexpected compatibility issue, support teams should know whether to remove a pilot assignment, disable a traffic profile, temporarily use the existing VPN or proxy, or bypass one application while preserving other protections. Controlled rollback prevents troubleshooting pressure from turning into broad permanent exclusions. Track client health, connector availability, Conditional Access results, and destination reachability as separate signals so the support path follows evidence.
Licensing and feature scope should also be checked before rollout. Internet Access for Microsoft traffic, broader Internet Access, and Private Access have different service and traffic-profile requirements. Pilot with multiple device types, user populations, and locations, then expand in rings. The architecture should document which team owns traffic acquisition, web policy, Conditional Access, private-app definitions, and connector infrastructure so one converged service does not create an unowned control plane.