What zero trust network access costs to build, partner for or buy as SaaS
Cost depends on the number of users, machines, applications and on who operates the control plane. Self-hosting shifts spend from subscriptions to infrastructure, migration work and staff time, so the cheapest option on paper can be the most expensive one to run. The published per-user prices for NetBird and Pomerium are comparison points only: NetBird's cloud Team plan is listed at 6 euros and Business at 12 euros per user per month, and Pomerium Zero Business at $9 per user per month billed monthly or $7 billed annually. No supplied price exists for OpenZiti, for NetFoundry's managed network, or for a self-hosted Pomerium Enterprise control plane, so you must request written quotes for those.
Before comparing numbers, list what each option charges for. Subscriptions bill active users and machines, and NetBird counts only active users and machines, so inactive contractor accounts and retired devices affect the bill. Self-hosting moves the cost to a Linux virtual machine or cluster, a public domain, backups, upgrades and scaling, all of which your team or a partner must run. NetBird's documentation states that self-hosted operators handle these tasks themselves. Per-application migration effort, device posture integrations and the run-both-in-parallel period during cutover usually cost more than the platform itself, and they recur whenever you add an application.
Ask each vendor or partner for a quote that separates one-time work (design, identity provider integration, route and policy migration per application, testing) from recurring items (subscriptions or support, infrastructure, upgrades, on-call time and log retention). Ask which Pomerium edition gates directory sync, Rego policies and session management, and which NetBird tier includes device posture checks and traffic logging, because those features often decide the tier. Confirm whether relays and control plane components sit inside your cloud account, and who pays for them if they run there.
Cost components across in-house, partner and SaaS delivery
This table compares who carries each cost of a ZTNA program when it is built in-house, delivered by an implementation partner, or bought as managed SaaS, and whether each cost is one-time or recurring. Read each row as a question to put to your own team, a partner's written scope or a SaaS vendor's order form. The main takeaway is that self-hosting moves the recurring hosting and upgrade work onto your side, while SaaS shifts it to the vendor and keeps per-user and per-machine fees.
| Cost component | In-house | Implementation partner | Managed SaaS |
|---|---|---|---|
| Control plane hosting (one-time setup, then recurring) | Your team pays for cloud or data center capacity and runs the controller or management service continuously | Partner is paid to design and deploy the control plane, then hosting stays on your infrastructure and your bill | Vendor hosts the control plane; you pay the subscription and do not run servers for it |
| Relay and gateway infrastructure (recurring) | You size, place and pay for public relays or edge routers, including bandwidth for relayed traffic | Partner sizes and deploys relays in your accounts; you keep paying the cloud or hardware costs | Vendor-run relays are included in the plan; check whether relayed traffic has limits or extra charges |
| Identity provider integration (one-time, then recurring changes) | Your identity team builds SSO, group mapping and MFA settings and maintains them as the directory changes | Partner is paid for the initial integration and test cases; ongoing directory changes stay with you or a retainer | Vendor connectors are paid through the plan tier; confirm which SSO and SCIM features each tier includes |
| Client rollout to devices (one-time per fleet, then recurring) | Your endpoint team packages clients, handles exceptions and supports users during rollout | Partner may write rollout guides and pilot scripts; device management tooling is usually your cost | Vendor provides clients; your endpoint team still deploys them through your MDM and supports users |
| Per-application migration (one-time per application) | Effort scales with the number of apps, protocols and owners you must engage, and is carried by your staff | Partner is paid per agreed application or per fixed scope, so ask for each app's inventory, tests and rollback steps | Vendor may offer templates; you still pay internal staff to define policies, owners and test cases for each app |
| Testing and cutover (one-time, with retesting after changes) | Your team designs the test plan, runs parallel access during cutover and owns the rollback decision | Partner is paid for test design, execution and cutover support; retests after later changes are a new scope item | Your team tests access policies; the vendor is typically paid only for the platform, not your app test cases |
| Logging and evidence (recurring) | You build log export, retention and reporting, and pay for storage and any SIEM ingestion | Partner can configure log forwarding and evidence packs; storage and SIEM ingestion remain your recurring cost | Access and audit logs come with the plan, but export, retention limits and SIEM costs need confirmation |
| Backups, upgrades and scaling (recurring) | Your staff run backups, restore tests, version upgrades and capacity changes on a schedule you set | Partner can take these on under a retainer; without one, they return to your team after handover | Vendor handles upgrades and scaling; you still own the backup of your policies and configuration exports |
| Support (recurring) | Your on-call and vendor or community support arrangements carry the full load | Support is a separate retainer or contract; confirm response expectations and who triages incidents | Support tier is part of the subscription; confirm response times and whether they are written into the contract |
What moves the zero trust access cost up or down
Self-hosted and managed zero trust access costs follow a few variables: how many people and machines connect, how many applications and protocols sit behind the gateway, which identity and posture controls you need, and where the control plane and relays run. Work through these drivers before comparing a quote with a self-hosted estimate.
Active users and machines
NetBird's cloud pricing bills only active users and machines, so the same headcount can cost differently depending on how many devices each person enrolls. Free covers up to 5 users and 100 machines, while Team and Business add per-user fees with 100 machines included and extra machines at 0.50 euros each. Ask a vendor how it defines an active user and whether service accounts, CI runners and routers count as machines.
Number and type of applications
Per-route and per-policy limits decide how far a managed proxy plan stretches. Pomerium's Zero Business tier includes 100 routes and 100 policies, while Zero Personal allows 10 routes and 5 policies. Count web apps, SSH hosts, TCP and UDP services and database endpoints separately, because each type changes the route count, the policy count and the migration work per application.
Posture and MFA tiers
Device posture checks, MFA enforcement and directory sync are often gated behind higher NetBird plans or Pomerium's Enterprise edition. NetBird's Team tier adds SSO and MFA with an enterprise identity provider and SCIM, while Business adds device approvals, MDM and EDR controls and posture checks. Pomerium reserves directory sync, FleetDM device posture and SSH session recording for Enterprise. Map each control your regulator or auditor expects to a specific tier before you budget.
Self-hosted versus managed control plane
A self-hosted control plane moves license spend into operations: you provision the servers, run backups, apply upgrades and scale the service yourself. NetBird's self-hosting quickstart starts with a Linux VM with at least 1 CPU and 2 GB of memory, a public domain and Docker with Compose, but that is the starting point, not the full operating load. A managed control plane removes that work but adds per-user fees and places part of the metadata with the vendor. Confirm what each component stores before deciding.
High availability and relay placement
Relays carry traffic when direct peer-to-peer paths fail, so their number and location affect both latency and bandwidth charges. A self-hosted NetBird deployment combines management, signal, relay and STUN in one configuration, so high availability means duplicating that stack across regions and load balancing it. OpenZiti lets you place public edge routers where you need entry points and private routers that dial out. Ask for the redundancy design, the regions covered and who pays for egress traffic.
Build effort and expert time
The fixed cost of self-hosting is mostly skilled engineering time, which varies with the identity provider, the posture integrations and the number of connection models you mix. OpenZiti supports network, host and SDK access models that can be combined, and each model adds configuration and testing. Ask an implementation partner to price the identity integration, the per-application migration, the cutover period and the first year of upgrades separately so you can see which items recur.
How the published NetBird and Pomerium plans compare
NetBird's published cloud prices start at free and rise per user. The Free plan covers up to 5 users and 100 machines. Team is listed at 6 euros and Business at 12 euros per user per month, each with 100 machines included and extra machines at 0.50 euros. Billing counts only active users and machines, so a seasonal contractor pool can cost less than a headcount multiplied by the list rate. Team adds SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging. Business adds device approvals, MDM and EDR device controls, posture checks and traffic logging and streaming. Enterprise is custom priced. Check which of these controls your audit and device policy actually requires before you pick a tier.
Pomerium's published prices split by who runs the control plane. Core is open source and self-run, so its license cost is zero, but you carry the hosting, upgrades and support. Zero Personal is free for personal use with a managed control plane and a limit of 1 cluster, 10 routes and 5 policies. Zero Business is listed at $9 per user per month billed monthly or $7 billed annually, with 5 clusters, 100 routes, 100 policies and 5 custom domains. With Zero, your own environment runs the Core cluster while Pomerium hosts the control plane and console, so application traffic stays with you. Directory sync, Rego policies, administrator RBAC, session management and SSH session recording and playback sit in the custom-priced Enterprise edition with a self-hosted control plane.
These are list prices for comparison, not a quote for your environment. Ask each vendor for written pricing based on your named user count, machine or device count, route or application count, support level and whether you need Enterprise features such as SSH session recording. Confirm whether the per-user figure is billed monthly or annually and whether taxes or minimums apply. Your own cost still includes the hosting and staff time that a self-run control plane requires, which the list price does not show. Compare the total against the fully self-hosted option, where OpenZiti and Headscale carry no license fee, and factor in the engineering effort to run them.
How to build your own ZTNA cost estimate
This sequence turns a vague VPN replacement idea into a costed comparison, so you can put self-hosted ZTNA side by side with a managed per-user quote for the same population and the same applications.
Inventory users, devices and applications by type
Start by listing who needs access, on which devices, and to which applications. Group applications by type: web apps, SSH, RDP, databases, UDP services and anything running on operational technology. Count active users and machines separately, because managed plans bill on both. Ask the application owners which services are still reached through the VPN and which are only assumed. The step is done when you have one table with user counts, machine counts and application counts per type, reviewed by the identity team and the application owners.
Choose the overlay, proxy or dark-service model
Decide which access pattern fits each application group. An overlay such as NetBird or Headscale suits device-level network reach for staff and engineers. An identity-aware proxy such as Pomerium suits browser and SSH access to named web apps. OpenZiti dark services suit outbound-only connections to protected services with no listening ports. Mixed designs are common, and each model carries different components to price. The step is done when each application group is assigned one model and the reasoning is written down for procurement.
Price the self-hosted control plane
Price the control plane for each model. As a reference point, NetBird's self-hosting quickstart lists a Linux virtual machine with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443 and UDP port 3478, plus Docker with the Compose plugin. That baseline is a starting point for a lab or small deployment, not a sizing for production. For production, ask your team or partner to size the control plane against your user count, high availability needs and region placement. The step is done when you have a written infrastructure line item for each environment, including production and non-production.
Add relay and gateway capacity
Relays and gateways carry traffic when direct peer-to-peer paths fail, or when all traffic must pass through a controlled point. Estimate relay count, placement and bandwidth from your traffic patterns, including large file transfers, remote imaging or engineering data flows. Confirm with each vendor whether relay traffic can be placed in your own regions and who can see its metadata. The step is done when relay capacity, location and expected egress costs are recorded against each application group.
List identity and posture integrations
List every identity provider, directory, MFA method and device posture signal the design depends on. For NetBird, the Team and Business tiers differ on SSO, MFA, SCIM, device approvals and posture checks, so note which features each tier needs. For Pomerium, directory sync, Rego policies and session recording sit in the Enterprise edition. Record the integration work as a separate line, because each connector needs configuration, testing and ongoing maintenance. The step is done when every required integration has an owner and a note on which edition or tier supplies it.
Estimate migration effort per application
Estimate the work to move each application off the VPN. Simple web apps behind a proxy usually need policy definition, route setup and testing. Databases, legacy thick clients and OT systems need more analysis, client rollout and cutover planning. Include time for running the VPN and the new path in parallel during cutover. Ask partners for a fixed-scope estimate per application group, since migration effort is what most often changes the total. The step is done when each application has a migration complexity rating and a written effort estimate from the team doing the work.
Add operations for backups, upgrades and on-call
Add recurring operations work to the model. NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves. The same applies to any self-hosted control plane, relay and reverse proxy. Include backup testing, version upgrades across all components, certificate renewal, monitoring, log retention and an on-call rota that covers access outages. Ask whether support, upgrades and continuous testing are covered by a retainer, and what that retainer costs in writing. The step is done when recurring operations are listed as a monthly and annual cost line with named owners.
Compare against per-user SaaS quotes using the same user count
Request written quotes from managed providers using your exact user count, machine count and required features, so the comparison is like for like. Published list prices exist for some plans, including NetBird's Team and Business tiers and Pomerium's Zero Business plan, but enterprise pricing is custom and tier limits differ. Build one table with one-time costs, recurring infrastructure, recurring operations, migration effort and vendor fees over the same period. Get written scope from any implementation partner before comparing numbers, because unstated scope is the most common reason estimates diverge. The step is done when the self-hosted total and the SaaS quotes are compared on identical assumptions.
Questions buyers ask before hiring help on ZTNA cost
How much does self-hosted ZTNA cost compared with a SaaS service?
The software licenses are often the smallest part of the comparison, so compare total cost, not list prices. Published SaaS plans are priced per user per month. NetBird Cloud lists Free for up to 5 users and 100 machines, Team at 6 euros and Business at 12 euros per user per month, and custom Enterprise pricing. Pomerium Zero Business is listed at $9 per user per month billed monthly or $7 billed annually. Self-hosted NetBird and Pomerium Core have no per-user license fee, but you pay for the servers, the relays, the staff time to run them, and the implementation work. Model both sides for your user count, machine count and app count before comparing.
What part of ZTNA cost is one-time and what recurs?
One-time costs are the design, the identity provider and posture integration, the migration of each application, testing and the cutover from the VPN. Recurring costs are the infrastructure that runs the control plane and relays, subscriptions or support contracts, upgrades, backups, monitoring, user and policy changes, and staff time. In a SaaS model, most recurring cost is the per-user subscription. In a self-hosted model, the recurring cost sits in cloud or data center hosting and in the people who operate the platform. Ask any partner to split the quote into these two groups so you can see what continues after go-live.
How long does migrating each application to ZTNA take?
Migration time depends on the number of applications and their types. A browser-based internal app behind an identity-aware proxy is usually a different job from an SSH host, a database, an RDP session or a UDP service, and each needs its own policy, testing and user communication. Timelines are set in the written scope agreed before work starts, after the application inventory is complete. Ask for the timeline to be tied to named applications and to the cutover steps for each one, including how the VPN stays available during the transition.
What does a ZTNA project need from our own team?
A ZTNA project needs decisions and access from several owners. Identity provider administrators configure single sign-on, multi-factor authentication and groups that map to access policy. Network owners approve firewall changes, routes, DNS and any relay or edge placement. Application owners confirm which users need which routes, test their apps after migration and sign off on access rules. Security leads approve the policy model, posture requirements, logging and the final cutover. Agree these named roles at the start, because delays in identity or network approvals usually slow the project more than the technical work.
Can our engineers run self-hosted ZTNA using only the public documentation?
Engineers with networking, identity and Linux skills can deploy a small self-hosted NetBird test environment from the public quickstart, which needs a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443, UDP port 3478 and Docker with the Compose plugin. Production use adds work the quickstart does not cover: high availability, relay placement, backups, upgrades, scaling, identity provider integration, device posture, logging and migration of real applications. Your team also takes on the ongoing duty to patch and monitor the platform. Decide whether that duty fits your staffing before you start.
What should a partner quote for ZTNA include?
A partner quote should follow from a written scope and list the following:
- The approach chosen (overlay, identity-aware proxy or both), the editions and the components to be deployed.
- The applications and access types in scope, with the migration steps for each.
- The identity provider, posture and logging integrations, and who configures them.
- Hardening, backup, upgrade and documentation work, plus the evidence delivered for compliance reviews.
- Acceptance criteria, the timeline tied to milestones, and what the client team must provide.
- Support options after go-live, such as a retainer, and any third-party license costs passed through.
DeployOpen does not publish a price list, and it prepares evidence for compliance assessments without issuing audit reports or certifications.
What ongoing operations cost after launch
Ongoing operations usually cost more over a platform's life than the initial build, so price them as a separate line from day one. For self-hosted ZTNA, the recurring work sits in four places: release upgrades, backups and scaling, certificate and domain management, and monitoring with evidence collection. The release cadence is visible in the sources: Pomerium published v0.33.4 on October 2, 2026, after v0.33.3 on September 9, 2026, and NetBird published v0.81.2 on October 16, 2026, one day after v0.81.0. Someone must track each release, test it against your identity provider and routes, and schedule the change window.
NetBird states that self-hosted operators handle backups, upgrades and scaling themselves, and its self-hosting quickstart places the management, signal, relay and STUN components, the dashboard, a Traefik reverse proxy with Let's Encrypt by default and an embedded Dex identity provider in one deployment. Each of these needs a named owner. Certificate renewal, the public domain, TCP 80 and 443 and UDP 3478 reachability, and any external SSO connection can each break access for every user if they lapse, so monitor them and test restores. Ask any partner to state in writing who performs upgrades, restore tests, and capacity reviews, and how often.
Access reviews and evidence collection recur on your compliance calendar, not the vendor's. Policies, groups and posture rules change as people move, and the logs must show who reached which application. Confirm with your assessor which logs, retention periods and review cadence they expect before you finalize the operating model. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and these can cover some of the recurring tasks above; ask for the retainer scope in writing, including response expectations, so you can compare it with doing the work in-house.
How DeployOpen scopes and delivers a fixed-scope ZTNA implementation
DeployOpen approaches zero trust network access cost as a written, fixed-scope question: which apps, users and devices are in scope, which control plane runs where, and what each option costs to build and run. The scope is agreed in writing before any work starts, so the cost comparison rests on your environment rather than on a generic estimate.
How we scope
- Inventory the applications, protocols (web, SSH, RDP, databases, UDP) and users that the ZTNA design must cover.
- Document where the control plane, relays or edge routers would run, and which cloud accounts, data centers or networks host them.
- Agree the written scope, deliverables and timeline before work starts, including which options are costed and which are excluded.
How we build
- Deploy the chosen open-source option, such as NetBird, Pomerium or OpenZiti, inside your own infrastructure.
- Connect the identity provider, group-based access policies and device posture signals that your scope requires.
- Test access paths, revocation behavior and logging for each migrated application before it leaves the VPN.
How we hand over
- Provide documentation of architecture, access policies, routes and the operating runbook for your team.
- Deliver a cost model that separates one-time migration work from recurring hosting, upgrade and support effort.
- Produce evidence of configuration and access logs that your compliance team can use in its own assessment.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately in writing.
- Plan platform upgrades and backups as part of the operating model, so recurring effort is visible in the quote.
- Retest access controls after policy or application changes, with findings reported against the agreed scope.
