For years the network and the identity were governed by different teams with different tools, and the seam between them was where attackers lived. Global Secure Access is Microsoft’s attempt to close that seam by making the network path itself something the identity system authorizes, so that reaching a resource is not a matter of being on the right network but of being the right principal. It is the point where the perimeter this series has been describing stops being a metaphor and becomes an actual gate on the wire.
This article opens a series, and it also sits where the identity work meets the endpoint work. The endpoint articles touched Global Secure Access as a networking capability and used its private-access side to give cloud-joined Windows devices a path to a domain controller for cloud Kerberos trust. This piece treats it from the identity direction: what it is, what the pieces do, which of them you can take without the others, and why an identity practitioner should care about a product that looks, at first glance, like networking.
One category, two products
Global Secure Access is the umbrella name for Microsoft’s security service edge, and underneath it are two products that share a client and a control plane but solve opposite problems. Entra Internet Access governs traffic going out, to the open internet and to software as a service, acting as an identity-aware secure web gateway that can filter by category, apply threat intelligence to where users are allowed to go, and inspect the encrypted sessions themselves. Entra Private Access governs traffic going in, to the private resources an organization used to expose through a virtual private network, replacing that broad network tunnel with per-application access that never puts the user on the network at all. The unifying idea, and the reason both live under one roof, is that in each direction the traffic is authorized against an Entra identity rather than against an address or a network location.
Two products, but three things you switch on. Traffic is acquired by traffic forwarding profiles, and there are three of them: a Microsoft traffic profile for Microsoft’s own services, a Private Access profile, and an Internet Access profile. They are evaluated in that order, and anything matching none of them is not forwarded at all and simply goes wherever it would have gone anyway. The Microsoft profile is the one included with the premium identity licensing most organizations already hold; the other two are separately licensed and also bundled into the identity suite.
There is also a fourth profile you never see and cannot switch off. A system-managed Microsoft Entra traffic profile turns on automatically the moment any other profile is active, is processed at the highest priority using mutual TLS, needs no assignment, and carries the authentication and directory endpoints the client itself depends on. Administrators do not see it in the portal. It is worth knowing it exists, because it is the reason the client can authenticate before any of your own configuration applies, and because a diagram of this product with three tunnels in it is missing one.
You can take this in pieces, and most estates should
The single most useful thing to understand early is that this is not one adoption decision. Each profile is enabled independently, assigned to its own users and groups independently, and licensed independently. You can run one and never the others. That means there are three quite different projects wearing the same product name, and a reader who arrives expecting a VPN-replacement programme with a budget attached may find that the piece they actually want is free and takes an afternoon.
Secure only Microsoft’s own services, and you are enabling one profile that is included with Entra ID P1. That buys the compliant network check, source IP restoration, universal tenant restrictions and the enriched logs, and it is the piece I recommend to almost everyone because it addresses token theft at no additional licence cost. Secure general internet traffic, and you are buying Internet Access and taking on a web gateway project with certificate work and a user-visible blast radius. Reach private resources, whether they sit in a datacentre or in Azure, and you are buying Private Access and building connectors. Those are three separate conversations and they can happen years apart.
Four things about that modularity are not obvious, and each one costs somebody a day.
Internet Access does not cover Microsoft’s own traffic. The destinations available to the Microsoft profile can only be acquired by the Microsoft profile. So you cannot secure Exchange or SharePoint by buying Internet Access, and if you set a rule in the Microsoft profile to bypass, that traffic does not fall through to Internet Access either. It leaves the service entirely and egresses by the client’s normal path. A bypass added for a performance reason is therefore a silent removal from inspection, which is the sort of change that gets made once and remembered never.
Azure is not a fourth mode. Reaching a private endpoint or a peered virtual network is Private Access doing what it always does, published by name or address, and it works because a connector has line of sight to the target. People hear “on-premises or Azure” as two capabilities. It is one capability and two places to point it.
The pieces are not equal in what can govern them. The compliant network check exists only on the Microsoft profile. Conditional Access cannot target the Private Access profile at all, only the individual applications published through it. And a clientless branch connection carries the Microsoft and Internet profiles but never Private Access. So the modularity is real at the plumbing layer and only partly real at the control layer, which is a distinction the next article is built around.
And the failure mode is open, not closed. If the client cannot reach the service, including because a Conditional Access policy refused it, the traffic is bypassed rather than blocked. It goes direct and local. That is a sensible default for a product whose worst outcome would otherwise be an outage, and it is also the reason the compliant network policy exists: without a policy that fails closed at the identity layer, a client that cannot connect is a client that is quietly unprotected.
The client is not a VPN, and that is a deliberate choice
Most security service edge products install as a virtual private network connection, because that is the straightforward way to capture traffic on Windows. Microsoft’s client instead uses a lightweight filter driver, and the documentation is explicit that this is what allows it to coexist with those other products rather than fight them for the same adapter.
That is a more consequential design decision than it sounds. It means a phased migration from an incumbent edge is a supported configuration rather than a cutover, with per-vendor guidance published for the major ones, and it means the practical work of coexistence is deciding which product acquires which destinations and then telling each one to leave the other alone. It also means the client is not something a user can see and disconnect in the way a VPN client is, which matters more than it should, because by default any standard user can still pause it from the system tray until you go and change that.
The traffic itself lands on an edge of forty-four points of presence, of which thirty-eight can also terminate branch connections, reached by anycast rather than by fixed regional addresses. There are no dedicated per-tenant egress addresses, which has a consequence worth carrying into any design: your users’ apparent location becomes the edge’s location, not theirs, and anything that trusts a source address will notice.
Private Access is a different answer to the VPN question
The private side is the part that most changes how you think, because it is not a better virtual private network but a different model. A traditional tunnel places the device onto the corporate network and then relies on internal controls to limit where it can go, which is why a single compromised laptop on the tunnel is such a useful foothold. Private Access inverts that: a connector reaches outward from inside the network to the service, individual applications are published as their own segments, and a user is granted a path to a specific application rather than to the network that hosts it. Paired with the private name resolution the service provides, this is also the mechanism that lets a cloud-only device reach an on-premises domain controller without a full network connection, which is the specific capability the cloud Kerberos trust article leaned on.
The design contrast to hold onto is that a virtual private network answers where can this device go once it is on the network, while Private Access answers which applications may this identity reach, and the second question has a far smaller blast radius when the answer is wrong.
A VPN answers where a device may go once it is on the network. Private Access answers which applications an identity may reach.
What that does not mean is that you get there app by app from day one, and this is where a lot of writing on the subject, including an earlier version of this article, has been too tidy. Microsoft’s own segmentation guidance replaces the VPN first, using a broad grouping called Quick Access carrying wide address ranges and wildcard names, and only then narrows toward per-application segments over the following months. The VPN comes out at the start of that process rather than the end. And Quick Access is not scaffolding that comes down afterwards: it stays permanently, because it hosts the private DNS configuration and because the discovery mechanism that finds your remaining applications only sees traffic that flows through it. The honest sequence is retire the tunnel, then spend a long time making the replacement smaller.
The connectors deserve a sentence of their own, because they are the part people forget to budget for. They are Windows servers you build, patch and own, reaching outward so nothing inbound is ever opened, at least two per group for resilience, and they are the same connector software that has served Application Proxy for years. Nothing about this is managed for you. What you are buying is a better shape for that responsibility, not its removal.
The controls that tie the network back to Conditional Access
What makes this an identity product rather than a networking one is a small set of controls that feed the network’s knowledge back into the identity decision. The compliant network check lets a Conditional Access policy require that a session actually traversed your tenant’s secure edge, which replaces the brittle practice of maintaining allowlists of egress addresses and defeats the replay of a stolen token from somewhere that never passed through your controls. Universal continuous access evaluation extends near-real-time revocation to resources reached through the edge even when the application itself is not built to honour it, so a change in an identity’s standing can cut off network access promptly rather than at the next token expiry. Universal tenant restrictions stop a managed device signing into a foreign tenant and moving data sideways. And source IP restoration solves a problem the edge would otherwise create, preserving the user’s true originating address in the sign-in logs and risk evaluation instead of collapsing everyone behind the service’s address, which keeps the location-based and risk-based controls from the rest of this series accurate.
These are the features that justify treating Global Secure Access as part of the identity plane. They are also where the honest caveats live, and there are three worth stating here rather than discovering later.
The compliant network check does not extend to Private Access applications, which is a real limitation when you are designing Conditional Access around private resources and expecting the network signal to be available there. Most of these capabilities depend on the client, which runs on the major desktop and mobile platforms and not on Linux, and Private Access in particular depends on it, while the Microsoft and internet profiles can alternatively be carried over a clientless branch connection. And the platforms are not interchangeable in the way you would expect: on Windows a device that is Entra registered rather than joined carries only private traffic, so it cannot satisfy the compliant network check at all, while on macOS, iOS and Android a registered device carries everything. A design that assumes universal coverage will find its gaps exactly where the awkward endpoints are, which is where it always finds them.
How it grew up, and why the dates are hard to pin down
The reason to revisit this product now rather than two years ago is that most of what made it unconvincing has been fixed. It entered preview in mid-2023 under a different name, before the phrase Global Secure Access existed, and reached general availability a year later alongside the identity suite. Since then the clients have gone generally available on all four platforms, encrypted session inspection went generally available in late 2025, multifactor authentication reached on-premises Kerberos through a sensor installed on domain controllers at the start of 2026, and bring-your-own-device support for Windows arrived in the middle of that year. The maturity arc is real and it is recent, which is precisely why so much of the writing about this product describes a version of it that no longer exists.
Pinning those dates is harder than it should be, and the difficulty is itself worth knowing about. There is no product-scoped changelog. The dedicated what’s-new page for Global Secure Access does not exist, the general Entra changelog carries only about six months before rolling into an archive, and several of the milestones above are recorded only on Microsoft blog posts rather than in the documentation. The mobile clients have no release history page at all, because they ship inside another product and their changes appear in that product’s release notes. For a service that changes monthly and enforces policy on your users’ traffic, that is a genuine operational problem rather than a documentation quibble, and it is the reason a later article in this series spends time on where to watch for changes.
What it is not
Microsoft positions this as security service edge rather than as full secure access service edge, and the distinction is not marketing hair-splitting: the software-defined wide area network half is delivered by partners, and the partner documentation has recently begun using the wider term for the combination. If somebody is selling you this as a complete network transformation, the missing half is being supplied by somebody else.
It is not available in the United States government high or defence clouds, and although the service is accredited at the FedRAMP high level it is not yet certified to FIPS 140-2. It does not tunnel IPv6, which passes straight to the network untouched, so a dual-stack estate needs a deliberate preference setting or it will route around the product without telling anyone. It does not support concurrent sessions on one machine, which rules out multi-session virtual desktops and session hosts. And there is one geography caveat worth reading twice: traffic can be terminated and inspected outside the United States not only when a user travels, but whenever the nearest edge happens to sit across a border, which for an organization near one is a steady-state condition rather than an exception.
The relationship with Application Proxy is coexistence rather than succession. They share the same connector software, there is no deprecation notice, no retirement date and no migration guidance of any kind, and Application Proxy is still receiving work. Anyone telling you that Private Access replaces it is describing a plan Microsoft has not published. What Microsoft has published a migration path for is DirectAccess, which is a different and much more welcome conversation.
Where it sits among the incumbents
Global Secure Access competes in the same security-service-edge category as the established independent vendors, and it is worth being clear-eyed rather than partisan about where it stands. It is a newer entrant, and some of its edge capabilities are more recent than the mature offerings it is measured against. Its distinguishing argument is not feature count but posture: because it is built on Entra, the network decisions are made against the same identities, the same Conditional Access and the same risk signals that govern everything else, rather than in a parallel policy system that has to be kept in sync with the identity one. Microsoft also documents running it alongside an incumbent edge rather than demanding a replacement, with the practical constraint that only one solution can tunnel a given destination, so a phased coexistence is a supported path rather than a compromise. For an organization already invested in Entra, the case is less about switching security-service-edge vendors and more about whether the network edge should be governed by the identity system it already runs, and that is a genuinely different question than the one the standalone vendors are answering.
What this series covers
The order is deliberate and it follows the money and the risk rather than the product structure. The next article is about what the pieces cost and what your existing licences already entitle you to, because that decides which of the three projects you are actually having. After that comes the Microsoft traffic profile and its Conditional Access story, which is the free piece and the one I would deploy first, with a build sheet that takes it from an empty tenant to an enforced policy.
Private Access follows, with the VPN retirement argued in the order Microsoft actually recommends rather than the order that sounds tidier, a build sheet for the connector and application foundation, and a second build sheet for the case most people arrive wanting, which is a remote laptop reaching a file share and a jump host with multifactor authentication at the network layer. Internet Access comes after that, deliberately last, because a session-inspecting web gateway is the most disruptive thing in this product and deserves to be its own project. Then operations, which is where the client and connector update problem lives and where the outage runbook gets rehearsed. And finally a decision article about where this fits and where it does not yet.
The reason this belongs with an identity series at all is the throughline it completes. Every earlier article moved a control from the network or the perimeter into identity, from federation to cloud authentication, from network location to device and risk signals, from broad membership to governed access. Global Secure Access is the same move applied to the last holdout, the network path itself, folding it into the control plane that already decides who you are and what you may reach. Whether you deploy it or not, the direction it represents is the one the rest of this series has been pointing at all along.
Global Secure Access
Next: [GSA 2] Paying for the Edge: Licensing Without the Fog ›
