Microsoft Entra Quick Access - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What Microsoft Entra Quick Access actually is. Microsoft built a network across seventy regions to replace the humble Company VPN. That's the scale behind Quick Access. One feature inside Microsoft Entra Private Access. It gives your laptop the same reach the VPN did, except the decision to let you in stops being about your network address. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. By the end, you'll know what it is, what it takes to run, and where it actually breaks. Quick access is the front door for the private things that never move to the cloud. Picture the file share your team has leaned on for a decade. The internal timesheet site nobody rebuilt, or the old server that runs one monthly report. None of that sits on the public internet, so reaching it has always needed a special route in. For years that route was a VPN. It opened a tunnel, dropped your laptop onto the company network, and then trusted you mostly because you were already inside. Quick access still uses a tunnel, but it moves the decision. So access follows who you are rather than where you happen to be sitting. That shift is the whole idea, and it's easy to miss the first time you see it. A VPN asks whether you're on the network. Quick access, asks who you are and whether you should be here at all. Two words get mixed up here all the time. Private access is the product and quick access is one way you use it. It lives inside Microsoft Enterprise Access, which is one half of a larger product called Global Secure Access, and the other half internet access watches the public web. If you've run into the term security service edge, this is Microsoft's version of it. The plain meaning is simple enough the security travels with the user instead of standing guard at the office door. Microsoft calls it quick for a reason, because it's the fastest way in. Instead of modeling every single app by hand, you publish broad chunks of your network and let people get back to work. Why a VPN feels wrong now the real tension here isn't the technology, it's the shape of work. People stopped working in one building and their apps shifted to the cloud, but plenty of private resources stayed exactly where they were tucked behind a firewall. A VPN was built for a world where the office was the front door. It hands out one big key, and once you're through, you can usually reach far more than the one thing you actually came for. There's a concrete version of that problem. A contractor joins for six weeks to fix a single internal booking page. The VPN gives that contractor the same network view as a full time engineer, because the VPN doesn't know or care about the difference, you either accept the extra risk or you spend your week writing exceptions. Neither option feels good, which is why the old model started to strain. You want to hand someone exactly the access they need, and you want that access to follow the person instead of the building. Quick access answers that strain. It keeps the convenience people liked about the VPN, and it swaps the blunt network key for a decision that's tied to identity. But that's only half the story because a decision doesn't get anyone anywhere unless something carries the traffic to the door. It also changes what you can prove afterward, a VPN leaves you guessing who reached what. While an identity based decision leaves a record you can actually read, that record matters more than it sounds, because when someone asks who could reach the payroll system last month, a network key can't answer that question, and an identity decision can think about how that plays out on a normal Tuesday. A new hire needs three internal tools. A vendor needs one, and an auditor needs a read only view for a week. A VPN tends to hand all three of them the same broad reach, while Quick Access lets you point each of them at their own slice. The three pieces that make it work Quick Access only works when three pieces line up, and once you can picture them, the whole thing stops feeling like magic. The first piece is a connector, a small agent that runs on a windows server inside your own network. It reaches out to Microsoft, so you never have to punch a hole in your firewall, and it acts as the hand that actually touches the private resource. Microsoft asks for Windows Server twenty sixteen or later, and the connector needs to be reasonably current to keep working. The connector tends to surprise people because it means something has to live inside your network. Quick access isn't a switch you flip in the cloud. It's a partnership between the cloud service and one small agent on your side of the fence. One connector is also a single point of failure. So most teams run more than one, and the service sends new requests to a healthy connector when one goes offline. The second piece is the client, a small app that lives on the user's device. It runs on windows, Mac OS, iOS, and Android, and its job is to watch the traffic leaving that device and decide what gets tunneled and what goes straight out to the internet. The same laptop can reach an internal file share and still browse the web normally, and the client is what keeps those two jobs apart. The third piece is the list. The resources you tell Microsoft about. You describe them as application segments, which is just a way of saying the names, the addresses, and the ports you want to cover. A segment might be a wild card for an internal domain, a single server address, or a whole range of addresses. Put those three together and traffic takes a clear path. It leaves the device, passes through the client, travels to Microsoft's network edge, comes back down through your connector, and lands on the internal resource. The network behind that path spans seventy regions and more than one hundred and ninety edge locations. Hold on to one part of this. One of those three pieces carries a limit that surprises almost everyone the first time it bites. What quick access does in practice. The setup sounds heavier than it is, so let's walk it as a story rather than a checklist. You start with the connector group, which is how you organize the connectors that carry the traffic. Then you create the Quick Access app and give it a name. One detail catches people off guard here. The moment you configure quick access, Microsoft creates an enterprise app for you automatically, and that app becomes the container for everything you're about to protect. Next, you add the application segments. You can name a specific web address, a single IP address, a range of addresses, or a wildcard domain. Then you open the ports you need, which in plain terms means the doors you're allowing. Port four hundred forty three covers secure web traffic four and four five covers file sharing, thirty three eighty nine covers remote desktop and twenty two cover secure shell. Then you assign people. A small rule matters a lot at this stage, users have to be assigned directly to the app or to a group that's assigned to it, and nested groups don't work. If you assume your usual group nesting applies, you'll spend an afternoon wondering why someone can't get in. Then you turn on the private access traffic profile and connect the private DNS settings. Private DNS is the piece that lets a user type an internal name, like a file server, and land in the right place. It only redirects the names that match your private suffixes, so ordinary web lookups aren't dragged through the tunnel for no reason. Picture what that feels like on a normal day. A designer opens a laptop in a coffee shop, clicks an internal timesheet link, and the page loads with no VPN pop up and no manual connect step. The client decided that traffic belonged in the tunnel and the connector delivered it. That's the moment the whole thing earns its keep. Because nobody had to open a VPN client, type a server name, or remember a second password. One more number is worth knowing. You can add up to five hundred segments to a single quick access app, which is generous for a broad first pass, but nowhere near enough if you try to model every internal system one by one. There's also a patient setting to expect the client refreshes its rules about every five minutes, so a change you make in the portal won't always land on a device the second you hit save. If something looks wrong right after a change waiting a few minutes before you start troubleshooting usually saves you a lot of effort. Quick access versus per app access. Now we hit the first real fork in the road because quick access is broad on purpose, and that's both its strength and its weakness. You might think quick access is the whole feature. It's the wide open first version. You publish whole address ranges and wild card names, which is exactly what makes the move of a VPN feel painless because people keep the reach they had before. Per app access is the narrow version. Instead of one big door, you create a separate app for a single resource, give it its own audience, and attach its own access policy. Only the finance team reaches the finance system and only HR reaches the HR platform. Microsoft is direct about this in its own guidance. Quick access is meant to be a transition state rather than a finish line. You use the broad version to get off the VPN, then you pull the sensitive systems into their own apps over time. A concrete way to see the difference comes down to who's on the guest list. Through quick access. A whole range like one zero dot zero dot zero dot zero sixteen might be open to everyone who needs internal access through per app access. That finance system becomes its own door with its own short list of names. Broad access isn't a mistake, and narrow access isn't automatically better. Broad access is fast to stand up and easy to reason about, while narrow access takes longer to build and is much easier to defend. When someone asks why a person could reach a system they never needed. The practical takeaway is that you don't really choose one or the other. You start broad and then go narrow, and for a while both versions exist side by side. That's the head fake of this whole topic. The thing that replaces your VPN is real, and it's also just step one where it fits in Microsoft three hundred sixty five and Azure. If you already live in Microsoft three hundred sixty five. This should slot into a picture you half know. So let's place it properly. Microsoft Entra is the identity family. You may remember it as Azure Active Directory, which Microsoft renamed to Microsoft Entra ID back in twenty twenty three. And that rename is why the older name still shows up in older articles. Quick access sits inside Private Access, which sits inside Global Secure Access, and all of it is managed from the Microsoft Entra Admin Center. So you're not learning a separate universe. You're adding one more pain to a place you already visit. That placement has some history behind it. Private access grew out of the older Microsoft Entra application proxy, which only handled web apps, and the newer service widened the door to any port and any protocol. If application proxy always felt narrow to you, this is the wider version of the same idea. Licensing is the part most beginners care about, so here it is. Plainly private access needs a Microsoft Entra ID, P1 or P2 licence, and it's sold either on its own or as part of the Microsoft Entra suite. Microsoft publishes these as list prices paid yearly. Private access on its own runs five dollars per user per month, and the Entra suite bundles it for twelve. If you only want the identity licenses underneath, entry ID P1 is seven dollars and P2 is ten. Your real cost moves with your agreement, so treat those numbers as a starting point and not a final quote. The Microsoft three hundred sixty five connection is that these licenses often arrive with plans you already own. Entry ID P1 comes with Microsoft three hundred sixty five e3. Entry id p2 comes with e5, and the entry suite is part of the newer Microsoft three hundred sixty five E7. None of that changes what you already know about Microsoft three hundred sixty five, and it simply adds a network layer to the identity layer you're already paying for. The Azure Connection is more practical than it sounds. The connectors that carry your traffic can run on Azure Virtual Machines and Azure Virtual Desktop, and you can deploy them straight from the Azure, AWS and GCP marketplaces. One caveat is worth knowing early, because private access isn't available in every cloud it runs in the US government community cloud, but not in the higher government or sovereign environments. The limits and the mistakes to avoid this is the part nobody mentions until it bites. So let's go through it. Honestly, the biggest limit is about conditional access. You might assume that because access is now an identity decision, your conditional access policies cover the traffic inside the tunnel automatically. They don't, at least not at the traffic level. Microsoft's own documentation says that applying conditional access to private access traffic isn't supported today, and the workaround is to attach the policy to the app itself, which means the Quick Access app or a per app app. Get this wrong and you can believe you're enforcing MFA when you aren't. The second limit is about the client. Private access traffic can only be picked up by the client on the device, which means a client list set up like a branch office connecting through its own tunnel doesn't cover your private resources at all. The third is IPv6. The client tunnels IPv4 traffic and lets IPv6 pass straight through to the network. So if your environment leans on IPv6, part of your traffic skips the service entirely. Setting the adapter to prefer IPv4 is the usual fix. Secure DNS is the fourth, and it's the one that makes people doubt their own setup. The client doesn't support the secure DNS variants that browsers increasingly turn on by default, so name based rules only work once secure DNS is off. If your rules seem to be ignored for no clear reason, that setting is usually the first place to look. There are more, and they share a theme. Tunneling by IP address only works for addresses outside the device's own local subnet. The site on the other end sees Microsoft's edge address instead of the user's address, which can confuse anything that cares about location Multi-session as your virtual desktop isn't supported either, so a shared desktop host is a dead end for now. If you run an outbound proxy. You also have to tell it to leave the tunneled addresses alone or that traffic heads for the proxy instead. Now the mistakes turning quick access on and stopping there is the first. Because broad access was meant to be temporary, assuming conditional access covers the tunnel directly as the second, moving a segment into its own app without checking who's assigned is the third. And that mistake causes real outages. Because when you move a segment, all of its traffic follows the new app immediately. The fourth is moving in address name but forgetting the address itself. So traffic that resolves the name locally still slips through the old broad door. The lesson underneath all of it is simple enough quick access moves the decision to identity, but it doesn't make the underlying network disappear. And the network is where every one of these limits lives. The phased path from VPN to least privilege. The good version of this looks like a journey with four stops, and Microsoft lays it out fairly clearly. Phase one is the one you already understand. You stand up quick access with broad ranges and wildcard names so people keep the access they had and then you switch the old VPN off. Nobody notices, which is the point. Phase two is discovery and it's more useful than it sounds. The traffic flowing through quick access feeds a report that shows which internal systems people actually reach that matters if your list of on premises resources is out of date, which it usually is. Phase three is segmentation. You take the sensitive systems, the finance platform, the HR system, the admin tools and pull them into separate apps with their own small audiences. Microsoft's advice is to start with the high sensitivity, low user count systems because they carry the most risk and touch the fewest people. Phase four is governance. You layer reviews on top, so access gets recertified on a schedule, and you automate removal when someone changes roles or leaves. That's what keeps the narrow doors narrow over time, because access that nobody reviews slowly drifts back toward being broad. That last phase is the one team skip, and skipping it is how the broad door creeps back in. The counter-intuitive rule that ties it together is this you don't delete quick access when you're done, you shrink it. It stays as the catchall for anything you haven't segmented, and it stays as the home of private DNS. So name resolution keeps working for everyone. The goal is to minimize the broad door rather than slam it shut. And that small distinction has a big effect on how much you break along the way. The one thing to remember here's the short version. Quick access is the identity based front door that replaces your VPN for private resources. It needs a connector, a client, and a list of segments to work. And it's a bridge rather than a destination, because the plan is to go from broad access to narrow access over time. If you remember one thing, remember this quick access isn't a better VPN. It's the moment access stops being about where you're sitting and starts being about who you are. So here's my question for you. If you could switch off your company VPN tomorrow, which internal system would you be most nervous to hand out to freely? If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.