Private Access is the first thing most people are shown and the last thing they should deploy. It genuinely does retire a virtual private network, and the honest description of how is not the tidy one anybody presents: you replace the tunnel with something almost as broad, then spend months making it smaller, and the broad thing you started with never entirely goes away.
What actually changes
A virtual private network admits a device to a network and then relies on everything inside that network to limit where it can go. That is why one compromised laptop on a tunnel is such a useful foothold: the compromise buys network position, and network position is what the internal controls were built to trust. Every subsequent control is downstream of a decision that has already been made badly.
Private Access inverts the direction of the connection and the unit of the grant. A connector inside your network reaches outward to the service, so nothing inbound is opened. Applications are published individually as segments of address, name, port and protocol. A user is granted a path to a named application rather than admission to the network that hosts it. The device never joins anything.
A VPN answers where a device may go once it is on the network. Private Access answers which applications an identity may reach.
That is a real improvement and it is worth being precise about why. It is not that the tunnel is encrypted better. It is that the blast radius of a wrong answer collapses from a network segment to one published application, and that the grant is now expressed in the same system that governs everything else about that identity.
The sequence is the opposite of the sales pitch
Everything above suggests you should start by publishing applications one at a time. Microsoft’s own guidance says otherwise, and having watched the tidy version fail, I think Microsoft is right.
The documented phasing begins by replacing the virtual private network with a broad grouping called Quick Access, carrying wide address ranges and wildcard names, covering roughly what the tunnel covered. The tunnel comes out at that point, not at the end. Then application discovery watches what people actually reach through that broad grant, and over the following months you promote what you find into individually published applications with their own assignments and their own policies.
The reason to do it in that order is that you do not know what your estate contains. Nobody does. The inventory you think you have is a list of the applications somebody remembered to write down, and the traffic that actually flows contains a decade of things nobody has thought about since. An app-by-app migration is a project that stalls on the twelfth application, because the thirteenth is something nobody can identify and nobody will admit to owning. Replacing the tunnel first means you are never blocking users while you work out what a host is for.
What I cannot tell you is how long the narrowing takes, and I have looked. There is no published account of anyone completing this. Not a case study, not a conference talk, not a practitioner post with a timeline in it. The literature describes the model in detail and contains no evidence of anyone finishing it. Treat that absence as information: plan the broad replacement as a project with an end date, and plan the narrowing as an ongoing operating duty with a review cadence, because the second one is not a project and pretending otherwise is how it quietly stops.
Quick Access does not go away, and Microsoft says both things
Here the documentation contradicts itself, and since the answer determines your target state it is worth naming rather than smoothing.
Microsoft’s segmentation strategies guidance states that Quick Access is not designed to be removed entirely after segmentation is complete, and that it is expected to remain in place even in mature deployments. The deployment guide for the same product, on the same documentation site, ends its per-application configuration sequence with an instruction to disable Quick Access. A third page calls it a transition state and a fourth calls it a migration bridge. All four are current.
The reconciliation is not a matter of preference, and this is the part worth carrying away. Quick Access is where private name resolution lives. The private DNS configuration, the suffixes that make your internal names resolvable through the tunnel at all, is attached to it. It is also the only traffic application discovery can see, so it is the mechanism that finds the applications you have not segmented yet. Delete it and you have deleted your name resolution and blinded the process that was going to finish the job.
So the target state is not an empty Quick Access. It is a Quick Access whose assignment scope and segment list have been narrowed to almost nothing, still present, still holding the DNS configuration. What was transitional was the breadth of the grant, never the object. If your design document has a step that ends with disabling it, that step is the one page of Microsoft’s own guidance that has not caught up with the other three.
The narrowing is the outage
Nothing about the broad replacement is likely to hurt you. The dangerous phase is the one that looks like tidying up.
When you publish an application whose segments overlap Quick Access, the individually published application wins for that traffic. That precedence exists deliberately, and it is what makes a gradual migration possible at all. It also means the moment you publish it, that traffic stops being governed by Quick Access and starts being governed by the new application, including its assignments. If you have not assigned anybody to the new application yet, you have just removed access for everyone who was reaching that resource a second ago, and the mechanism that did it is the mechanism you were relying on.
Whether assignments carry across depends on how you created the application, and Microsoft’s own pages describe this three different ways. Creating one by hand transfers nothing. Creating one from a discovered segment offers to import the users and groups, as a checkbox you can leave unticked. A third page describes that import as automatic. The safe reading, and the one to design to, is that assignment never follows unless you explicitly made it follow, and that you should confirm it on the application rather than assume it.
There is a second trap in the same operation, and it catches the careful. Publishing an application by name does not stop traffic matching Quick Access by address. If the addresses that name resolves to are still inside a Quick Access range, some traffic will keep taking the old path, and you will have a resource that is half migrated in a way that is invisible until something behaves oddly. The remedy is unglamorous: publish both the names and the addresses on the new application, and break the Quick Access ranges into smaller pieces so the migrated addresses can be removed from them.
The connectors are yours, and the numbers are softer than they look
Every private application reaches its destination through a connector, which is a Windows server you build, patch, monitor and own. There is no managed option and no per-connector fee. Two per group is a floor rather than a target, and it is a floor per group, so an estate with connectors in three sites is running six machines before it has published anything.
Be careful with the published capacity figures, because they are softer than they are usually quoted. The throughput number that circulates is a controlled laboratory measurement using synthetic streams on a four-vCPU virtual machine in a dedicated tenant, and Microsoft says so on the same page, along with a list of factors that change it including intermediate firewalls and inspection. Microsoft’s own sizing pages also disagree with each other about memory, one giving a general recommendation and another giving a larger figure tied to a stated number of concurrent connections. I would size against the connection-count figure, keep peak utilisation well under the documented ceiling, and treat any headline throughput as a shape rather than a budget. If you need a real number for your estate, measure it on your estate.
Placement matters more than capacity for the workloads in this article. Connectors are bound to the Active Directory site they sit in for the purposes of domain controller publishing, so the question is not whether a connector is near your file server in a network sense, it is which site it belongs to. Put them where the resources are, and use a dedicated group per site rather than one group reaching everywhere, because a connector group is the unit you will later drain for patching.
Private DNS, and what it does to a split-brain estate
This is the section that decides whether your first migration is smooth or miserable, and it is the one almost nobody covers, because the estates in the documentation are conveniently shaped.
Private name resolution works by adding a rule to the client that says: any name ending in this suffix gets resolved through the tunnel rather than by whatever resolver the device would normally use. The resolution happens inside your network, against the DNS servers your connector host uses, and the client is handed back a synthetic address from a reserved range that stands in for the real one.
The consequence is a rule with no exceptions in it. Configure a suffix and every name under it resolves through the tunnel. There is no mechanism to exclude a subdomain, a host, or a record. That is fine for an estate whose internal namespace is separate from its public one. It is a genuine problem for the far more common shape, where the same domain serves both, because the moment you configure that suffix, your public website, your externally hosted portal and anything else living under the same name are being resolved internally too, whether or not that is what your internal DNS answers for them.
There are two ways out and they are not equal. The client-side approach is to layer additional name resolution rules on the device to carve out the names you want resolved normally, which works and which puts the exception list on every endpoint, where it will drift and where it collides with anything else managing those rules. The server-side approach is to make your internal DNS answer correctly for the names that should go outside, using the policy capability your DNS servers already have, so the carve-out lives in one place that is already authoritative and already backed up.
I would take the server-side answer every time. It puts the decision in the system whose job is answering name queries, rather than in a per-device rule table that another product may also be writing to. It is also the only one of the two that survives somebody reimaging a laptop.
Two smaller things belong here. Single-label names, the bare hostname with no domain, are handled by a synthetic suffix mechanism that Microsoft warns can break the service principal names Kerberos depends on, so anything authenticating with Kerberos should be reached by its fully qualified name. And whether reverse lookups work through this path is undocumented in both directions. I have not tested it, Microsoft does not describe it, and I am not going to assert it either way.
Kerberos, where success looks exactly like success
Reaching a file share means authenticating to it, and for a cloud-joined device reaching an on-premises share that means the machinery described in cloud Kerberos trust: the device obtains a partial ticket from Entra ID, exchanges it at a domain controller for a full one, and uses that to get a ticket for the share.
Two failure modes matter, and the first is nasty because it presents as success.
If the Kerberos path is not working, Windows will often fall back to an older authentication protocol without telling anybody. The share opens. The user is happy. Nothing prompts. And the thing you built this for, an identity-anchored authentication to an on-premises resource, is not what happened. You cannot detect that from the client’s behaviour because the client’s behaviour is indistinguishable from working. The only reliable evidence is on the server, in the logon event, where the authentication package is recorded. Any validation that stops at “the drive mapped” is not a validation.
The second is a timing problem that will define your pilot’s reputation. At sign-in, Windows tries to locate a domain controller before the tunnel is up, fails, and caches that failure. The default caching interval is ten minutes, so for ten minutes after every restart the domain-joined resources are simply unreachable, and then they work, and the user has already logged a ticket. This is documented, it has a named registry value behind it, and it has been independently reported by practitioners for two years. It is also the single most likely reason a technically correct pilot gets judged a failure on user experience alone, so it belongs in the build rather than in the troubleshooting section.
Worth knowing before you design around it: password sign-in and Windows Hello for Business do not take the same path here, and the Hello path has a dependency the password path does not. If your pilot group is passwordless and your test account is not, you will get different results and reach the wrong conclusion about why.
The sensor, and the thing it genuinely adds
The most interesting recent addition to this product is not on the network side at all. A sensor installed on domain controllers, generally available since January 2026, brings multifactor authentication to on-premises Kerberos, including for access that never leaves the building. That is a control the Windows authentication stack has never had, and for an estate that still has a domain, it is a larger security change than anything else in this article.
It installs in report-only mode by default, which is correct and which you should leave alone until the logs are boring. It has a documented break-glass path, both in the portal and as a registry value, and you should rehearse that before enforcing rather than after.
The honest limitation is that it governs Kerberos, and Kerberos is not the only way to authenticate to a Windows resource. An estate that has not restricted the older protocol has left the door the sensor is not watching. So this is a control worth deploying and it is not a control worth overstating: it raises the floor for Kerberos authentication and it does not close the room.
What the old tunnel still does better
An honest retirement plan needs a keeper list, because there are things this does not do and discovering them late is expensive.
There is no device tunnel and no pre-logon connectivity, so anything that needs the network before a user has signed in is outside this model. That covers first-boot domain join over the tunnel, machine-context policy processing at startup, and the management pattern where administrators reach out to a machine rather than the machine reaching in. Traffic is acquired only where the client is installed, so anything that cannot run the client cannot be reached this way. And the protocols that negotiate their own dynamic ports are not a comfortable fit.
None of that is a reason to keep a full tunnel for everyone. It is a reason to work out which small population genuinely needs one, and to be honest in the business case that the answer is rarely zero.
One more asymmetry, carried over from [GSA 3] because it shapes the design rather than the deployment. Conditional Access cannot target the Private Access tunnel. It targets the individual published applications, which means multifactor authentication, device compliance and risk conditions are all available to you per application, and the compliant network check is not available at all. Your private applications are protected by assignment and by per-application policy. They are not protected by a signal asserting the traffic came through your service, because that signal does not reach them.
Where I would start
Build the connectors properly, in groups that match your sites, before publishing anything. Get private DNS right for your namespace before the first user tries a file share, because in a split-brain estate that is the decision the whole migration rests on. Replace the tunnel with a broad grant and take the tunnel out. Then narrow, forever, at a cadence somebody owns.
And validate Kerberos on the server rather than on the client, because the client cannot tell you the difference between the outcome you wanted and the one you got.
The next article builds the foundation: connectors, groups, the broad grant, private DNS and the first published application, with the checks that prove each one before the next. The one after that does 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. If you have not read the argument for why the free profile comes first, [GSA 1] sets out the order.
Global Secure Access
‹ Previous: [GSA 3.1] Build Sheet: The Microsoft Profile and the Compliant Network Policy
Next: [GSA 4.1] Build Sheet: The Private Access Foundation ›
