Replacing a corporate VPN with open source zero trust access: why the starting point matters
A corporate VPN that places every user on the whole network gives an attacker the same reach as the employee whose credentials were phished. The practical way to shrink it is to move from network-wide access to identity-based, per-application access, where each user reaches only the services their role and device justify. For network-level reach to internal servers, databases and non-web protocols, an overlay such as NetBird, Headscale or OpenZiti fits best. For web applications and SSH, an identity-aware proxy such as Pomerium is usually the smaller change. Most organizations end up using both, and the split follows the app types on your list, not a preference for one product.
In regulated settings, two decisions carry more weight than the product choice: where the control plane runs and who owns the access logs. The control plane decides who may connect to what, so an auditor or regulator will ask whether it sits in your cloud account, your data center or a vendor's region. Logs of every authentication, policy decision and session are the evidence that access is controlled and monitored, so you need to know which component writes them, where they are stored and how long they are kept. NetBird self-hosting, OpenZiti and Pomerium Core can all run in infrastructure you control. Pomerium Zero is different: the control plane is hosted by Pomerium, while the Core cluster and application traffic stay in your environment. Confirm that split in writing before you design around it.
Before you pick a component, inventory the applications that currently sit behind the VPN and classify each one as web, SSH, RDP, database or UDP. Then decide what device posture signals you need, such as managed-device status or disk encryption, and confirm which of them each candidate supports in the edition you would actually license. NetBird lists posture checks in its Business plan and Pomerium reserves external device posture integrations for its Enterprise edition, so edition limits can change the design. Ask each vendor or partner to show these capabilities in a test tenant before you commit, and plan to run the VPN and the new access path side by side during cutover so no application loses access while it moves.
Which access controls regulators expect from remote access
This table maps the access control duties in the HIPAA Security Rule (45 CFR 164.312) and the FTC Safeguards Rule (16 CFR 314.4) to concrete design decisions for a self-hosted replacement of a corporate VPN. Read each row as a requirement, the design choice that answers it and the evidence an assessor will ask to see. The main takeaway is that identity, MFA, encryption and per-session logging must be enforced at the access point, not left to the VPN client.
| Requirement | Design decision | Evidence to keep |
|---|---|---|
| Unique user identification (HIPAA 164.312 access control) | Every user signs in with a named account from the identity provider. No shared VPN or gateway credentials are used for remote access. | IdP account list, group membership exports and a documented rule that shared accounts are not permitted for remote access. |
| Person or entity authentication (HIPAA 164.312) | Authenticate each session against the identity provider before the overlay or proxy grants any route. Confirm the chosen platform's SSO integration with your IdP. | IdP sign-in logs and the access policy showing which identity provider is trusted for each application. |
| Multi-factor authentication (FTC 314.4) | Enforce MFA in the identity provider and make it a condition of access at the ZTNA layer, so a session without a recent MFA event is refused. Confirm the MFA step-up options in your platform edition. | MFA policy export, enrollment reports and test results showing a login without MFA is denied. |
| Encryption in transit (FTC 314.4, HIPAA transmission security) | Use WireGuard-based overlays or mTLS-protected proxy connections. Confirm whether relays or routers terminate TLS, since that determines where plaintext exists. | Architecture diagram of encrypted hops, certificate configuration and relay placement records. |
| Audit controls and activity logging (HIPAA 164.312, FTC 314.4) | Send connection, policy decision and session events to your SIEM. Confirm which events each edition logs, since some traffic logging and audit features sit in higher tiers. | Log source inventory, retention settings, sample records showing user, app, time and outcome, and a review procedure. |
| App types: web, SSH, TCP/UDP and databases | Route browser apps through a proxy, shell access through SSH with central policies, and TCP/UDP or database ports through an overlay. Confirm protocol support per product before scoping. | Route inventory mapping each application to its protocol, owner, policy and the encryption method used. |
| Migration period with the legacy VPN | Run the VPN and ZTNA in parallel, move one application group at a time, and keep the VPN read-only for named exceptions. Set a retirement date in the change record. | Cutover plan, per-application sign-off, exception register and logs proving the VPN no longer serves migrated apps. |
Overlay or identity-aware proxy: which fits which access pattern
NetBird builds a peer-to-peer WireGuard overlay where each enrolled device can reach the network segments and hosts its policies allow. It suits teams that need broad network-level access from laptops and servers, such as engineers reaching staging networks, databases and SSH targets. The management, signal and relay components are licensed under AGPLv3, while the client code is BSD-3-Clause, so review the license terms with your counsel before modifying the server components.
- Identity and MFA: Single sign-on and MFA are listed in the README, and the pricing page places SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging on the Team tier.
- Posture checks: Device posture checks, device approvals, MDM and EDR controls, and traffic logging and streaming are listed for the Business tier, so confirm these capabilities before relying on them for a self-hosted deployment.
- Self-hosting: The quickstart runs management, signal, relay and STUN from one combined configuration behind Traefik, with an embedded Dex identity provider that can add external SSO providers.
- Operations: NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves.
Confirm with NetBird which features your self-hosted edition includes compared with the cloud tiers before you commit to a design.",
Headscale is a self-hosted coordination server for clients built on the Tailscale model, so teams already using Tailscale clients can keep the client experience while moving the control plane into their own infrastructure. It fits organizations that want a self-hosted control plane for mesh networking and that accept the client ecosystem it implies. Feature coverage, supported client platforms and licensing terms are not covered by the facts supplied for this page, so verify them directly before design work begins.
- Control plane ownership: The coordination server runs in your environment, which keeps the node registry and policy data under your control.
- Client compatibility: Confirm which Tailscale client versions and platforms work with the Headscale release you plan to run.
- Access policy: Check how access control lists map to your identity groups, and whether SSO and posture signals are available or need extra components.
- Relay and NAT traversal: Confirm how relays are placed and whether traffic can route through them when direct connections fail.
- Licensing: Review the project license yourself, because it is outside the facts supplied here.
Ask your implementation partner to document each of these points in a written test plan before selecting Headscale over NetBird or OpenZiti.",
OpenZiti is the option for services that must have no open inbound ports. Its controller issues x509 identities, defines which identities reach which services through which edge routers, and provides a REST API and admin console. It is licensed under Apache 2.0 and can run entirely on the operator's infrastructure. Its three deployment models make it suitable for network access, host access and application access, which can be mixed.
- Network access: An edge router in a trusted zone gives enrolled clients access to a range of services.
- Host access: A tunneler beside a service provides access to that host without changing the application.
- Application access: The SDKs for Go, C, Python, Node.js, Java, Swift and C# embed identity and encryption directly in the application with no listening ports.
- Dark services: Private routers only make outbound connections, and revoking access ends active connections immediately.
- Operations: The controller, edge routers and identity issuance are your responsibility to run, back up and upgrade.
Check which tunneler platforms and SDK versions your application stack needs before scoping the migration.",
Pomerium Core is an Apache 2.0 identity and context-aware reverse proxy that gives users access to internal web apps without a VPN client. It also handles SSH, TCP and UDP access through the Pomerium CLI and provides a Kubernetes ingress controller under Apache 2.0. It suits browser-based internal tools, contractor access and per-route policies tied to your identity provider.
- Clientless web access: Users reach internal web apps through the browser, with policies per route.
- Identity providers: OAuth 2.0 and OIDC are supported with providers such as Keycloak, Microsoft Entra ID, Okta and Google.
- Non-web protocols: SSH, TCP and UDP access run through the CLI or desktop app, so confirm the coverage your protocols need.
- Kubernetes: The ingress controller runs Pomerium as the front door for cluster services.
- Reserved features: Directory sync, Rego policies, RBAC for administrators, session management and SSH session recording and playback are reserved for the Enterprise edition.
If your audit scope requires recorded privileged sessions or Rego policies, price the Enterprise edition into your evaluation from the start.",
Which open source platform fits which VPN replacement
A VPN replacement starts with the access pattern, not the product. The four options below differ in what they connect (whole networks, individual services, browser apps or a coordination layer), so the first question on each card decides whether it belongs in your shortlist.
NetBird for whole-network reach
NetBird fits staff who need broad reach to laptops, servers and internal subnets, the closest match to what a VPN does today. Access is governed by SSO groups and rules, so the group model in your identity provider becomes the access policy. The component you run is the management, signal, relay and STUN stack, plus the dashboard and the Traefik proxy in a self-hosted deployment. Check the license split first: the management, signal and relay directories fall under AGPLv3, while the rest of the repository is BSD-3-Clause. Confirm which directories your deployment and any modifications touch.
OpenZiti for dark services
OpenZiti fits services that should have no open inbound ports at all. Edge routers and tunnelers dial out, so private networks need no inbound firewall rules, and revoking an identity ends active connections. The first question is whether you can install a tunneler beside the service or embed an SDK in the application. The components you run are the controller, the edge routers and the tunnelers or SDK integrations, which means more design work than a whole-network overlay. Confirm whether your operations team can maintain a controller and router mesh before committing.
Pomerium for browser and SSH access
Pomerium fits when contractors and staff need clientless access to named web apps or SSH targets, with no VPN client on the device. Each route gets its own policy tied to your identity provider, so the first question is which applications matter and whether they all speak HTTP or SSH. You run Pomerium Core, which is Apache-2.0 and self-managed, or pair it with a managed control plane. Confirm early which features your edition includes, since directory sync, Rego policies and SSH session recording are reserved for the Enterprise edition.
Headscale for standardized Tailscale teams
Headscale fits organizations that already run the Tailscale client and coordination model and want to keep it under their own control. The question to answer first is whether your clients and workflows are already standardized on that model, because switching clients is the expensive part of a migration. You run the Headscale coordination server and manage the access policy alongside it. Check the license terms and the feature set in the current release before you rely on it for regulated access, and confirm that the policy and logging features you need are available in the version you deploy.
Migrating from VPN to zero trust app by app
This sequence moves users and applications off a flat VPN in controlled waves, so each app has a tested access path, a rollback option and log evidence before the VPN route to it is removed. It starts from what the VPN actually carries and ends with documented proof that the old routes are gone.
Inventory users, devices, apps and flows
Start from the VPN concentrator logs, firewall rules and the directory: list every user group, device class, internal host, port and protocol that reaches the network through the VPN. Include service accounts, vendor tunnels and UDP-based traffic, since these often hide in the logs. The output is an access inventory that maps each flow to an owner, a business purpose and a proposed access method, either overlay network access or a per-application proxy route. Confirm the inventory with application owners before any design work continues, because undocumented flows are the most common cause of cutover failures.
Choose a pilot group and two low-risk apps
Select a small pilot group of users who can report problems quickly, such as an IT or security team, plus two internal web or SSH applications with low impact if access is briefly interrupted. Decide between an overlay (NetBird, Headscale or OpenZiti) for network-level access and Pomerium for browser and SSH access to specific routes, based on the flows in the inventory. The output is a signed pilot scope that names the users, apps, protocols and success criteria, including who can approve a rollback.
Configure identity provider, MFA and groups
Connect the chosen ZTNA component to the existing workforce identity provider, through SSO and MFA, and map directory groups to access roles. Keep one group per access level so that policy changes happen in the directory rather than in individual rules. Confirm that the identity provider enforces MFA for every user who reaches the pilot apps, and that groups do not inherit broad VPN rights. The output is a tested login path for pilot users and a documented group-to-policy mapping that the security team has reviewed.
Deploy control plane and relays on the chosen host
Deploy the control plane and any relays or edge routers on the self-hosted infrastructure chosen during design, with a public entry point and the network ports that the product documentation requires. For NetBird, that includes its combined management, signal, relay and STUN configuration behind a reverse proxy with certificates. For OpenZiti, place public edge routers where clients can reach them and private routers inside protected networks, which make outbound connections only. Ask the vendor or partner to confirm exact host sizing and port requirements for your edition. The output is a reachable control plane with backups configured and a documented restore test.
Onboard devices and set posture checks
Enroll pilot devices using the client software or tunnelers, then define device posture checks such as OS version, disk encryption, screen lock and managed status. Confirm which posture signals your chosen product can read natively and which need an integration with an MDM or EDR tool, since posture support differs by edition. Test a non-compliant device to verify it is denied access. The output is a list of enrolled devices with their posture state and a test record showing that the policy blocks a device that fails the check.
Move apps in waves with a rollback path
Migrate applications in waves, starting with the two pilot apps and then grouping the rest by risk and dependency. For each application, publish the ZTNA route or service alongside the existing VPN path, switch the pilot group to the new path, and keep the VPN route in place so that rollback is a configuration change, not a rebuild. Record the rollback steps and the owner for each wave. The output for each wave is a signed change record, a test script that the application owner has run, and confirmation that users can reach the application through the new path.
Run VPN and ZTNA in parallel and compare logs
Keep the VPN and the new access path running side by side for each wave, and compare access logs for the same users and applications. Look for flows that appear on the VPN but not on the ZTNA path, which signal a missed dependency, and for denied requests that show over-blocking. Confirm that the ZTNA logs capture user identity, device, application and session times, since these are the fields auditors and incident responders ask for. The output is a reconciliation report per wave that lists every unexplained flow and its resolution.
Retire VPN routes and document evidence
Once a wave has run cleanly through the parallel period and the reconciliation report has no open items, remove the corresponding VPN routes, firewall rules and user group memberships. Revoke any leftover VPN credentials and confirm that the old route no longer responds. Assemble the evidence pack: the access inventory, change records, posture test results, log comparison, and the removal records. The output is a documented decommission for each wave and a final evidence set that the compliance team can use for assessments. This pack supports readiness work, but it does not replace the independent assessment of your controls.
Integration points and deployment pattern for a VPN replacement
Which identity provider should sit behind a ZTNA control plane?
Use the identity provider your workforce already signs in to, and connect the ZTNA control plane to it over OpenID Connect or SAML. Keycloak, authentik and ZITADEL are open-source options that can serve as the directory-facing IdP, and an enterprise IdP such as Microsoft Entra ID or Okta can be federated into them. A self-hosted NetBird deployment includes an embedded Dex identity provider that can add external SSO providers, so confirm whether you want it as the primary login path or only as a bridge. Pomerium lists Keycloak, Okta, Microsoft Entra ID, Google and others among its supported identity providers. Settle group mapping first, because access policies in both NetBird and Pomerium depend on the groups and claims the IdP returns. Confirm MFA enforcement at the IdP, since the ZTNA layer usually inherits it.
How do device posture signals from MDM or EDR reach the access policy?
Posture checks need a source that reports device health, such as an MDM profile or an EDR agent, and a way for the ZTNA policy engine to read it. NetBird lists device posture checks as part of its feature set, but the posture controls such as device approvals, MDM and EDR device controls, and posture checks sit on its Business tier according to its pricing page. Pomerium reserves external data integrations such as FleetDM device posture for its Enterprise edition. Confirm which posture attributes your MDM or EDR can export, how often they refresh, and what the policy does when a signal is missing. Decide early whether an unmanaged device gets no access or a limited clientless path.
How should ZTNA access logs feed a SIEM such as Wazuh?
Send authentication, policy decision and session logs from the ZTNA control plane and proxy to a central pipeline, then forward them to your SIEM. Wazuh is an open source XDR and SIEM platform with a GPL-2.0 licensed core, so it can receive and correlate these events on your own infrastructure. NetBird lists activity and traffic event logging, and its Team tier adds audit event logging, while Business adds traffic logging and streaming. Pomerium Zero plans include access and audit logs, and session recording for SSH is an Enterprise feature. Define the fields you need, such as user, group, device, destination, decision and timestamp, and test that they arrive with the time synchronization your regulator expects.
Which ports and hosts does a self-hosted NetBird control plane need?
A self-hosted NetBird control plane needs a Linux virtual machine with at least 1 CPU and 2 GB of memory, a public domain, Docker with the Compose plugin, and specific ports open. According to the NetBird self-hosting quickstart, TCP ports 80 and 443 and UDP port 3478 must be reachable. That host runs management, signal, relay and STUN from one combined configuration, a dashboard container and a Traefik reverse proxy that uses Let's Encrypt by default. The quickstart states that backups, upgrades and scaling are the operator's job. Plan the host in a DMZ or a dedicated network segment, restrict administrative access, and confirm that your firewall team accepts the public exposure before the pilot starts.
Where should relays sit so traffic still flows when peers cannot connect directly?
Relays carry traffic when two endpoints cannot establish a direct path, so place them where both sides can reach them over outbound connections. In NetBird, the relay is part of the combined self-hosted stack, and the README notes relay fallback when peer-to-peer connectivity fails. In OpenZiti, private edge routers make only outbound connections, so no inbound firewall rules are needed inside the private network, and public routers serve as entry points. Place at least one relay or router in each network zone that has restrictive egress, and measure latency from the regions where users work. Ask the vendor or partner how relay traffic is encrypted and what metadata a relay can observe.
Should the legacy VPN stay in place as a fallback during cutover?
Keep the legacy VPN running during migration as a fallback for applications and users that have not moved yet, but restrict it to a shrinking list of routes. Running both paths lets you migrate application by application, roll back a single app without an outage, and keep emergency access while the new control plane matures. Set an explicit retirement date for each group of applications and track which users still rely on the VPN. Review whether the fallback path still gives broad network reach, because a VPN left wide open defeats the purpose of the migration. Document the criteria for removing it, and ask the implementation partner to test rollback before the first production cutover.
What does a VPN replacement engagement typically cost and who pays for what?
Cost falls into a few components: the software license or subscription, the infrastructure that runs the control plane and relays, the integration work with the identity provider, MDM or EDR and SIEM, and the per-application migration effort. Open-source core editions such as NetBird's self-hosted stack and Pomerium Core carry no license fee, but cloud tiers are priced per user and per machine. NetBird's published pricing lists Team at 6 euros and Business at 12 euros per user per month, with custom Enterprise pricing, and Pomerium Zero Business at $9 per user per month billed monthly. Infrastructure and staff time recur, while integration and migration are largely one-time. Ask for a quote built from a written scope that names the applications, identity sources and posture signals in use.
Evidence auditors ask for from a ZTNA deployment
This table lists the evidence an assessor typically asks for when a VPN is replaced with identity-based access, what each item shows, and which component produces it. Use it to plan log retention, exports and test records before the cutover, not after. DeployOpen prepares this evidence from your environment; auditors and certification bodies draw the conclusions.
| Evidence item | What it proves | Component that produces it |
|---|---|---|
| Access policy export | Which groups or identities can reach which apps, routes and SSH targets, and that the policy is version controlled | NetBird groups and rules via API or Terraform, Pomerium policies via management API or Terraform, OpenZiti service and policy definitions from the controller |
| Group membership from the identity provider | That each access grant traces to a named user or group in the source directory, with a dated snapshot | Keycloak, authentik, ZITADEL or your existing IdP, exported with the SSO group mappings used by the overlay or proxy |
| MFA enforcement records | That every session to an internal app or network used multi-factor authentication, and that exceptions are approved | Identity provider authentication logs, paired with the policy setting that requires MFA on each route |
| Session and activity logs | Who connected to what, when, from which device, and what traffic or requests were allowed or denied | NetBird activity and traffic event logging (Business tier for traffic logging), Pomerium access and audit logs, OpenZiti controller logs |
| Revocation test records | That disabling a user or device ends active sessions and blocks new ones within the agreed time | Dated test runs showing terminated connections in the overlay or proxy logs, plus the identity provider change record |
| Device posture configuration and results | That only managed or compliant devices receive access, and what checks were applied | NetBird posture checks and device approvals (Business tier), Pomerium external posture integrations (Enterprise edition) |
| Migration decision record | Why each application moved to ZTNA, which access paths were retired, and who approved the cutover | Change tickets and the migration register kept by your team, with the scope agreed in writing with DeployOpen |
What changes for staff, administrators and the security team
For staff, the most visible change is that the full-tunnel client stops being the way they reach internal systems. Instead of connecting to a network and then finding the app they need, a user opens a single application, a browser route, an SSH target or a service mapped to a group they belong to, and authenticates through the identity provider the organization already runs. Administrators change their daily work at the same time. Firewall rule sets and VPN address pools give way to identity groups, routes, services and policies, and the review question moves from "which subnet can this laptop reach" to "which group can use which service, from which managed device, under which conditions." Teams should confirm how their chosen product models groups, device posture and routes before they rewrite any rules, since NetBird, OpenZiti and Pomerium each express these differently.
For the security team, the gain is evidence. Each session produces an identity, a policy decision and a log entry tied to a specific service, which a flat VPN rarely offers. NetBird lists activity and traffic event logging among its features, and Pomerium's Zero plans include access and audit logs, but the retention, export and SIEM forwarding path must be confirmed for the edition in use. The main operational risk is dual running: while the VPN and the new overlay or proxy both exist, a user or device can reach the same system through two trust paths, and the weaker path sets the real security level. Plan a fixed date after which VPN routes to migrated applications are removed, and log which path each session uses during the overlap.
Retiring the VPN without stranding contractors or OT vendors depends on inventory before cutover. List every external account, its identity source, its devices and the exact applications it uses, then check whether a clientless path or a tunneler on a managed host is workable for each. Vendors who cannot install a client need a browser-based route or a host-side connector, and their access should be the last to move. Keep the VPN running for these groups until their replacement is tested with their own staff, and agree the removal date with the vendor in writing. Ask any implementation partner to produce this inventory, a route-by-route cutover plan and a rollback procedure for each application before work starts.
What does replacing a VPN with open source zero trust cost and take?
What drives the cost of replacing a VPN with open source zero trust access?
The cost follows the scope: how many applications and app types move, how many identity providers and posture sources connect, and what infrastructure you host yourself. The software itself is open source, so the main costs are infrastructure to run the control plane and relays, integration work per application, identity provider and posture connections, and the parallel running period while the VPN stays on. Each application that uses SSH, RDP, databases or UDP needs its own policy and testing, so a long list of mixed app types costs more than a short list of web apps. Ask any quote to itemize these components separately so you can see which ones shrink as the migration progresses.
What does the work need from our team before it starts?
Before the work starts, your team needs to provide a complete inventory of internal applications, the network ranges they use, the users and groups who reach them, and the devices that must be managed or checked. You also need administrators for your identity provider who can add clients, groups and claims, and a named owner for each application who can confirm behavior during testing. Plan change windows for DNS, firewall and identity provider changes, and agree on how the VPN will be retired. Missing inventory is the most common reason migrations take longer than planned, so treat it as a deliverable rather than a formality.
Can our internal team replace the VPN without outside help?
Internal teams can do this if they have people with networking, identity and application ownership skills and enough time to run a parallel migration. Both NetBird and Pomerium publish their source code and self-hosting documentation, so the software is accessible without a license purchase. The harder parts are usually the non-web applications, device posture integration and the cutover plan, where a mistake can lock users out. Many organizations split the work: internal staff own applications and users, while a partner handles architecture, hardening and the runbook. Compare the skills you have against the app inventory before deciding.
How long does a VPN replacement take with open source tools?
Duration depends on the number of applications, their types, the number of identity providers and posture sources involved, and how many change windows your organization allows. No supplied figure sets a general timeline, so the length is set by the written plan agreed before work begins. A fixed-scope engagement lists the applications in each wave, the acceptance tests and the dates for each stage. Ask for the plan to show how many applications move per wave, what testing each wave includes, and what happens if an application fails testing. Fast starts often come from a small pilot group with a few web apps, while the full cutover waits for the non-web apps.
What do the published NetBird and Pomerium per-user plans cover?
NetBird's cloud pricing page lists a Free plan for up to 5 users and 100 machines, a Team plan at 6 euros per user per month and a Business plan at 12 euros per user per month with 100 machines included plus extra machines at 0.50 euros each, with custom Enterprise pricing. Team adds SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging, while Business adds device approvals, MDM and EDR device controls, posture checks and traffic logging. Pomerium's pricing page lists Zero Business at $9 per user per month billed monthly or $7 billed annually, with Enterprise at custom pricing and a self-hosted control plane. These are managed subscription prices, so compare them with the infrastructure and staff time of a self-hosted design, and check the current pages before budgeting.
What recurring work follows go-live for a self-hosted ZTNA?
After go-live, the recurring work includes upgrades, backups, monitoring, access reviews, policy changes for new applications and support for users and devices. NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves. Expect regular release updates to the overlay or proxy, the identity provider and the client software, each of which needs testing before rollout. Recurring costs therefore include infrastructure, staff time and any support retainer you choose. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which can cover this work for the client's own infrastructure, with scope agreed in writing.
Which costs are one-time and which recur during a migration?
One-time costs include the application inventory, architecture and design, initial deployment, identity provider and posture integration, migration of each application, and the cutover itself. Recurring costs include infrastructure for the control plane and relays, subscription fees if you choose a managed plan, upgrades, backups, monitoring and access reviews. Parallel running sits between the two: the VPN and the new access path both cost money until the last application moves and the VPN is retired. Ask for quotes that separate these categories so you can see the monthly cost after cutover.
How DeployOpen scopes and runs a VPN replacement
DeployOpen plans, implements, hardens, integrates, backs up, documents and supports self-hosted zero trust access inside the client's own cloud accounts, data centers or air-gapped networks. In a VPN replacement, that means working through the control plane, the data plane, the identity provider integration, the device posture inputs and the application policies as one scope. Most engagements are fixed-scope: the written agreement names the platform components (for example, a self-hosted NetBird deployment or an OpenZiti controller with edge routers), the applications in the first migration wave, the identity provider and posture signals to connect, and the acceptance tests for each. Ongoing support, upgrades and continuous testing are offered as retainers, which matters because a self-hosted control plane needs its own backups, patching and capacity planning after go-live.
Security testing is part of the delivery, not an afterthought. Every new access path is a new way in, so DeployOpen can test the published routes of a Pomerium deployment, the public routers of an OpenZiti network or the NetBird management and relay endpoints before users depend on them, and test the applications behind them for authorization gaps. Before the written scope is signed, the client should confirm which systems will be tested, who owns the test accounts, and how findings feed into the migration plan. The client's own owners remain responsible for policy decisions, such as which groups can reach which route, and for the sign-off on each application moved off the VPN.
DeployOpen prepares systems, controls and evidence for compliance assessments, including access policy exports, authentication settings, session and audit logs and change records. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Before the scope is agreed, ask which control objectives the new access design must support, which evidence the assessor expects for each one, and how long logs will be retained in the client's environment. Those answers determine the logging and documentation deliverables, and they should be written into the agreement so that the evidence exists when the assessor asks for it.

