Open-source alternative to Microsoft Entra Private Access

Open-source alternative to Microsoft Entra Private Access: the short answer

If you are deciding whether to keep paying for Microsoft Entra Private Access, the short answer is that OpenZiti and NetBird are the two self-hosted options worth evaluating. OpenZiti fits teams that want dark services with no open inbound ports and identity-based policy enforced on every connection. NetBird fits teams that want a WireGuard mesh with SSO, groups and access rules that an administrator can run from a web console. In both cases, the element that does not carry over unchanged is the Conditional Access signal set. Entra Private Access decisions today can depend on device state, user risk and location policies that live in Entra ID, and neither open-source platform reads those signals natively. You will need to rebuild that logic from posture checks, identity provider claims and group membership, and confirm each rule against your own requirements. The decision usually starts with one of three triggers: a renewal date, a question about whether Global Secure Access licensing still fits your user count, or a requirement to keep traffic to internal applications on infrastructure you control. Start by inventorying the private FQDNs and IP addresses published through Quick Access and per-app Global Secure Access apps, and note which of them are gated by Conditional Access policies. Confirm current licensing terms with Microsoft, since those terms, not the product description, determine the cost comparison. Microsoft Entra Private Access remains the better choice if your users already depend on Entra ID for Microsoft 365 sign-in, your Conditional Access policies are central to your access model, and you would rather not operate connectors, routers or a control plane yourself. Self-hosting shifts the work of availability, patching, upgrades and backups onto your team or an implementation partner. Choose an open-source path when data residency, air-gapped operation or vendor lock-in is the controlling concern, and when you can staff the operation for the life of the platform.

How Entra Private Access capabilities map to OpenZiti and NetBird

This table maps each Entra Private Access capability to its closest equivalent in OpenZiti and NetBird and marks each as full, partial or no equivalent. Use the middle columns as a starting point for a pilot and verify each mapping before cutover. The main takeaway is that per-app access and the private network connector map well, while Conditional Access and Quick Access need redesign.

Entra Private Access capability	OpenZiti	NetBird	What to confirm
Quick Access (one group for many private targets)	Partial: group services under shared policies using roles or tags	Partial: group resources as network routes and apply rules to groups	Bulk onboarding effort and how admins manage large target lists
Per-app access (one Global Secure Access app per target)	Full: each service has its own dial policy tied to identities	Full: access rules link source groups to destination groups or routes	Rule granularity by port and protocol in the version you deploy
Private FQDN and IP definitions	Partial: services reference hosts and addresses; FQDN handling needs testing	Partial: routes to external networks and private DNS; split DNS needs testing	How each handles FQDN-based targets, wildcards and split DNS in your zones
Private network connector	Full: edge router or tunneler beside the service, connecting outbound	Full: a NetBird peer or routing peer on the network, connecting outbound	Outbound-only design against your firewall and egress policy
Conditional Access gating	No equivalent: policy is identity and service based, so MFA and risk checks come from your IdP	Partial: SSO and MFA through your IdP, with access rules by group	Which Conditional Access signals (location, risk, compliant device) your IdP can supply
Device posture	Partial: depends on identity attributes and external checks	Partial: posture checks on the Business plan, per NetBird's pricing page	Which posture checks exist and whether they match your MDM data
Activity logging	Partial: controller and router logs; SIEM export needs confirmation	Full: audit events on Team and traffic logging on Business, per NetBird's pricing page	Log retention, fields and streaming to your SIEM
Session revocation	Full: revoking access terminates active connections immediately	Partial: removing peers or group membership; active session timing needs testing	How quickly an access removal ends an open session in your setup

OpenZiti or NetBird: which option fits which private access pattern

Entra Private Access publishes private apps through a broker, and the open-source replacements take different routes to the same goal. OpenZiti builds service-level access from identities and policies, while NetBird builds a network overlay for devices. The cards below compare how each one is deployed, licensed, operated and where it trades away convenience.

OpenZiti for per-service access

OpenZiti maps each Entra Private Access app to a named OpenZiti service, with the controller issuing x509 identities and policies deciding which identity reaches which service through which edge router. Three models can be mixed: an edge router in a trusted zone for network access, a tunneler beside a host, or an SDK for application access with no listening ports. Check whether your apps can embed an SDK, since that is the only model that removes the tunneler entirely. Licensing is Apache 2.0, and the README states the full platform can run without vendor dependencies.

NetBird for device-level overlay access

NetBird creates a WireGuard peer-to-peer overlay where devices join through an SSO-backed agent, and groups and rules decide which peers reach which resources. It fits teams whose Entra Private Access use is mostly remote staff reaching internal hosts, subnets or SSH targets, rather than individual application integrations. Client platforms include Linux, Windows, macOS, mobile and several network appliances. The repository is BSD-3-Clause, but the management, signal, relay and combined directories are AGPLv3, so review that split with counsel before modifying those components.

Operating the self-hosted stack

Running OpenZiti means operating a controller, edge routers and the admin console, with public routers reachable from the internet and private routers making outbound connections only. Running NetBird self-hosted means a Linux host with Docker Compose, TCP 80 and 443 and UDP 3478 open, plus a Dex identity provider unless you connect an external one. Your team owns backups, upgrades and scaling in both cases. Ask whether the operating team has time to patch relay infrastructure monthly, and confirm the current release cadence on each project's release page before you commit.

Conditional Access and logging trade-offs

Entra Private Access sits inside Conditional Access, so sign-in risk and device compliance policies apply before traffic reaches a private app. Neither OpenZiti nor NetBird reproduces that signal stack natively. NetBird lists device posture checks and activity logging, and its paid tiers add device controls and traffic streaming, but you should map each Conditional Access rule to a concrete posture check before cutover. OpenZiti relies on identity and policy definitions, so compliance evidence for who reached what has to be assembled from its logs.

Pomerium as a neighboring option

Pomerium is worth evaluating if your private access need is mainly identity-aware proxying for web applications, where users authenticate through your existing OIDC provider and reach internal sites over HTTPS. It does not replace network-level reachability for non-HTTP services, so it is a complement rather than a full substitute for either OpenZiti or NetBird. Confirm its current license and feature set directly with the project before comparing it against the two options above.

Headscale as a neighboring option

Headscale is an open-source control server for Tailscale clients, which suits teams that already run Tailscale-compatible devices and want the control plane on their own servers. It does not provide the application-level service model that OpenZiti offers, and its feature coverage for posture and access policy differs from NetBird's, so verify each against your own requirements. Treat it as a candidate to evaluate, not a default replacement for Entra Private Access.

What Conditional Access integration is lost when private access moves

Entra Private Access per-app rules are enforced through Conditional Access, so the signals behind those rules do not move with the apps. In Microsoft's model, a Global Secure Access app is gated by Conditional Access policies that can check the user, the device, the sign-in risk and the location. A self-hosted replacement does not read those signals from Entra ID by default. Before cutover, list every Conditional Access policy that targets a private app, record which conditions it uses (device compliance, risk level, named locations, sign-in frequency, MFA strength), and decide for each one whether the replacement will enforce it, approximate it, or accept the gap. Confirm with Microsoft exactly which conditions apply to Global Secure Access apps in your tenant, because the set of available conditions changes over time.

The closest approximations sit in NetBird's posture checks and in OpenZiti's identity-based policies. NetBird lists SSO and MFA support, groups and access rules, and device posture checks on its Business tier, which is the nearest match to a compliance-gated rule, and its Team tier adds SSO and MFA with an enterprise identity provider and SCIM provisioning. OpenZiti authorizes access through policies that tie identities to services, and identity attributes can be used to shape which identities reach which services through which routers. Neither product is a drop-in copy of Entra device compliance or location conditions. Ask each vendor how their posture checks read device state, whether they can evaluate geography or network location, and how a failed check is reflected in active sessions.

Entra risk detection has no direct equivalent in either product, and that gap should be planned for rather than assumed away. Entra ID P2 risk signals, such as risky sign-ins and leaked credentials, depend on Microsoft's own telemetry and do not transfer to a self-hosted identity provider. Plan for step-up MFA at the identity provider, session lifetime limits, and alerting from NetBird's activity and traffic event logs or OpenZiti's controller logs into your SIEM. Ask your vendor or integrator to document each lost condition, its compensating control, and the residual risk accepted by the application owner.

Moving private app access from Entra Private Access to a self-hosted overlay

This sequence moves each private application from Entra Private Access to OpenZiti or NetBird in groups, with a pilot, a tested rollback path and Entra kept in place for Microsoft 365 sign-in.

Inventory every Quick Access and per-app definition
The network or identity team exports the current configuration: each Quick Access entry, each Global Secure Access app, its private FQDNs and IP addresses, ports, the private network connector it uses, and the Conditional Access policies and user groups attached to it. Record this in a spreadsheet or configuration file kept under change control. The step is done when every private app has one row that a second reviewer has checked against the Entra admin center, and no app is known only from memory.
Classify apps by protocol and access pattern
Group each inventoried app by what it does on the network: browser-based web apps, SSH or RDP administration, database or message connections, file shares, and client-server applications that embed their own endpoints. Note which apps need a user to reach them from unmanaged devices and which only run from managed endpoints. The output is a classified list in which each group has a known transport and a named business owner. Confirm with each owner which apps need to stay reachable during cutover.
Choose OpenZiti or NetBird for each app group
Assign each group to a platform based on how it is reached. OpenZiti fits services that should be dark, where applications can use an SDK or a tunneler sits beside the service and no inbound ports are opened. NetBird fits device-level network access with a WireGuard overlay, groups, rules and posture checks. Groups that depend on Conditional Access signals with no equivalent in either platform should stay on Entra until a decision is recorded. The output is a decision table approved by the security owner that names each group and its platform.
Deploy the controller or management stack
The platform team deploys the chosen control plane in the organization's own infrastructure. For OpenZiti, this means the controller, the edge routers (public routers where clients connect from the internet, private routers inside each private network) and the admin console. For NetBird, it means the self-hosted stack with its management, signal, relay and dashboard components, a reverse proxy with TLS, and an identity provider connected to the corporate directory. Operators must also set up backups and upgrade procedures, since the NetBird documentation says self-hosted operators own these tasks. The step is done when the console is reachable by administrators, the TLS certificates are valid, and a test identity can sign in.
Pilot with a small user group
Select a small group of technical users and one or two non-critical applications. Create identities, service definitions and access policies in the new platform, install the client or tunneler on test devices, and confirm that access works while the Entra configuration stays active. Test the access denial paths too: a user outside the group should be blocked, and revoking a test identity should end active sessions. The pilot is complete when the test group has used the apps for a period agreed with the application owners and the incidents are logged and resolved.
Cut over applications group by group
Move each approved group in a planned change window. For each app, add the new service definition, switch the client to the new route, and keep the Entra entry in place until the owner confirms the app works from the new path. Log every user population moved and record any app that needs a different approach, such as an embedded SDK change for a client-server app. Change records and the decision table should match at the end of each group.
Define and test the rollback path
Before the cutover of each group, write a rollback procedure: the Entra Private Access app or Quick Access entry that will be reactivated, the user group that receives it, and the person who approves the switch. Test it in the pilot. Keep the Entra connector running until the last group has been stable for the period the application owners agreed. Only retire the connector and Global Secure Access policies after rollback is no longer needed and the decision is signed off.
Retire the Entra connector and keep Entra for Microsoft 365 sign-in
After every group is stable, remove the Entra private network connectors, Quick Access entries and per-app Global Secure Access policies, and export the final configuration for records. Keep Microsoft Entra ID for Microsoft 365 and any Entra-integrated services that still depend on it, and confirm with the identity team which sign-ins remain there. The step is complete when Entra no longer brokers private traffic, the self-hosted platform is the only path for those apps, and the change records and rollback notes are filed with the security team.

Who should keep Entra Private Access and who should move

Organizations that already gate private app access with Conditional Access policies, device compliance and risk signals usually have the most to lose by moving. Entra Private Access sits inside the Global Secure Access model, so its per-app access is controlled by the same Conditional Access rules that protect Microsoft 365 and other Entra-integrated apps. OpenZiti and NetBird can enforce their own identity and device policies, but they do not read Entra risk signals or Conditional Access evaluations natively, so those controls would have to be rebuilt or accepted as lost.

Signal inventory: List every Conditional Access condition that applies to private app access today, including location, device compliance, sign-in risk and session controls.
Replacement path: Confirm whether NetBird's SSO, MFA, posture checks and groups, or OpenZiti's policy model, can express each rule you depend on.
Risk signals: Identify which decisions rely on Entra ID P2 risk detections and whether a self-hosted policy engine can act on equivalent data.
Audit evidence: Check how access decisions are logged today and whether the replacement produces records your auditors accept.

Confirm with the vendors and in your own tenant which features are available in your license tier before deciding.

Running the self-hosted overlay next to Entra ID and Microsoft 365

Replacing Entra Private Access does not remove Entra ID from the estate. Most organizations keep Entra ID for Microsoft 365 and for overlay sign-in, while the overlay, its logs and its admin accounts gain their own decisions. The cards below cover the identity, licensing, transition and monitoring choices that connect the two.

Keep Entra ID as the overlay identity source

NetBird can use an enterprise identity provider for SSO and MFA, and its Team tier lists SCIM provisioning on NetBird's pricing page, so Entra ID can keep owning users and groups. Confirm which NetBird tier includes the SSO and SCIM features you need, and whether group membership maps cleanly to the access rules you plan to write. For OpenZiti, the controller issues x509 identities to each participant, so the question becomes how enrollment is tied to people who already exist in Entra ID.

Keep Microsoft 365 sign-in on Entra

The overlay does not change how people sign in to Outlook, Teams or SharePoint. Entra ID continues to enforce those sign-ins, and its Conditional Access policies still apply to Microsoft 365 workloads. Document which apps stay on Entra and which move to the overlay, so a user is not asked to satisfy two different MFA prompts without knowing why. Check whether your Entra licensing still covers the Conditional Access policies you rely on after Entra Private Access is switched off.

Run both during a transition window

Most migrations keep Entra Private Access running while the overlay takes over one application group at a time. Pick a low-risk internal app first, then move its users and routes, and keep the old path available until the overlay has been stable for your agreed test period. Record which Entra Quick Access or per-app rules are still in use, because removing a shared connector too early can break an application that was assumed to be retired.

Monitor the overlay with existing SIEM tools

NetBird logs activity and traffic events, and its Business tier adds traffic logging and streaming. Decide where these logs go before go-live, and confirm that your SIEM can ingest them without losing the user, device and destination fields you need for investigations. OpenZiti's controller and router logs need the same decision. Set retention and access rules for these logs as deliberately as you would for Entra sign-in logs.

Decide the overlay's own identity and logging

The overlay adds administrator accounts, API tokens, setup keys and, for NetBird self-hosting, an embedded Dex identity provider unless you connect an external one. These are new identity surfaces that must be decided explicitly, not inherited by default from Entra ID. Name the owner of each admin role, confirm how MFA applies to the overlay console, and decide whether the self-hosted instance uses Entra ID as its external provider or a separate one.

Questions buyers ask before replacing Entra Private Access

What does replacing Entra Private Access cost in components?

The cost splits into things you run yourself and things you may buy. Self-hosting needs a Linux virtual machine, a public domain, open inbound ports and staff time to operate it, and those costs recur. The NetBird self-hosting quickstart sets the minimum for its stack at 1 CPU and 2 GB of memory, with TCP ports 80 and 443 and UDP port 3478 open, plus Docker with the Compose plugin. Staff time is usually the largest line: someone owns backups, upgrades and scaling, which NetBird's documentation assigns to self-hosted operators. If you choose a managed tier, NetBird's pricing page lists Team at 6 euros and Business at 12 euros per user per month, each with 100 machines included and extra machines at 0.50 euros. Ask any vendor for the exact tier, the billing unit and whether support is included.

How long does a pilot take, and what drives the timing?

The length depends on how many private applications you move, how they are reached today, and how much policy has to be rebuilt. No figure has been published for this, so confirm it against your own inventory. The main drivers are the number of Quick Access entries and per-app rules to translate into services and policies, whether applications are reached by fully qualified domain name or by IP address, the connectors or tunnelers each host needs, and how many device types must be supported. Plan a pilot with a few low-risk applications, a test identity group and a rollback path back to your existing access method. Scope, deliverables and timeline are agreed in writing before work starts on fixed-scope engagements.

Can our own team run this migration without outside help?

A team with Linux, container and network administration skills can build a pilot itself, especially with NetBird, which ships a Docker Compose self-hosting path. Production is a different load. Someone must own certificates, access policy design, logging, patching and incident response, and OpenZiti requires careful design of identities, routers and services before anything is switched over. Be honest about who is on call and how much time they have. Outside help is most useful for the design, a hardened baseline and a documented handover. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your environment, usually under a fixed-scope agreement or a retainer.

Which Conditional Access features do we lose?

You lose the native link between Entra Private Access and Entra Conditional Access, where access to a private app is evaluated against sign-in risk, device compliance and other Entra signals. Neither NetBird nor OpenZiti reads Entra Conditional Access policies. NetBird offers SSO and MFA through an external identity provider, groups and rules, device posture checks and activity logging, and its Business tier adds device approvals and posture checks, so you can rebuild a subset of these rules. Confirm which signals your identity provider passes and which posture attributes your devices report. Map every existing Conditional Access rule before you retire anything, and record the ones with no equivalent as accepted risk.

Does NetBird or OpenZiti fit a regulated environment?

Both can fit, but the answer depends on your control requirements and how you deploy them, not on the licence alone. OpenZiti authenticates every connection with a cryptographic identity, applies policy, encrypts traffic end to end, and can present services with no open ports, and it is licensed under Apache 2.0. NetBird's repository uses BSD-3-Clause for most code and AGPLv3 for its management, signal, relay and combined directories, which your legal team should review. Confirm data location, logging retention, key management and how each product's controls map to your framework. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications; independent auditors and certification bodies do that.

What should a written quote for this migration include?

A useful quote lists each component and who pays for it. Ask for the scope in writing: the applications and networks in scope, the number of users, devices and machines, and the deployment model for each host, whether network edge router, tunneler or SDK. Require separate lines for design, implementation, policy translation, pilot, cutover, documentation and handover, plus any hardening or testing you want. Name the infrastructure that is yours to provide, such as the virtual machines, domain and firewall changes, and the vendor cloud or support tier if chosen. Ask what recurs (hosting, licences per user, support, retainers) and what is one-time, and confirm the acceptance criteria and the rollback plan.

Who should keep Entra Private Access instead of replacing it?

Keep Entra Private Access if your private applications are already tightly bound to Entra Conditional Access, if your identity is Entra ID across Microsoft 365 and Azure, or if your team cannot staff the operation for the long term. It is also reasonable to keep it when the cost of rebuilding policy exceeds the benefit of owning the network path. Consider a self-hosted option when data location, vendor lock-in or licence terms matter more than native integration, or when you need network access on infrastructure you control, including sites with restricted connectivity. Replacing Entra ID's other functions is a separate decision that your existing identity pages cover.

How licensing and support differ between OpenZiti, NetBird and Entra

The software license is the smallest part of what you are buying with either open-source option, so read the terms with the operating model in mind. OpenZiti is licensed under Apache 2.0, and the README states that the whole platform can run on your own infrastructure with no vendor dependencies. NetFoundry, which created and sponsors OpenZiti, sells a fully managed, globally distributed OpenZiti network with SLAs and enterprise support. That managed network is a separate commercial service with its own contract, not a condition of using the Apache 2.0 code. NetBird's repository is BSD-3-Clause, except the management, signal, relay and combined directories, which are licensed under AGPLv3. If you modify and offer those AGPLv3 components to users over a network, have your legal team confirm what that obligates you to publish. Confirm the current terms in each project's LICENSE file before you build on a specific release.

With self-hosting, your team owns backups, upgrades and scaling. NetBird's self-hosting documentation says so directly: operators handle those tasks themselves, while NetBird Cloud is the managed version that needs no servers or domain. For OpenZiti, the controller and edge routers are your operational responsibility in the same way, and the controller holds the identity and policy state you would need to restore. Plan a tested restore procedure, a patch cadence for the controller and routers, and capacity planning for the router mesh before production cutover. On the NetBird side, NetBird's pricing page lists Team and Business plans per active user with SSO, SCIM and audit logging on higher tiers, so ask whether you need those features or whether the free self-hosted route covers your use.

Entra Private Access is a Microsoft service with its support and service terms covered by your Microsoft agreement, so compare what each option promises in writing. An SLA is a contractual commitment; an open-source license is not. Support from a vendor, a managed-network provider or a systems integrator is also bought separately from the software, and it recurs as long as you rely on it. When you request quotes, ask for response times, severity definitions, the named responsibilities for patching and backups, and what happens to your policies if you stop the contract. Ask Microsoft to confirm the Global Secure Access licensing that applies to your users, and ask NetFoundry or NetBird what their support tiers cover.

How DeployOpen scopes and delivers a private access migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For private access, that means mapping your Entra Private Access apps to OpenZiti or NetBird services and policies in your own environment, with the Conditional Access gaps named before any cutover begins.

How we scope

Inventory every Quick Access app and per-app Global Secure Access app, with its private FQDNs and IP addresses.
Record which Conditional Access conditions protect each app, and agree in writing how each one will be handled or accepted as lost.
Agree the written scope, deliverables and timelines before work starts, since most engagements are fixed-scope and quoted from that scope.

How we build

Deploy the OpenZiti controller and edge routers, or the NetBird management stack, in the network zones you choose.
Model each private app as a service with identities and policies, then test reachability and denial paths for each user group.
Harden the deployment, configure identity provider integration and back up configuration, then run security testing where the scope requires it.

How we hand over

Document the service-to-policy map, connector and router placement, and the controls that replace the Conditional Access rules.
Walk your operations and security staff through daily administration, revoking access, reviewing logs and running backups.
Provide a rollback path and a written list of the access rules and posture checks that remain your responsibility after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, aligned to the version releases you choose to adopt.
Confirm the upgrade cadence for OpenZiti or NetBird releases with your team before each change window goes ahead.
Prepare the systems, controls and evidence your compliance assessors will ask for, while independent auditors issue any attestation.

Open-source alternative to Microsoft Entra Private Access