Deployment of Microsoft Entra Private Access — the private-application side of Microsoft's Global Secure Access — to replace legacy VPN access to your internal applications with identity-centric, per-app Zero Trust access. IT Partner installs and load-balances the private network connectors, defines your application segments (specific apps, IP ranges, and FQDNs rather than a flat network), attaches Conditional Access with MFA and device checks per application, rolls out the Global Secure Access client to a pilot group and then the estate, and runs a deliberate coexistence period alongside your current VPN until you are ready to switch it off. $3,950 per project (estimate — confirmed in writing after discovery), typically 2 weeks.
A traditional VPN grants a network position: once connected, a user — or the malware on their laptop — can typically reach far more than the one application they needed. Microsoft Entra Private Access inverts that model. Each internal application becomes an app segment in Entra; users reach exactly the applications policy grants them, each connection is brokered through Microsoft's edge with Conditional Access evaluated per app — MFA, device compliance, risk signals — and nothing hands out a routable position on your network. For organizations already invested in Entra ID, it is the shortest path from 'VPN because we have always had one' to Zero Trust remote access that an auditor will recognize, and it pairs naturally with a broader Zero Trust architecture. The deployment has four moving parts, and we build all of them. Private network connectors — lightweight outbound-only services on Windows Server, deployed in pairs for resilience — link your private network to Microsoft's edge without inbound firewall holes. App segments define what is reachable: we start segment-by-segment with your named applications (by FQDN, IP, and port), and use broader Quick Access ranges only as a transitional device, because per-app segmentation is the entire point. Conditional Access policies attach identity requirements to each segment — who, from what device state, with what authentication strength. And the Global Secure Access client goes out to Windows and macOS (mobile platforms where scoped) through your management tooling, piloted with a real user group before anyone touches the estate. What this service is not: a rip-and-replace stunt. Your existing VPN stays up through a planned coexistence window while access moves segment by segment and the pilot proves out the patterns that matter — including legacy protocols, single sign-on to on-premises resources via Kerberos where needed, and the traffic types that deserve validation before commitment. When every access pattern has moved or been consciously dispositioned, you hold the evidence to decommission the VPN. The decommissioning itself — appliance retirement, contract termination, firewall cleanup — is your action, on your schedule, and we hand you the checklist that makes it safe.
Inventory remote-access patterns, applications, protocols, and client platforms; assess licensing position; produce the design document and confirm the fixed quote. Anything that will not fit Private Access is named here, not discovered later.
Connector hosts prepared and connectors deployed in redundant pairs; tenant Global Secure Access settings configured; first app segments built; Conditional Access policies staged in report-only mode.
Client deployed to the pilot group; each access pattern exercised against the validation script — including legacy protocols, printing, file shares, and admin tools; policies switched from report-only to enforced for the pilot; findings fixed or dispositioned.
Client rollout expands in rings; application segments cut over in agreed order; the legacy VPN remains available as the fallback throughout, with usage monitored so you can watch it drain.
Runbook walkthrough with your team, final policy review, coexistence state documented, and the VPN decommission-readiness checklist delivered. The VPN switch-off decision and execution stay with you.
It is the private-application half of Microsoft's Global Secure Access (the other half, Entra Internet Access, handles web traffic). Instead of connecting users to your network the way a VPN does, it brokers each connection to a specific internal application through Microsoft's edge, with Entra ID authentication and Conditional Access evaluated per app. Users get the applications they are authorized for; they never get a network position.
Three concrete differences. Blast radius: a compromised VPN account exposes whatever the network reaches; a compromised Private Access account exposes only its assigned app segments, each still gated by MFA and device checks. Policy: access rules live in Conditional Access per application, auditable in one place, instead of in firewall rules and VPN group mappings. Operations: no inbound firewall holes, no appliance patching cycle, and adding an application is a policy change rather than a network change. Whether those advantages justify the move for you is what discovery establishes.
It is an estimate for the typical scope: redundant connectors at one site, an agreed initial set of app segments, per-segment Conditional Access, client rollout with a pilot, Kerberos SSO where needed, coexistence support, and the runbook. Discovery confirms it as a fixed quote in writing before work begins — more sites, many segments, or heavy legacy-protocol work are what move it. You pay after you approve delivery.
Two layers, both Microsoft's meter: Entra ID P1 or P2 as the platform prerequisite (already included in Microsoft 365 Business Premium, E3, and E5), plus Entra Private Access per user — available standalone or as part of the Microsoft Entra Suite, which also bundles Internet Access, ID Protection, and ID Governance. Which path is cheapest depends on what you already own and what else you plan to deploy; we put the exact requirement and options in writing during discovery, against Microsoft's current published pricing.
No, and be wary of anyone who promises that. The engagement ends with Private Access serving the migrated segments, the VPN running as fallback, and a decommission-readiness checklist showing exactly what still depends on it, if anything. You switch the VPN off when the checklist is clean and you are comfortable — for many organizations that is weeks after go-live, deliberately.
They are the honest test of any VPN replacement, so they go into the pilot's validation script explicitly. SMB file shares and many legacy applications work through Private Access as app segments, and single sign-on to Kerberos-protected on-premises resources is configurable — we set that up where in scope. Patterns that genuinely do not fit (a rare few do exist, typically apps that initiate connections toward the client) are identified during pilot and given documented options rather than quietly left broken.
Windows and macOS carry most deployments, with mobile client support available for scoped platforms — the exact platform matrix is verified against Microsoft's current documentation at design time, because the client is under active development. Rollout goes through your endpoint management (Intune where you have it), pilot ring first. Unmanaged personal devices are a policy conversation: Conditional Access can require compliant devices per segment, which is often the moment organizations tighten BYOD access deliberately.
No — the rollout is ringed twice over. The client goes out in deployment rings (pilot, then expanding groups), and applications cut over segment by segment in an order you approve. Any user not yet migrated keeps using the VPN; both paths work during coexistence. This is also the honest reason the project succeeds: nothing forces a big-bang moment where everything must work simultaneously.
Not in this scope, and mostly not as a product: Private Access replaces user-to-application access. Site-to-site links, branch connectivity, and server-to-server flows are network architecture — if your current VPN concentrator carries both duties, the design document separates them explicitly so the user side can move to Zero Trust while the network side gets its own plan. We can scope that separately.
It builds on them rather than replacing them. Each app segment becomes an object Conditional Access can target, so your existing patterns — MFA enforcement, compliant-device requirements, named locations — extend to internal applications that policy could never see behind the VPN. New policies deploy in report-only mode first, and if your Conditional Access baseline itself needs work, our dedicated Conditional Access implementation covers that foundation.
It implements the network-access slice of Zero Trust properly: per-application access, identity and device verification on every connection, no implicit trust from network position. It is not the whole architecture — data protection, endpoint hardening, and monitoring are their own pillars. If you are working toward a full Zero Trust posture, this project slots into our broader Zero Trust architecture implementation as the remote-access component.
The classic failure modes are: an application inventory that missed something users depend on (found by our discovery and pilot, which is why both exist), a legacy traffic pattern that does not fit the model (found by the validation script, dispositioned with options), connector hosts that were undersized or non-redundant (we deploy pairs and check health), and a VPN switched off before the checklist was clean (which is why decommission is your deliberate act, not our closing stunt). The two-week timeline holds when the prerequisites are ready; discovery tells you if your estate needs longer.
Your team, with the runbook: connector health monitoring, traffic logs, adding new app segments, and client troubleshooting are all documented procedures rather than tribal knowledge. Adding an application later is minutes of policy work, not a project. If you would rather we operate or monitor it ongoing, that is available separately — no obligation, and the runbook is written so you never need us for routine work.