Open-source zero trust network access: which option fits your situation
If your team wants private network access without exposing internal services to the internet, the first decision is which overlay model you can run. NetBird suits teams that want a managed-feel overlay with central policy and an admin UI. Headscale suits a single small tailnet within a narrow scope, aimed at self-hosters and small open-source organizations. OpenZiti suits dark services and application-level access, where services have no open ports and identity is embedded in the application. For web-only access, Pomerium is the option to evaluate first, and it is covered on its own comparison page. The rest of this page compares the three overlay and network options.
The right choice depends on three things: your identity provider, your team size and how much operating work your team can carry. NetBird's self-hosted quickstart runs management, signal, relay and STUN from one combined configuration, with a Traefik reverse proxy and an embedded Dex identity provider that can add external SSO providers such as Google, Microsoft or Okta. Confirm that your identity provider fits that path before you commit. Headscale's documentation says it does not support or encourage running it behind reverse proxies or in containers, which constrains where you can host it. OpenZiti's controller and edge routers are a different model, so plan for more architecture work up front.
Operating effort is the variable most teams underestimate. NetBird's documentation says self-hosted operators handle backups, upgrades and scaling themselves, while NetBird Cloud removes the servers and domain. Ask each vendor, or test in your own environment, how identity provider changes, certificate renewal and client rollout are handled. Check which identity features your edition includes, because NetBird's cloud pricing page places SSO, MFA and SCIM provisioning in its paid tiers. Use the sections below to compare architecture, clients, identity integration, access policies and operating effort side by side before you shortlist.
Which open-source zero trust network access tool fits each scenario
This table matches common zero trust network access needs to the self-hosted option whose design fits them best, with the supplied fact that drives each choice. Read it by finding your situation in the first column, then checking the reason before you shortlist a tool.
| Scenario | Best fit | Why |
|---|---|---|
| Small team or lab needing private access to a few hosts | Headscale | Its stated scope is a single tailnet for personal use or a small open-source organization. Confirm that your setup avoids reverse proxies and containers, which the project does not support or encourage. |
| Company wanting SSO, MFA and device posture under one admin UI | NetBird | It combines SSO and MFA, groups and rules, device posture checks and an admin web UI in one product. Check which of these need the Team or Business tier on the cloud pricing page if you use the managed service. |
| Organization needing dark services with no inbound firewall rules | OpenZiti | Services can have no open ports, and private edge routers make only outbound connections, so no inbound firewall rules are needed. Revoking access terminates active connections immediately. |
| Application-level access with an embedded SDK | OpenZiti | Its SDKs for Go, C, Python, Node.js, Java, Swift and C# embed identity and encryption in the application, with no listening ports. This requires changes to the application code. |
| Team that needs only browser access to internal web apps | Pomerium (see its own page) | Web-only access is covered on the Pomerium comparison page. Compare it there before choosing a mesh overlay for browser-based apps. |
| Team that needs a fully managed service | NetBird Cloud or OpenZiti via NetFoundry (confirm terms) | NetBird Cloud is the managed version that needs no servers or domain. NetFoundry offers a managed OpenZiti network with SLAs and enterprise support, so request its written terms before relying on them. |
| Team with an existing identity provider and a need for self-hosted control of the data plane | NetBird (self-hosted) or OpenZiti | NetBird's self-hosted quickstart includes an embedded Dex identity provider that can add external SSO. OpenZiti runs on your own infrastructure with no vendor dependencies. Confirm the identity provider integration you need against each project's documentation. |
What each option is built for and under which license
These four options solve different parts of the same problem: giving people and devices private access to internal resources without a flat network. Their licenses, control planes and client models differ enough that the license and the scope of each project should be checked before the architecture is compared.
NetBird
NetBird pairs a WireGuard overlay network with a central access control system and an admin web UI. Its repository is BSD-3-Clause, but the management, signal, relay and combined directories are AGPLv3, so modifications to those components carry source obligations to check with counsel. The cloud tiers are a managed service, not open source. This option matters when you want a self-hosted overlay with SSO, posture checks and SSH policies and you can run the combined stack on your own server.
Headscale
Headscale is a BSD-3-Clause open-source implementation of the Tailscale control server. The Tailscale GUI clients for Windows, macOS and iOS and the control server are not open source, so the open-source part is the control plane and the clients you run on other platforms. Its stated scope is a single tailnet for personal use or a small open-source organization. It matters when your team already runs Tailscale clients and needs a self-hosted coordinator, and you should confirm that the project's own guidance on reverse proxies and containers fits your deployment.
OpenZiti
OpenZiti is an Apache 2.0 zero trust networking platform in which every connection is authenticated with a cryptographic identity, authorized by policy and encrypted end to end. NetFoundry created and sponsors the project. NetFoundry also offers a fully managed, globally distributed network with SLAs, which is not open source. It matters when you need dark services with no inbound ports, or application-level access through an embedded SDK, and you can operate a controller and edge routers yourself.
Pomerium
Pomerium is an Apache-2.0 identity and context-aware reverse proxy that controls access to web applications. It covers web-only access, so it does not replace an overlay network for SSH, database or non-HTTP traffic. Its licensing and editions are covered on its own comparison page, and the details belong there rather than here. It matters when the resources you need to protect are web applications that can sit behind a proxy.
How the control plane and data plane split across these tools
The first decision is which system holds the control plane, because that system decides who may connect and which routes or services exist, and it is the component an attacker most wants. In NetBird, the management and signal services handle peer registration, policy and key exchange, while WireGuard peers carry the traffic directly or through a relay when a direct path fails. Headscale's control server plays the same role for a Tailscale-compatible network: it exchanges WireGuard public keys, assigns client addresses and sets the boundaries between users. In OpenZiti, the controller issues and verifies x509 identities, defines which identities reach which services through which edge routers, and exposes the REST API and admin console. Edge routers, tunnelers and SDKs form the data path. Treat the control plane as a trust boundary: restrict admin access, put MFA on operator accounts, and protect signing keys and the private keys used for identities.
Identity works differently in each tool. NetBird ships an embedded Dex identity provider and can add external SSO providers such as Google, Microsoft or Okta, so you choose whether users sign in through Dex or through your corporate IdP. Headscale supports basic OIDC login and updates user profiles from the provider, but OIDC groups cannot be used in ACLs, so group-based access must be modeled another way or accepted as a limit. OpenZiti does not rely on a user login for its trust model: every participant holds an x509 identity that the controller verifies on each connection. Confirm with each vendor how these identities are enrolled, renewed and revoked in your environment, because that process determines how quickly a lost device or departed user loses access.
The items to back up differ by tool. For NetBird, the self-hosting documentation states that operators handle backups themselves, so the management database, configuration, and the keys and certificates that identify the deployment must be in your backup plan and tested by restoring them to a clean host. For Headscale, the node keys and user state held by the control server determine whether existing clients reconnect, so back up its database and configuration together. For OpenZiti, back up the controller's data and the certificate authority material, since losing them means re-enrolling every identity. Ask each vendor which state is required for a restore and how long a restore takes in your own environment, because no supplied fact gives those figures.
How open-source zero trust network access tools differ on identity and policy
This table compares NetBird, Headscale and OpenZiti on the identity, policy and operating features that matter most when choosing a self-hosted zero trust network access tool. Where the supplied facts do not settle a capability, the cell says what to confirm, so treat unconfirmed cells as pilot questions rather than settled answers.
| Capability | NetBird | Headscale | OpenZiti |
|---|---|---|---|
| Architecture | WireGuard peer-to-peer overlay with a centralized access control system, relay fallback and an admin web UI | Open-source implementation of the Tailscale control server, managing a single tailnet with WireGuard clients | Controller as management plane and edge router mesh as data plane, with public and private routers |
| Clients | Linux, macOS, Windows, Android, iOS, FreeBSD, pfSense, OPNsense, MikroTik, OpenWRT, Synology, TrueNAS, Proxmox and Raspberry Pi, among others | Uses Tailscale clients; the GUI clients for Windows, macOS and iOS are not open source | Tunnelers for Linux, Windows, macOS, iOS and Android, plus SDKs for Go, C, Python, Node.js, Java, Swift and C# |
| Identity provider integration | SSO and MFA on paid tiers with an enterprise identity provider; self-hosted Dex can add Google, Microsoft or Okta | Basic OIDC login that updates user profiles; OIDC groups cannot be used in ACLs | Cryptographic identity issued by the controller as x509 identities; confirm external IdP options with the vendor |
| Access policy model | Groups and rules for access control with device posture checks | ACLs, grants, some autogroups, tags and pre-authenticated keys; autogroups only partly supported | Policy defines which identities reach which services through which edge routers |
| SSH | SSH with central access policies | Tailscale SSH | Not listed as a native feature in the supplied facts; confirm in a pilot |
| Posture checks | Device posture checks listed; on the Business tier per the pricing page | Not in the supplied facts; confirm with the project before relying on it | Not in the supplied facts; confirm with NetFoundry or the project |
| Audit logging | Activity and traffic event logging; audit event logging on Team, traffic logging and streaming on Business | Not detailed in the supplied facts; confirm log output and retention | Not detailed in the supplied facts; confirm log output with the controller documentation |
| SCIM provisioning | SCIM provisioning on the Team tier per the pricing page | Not in the supplied facts; confirm before planning joiner and leaver automation | Not in the supplied facts; confirm in a pilot |
| Deployment model | Self-hosted combined container stack with Traefik and Let's Encrypt; operators handle backups, upgrades and scaling | Self-hosted control server, documented as not supported behind reverse proxies or in containers | Runs on your own infrastructure with three mixable models: network, host and application access |
| License | BSD-3-Clause for most of the repository; AGPLv3 for management, signal, relay and combined directories | BSD-3-Clause | Apache 2.0 |
| Latest supplied release | v0.81.2, published October 16, 2026 | v0.29.5, published October 13, 2026 | v2.0.6, published September 17, 2026 as the latest non-prerelease 2.0 release |
Licensing and editions: what is open source and what is paid
NetBird's license is split by directory. Most of the repository is BSD-3-Clause, while the management, signal, relay and combined directories are AGPLv3, with copyright held by NetBird GmbH and authors. The split matters if you modify those control plane components, because AGPLv3 requires you to offer modified source to users who interact with the software over a network. NetBird Cloud is a separate hosted service with paid tiers.
- Free tier: up to 5 users and 100 machines, according to the NetBird pricing page.
- Team tier: 6 euros per user per month, adding SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging.
- Business tier: 12 euros per user per month with 100 machines included, plus 10 per user and extra machines at 0.50 euros. It adds device approvals, MDM and EDR device controls, posture checks and traffic logging and streaming.
- Enterprise tier: custom pricing on request, so ask for a written quote.
- Billing basis: only active users and machines are billed, so ask NetBird to define "active" in the contract.
Confirm whether the Team and Business feature lists apply to NetBird Cloud only or to self-hosted deployments as well, because the pricing page describes the hosted tiers.
Headscale is an open-source control server, licensed under BSD-3-Clause, that replaces Tailscale's coordination service for a single tailnet. The Headscale README states that everything in Tailscale is open source except the GUI clients for Windows, macOS and iOS and the control server. Headscale is therefore an independent open implementation of the control server, not a fork of Tailscale's own. Your open-source coverage depends on which clients you deploy.
- Headscale control server (open source): BSD-3-Clause, maintained by the community.
- Tailscale control server (not open source): Tailscale's own control server is proprietary, and Headscale does not use it.
- Tailscale GUI clients for Windows, macOS and iOS (not open source): the README excludes them from the open-source set.
- Tailscale client code (open source): the tailscale/tailscale repository is BSD-3-Clause, so confirm which packages and clients your fleet uses.
- Support model: the project is community-maintained and shows sponsorship and donation links. No paid support tier appears in the supplied sources, so ask the maintainers or a commercial provider whether one exists.
Before you standardize, check the client licenses for each operating system in your fleet and the support options you need in writing, since the README places the proprietary boundary outside the server.
OpenZiti is licensed under Apache 2.0 and is created and sponsored by NetFoundry. The README states that the whole platform can run on your own infrastructure with no vendor dependencies. NetFoundry also sells a fully managed, globally distributed OpenZiti network with SLAs and enterprise support. That managed network is a separate paid service, not part of the open-source release, so the license you read does not cover its terms.
- OpenZiti platform (open source): Apache 2.0, covering the controller, edge routers, tunnelers and SDKs.
- NetFoundry managed network (paid, not open source): a hosted, globally distributed network with SLAs and enterprise support. Pricing is not in the supplied sources, so request a written quote.
- Self-operated network (open source, your cost): you carry hosting, upgrades, identity operations and incident response.
- zrok (open source): an Apache-2.0 sharing tool built on OpenZiti, published by NetFoundry as a separate project.
- Release status: v2.0.6 is the latest non-prerelease 2.0 release, with v2.0.7 and v2.0.8 published as prereleases. Choose the release line you will standardize on and confirm its support window.
Ask NetFoundry which SLA and support terms apply to the managed network, and whether any of them extend to a self-operated deployment.
Pomerium is covered here for web-only access. It is an identity and context-aware reverse proxy licensed under Apache-2.0, offered in Core, Zero and Enterprise editions. It protects web applications in front of your services, so it does not give the same network-level reach as an overlay network. If your need is limited to web apps, its scope may be enough, but confirm the feature boundaries before you assume it.
- License (open source): Apache-2.0 for the proxy project.
- Core and Zero editions: confirm with Pomerium which features each includes and which, if any, require a paid agreement.
- Enterprise edition (paid): its features and support terms are not covered in the supplied sources, so request a written scope.
- Operating cost: you pay for the infrastructure, certificates, identity provider and upgrades that you run, whichever edition you choose.
- Non-web traffic: NetBird and OpenZiti also carry traffic beyond HTTP, so a web-only proxy may leave some services uncovered.
Before you choose, get Pomerium's current edition feature matrix and support terms in writing, and map each protected application to the edition that covers it.
What self-hosting each option asks of your team
Self-hosting NetBird starts with a small footprint on paper. The quickstart needs a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443 and UDP port 3478 open, and Docker with the Compose plugin. The deployment combines management, signal, relay and STUN under one configuration, plus a dashboard, a Traefik reverse proxy with Let's Encrypt by default, and an embedded Dex identity provider. NetBird's documentation is explicit that self-hosted operators handle backups, upgrades and scaling themselves, so the footprint is small but the operating duties are fully yours. Confirm with NetBird how the combined configuration is versioned and migrated between releases before you commit to an upgrade cadence.
Headscale asks a different question of your team. Its releases are frequent, with v0.29.3 on July 29, 2026, v0.29.4 on September 23, 2026 and v0.29.5 on October 13, 2026, so someone must own tracking and testing each release against your Tailscale clients. The README also says the project does not support or encourage running Headscale behind reverse proxies or in containers. That rules out the container and proxy patterns many platform teams use by default, so check that your certificate handling and ingress design can work with a bare control server. Its stated scope is a single tailnet aimed at personal use or a small open-source organization, which matters if you expect many tenants or large groups.
OpenZiti asks the most of your team, because it is a mesh you must design and secure. The controller is the management plane: it issues and verifies x509 identities for every participant, defines which identities reach which services through which edge routers, and exposes a REST API and web admin console. Edge routers form the data plane, with public routers as internet entry points and private routers making only outbound connections. Your team owns controller key material, router enrollment, identity lifecycle and tunneler or SDK rollout across hosts and applications. Ask your provider to specify the controller and router high availability design, the certificate and identity backup procedure, and who performs upgrades across the mesh. Cost falls into four recurring and one-time buckets. Staff time is the largest: upgrades, certificate renewal, backups, restore testing and identity provider configuration (OIDC or SAML connections, group mapping and MFA enforcement). The one-time cost is the pilot, which proves enrollment, policy design and failover before you expand. Effort rises with the number of sites, tunnelers, services and identity sources, and with the need for high availability and audit evidence. In a quote, ask for the written scope to name each component to be deployed, who runs upgrades after handover, which backups and restore tests are included, and what support window applies.
How to choose and pilot a zero trust network access tool
This sequence moves a team from a clear statement of the access problem to a tested pilot with backup and upgrade evidence, so the final choice rests on records rather than vendor pages.
Define the access problem first
Write down what must be reached privately: internal hosts reached over a network, web applications behind a login, services that must stay dark with no open ports, and any application code you can change to embed identity. Each group points to a different tool class. Pomerium suits web-only access, while NetBird, Headscale and OpenZiti cover network-level or application-level reach in different ways. Record the list of hosts, applications and services, the owner of each, and whether any of them must accept inbound connections today. The architecture owner signs off on the list before any tool is evaluated, and the output is a one-page access inventory.
Confirm the identity provider and policy model
Identify the identity provider your staff already use and the group structure that policies must reference. Check whether the candidate can take SSO and MFA from that provider, whether it reads groups for access rules, and whether it provisions users through SCIM. Headscale supports basic OIDC login and profile updates, but OIDC groups cannot be used in its ACLs, so a group-based policy model may rule it out for you. NetBird lists SSO, MFA and groups-based rules, with SCIM on its paid Team tier. Ask the identity owner to confirm the claims and group names in writing, and record the result as a pass or fail per candidate.
Check client platforms against device inventory
List every operating system and device class your users and servers run, including phones, NAS units, routers, hypervisors and single-board computers. Compare that list with each candidate's published client support. NetBird documents clients for Linux, macOS, Windows, Android, iOS, FreeBSD, several router and NAS platforms, Proxmox and Raspberry Pi, among others. Headscale relies on Tailscale's clients, and Tailscale's GUI clients for Windows, macOS and iOS are closed source. OpenZiti offers tunnelers for Linux, Windows, macOS, iOS and Android, plus SDKs for application embedding. Confirm any platform that matters to you with the vendor, and record the gaps as a signed-off device matrix.
Test two options against the same three use cases
Select two candidates whose architectures match the inventory from step one. Build the same three test cases on both: a private host reached from a managed laptop, a web application reached through identity, and a dark service that accepts no inbound connections. For OpenZiti, the dark service case uses a tunneler or SDK beside the service with outbound connections to an edge router. For NetBird or Headscale, use a subnet route or exit node to reach the private host. Measure whether access is granted and revoked as the policy says, and whether revocation ends active sessions. The test lead and the security owner both sign the result sheet, which should show pass or fail per case and the steps needed to reproduce it.
Verify license and paid features for required functions
For each feature the test relies on, check the license and the edition that includes it. NetBird's repository uses BSD-3-Clause for most code and AGPLv3 for the management, signal and relay directories, and its pricing page places SSO, MFA, SCIM and audit logging in the Team tier, while device posture checks and traffic logging sit in Business. Headscale is BSD-3-Clause, and Tailscale's client code is BSD-3-Clause, but the GUI clients for Windows, macOS and iOS are not open source. OpenZiti is Apache 2.0, with managed operation sold by NetFoundry under SLAs. Ask the vendor to confirm in writing which features your scenario needs are free, paid or unavailable, and keep that answer with the license review.
Run a pilot with backup and upgrade tests
Deploy the chosen option in a pilot environment that matches your production network, and document the self-hosted operating model. NetBird's quickstart needs a Linux virtual machine 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, and NetBird states that self-hosted operators handle backups, upgrades and scaling. Headscale's documentation says it does not support or encourage running behind reverse proxies or in containers, which affects where it can sit. Restore the configuration and database from a backup into a second host, then perform one upgrade and one rollback. Record the restore time, any manual steps, and the on-call owner, and have operations and security sign off before production.
Decide and record the production baseline
Combine the access inventory, identity and device results, use-case outcomes, license review and pilot evidence into one decision record. State which option was chosen, which features depend on a paid tier or a managed service, and what must be confirmed before go-live, such as vendor support terms or a quote for managed operation. Name the owners for patching, certificate renewal, identity changes and key rotation. The chief information security officer or equivalent approver signs the record, and the file is stored with the change request so the reasoning can be audited later.
What buyers ask about open-source zero trust network access cost, effort and help
Are the open-source versions of NetBird, Headscale and OpenZiti enough for production?
Each project is usable without a paid license, but the free version is not the same as a fully supported service. NetBird's self-hosted repository is BSD-3-Clause for most directories and AGPLv3 for management, signal, relay and combined directories, and NetBird's documentation says self-hosted operators handle backups, upgrades and scaling themselves. Headscale is BSD-3-Clause, but its README describes a narrow scope for personal use or a small open-source organization and says it does not support or encourage running behind reverse proxies or in containers. OpenZiti is Apache 2.0 and says the platform can run on your own infrastructure. Confirm which features you need, such as device posture, SSO and MFA, and check them against each vendor's current edition and license terms before you commit.
What drives the cost of self-hosting a zero trust network?
Most of the cost is people time and infrastructure, not license fees for the open-source cores. Infrastructure depends on the number of sites, the number of machines and whether you run relays or edge routers in several zones. NetBird's self-hosting quickstart lists a minimum of a Linux VM with at least 1 CPU and 2 GB of memory, but production sizing depends on your traffic and availability needs. Recurring costs include upgrades, certificate renewal, monitoring and on-call coverage. If you choose a managed option, NetBird's pricing page lists per-user and per-machine fees for its cloud tiers, and billing counts only active users and machines. Ask any provider for a written list of what is one-time and what recurs, and what changes the price when your user or device count grows.
Can a small team run a self-hosted zero trust network on its own?
A small team can run NetBird or Headscale on its own if it has someone comfortable with Linux, Docker and DNS, and if the scope stays small. NetBird's self-hosted stack bundles management, signal, relay, STUN, a dashboard, Traefik with Let's Encrypt and an embedded Dex identity provider, which reduces the number of separate parts but still needs ongoing care. Headscale's documentation positions it for personal use or small organizations, so its operating burden falls on the same few people. OpenZiti has more moving parts, including a controller, edge routers and tunnelers or SDKs inside applications, so it usually needs more engineering time. Ask whether the people on call can respond to an outage at night, and whether a second person can perform every task.
What determines how long a zero trust pilot takes?
The length of a pilot depends on the scope you agree, not on a standard duration. The main drivers are the number of applications and networks to reach, how many device types you must support, how much of your identity provider integration is new, and whether posture checks, logging and access policies must match existing controls. Teams that already run an identity provider with SSO and MFA usually move faster than teams that must build those pieces first. Networks with strict change control or restricted outbound rules add review cycles. Because no timeline figure applies to every environment, ask for a written plan with milestones, named dependencies and the acceptance tests that close the pilot.
What does a zero trust rollout need from our team before it starts?
Before the work begins, the team should be ready to provide several inputs. You need administrative access to your identity provider so the ZTNA platform can register clients and map groups, plus a decision on who owns that integration. DNS control for a public domain is required for NetBird's self-hosted quickstart, which expects a public domain and TCP ports 80 and 443 plus UDP port 3478 open. Certificates are needed for the web admin console and any public endpoints, and Let's Encrypt is the default in the NetBird quickstart. Confirm firewall change windows, device management tooling and who approves network rule changes. Writing these down early prevents the most common delays.
Is it practical to migrate from Headscale to NetBird later?
Migration is practical when the access policies are simple and the clients are standard, but it is not a click-through change. Headscale uses Tailscale-compatible clients and control-server concepts, while NetBird uses its own management service, groups, rules and setup keys. Plan to rebuild group and access policies in the new system, reissue device enrollment, and test every route, exit node and DNS setting. Headscale's OIDC support has limits: OIDC groups cannot be used in its ACLs, so group-based policies must be rebuilt rather than copied. Before you choose, document your current policies and the device types you must keep working, and ask the new vendor to confirm how it handles them.
When should a team bring in an implementation partner for zero trust?
Bring in a partner when the internal team cannot cover design, testing and ongoing operation alongside its normal work. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any partner for its named engineers, how it handles your identity provider and secrets, and how it documents the handover to your team.
How DeployOpen scopes and delivers a zero trust network access selection and implementation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For zero trust network access, that means working from your identity provider, access policies and network layout to a written scope before any platform is deployed.
How we scope
- Map which applications, hosts, databases or APIs need private access and which users and devices must reach them.
- Confirm the identity provider, group model and device posture requirements that the access policies must enforce.
- Agree in writing whether the target is NetBird, Headscale, OpenZiti, Pomerium or a combination, and why it fits your team.
- Ask for the licensing and edition review, including which features need a paid tier, before the scope is signed.
How we build
- Deploy the chosen platform in your infrastructure, including controller, relay or edge router components and their network placement.
- Integrate the identity provider and test group-based access rules against real user and device accounts.
- Run security testing on the access paths, including revocation behavior and whether services remain free of inbound ports.
- Document configuration, network diagrams and access policy decisions so your own staff can review and change them.
How we hand over
- Deliver the runbook covering backups, upgrades, certificate renewal and client enrollment for your environment.
- Walk your platform, network and security teams through policy changes, onboarding and offboarding procedures.
- Provide compliance-ready evidence of configuration and access controls, while independent auditors issue any formal assessment.
- Confirm the handover checklist with your team in writing, so ownership of each component is clear.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial project.
- Retainers can cover platform version upgrades, such as tracking releases for the components in your deployment.
- Ask any quote to state what recurs (support hours, testing cycles, upgrade work) and what is one-time setup.
