Why self-hosted zero trust networking changes for EU data sovereignty
An EU controller replacing a VPN with zero trust network access (ZTNA) has to answer one question before choosing a product: who can reach the systems that decide who gets in, and the traffic that passes through them. The decision is about where each component runs and who can compel access to it, not only about which application protocols are supported. In a ZTNA deployment, the control plane issues identities and policies, coordination or signal servers help peers find each other, relays carry traffic when a direct path fails, and logs record who connected to what. Each of these can hold personal data, and under the GDPR a remote session viewed from a third country, or data stored in a cloud outside the EEA, can count as a transfer under EDPB Guidelines 05/2021.
On the platform side, the short answer is to self-host the control plane under EU control. For a mesh that serves users and devices, self-hosted NetBird is the natural candidate: its management, signal and relay services run from one combined configuration, and its documentation makes the operator responsible for backups, upgrades and scaling. For identity-based access to individual services, self-hosted OpenZiti keeps the controller and edge routers in your environment, with no vendor dependency according to its README. Pomerium fits web-only cases such as contractor portals. Confirm for each option where the admin UI, identity provider (the embedded Dex in NetBird, or an external provider you choose), logs and any relay traffic are hosted, and whether the vendor or its support staff can reach them remotely.
Which GDPR and transfer rules shape the ZTNA design
This table maps each GDPR, transfer and sector rule to the parts of a ZTNA deployment it touches: control plane hosting, relay placement, support access and log storage. Read each row as a design question to settle before choosing a platform. The main takeaway is that a transfer can occur through remote support access or log replication even when the data never sits in a foreign data center.
| Rule | What it means for the ZTNA design | What to confirm or evidence |
|---|---|---|
| GDPR Article 44 and Chapter V | Every transfer of personal data to a third country, including onward transfers, needs a Chapter V basis. Control plane identity records, device attributes and access logs that contain personal data count if they leave the EEA. | Map which ZTNA components hold personal data and where each is hosted, including backups and vendor-operated copies. |
| EDPB Guidelines 05/2021 | Remote access from a third country, even only displaying data on a screen, counts as a transfer. Vendor engineers in another country troubleshooting the control plane may create one. | Document who can reach the management plane, from which countries, and under which access procedure. |
| Support and admin access | A self-hosted control plane still creates transfers if a non-EEA support team can view configuration, identities or logs during an incident. | Ask partners and vendors to state their support locations, access method and whether data is viewed in the clear. |
| Relay and STUN placement | Relays carry traffic metadata and, depending on the design, encrypted payloads. Placing them outside the EEA can move personal data data-flow metadata out of the Union. | Confirm relay regions, who operates them, what fields they log and whether relays can be restricted to EEA hosts. |
| Log storage and retention | Access, activity and traffic logs with user identifiers are personal data. Shipping them to a SIEM or vendor cloud outside the EEA is a transfer in its own right. | Set retention periods per log type, keep logs in EEA storage and document where SIEM or SaaS log copies go. |
| CLOUD Act reach under 18 U.S.C. 2713 | US-headquartered providers must preserve or disclose data in their possession, custody or control, wherever it is stored. An EU-hosted instance run by a US provider can still be reachable. | Ask whether the provider or its parent receives US legal process and what contractual and technical limits apply. |
| GDPR Article 48 | A third-country court or agency order to disclose personal data is enforceable in the EU only under an international agreement such as a mutual legal assistance treaty. Use this to frame the risk of foreign orders against any vendor-held data. | Ask counsel to assess whether any vendor-held control plane data could be subject to foreign orders, and how notification is handled. |
| EU Data Act Article 32 | Providers of data processing services must take measures against third-country governmental access to non-personal data held in the Union. Relevant when a ZTNA service is contracted as a data processing service. | Request the provider's written measures and check the Article 25 switching rights before signing. |
| Fines under GDPR Article 83(5)(c) | Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover. These are the only penalty figures supplied for this topic. | Treat this as the upper bound stated in the regulation, and confirm exposure with legal counsel. |
| HIPAA Security Rule (only if healthcare applies) | For covered entities and business associates, 45 CFR 164.312 requires unique user identification, audit controls, person authentication and transmission security. Apply where ePHI passes through the ZTNA path. | Map audit logs and transmission encryption to the Security Rule items and check the business associate agreement terms. |
| FTC Safeguards Rule (only if financial institution applies) | For covered financial institutions, 16 CFR 314.4 requires MFA for remote users, encryption in transit and at rest, and monitoring of authorized user activity. Relevant to the ZTNA login and log design. | Confirm the institution's status under the rule and map MFA enforcement and activity logs to the ZTNA configuration. |
NetBird, OpenZiti or Pomerium: which fits an EU self-hosted design
NetBird is an overlay option that combines a WireGuard peer-to-peer network with a central access control system. For a self-hosted EU design, the server side is one combined configuration that runs management, signal, relay and STUN, plus a dashboard container and a Traefik reverse proxy that obtains Let's Encrypt certificates by default. An embedded Dex identity provider can be extended with external SSO providers such as Google, Microsoft or Okta. The quickstart expects 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.
- Single control plane: Management, signal, relay and STUN are configured together, so placement decisions are made for the whole set rather than per service.
- Identity: The embedded Dex can be connected to your own identity provider, which keeps user authentication tied to your directory.
- Licensing: The repository is BSD-3-Clause except the management, signal, relay and combined directories, which are AGPLv3. Confirm what AGPLv3 obligations apply to your modifications and hosting.
- Operations: NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves.
- Edition limits: SSO, SCIM, posture checks and traffic logging appear in the paid plans. Confirm which of these features the self-hosted edition includes.
Before committing, confirm the data each component holds, where the relay will run, and whether your public domain and certificate process meet your EU hosting rules.
OpenZiti is a zero trust networking platform in which connections are authenticated with cryptographic identity, authorized by policy and encrypted end to end. The controller is the management plane: it issues and verifies x509 identities, defines which identities reach which services through which edge routers, and provides a REST API and web admin console. Edge routers form the data plane. Private routers make only outbound connections, so inside a private network no inbound firewall rules are needed. OpenZiti is licensed under Apache 2.0 and was created and sponsored by NetFoundry.
- Controller: It is the component that holds identity and policy, so it is the first item to place inside your EU infrastructure.
- Dark services: A service can have no open ports, with its tunneler or SDK connecting outbound to an edge router, and revoking access ends active connections immediately.
- Deployment models: Network access through an edge router, host access with a tunneler beside the service, and application access with an SDK can be mixed in one design.
- Encryption: With SDKs, traffic is encrypted application to application. With tunnelers, encryption covers tunneler to tunneler, so confirm the path for each app.
- NetFoundry managed option: NetFoundry offers a managed, globally distributed network with SLAs and enterprise support. Treat it as a separate contract to assess, including where its infrastructure and logs sit.
The current non-prerelease 2.0 release is v2.0.6, so confirm the version you deploy against the releases page before planning upgrades.
Pomerium is generally used as an identity-aware proxy placed in front of web applications, applying policy per route tied to an identity provider. It fits a different access pattern from an overlay network: browser-based access to selected internal apps rather than full network reachability for non-web protocols. The supplied facts for this topic do not cover Pomerium's licensing, components, data flows or self-hosting requirements, so every point below is a question to answer from its own documentation.
- Scope: Confirm which protocols it proxies beyond HTTP, and whether SSH, RDP or database access is in scope.
- Data path: Confirm whether session data passes through the proxy in clear form inside your network and where logs are written.
- Licensing: Confirm the license of the version you intend to run and any features that sit in a separate enterprise edition.
- Support: Confirm which support and upgrade options exist for a self-hosted deployment.
- Identity: Confirm supported identity providers and whether they can be operated from EU infrastructure.
If web applications are the main target, Pomerium may be the simpler starting point. Validate the points above before comparing it directly with the overlay options.
Where control plane, relays and logs should run in the EU
A ZTNA deployment is several components, and each holds a different slice of your data. Placing the control plane, relays, identity brokering, logs and backups inside EU infrastructure only works if you know what each one stores and who can reach it. The cards below walk through each location and the question to settle with your vendor or implementation partner.
Control plane hosting
The control plane holds user and group records, device identities, access policies and the map of which services exist. For a self-hosted NetBird deployment, the management, signal, relay and STUN components run from one combined configuration on a Linux host you choose, so the EU question is which cloud account or data center that host sits in. Confirm the hosting location of every control plane component, including any managed add-on, before you sign.
Relay and edge router placement
Relays carry traffic when a direct peer-to-peer path fails, so they may see encrypted payloads and connection metadata. In OpenZiti, public edge routers are reachable from the internet, while private routers inside your networks only make outbound connections and need no inbound firewall rules. Place public entry points in EU infrastructure, keep private routers in the networks they protect, and ask whether any relay fallback can route through a node outside the EU.
Identity provider and SSO brokering
Your identity provider sees every login, MFA event and group membership, and it is the source of truth for access decisions. A self-hosted NetBird instance uses an embedded Dex identity provider that can federate external SSO such as Microsoft or Okta, so the brokering layer and the upstream directory may sit in different jurisdictions. Confirm where the embedded identity service stores user records and whether upstream SSO sessions cross the Atlantic.
Log storage and retention
Activity and traffic logs record who connected to what, when, and from which device, which is personal data under GDPR. NetBird lists activity and traffic event logging as features, and its Business plan adds traffic logging and streaming, so an export pipeline may send copies to a SIEM or a SaaS tool. Ask where logs are stored, how long they are kept by default, and whether any streaming target is hosted outside the EU.
Backup and admin access locations
Backups copy the full control plane state, including keys, policies and user records, and administrator sessions reveal who can change access rules. Under GDPR, displaying personal data on a screen from a third country for support counts as a transfer, so remote administration from outside the EEA matters as much as storage. Confirm where backups are stored, which staff and support personnel can reach the admin console from which countries, and how those accesses are logged.
How an EU sovereign ZTNA rollout runs in phases
This sequence moves a ZTNA deployment from a data map to a self-hosted control plane under EU control, with each phase closing on a written record. It ends with a handover that leaves the operator able to run backups and upgrades without the vendor.
Map data flows and possible transfers
The team lists every component of the planned ZTNA design (controller or management plane, coordination and signal servers, relays, routers, identity provider, logs) and records what personal data each one holds, where it is processed and who can administer it. Legal and privacy staff then mark each flow that could be a transfer under GDPR Chapter V, including remote support sessions from outside the EEA, which the EDPB guidelines treat as transfers. The output is a data map signed by the data protection lead. The step is complete when every component has a row and every open question has an owner.
Decide hosting and jurisdiction in writing
Using the data map, the organization chooses where each component runs, which cloud accounts or data centers host it, and which operators and sub-processors have administrative or log access. The decision includes an assessment of whether any provider is subject to third-country law with extraterritorial reach, such as the US CLOUD Act, and what that means for compelled disclosure. The output is a signed hosting record that names each location, operator and exposure, along with the reasons for accepting or rejecting each option. Confirm current status of the EU-US Data Privacy Framework with counsel before relying on it.
Pilot the control plane with one app group
The team deploys the chosen overlay or proxy control plane inside the approved environment and connects one application group, such as an internal wiki or a staging database, with a small set of named users. Administrators confirm that the self-hosted components handle backups, upgrades and scaling under the organization's own runbooks, since the NetBird documentation places those tasks on self-hosted operators. The output is a working pilot with documented configuration, access policies and a test log showing that the control plane and its logs stay in the approved locations.
Test relay and router placement
Engineers place relays, edge routers or exit nodes in the regions the hosting record allows, then test connections from inside and outside the network, including fallback paths when direct peer connections fail. They check that relay traffic is encrypted end to end where the product supports it and that no relay sees more metadata than the data map permits. The output is a placement test report with measured paths, failure cases and a corrected topology diagram. Confirm with the vendor what traffic a relay can observe in the chosen edition.
Integrate identity and device posture
The team connects the EU-hosted identity provider or the embedded identity component to the workforce directory, configures MFA and group-based access policies, and adds device posture checks where the edition supports them. Logging of authentication and access events is routed to the EU-hosted log store and tested against the access records the organization must keep. The output is a test matrix showing that each group reaches only its intended applications, that a revoked user loses active sessions and that every login and access event lands in the approved log location.
Cut over from the VPN with both running
Applications move from the legacy VPN to the new path in batches, while the VPN stays available for the same users until each batch has passed checks. Support staff run a rehearsal of the rollback path for each batch, reverting one application to the VPN and confirming that users regain access within the time the business accepts. The output is a cutover log for each batch and a tested rollback procedure. Retire VPN routes only after the final batch has run for a period the change board has agreed in writing.
Hand over backups, upgrades and evidence
The implementation partner transfers operating duties to the internal team or to a retained support arrangement, covering backup schedules, restore tests, upgrade procedures for each component, key and certificate rotation, and the sources of security advisories. The team restores the control plane from a backup into a clean environment to prove the procedure works. The output is a handover package with runbooks, the hosting record, the data map, restore test results and a named owner for each component. Ask any partner to define in the quote which of these items are included and which recur.
Evidence a regulator or auditor will ask for from the ZTNA layer
This table lists the evidence files an assessor is likely to request for a self-hosted ZTNA deployment, which component produces each one, and what the reader should confirm before the request arrives. Use it to plan evidence collection during the build rather than after go-live. DeployOpen prepares this evidence, but auditors, certification bodies and data protection authorities issue the conclusions.
| Evidence item | Producing component | What to prepare and confirm |
|---|---|---|
| Data processing records and transfer assessments | Controller's records of processing and the vendor or partner contracts (not the ZTNA software) | List every ZTNA component that holds personal data, its location and any third-country access. Record the transfer assessment for any remote access from outside the EEA, per EDPB Guidelines 05/2021. |
| Network diagram of relay and controller placement | OpenZiti controller and edge routers, or NetBird management, signal and relay services | Show where each control plane service and relay runs, which are public and which are private, and the outbound-only paths. Confirm the placement matches the data residency commitments in your records. |
| Access policy export from groups and rules | OpenZiti service and policy definitions via the REST API, or NetBird groups, rules and posture checks via the public API | Export policies on a fixed schedule and store them with change records. Confirm that each exported group maps to a named owner and an identity provider source. |
| Audit and activity logs from NetBird or OpenZiti | NetBird activity and traffic event logs (traffic logging depends on edition), OpenZiti controller and router logs | Confirm which events are retained, for how long, and where they are stored. Check whether traffic logging is included in your NetBird edition before relying on it. |
| TLS and transmission security configuration | Traefik reverse proxy with Let's Encrypt in NetBird, OpenZiti mTLS and libsodium data path | Document cipher and certificate settings, certificate renewal logs and the encryption boundary (tunneler to tunneler or application to application). Test and record these settings after each upgrade. |
| Key and certificate handling | OpenZiti x509 identity issuance and enrollment records, NetBird setup keys and TLS certificates | Record who issued identities, how enrollment keys are generated and revoked, and where private keys are stored. Confirm whether a secrets manager such as OpenBao will hold them. |
| Backup, restore and deletion records | Operator-run backups of the controller database and NetBird configuration, plus log retention settings | NetBird's documentation says self-hosted operators handle backups themselves, so keep restore test results and deletion logs. Confirm how deletion propagates to backups and log archives. |
What buyers ask before self-hosting ZTNA for EU data sovereignty
Does a self-hosted NetBird or OpenZiti deployment avoid all third-country transfers?
No. Self-hosting keeps the control plane and logs in infrastructure you choose, but it does not by itself remove every transfer. EDPB Guidelines 05/2021 (version 2.0) treat remote access from a third country, even only displaying data on a screen for support, as a transfer, so a vendor engineer troubleshooting from outside the EEA can trigger one. Software update channels, license checks and any telemetry also need review. Map each flow, decide which vendor access is allowed, and document the controls. The EDPB guidelines are the natural starting read for this analysis.
What is the NetBird self-hosting footprint?
The NetBird self-hosting quickstart asks for a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443 open, UDP port 3478 open, and Docker with the Compose plugin. A single combined configuration runs management, signal, relay and STUN, alongside a dashboard container, a Traefik reverse proxy with Let's Encrypt by default, and an embedded Dex identity provider that can connect external SSO providers. That quickstart sizes a starting point, not a production estimate. Confirm sizing for your user and peer count, and plan where the relays sit relative to your jurisdictional boundary.
What drives the cost of self-hosting ZTNA, and what recurs?
Costs fall into four groups: infrastructure (VMs or hosts in the EU, backups, DNS and certificates), software (NetBird and OpenZiti are open source, so license fees are not the main line item for the core components), implementation (design, identity provider integration, posture checks, app-by-app migration) and operations (upgrades, monitoring, incident response, backups and scaling). Infrastructure and operations recur. Design and migration are mostly one-time, though new applications add work over time. Costs rise with the number of apps, the identity sources, the device posture requirements and the required uptime. In a quote, ask for each item separately, the assumptions behind it and what is excluded.
Can our own team run a self-hosted ZTNA control plane alone?
It depends on the skills you already have. Running NetBird or OpenZiti needs people who can operate Linux, containers, reverse proxies, certificates, DNS, identity federation and firewall rules, and who can handle upgrades without breaking client connectivity. The NetBird documentation states that self-hosted operators handle backups, upgrades and scaling themselves. Before deciding, check whether two people can cover on-call, patching and incident response, and whether the design needs an OpenZiti network with edge routers in several zones. Teams without that depth often split the work, keeping day-to-day operations in-house and contracting design, hardening and upgrades.
How long does a self-hosted ZTNA rollout take, and what does it need from our staff?
The duration depends on scope rather than on the software. The main inputs are the number of applications to migrate, the identity provider and group model, the device posture sources, the approval process for changes, and whether an existing VPN must run in parallel during cutover. Your staff will need to supply identity administrators, network and firewall owners for the DNS and port decisions, a named application owner for each migrated service, and security approval for the data flow map. Ask any implementation partner for a written schedule that lists these dependencies and the review gates.
Which parts of the data flow should we map before choosing a design?
Map each component and the data it holds. For NetBird, that covers the management and signal services, the relays that forward traffic when peers cannot connect directly, the identity provider, and the activity and traffic event logs. For OpenZiti, it covers the controller, the edge routers and the identity records. Note where each relay runs, whether traffic passes through it in the clear to a third party, and which logs leave the EU. Relays that fall back to forwarding traffic deserve particular attention. Verify each point against the product documentation and your own network tests.
When is a managed NetFoundry or NetBird Cloud service still a fit?
A managed service fits when you want the vendor to run the control plane, when the team lacks operations depth, or when a fast start matters more than full control of infrastructure. The OpenZiti README notes that NetFoundry offers a fully managed, globally distributed network with SLAs and enterprise support. NetBird's pricing page lists Free, Team, Business and custom Enterprise plans, and NetBird Cloud needs no servers or domain. The trade-off is that you must confirm where the cloud control plane and relays run, what traffic they can see, and how the contract addresses access by the provider's staff and foreign authorities. Those answers decide whether a managed plan meets your transfer position.
What should we confirm about licensing before we self-host?
Confirm the license for each component you deploy. The NetBird repository is BSD-3-Clause, except the management, signal, relay and combined directories, which are licensed under AGPLv3. OpenZiti is licensed under Apache 2.0. Those licenses permit self-hosting, but AGPL obligations can apply if you modify and offer the AGPL components over a network. Also check whether any feature you need sits in a commercial tier, since NetBird's pricing page places SCIM, device approvals, MDM and EDR controls and traffic logging in its paid plans. Have legal counsel review the obligations against your planned changes.
Questions to put to an implementation partner on EU hosting
Start with location and access, because those answers decide whether the rest of the design holds. Ask the partner to list every component of the deployment (NetBird management, signal, relay and STUN services, the dashboard, the Traefik reverse proxy, the embedded Dex identity provider or OpenZiti controller and edge routers) and the region and provider where each one runs, including backups, snapshots and any disaster recovery copy. For each component, ask who holds administrator access, from which countries those staff log in, whether access goes through a jump host inside the EU, and how that access is recorded. Under the GDPR, remote access from a third country counts as a transfer even when the data is only displayed, so a support engineer working from outside the EEA is part of the design, not an afterthought.
Next, ask how software reaches the platform. Find out whether container images, the NetBird or OpenZiti release artifacts, operating system packages and TLS certificate issuance are pulled from servers outside the EU, and whether the partner mirrors them into an EU registry before installation. Ask who signs the artifacts and how the partner checks them before they reach production. For logs, require a written answer on where the management activity and traffic event logs are stored, how long they are kept, how they are exported to your SIEM, and who can read the export. Ask whether the partner can show a written retention setting in the configuration and where that setting lives, rather than a verbal assurance. Relay placement and the switching right need the same precision. Ask which relay and edge router locations carry traffic, whether any relay runs outside the EU, and what happens to sessions when a relay in one region fails. If a managed service is part of the scope, ask how the Data Act switching right applies: the Act gives customers a right to move to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and bans switching charges from 12 January 2027. Confirm in the contract how export of configuration, policies and logs would work. Finally, ask the partner to state in writing what the scope excludes, such as legal review of transfer impact assessments, audit reports, or the operation of the identity provider you already run.
How DeployOpen delivers EU-controlled zero trust access
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source zero trust platforms inside the client's own infrastructure, so the control plane, coordination servers and logs stay where the client decides. Engagements start with a written scope that maps each data flow, component and jurisdiction question before any platform is installed.
How we scope
- We map which components hold personal data, including the control plane, coordination servers, relays and logs.
- We record hosting locations, administrator access paths and any third-country support or remote access exposure in writing.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.
How we build
- We deploy the self-hosted control plane and relays in the client's EU cloud accounts, data centers or private networks.
- We configure identity provider integration, device posture signals, access groups and per-application policies for the agreed scope.
- We test access paths, verify that no unintended third-country endpoints are reachable, and confirm logs stay inside the agreed environment.
How we hand over
- We document the architecture, data inventory, hosting map, key and certificate handling and the operating runbooks.
- We deliver backup, upgrade and recovery procedures so the client's own teams can run the platform after handover.
- We prepare configuration records and access evidence that the client's auditors and assessors can review; we do not issue audit reports or certifications.
How we support
- Retainers cover upgrades, security patching, configuration changes and continuous testing of the access layer.
- We review changes to hosting, sub-processors and vendor licensing that could affect the data sovereignty position.
- We run security testing of the deployed access layer on a schedule agreed in the retainer scope.
