Global Secure Access - Simply Explained

Imagine you're sitting in a coffee shop with your work laptop needing one thing, an internal finance app that only works from inside the company network. So you start the old VPN, wait for it to connect, and then you're effectively through the front door of the company building. That probably sounds normal, right? But think about what just happened. You needed one room, yet the VPN gives your device a root into a much larger part of the building, like asking reception for access to one meeting room, then getting a master key for most of the floor. That old way made sense when nearly everyone worked in one office, company apps lived in one data center, and the network itself felt like a safe place. But work doesn't look like that anymore. People work from home, airports, customer sites, and coffee shops. Some company apps still sit in an office or data center, while other tools live in the cloud, and every browser, Sass app, file sharing site, and AI tool creates another route where company data could leave. So what exactly is Microsoft, Entra, global, secure access? Is it just a new VPN? No, it's a different way to think about access. Global secure access, often shortened to GSA, helps the company give you a checked pass to the exact place you need to reach, instead of treating a VPN connection like permission to enter a broad part of the network. By the end of this knowledge nugget, you'll understand why the old VPN models struggles with modern work, how identity moves to the center of the decision, and how Microsoft entra private access, and Microsoft entra internet access fit together. We'll start with the old model first, because the new model makes far more sense once you see the problem it tries to fix. Why traditional VPNs no longer fit? A traditional VPN has a simple job. It creates an encrypted tunnel from your remote device back into the company network. Picture an employee working from home who needs to open a file share, connect to a remote desktop, or use an internal finance app that isn't available on the public internet. The VPN gives that employee a protected route back to the company for years that solved a real problem. Your traffic crossed the internet inside an encrypted tunnel and the company could treat your laptop more like it was sitting in the office. But here's where the trouble starts. After the tunnel connects, a VPN usually connects you to a network area, not necessarily to a single named app. That different sounds small, but it changes everything. Imagine you work in a large office building and need to book one meeting room. You show your badge at the front desk, and instead of receiving a pass for that room, you get a master key for an entire office floor. You may only intend to use one room, but still more doors are now visible and reachable than your job requires. A traditional VPN works the same way. A person who needs one file share, or one internal web app may receive access to a network segment where many other systems sit. Companies can limit that access with network rules, firewall rules, and separate VPN groups, but those controls become hard to manage as the number of users, apps, contractors, locations, and exceptions grows. And if a sign-in goes wrong or a device becomes compromised, broad access creates a bigger problem. An attacker who gains control of a connected device may see more systems than they should and more visible systems mean more places to try next. That's what people mean by lateral movement. Moving from one system to another after getting an initial way in. Now, the issue isn't that every VPN automatically gives access to everything. Well-managed VPNs can restrict access. The real issue is that the VPN model starts with the network, often asking, "has this person connected to the right network?" Then it uses network routes and rules to decide what happens next. Modern work needs a more focused question. Another problem is the route your traffic takes. Suppose you're at home and opening a cloud service. With a traditional full-tunnel VPN setup, your internet traffic might travel from your home to the company VPN gateway, then out to the cloud service, even when that service doesn't sit anywhere near the company office. It's like driving across town to pick up a package, then returning to the same area where you started before taking it home, and that extra trip adds delay and puts more pressure on the company's central VPN equipment. This became especially clear when remote work became normal. VPN systems were often designed for a smaller number of people working away from the office at the same time. So when large parts of a workforce needed remote access every day, companies had to deal with more connections, more traffic, and more support issues. Users felt that too. They had to remember to connect. They could lose the connection when moving between networks and when something didn't work. It wasn't always clear whether the issue involved the laptop, the home internet connection, the VPN, the company network, or the app itself. The old VPN checks you at the front gate, then may trust the connection too broadly. Modern access keeps asking more useful questions. Who are you? What device are you using? What are you trying to reach? And should you still be allowed to reach it right now? The core idea, identity at the center. So what takes the place of that old network first way of thinking? Microsoft Entra Global Secure Access, GSA for short, is Microsoft's cloud-based service that secures access to both private company resources and the public internet. That name sounds heavy, so let's make it plain. GSA is the security layer that decides whether you can reach a company app, a website, or a cloud service. It makes that call based on who you are, the device you use, and the rules your organization sets. GSA works with two types of destinations, private ones like an internal app that still lives in a company data center. And public ones like SaaS services, websites, and AI tools on the internet. It handles both, but it doesn't treat them as one big blob. It looks at the specific route you're asking for. You might also hear the term security service edge, or SSE. Sounds complicated, but the idea is simple. In the old setup, most security checking lived at company headquarters. Your traffic had to travel all the way back to that central location, so the company could inspect it and apply its rules. With SSE, those checks move into a cloud service that sits closer to users and cloud services. Think of it like moving a security desk from one distant office building to well-placed stations that can handle access wherever people work. The security rules still belong to the company, but where those rules are applied no longer depends only on a central office network. That matters because work now happens in more places, and company tools live in more places too. Underneath GSA is an approach called zero trust. Zero trust doesn't mean trusting nobody forever. It means a connection doesn't earn broad permission, just because it comes from a familiar network, a company location, or an encrypted tunnel. Every request needs context. The system checks your identity, your device, where policy requires it, and the destination you're requesting. This is where Microsoft Enter ID comes in. Think of Enter ID as the reception desk for your company's digital building. When you sign in, it checks your identity and knows which groups or roles that account belongs to. Then conditional access applies the company's access rules. Conditional access is the rule book at that reception desk. It can decide that a certain app needs more proof before you enter. It can require multi-factor authentication, often called MFA, or it can require that you use a company-managed device that meets the organization's security rules. Imagine someone in finance opening a sensitive internal finance app. They may already have signed into their laptop earlier that day. Even so, the finance app can trigger another check because the app is sensitive and the company wants stronger proof at that moment. The person receives an MFA prompt, completes it, and then gets access to that specific app. The decision follows the app and the situation. It isn't only tied to where the person happens to be sitting. That decision can change too. Suppose a security signal suggests the account may be at risk or the device no longer meets the company's rules. Enter can require the person to sign in again, ask for stronger proof, or stop access. The company doesn't have to wait for an old-style remote connection to end before it responds. This is the practical meaning of least privilege access. You get access to the app or destination you need for your job. You don't automatically get access to everything sitting behind it. For that to happen on a managed device, GSA uses the Global Secure Access client. Think of the client as a secure courier on your laptop. When you open something covered by GSA, the client sends that selected traffic through the service so Entra can apply the right checks behind the scenes. You usually don't need to decide which route to take the rules to that work. With that foundation in place, let's look at the first building block, the part that handles access to private company apps. Entra private access, the modern VPN replacement. The first building block is Microsoft Entra private access. This is Microsoft's Zero Trust Network Access Service. Often shortened to ZTNA. That name is long, but the job is simple. Private access gives you secure access to a specific company app or service without giving you broad access across the company network. Think about the kinds of tools that still sit behind company walls. It might be an on-premises file share. It could be a remote desktop system, used to reach a work computer or server. Maybe it's an internal web app for expenses, stock control or customer records. It could also be a business app connected to a database or a workload running in another cloud that the public internet can't reach. These are private resources. They aren't meant for anyone on the internet to open in a browser. In the old approach, you would often connect to the VPN first, then use the network routes available to find the resource you needed. Private access flips that around. You define the app or service a person needs. Then you give that person a controlled path to that app. Nothing else needs to come along for the ride. Imagine a service door inside the company building. It doesn't open the whole building to the street. Instead, it connects one approved room to a guarded route for people who have permission to enter. That service door is similar to a private access connector. A connector runs inside the company network close to the private apps and creates an outbound connection to the global secure access service. The connector reaches out from inside. That matters because the company doesn't need to put a public front door directly in front of the private app, just so remote users can reach it. Instead, the approved traffic follows the controlled route through the connector to the specific app. Let's use a contractor as an example. A contractor joins a project for six months and needs access to one internal project tool. With a broad VPN setup, somebody might add that contractor to a VPN group that reaches a section of the network. That group may work, but it can also carry more access than the contractor actually needs. With private access, the contractor can receive access to that one project tool. Not the nearby file server, not another internal website, not a set of systems that happen to sit on the same network. Just a project tool under the company's sign-in rules. Those rules can be different for different apps. Enter ID checks who the contractor is. Conditional access can require MFA before access to the project tool. The company can require a managed device, depending on its policy, and can also use device condition and risk signals when deciding whether access should continue. So the access decision is not just, is the contractor connected? It becomes, is this the right contractor on an accepted device asking for the approved app under the current conditions? That is much closer to how people actually work. You don't need access to a network. You need access to a tool that helps you do a job. For the company that can mean fewer large VPN groups and fewer hard-to-explain exceptions, it also creates a clearer answer when someone asks, "Who can reach this private resource?" The answer can be a named group of users and a named app, rather than a complicated set of network paths. There's another useful detail for people working inside an office. Sometimes you sit on the same local network as the private app you need, sending all of that app traffic out to the cloud and back again would create an unnecessary trip. Private access includes intelligent local access for supported situations. It can keep the local app traffic on the local network, while the identity check still goes to Microsoft Entra. You get the local route where it makes sense, while the access decision still follows the company's rules. Private access can modernize many VPN scenarios, but it isn't magic. A company still needs to understand its apps, the protocols those apps use, who needs access, which devices are involved, and what existing network needs must remain. That planning matters, because moving from broad network access to specific app access means being clear about what each person actually needs. Private access protects the company tools hidden behind the office walls, but employees also spend much of the day on websites, SaaS tools, cloud storage, and AI services. The second building block watches traffic, leaving the building for the public internet. Entra internet access, the secure web gateway, so the other half of global secure access is Microsoft Entra Internet access, the secure web gateway side of the service. Most people call it SBIRG. Private access handles company resources behind private walls, while internet access handles traffic going out to the public internet. In plain English, it's a cloud service that applies company security rules before users reach websites, SaaS apps, and other public destinations. Why does that matter? Because work doesn't happen in just one browser tab anymore. You might use a web browser for research. A desktop app could connect to a cloud service. Someone might open personal web mail, upload a document to cloud storage, or ask an AI tool to summarize a file. Each action creates a route out of the company, and some routes lead to harmful websites, while others can cause data to leave by mistake. Think of internet access, like a security checkpoint at the exit of an office building. People can still leave and send packages where they need to go, but before a package leaves, the checkpoint checks the destination and applies the company's rules. Is this destination known to be harmful? Is this service allowed for this group? Is this package allowed to leave at all? Here's the thing, that check follows the user. Someone working from home gets the same web rules as someone in a branch office or at a company desk. If the organization blocks a harmful website category, that rule doesn't disappear just because the employee is on home Wi-Fi. The same idea applies to SAS apps and AI services. A company might discover that employees use cloud tools nobody formally approved. That doesn't always mean they did something wrong. Often they were just trying to get work done faster. Still, the company needs to know which tools are in use before it can make a sensible choice. Internet access provides that visibility. The company can see an unapproved cloud app or AI tool showing up in traffic, then decide what to do next. It might allow the service, limit what users can do there, or block it because it doesn't meet security or data rules. That's a much more useful conversation than simply hoping people only use approved tools. Let's make this more real. Imagine an employee has a planning document and wants an AI tool to summarize it. They drag the file into an AI app, the company hasn't approved. If the organization uses network file filtering with Microsoft PerView, it can scan supported file types under the company's policy. If that planning document matches a rule, the upload gets blocked before the file reaches the AI service. The employee sees the upload failed and behind the scenes the company has stopped a document from leaving through an unapproved route. That isn't about blocking every new tool by default. It's about giving the organization a way to decide which data can go where. The rules can also change based on context. The same website or cloud service might be allowed for one group and blocked for another. A company managed device may receive more access than an unknown device, and a user account with a risk signal may face stricter rules than normal. That's possible because Internet access works with Android controls instead of treating all web traffic as identical. There's one technical idea worth knowing here, TLS inspection. Most web traffic is encrypted, and that's normally a good thing because it protects information while traveling across the Internet. But encryption also means a security service can't read the contents unless the organization chooses to inspect that traffic under its policy. Think of a sealed delivery box. You can see the address on the outside, but you can't check what's inside without opening it. TLS inspection, lets the organization inspect selected encrypted traffic so content-based checks like file filtering can happen. The organization then sends the traffic on its way if the policy allows it. This needs careful thought. The organization chooses which traffic goes through global secure access and how much inspection it applies, and those choices should match clear internal policy, employee expectations, and local legal requirements. Internet access handles the public website of the picture and private access handles access to private company apps. They can sound like two separate products, but the bigger idea appears when both routes use the same identity and policy engine. How the pieces work as one system. This is where the full picture clicks. Global secure access isn't one giant tunnel that takes all your traffic to one place. It's a set of guarded routes. Each route has a destination, a set of rules, and a decision about whether you should be allowed through. Imagine the same employee starting work on a managed laptop. They sign in once using their work account. First, they open an internal finance app that request goes through private access because the app lives inside the company's private environment. Later, they open a SaaS service in a browser and visit an AI tool. Those requests go through Internet access because the destination sit on the public Internet. From the employee's view, they open the tools they need. Behind the scenes, the traffic takes different routes because the destinations need different protection. One shared reception desk handles the identity side. Entra ID knows who signed in. Conditional access applies the company's rules. Global secure access then sends the traffic down the right-guarded route, whether that means a private app or an Internet destination. The decision doesn't start with, "Are you on the company network?" It starts with better information. Who is the user? Is the device in an accepted condition? Which destination are they requesting? Has anything changed that makes the request more risky? That matters after access begins too. Supposed the security system detects a risk with an employee's account. Maybe the sign in activity changes in a way that needs attention. Or the device reports a problem. Entra can react while the person is working. It may ask for another sign in check, "Require a stronger proof" or stop the route to the protected destination near real time. Other Microsoft tools contribute useful signals here. Intune reports whether the device meets the company's device rules. Defender reports, threats found on the device or account. Pervue helps protect sensitive files when users try to move them to cloud destinations. None of these tools work as separate islands in this scenario. They feed information into the access decision. The older model builds one trusted tunnel into the network and tries to control everything from there. The newer model creates controlled paths to each approved destination using identity and context to decide what happens along the way. With the full system in view, don't try to replace every connection at once. Start with just one VPN use case. Pick one user group, one private app, and one clear business need. Then ask three plain English questions who needs this app, what exact app or service do they need, and what sign-in or device checks should apply before they get access. A focused private access pilot is your practical first step. After that, look at Internet Access for Web, SAS, and AI traffic. Bring your identity, network, device, and data protection teams into the conversation early because each team owns part of the access decision. Remember, access should follow the work not the network. Global secure access replaces broad tunnels with controlled routes. Start with one app, then subscribe to M365, EdFam, and share this with someone starting their journey. I'm Mirko Peters, and this has been another knowledge nugget.