How to run a zero trust network access RFP with open source options
To run this RFP well, put every candidate on the same written list of questions and score the answers against your own requirements, not against vendor marketing. The candidates are self-hosted OpenZiti, NetBird, Headscale and Pomerium, plus managed ZTNA services. Your current VPN probably gives too much access, so the first question for every candidate is which users, devices and applications the replacement will reach, and how that scope is enforced. Send the same neutral questions to two groups: the product vendors or maintainers, and the implementation partners who would deploy and run the chosen platform. Vendors can tell you what the software does. Partners can tell you what it takes to run it in your environment, and which parts will be your responsibility.
Ask both groups for the same answers in writing: where the controller or control plane runs, where relays or public routers sit, what traffic and metadata each component can see, how access behaves when the controller or identity provider is unreachable, and how posture signals reach policy. For self-hosted options, confirm which edition includes directory sync, SSO, device posture integrations and audit logging, because several of these sit in paid or enterprise tiers. For example, NetBird's published pricing places SCIM provisioning and audit event logging in its Team plan, while Pomerium reserves directory sync and Rego policies for its Enterprise edition. Verify those tier boundaries on the current pricing pages before scoring.
Agree the scope in writing before any work starts. DeployOpen does not publish prices, and a quote follows from the written scope, so ask every bidder to price the same list of applications, user groups, environments and migration waves. Ask each partner which tasks are one-time (design, migration of each application, cutover, hardening, documentation) and which recur (upgrades, backups, monitoring, support or retainers). Those recurring items are often where self-hosted costs differ most between bids. Keep the VPN running until each application is verified on the new path, and ask every bidder how they will support parallel operation during cutover.
Where the control plane, relays and data plane run
An overlay network such as NetBird builds a private WireGuard mesh between enrolled devices and the resources they reach. Self-hosted NetBird runs its management, signal, relay and STUN components from one combined configuration on a Linux host you operate, and a dashboard container, a Traefik reverse proxy and an embedded Dex identity provider sit beside them. Peers connect directly when they can, and traffic falls back to a relay when they cannot, so the relay location affects latency and what transits outside your network.
- Management and signal: Hold the device registry, group membership and access rules. Ask which of them store user identities and which store only connection metadata.
- Relay and STUN: Carry encrypted traffic when a direct path fails. Confirm whether relays run in your network, in a cloud region you choose, or in the vendor's cloud.
- Embedded Dex: Can be replaced by external SSO such as Google, Microsoft or Okta. Confirm where login events are stored.
- Operations: Self-hosted operators handle backups, upgrades and scaling. NetBird Cloud is the managed alternative and needs no servers or domain.
Ask the vendor to draw the data flow for each component, including which hostnames and ports must be reachable from the internet.
An identity-aware proxy such as Pomerium sits in front of internal web apps, SSH, TCP and Kubernetes services and evaluates each request against identity and policy. Pomerium Core is Apache-2.0 software you run in your own environment, so the proxy, policy evaluation and application traffic all stay with you. The question is then which parts of the management experience you consume as a service, since the proxy and the control plane can be separated.
- Pomerium Core: Runs the proxy in your infrastructure, typically in front of applications, with configuration you manage.
- Pomerium Zero: Hosts the control plane and management console while the customer runs the Core cluster in its own environment, so application traffic stays in the customer environment.
- Pomerium Enterprise: Offers a self-hosted control plane for organizations that want the management layer inside their own boundary as well.
- Identity provider: Users authenticate through OAuth 2.0 and OIDC with providers such as Microsoft Entra ID, Okta or Keycloak. Confirm which session and token data the control plane receives.
- Kubernetes: The Pomerium ingress controller runs Pomerium as the ingress for Kubernetes services, under Apache-2.0.
Ask whether the control plane sees policy metadata, session identifiers and access logs, and where those logs are stored and for how long.
OpenZiti separates a controller, which issues identities and defines which identities reach which services, from an edge router mesh that carries the data. Public edge routers are the only entry points reachable from the internet. Private edge routers inside your networks make outbound connections only, so no inbound firewall rules are needed. A service can be dark, with no listening port, because its tunneler or SDK dials out to a router.
- Controller: The management plane that issues x509 identities and exposes the REST API and web admin console. Confirm whether it is hosted in your environment or in a vendor-run network.
- Public routers: Reachable from the internet and therefore a deliberate exposure point. Ask how many you need and in which jurisdictions they can be placed.
- Private routers: Sit in trusted zones and dial out. Ask which networks host them and how their outbound paths are restricted.
- Data path: With SDKs, traffic is encrypted application to application. With tunnelers, encryption covers tunneler to tunneler. Confirm where a router can see plaintext in each model.
- NetFoundry managed network: A vendor-operated, globally distributed option with SLAs and enterprise support. Compare it with the self-operated controller and routers.
Ask the vendor to state which components hold keys, which hold only ciphertext, and who can revoke an identity.
Managed editions move the management layer to the vendor while leaving some data-path components with you. The split matters because a managed control plane may still hold identities, policies, device data and logs even when application traffic never passes through it. Pricing pages make the operating model visible, but the data-handling terms are what decide fit for regulated work.
- NetBird Cloud: Managed service with no servers or domain required. Its paid plans add SSO, MFA, SCIM provisioning, audit event logging, device controls and traffic logging. Ask where the management, signal and relay services run and which regions host them.
- Pomerium Zero: Keeps application traffic in your environment while Pomerium hosts the control plane. Business plans list clusters, routes, policies and custom domains as limits to check against your design.
- Data residency: Confirm the region of each hosted component, subprocessors, encryption at rest, and whether support staff can access tenant data.
- Exit path: Ask how configuration and logs can be exported and whether the self-hosted edition can take over the same policies.
Ask for the data processing agreement, the list of hosted components, and the written incident notification terms before comparing prices.
Operating responsibility is often the deciding factor, and it is separate from where the software runs. Each option leaves a different set of tasks with your platform team and a different set with the vendor or a partner. A self-hosted control plane shifts patching, backup, certificate renewal and incident response to you. A managed control plane shifts those tasks but adds a dependency on the vendor's availability and change process.
- Self-hosted control plane: Your team handles upgrades, backups, scaling, certificates and monitoring of the management and relay services.
- Hybrid model: The vendor runs the control plane while you run relays, routers or proxies. Confirm who patches the components you own.
- Partner support: An implementation partner can build, harden and document the deployment, and retainers can cover upgrades and continuous testing. Scope and timelines are agreed in writing before work starts.
- Escalation: Confirm response expectations for control plane outages, relay failures and revocation problems, and whether they are contractual.
Ask each vendor and partner to name the team that performs each operational task and the evidence they provide when they do it.
Which questions to ask about traffic visibility, posture and migration
Does the ZTNA product encrypt traffic end to end, or only up to the tunneler?
It depends on the access model, so ask which one each use case uses. With OpenZiti SDKs, traffic is encrypted from application to application, using libsodium for the data path and mTLS for authentication. With OpenZiti tunnelers, encryption covers tunneler to tunneler, so the hop between a tunneler and the application it fronts on the same host or in a trusted zone needs its own review. A good answer names each deployment model (edge router in a trusted zone, host tunneler, embedded SDK) and states what is encrypted on each segment. Confirm this with the vendor against your own network diagram, and have your security team test a packet capture on a pilot service before signing off.
What traffic metadata and logs does the ZTNA platform keep, and where are they stored?
Ask for a field-level list of what is logged: user identity, device, destination service, timestamps, byte counts, policy decisions and denied attempts. The answer should say whether payload content is ever visible to the control plane or relays, and where each log type is written. For self-hosted NetBird, the documentation covers activity and traffic event logging, and traffic logging is listed on the Business plan of its cloud pricing page, so confirm which of these you get in your edition. For Pomerium, access and audit logs appear on Zero plans, while SSH session recording and playback are reserved for Enterprise. Ask how logs reach your SIEM, such as a Wazuh or Security Onion pipeline, and how long they are retained.
How does the ZTNA platform behave when the control plane or relays are unreachable?
A good answer separates what keeps working from what stops. Ask whether established sessions survive a controller outage, whether new connections need the control plane to authorize them, and whether edge routers or relays keep the last known policy. For OpenZiti, revoking access terminates active connections immediately, so confirm how revocation behaves during a partition. For NetBird, ask how relay fallback works when direct peer-to-peer paths fail and what happens to peers on a management outage. Also ask who restores service: in self-hosted deployments the operator handles backups, upgrades and scaling. Test the answer in a lab by stopping the management component and observing a live session and a new connection.
Which device posture signals can the ZTNA product check, and how are they enforced?
List the signals you need, such as disk encryption, OS patch level, EDR presence and managed-device status, then ask which ones the product evaluates natively and which need an integration. NetBird lists device posture checks and device approvals, MDM and EDR device controls on its Business plan, so confirm whether those controls are in your edition or only in the managed service. Pomerium lists external data integrations such as FleetDM device posture as Enterprise features. Ask how posture is refreshed, whether a failing check ends an active session or only blocks new ones, and whether the signal source is on your network. Confirm each integration against the vendor's current documentation and your own endpoint tooling.
How do identity provider integration, SCIM and group mapping work in a self-hosted edition?
Ask which identity providers are supported with SSO and MFA, and whether group claims from the provider map to access policies. NetBird's self-hosted quickstart uses an embedded Dex identity provider that can add external SSO providers such as Google, Microsoft or Okta, and its Team plan lists SCIM provisioning. Pomerium uses OAuth 2.0 and OIDC and documents identity providers including Microsoft Entra ID, Okta and Keycloak. Ask whether SCIM provisioning is included in the self-hosted build or only in a paid tier, how group membership is refreshed, and what happens to access when a user is removed from the directory. Your answer should name the identity provider you already run and the test users you will use in the pilot.
What is the migration path from a corporate VPN, and can both run during cutover?
A useful answer describes a per-application migration, not a single switch-over. Ask how the product coexists with your VPN, whether you can publish one internal app through the new path while others stay on the VPN, and how DNS and routing change for users. Ask about the migration steps for each app type: web apps through a proxy, SSH, RDP, databases and UDP services through an overlay. Also ask what the vendor's own documentation says about running the two side by side and how you roll back one application. Ask your partner for a written migration plan with a pilot group, a rollback step per application and a date to retire VPN access for each application group. Durations depend on the number of applications and their dependencies, so request an estimate tied to your app inventory.
Which self-hosted features require a paid edition, and what does support cover?
Ask for a feature-by-feature matrix against the edition you plan to run, because the free self-hosted build and the managed service often differ. NetBird publishes Free, Team and Business cloud plans and a custom Enterprise tier, with SSO and MFA, SCIM and audit logs on Team and device controls and traffic logging on Business. Pomerium separates Core (open source, self-run), Zero (managed control plane) and Enterprise (self-hosted control plane), with directory sync, Rego policies, administrator RBAC and session recording reserved for Enterprise. Ask what the license terms require for your use, whether the license of each component (for example, the AGPLv3 management directories in NetBird) affects internal modifications, and what support SLA or response commitment is written into the contract. Confirm pricing directly with the vendor, since the published tiers may change.
Who runs the control plane, relays and upgrades, and what does DeployOpen handle?
Start by naming who operates each component after go-live: the controller or management service, relays or edge routers, the identity provider, certificates and upgrades. 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. Work is usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not issue audit reports or certifications, so ask for the evidence package your auditor will need. Ask any partner for a written responsibility split (RACI) covering each component, and ask for the quote to list the scope items it contains.
What to confirm about licensing and enterprise editions
Open-source ZTNA projects rarely ship every feature under one license, so the first question is which edition your requirements depend on. NetBird's repository is BSD-3-Clause except the management, signal, relay and combined directories, which are licensed under AGPLv3. Those are the server components you would run yourself, so your legal team needs to confirm what AGPLv3 obligations apply to your modifications and internal use before you commit. On the cloud side, NetBird's pricing page separates features by tier: SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging sit in Team, while device approvals, MDM and EDR controls, posture checks and traffic logging and streaming sit in Business. Ask the vendor to map each requirement in your checklist to a specific tier or to the open-source core, in writing.
Pomerium draws the same line in a different place. Pomerium Core is Apache-2.0 and self-run, but directory sync, external data integrations such as FleetDM device posture, Rego policies, RBAC for administrators, session management and SSH session recording and playback are reserved for its Enterprise edition. If your audit evidence depends on recorded SSH sessions or on administrator role separation, those features belong in the price discussion from the start, not as a later add-on. The Zero plans also carry hard limits: Zero Business allows 5 clusters, 100 routes, 100 policies and 5 custom domains, while Zero Personal allows 1 cluster, 10 routes and 5 policies. Count your applications and policies against these numbers, and ask what happens when a limit is reached. Confirm current pricing and limits directly with each vendor, since published tiers change.
Vendor and partner answers that should worry you
A ZTNA vendor or partner answer is only as useful as the specifics behind it. The six answers below are the ones that most often hide a deployment that will not match the claim once it reaches your network, your auditors or your regulators. Ask for each specific in writing before you compare prices.
Control plane location claimed as self-hosted
Some vendors say the control plane runs in your environment when only the data path does, or when the management console is hosted by the vendor. The OpenZiti controller issues identities and defines which identities reach which services, so whoever runs it controls access. Ask which components run in your accounts, which run in the vendor's cloud, and who holds the administrative credentials for each. Ask for that split in a diagram you can sign off.
Vague answers on relays and logs
Relays, coordination servers and log pipelines carry metadata about who connected to what and when, and sometimes traffic that the vendor can see. A answer such as "traffic is encrypted" does not say where a relay runs, which hosts hold connection logs, or how long they are retained. Ask for the location of each relay, the data each component stores, the retention period you can configure, and whether the vendor can read application payloads.
No statement on offline behavior
A ZTNA design that depends on a control plane being reachable can fail closed for everyone during an outage or an isolated site visit. Ask what happens to existing sessions, new sessions, and posture checks when the controller, the identity provider or the relay cannot be reached. Ask whether a policy change made during an outage takes effect at the next reconnect, and whether the answer changes for air-gapped or remote sites.
Posture claims without named integrations
"Device posture" can mean an MDM check, an EDR signal, a disk encryption check or nothing that your policy engine can enforce. Vendors often list posture as a feature without naming the integrations. Ask which MDM, EDR and endpoint tools feed posture checks, which of those are in the tier you are quoting, and which checks run on Linux and on unmanaged devices. Ask for the posture signals that block access, not only the ones that log.
Migration without per-application cutover
A plan that moves all users from the VPN on one date leaves no fallback when an application breaks. Ask for the cutover order by application, how the old VPN route and the new policy run side by side, and who signs off each move. Ask how DNS, certificates and firewall rules change per application and how a failed cutover is rolled back without disconnecting other users.
Support and SLA claims without written terms
Phrases such as "enterprise support" or "99.9 percent uptime" mean little unless they appear in a signed agreement with defined response times, severity levels and remedies. The OpenZiti README distinguishes the self-run platform from NetFoundry's managed network with SLAs, so confirm which one is being quoted. Ask for the support terms, the upgrade and security patch commitments, and the licensing terms for any self-hosted edition, in writing, before the evaluation closes.
How to score responses
This table gives a strong, partial and missing reading for each criterion you should test in a ZTNA response. Use it to compare answers from vendors and partners side by side. Weight the criteria according to your own requirements, since a regulated bank and a SaaS engineering team will rank data residency, offline behavior and posture fit differently.
| Criterion | Strong | Partial | Missing |
|---|---|---|---|
| Data residency clarity | Names where the controller, relays, logs and metadata run, and which of these the customer can self-host | Says self-hosting is possible but leaves relay, log or telemetry locations unstated | Only describes a managed service with no location or hosting detail |
| Traffic visibility | States whether the relay or proxy can read payloads, and what metadata and flow logs are kept and where | Describes logging in general terms without saying what traffic fields are recorded | No answer on what the platform can observe in transit |
| Offline and failure behavior | Describes behavior when the controller or relay is unreachable, including cached policy and existing session handling | Confirms failover exists but not how sessions or new connections behave during an outage | No answer, or assumes continuous cloud connectivity |
| Posture integration fit | Lists supported posture signals and the MDM, EDR or device inventory tools it connects to, with the policy fields it feeds | Mentions posture checks but names few signals or requires custom work for your tooling | Posture is absent or only applies to a single client platform |
| Migration plan | Proposes app-by-app cutover with a dual-running period, rollback steps and named route or policy inventory | Offers generic migration guidance without a per-application plan | No migration approach, or requires a full network cutover |
| Licensing transparency | States which features sit in the open-source edition and which in paid tiers, with license terms for each component | Gives a price page but leaves edition limits or self-hosted feature gaps unclear | Pricing and feature split only available after a sales call |
| Support scope | Defines what is covered for self-hosted installs, including upgrades, security fixes, response times and who holds on-call duty | Offers support tiers without stating what applies to self-hosted components | Support covers the managed service only, or is undefined |
How to test answers in a proof of concept
This sequence turns vendor answers into observed behavior by testing two or three representative applications, dark service access, revocation, logging and offline use, then recording each result against the questions you asked.
Choose representative applications and test users
Select two or three applications that cover the access types you need to prove, such as one browser-based internal app and one SSH or database target, plus a small group of test users with different roles and group memberships. Include at least one managed device and one unmanaged or contractor-style identity if those populations are in scope. The step is done when each application has a named owner, a written access policy to enforce and an agreed list of test users, so that results can be compared against the same baseline.
Deploy the control plane in your environment
Stand up the candidate control plane, relays or proxy inside a test segment of your own infrastructure, following the vendor's documented installation path, and record exactly where each component runs, which ports it needs and which components are reachable from the internet. Ask the vendor's engineer to confirm the same layout for production. The step is done when you can point to a diagram that shows where the control plane, relays and logs live and whether any traffic leaves your network, which is the evidence you need to check the answers on data location.
Test dark service behavior
From a test client with no VPN or ZTNA session, confirm that each application is unreachable by scanning its host address and port from the network path a user would have, then confirm that access works only after authentication and policy evaluation. Repeat the check for each service type you chose. The step is done when a written record shows the application port is not reachable without an authorized session, and that the vendor's claim about outbound-only connectors or absent listening ports holds in your network.
Test revocation and policy changes
With an active session open to each application, remove the test user from the group or policy, change the device posture state if the product supports it, and disable the identity in the provider. Measure whether existing connections end and whether new connections are refused, and note any delay between the change and its effect. Repeat once for a group-level change. The step is done when you have a timestamped record for each change showing whether active sessions terminated, which is the behavior the vendor's answers on revocation must match.
Verify logs against your audit needs
Generate a defined set of events, including successful logins, denied attempts, policy changes and session starts and ends, then export them from the product and from any external log destination. Compare the fields against the audit questions your compliance and security teams need answered, such as who accessed what, when, from which device and under which policy. Confirm which logging features your edition includes. The step is done when a reviewer can answer each audit question from the exported records alone, and any gaps are logged as open items for the vendor.
Test offline and degraded client behavior
Disconnect a test client from the network, then from the control plane, and attempt access to the applications and to the client itself. Record what the client allows or blocks, whether cached policy or session state persists, and how the client behaves when connectivity returns. Repeat the test after a control plane restart if the vendor's architecture allows it. The step is done when you have documented the offline behavior for each client type, including whether access fails closed, which determines how the product will behave for field staff or sites with unreliable links.
Record results against the RFP questions
Build a matrix with one row per question from your RFP, a column for the vendor's written answer, and a column for the observed result from the tests above, marked as confirmed, partly confirmed or not confirmed, with the evidence reference. Share the matrix with the vendor and ask for written explanations of any gaps, including licensing limits on the edition under test. The step is done when every question has a recorded result and an evidence reference, so that the scoring reflects what you observed rather than what was claimed.
What drives the cost of a ZTNA implementation
A ZTNA quote is really several costs bundled together, and the first split to ask for is between recurring subscriptions and one-time work. Software licensing is the most visible recurring item if you buy a managed tier, but a self-hosted edition is not free to run. For NetBird's cloud service, the published plans are Free for up to 5 users and 100 machines, Team at 6 euros and Business at 12 euros per user per month with 100 machines included, plus 0.50 euros per extra machine (NetBird pricing page). For Pomerium, the published Zero Business plan is $9 per user per month billed monthly or $7 billed annually (Pomerium pricing page). Both figures are list prices from the vendors' own pages, so confirm current rates, minimum seats and whether billing counts only active users and machines before comparing them with a self-hosted quote.
Self-hosting moves the recurring spend from a vendor invoice to your infrastructure and staff time. The NetBird self-hosting quickstart lists a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP 80 and 443 and UDP 3478 open, and Docker with the Compose plugin as the starting point, but production sizing, relay capacity, high availability and backups are your responsibility (NetBird self-hosting quickstart). For OpenZiti, the controller and edge routers are the components to price, and NetFoundry's managed network is an alternative to running them yourself. Ask the implementer to quote the controller, public and private routers, the identity provider integration, and the backup and upgrade work separately so you can see which lines recur.
One-time migration effort usually dominates the first year. Each application needs its own route or service definition, a policy tied to identity groups, posture rules where required, and a test run in parallel with the VPN. Ask for the effort per application class (browser apps, SSH, databases, UDP) and for the identity provider work, including SCIM provisioning and posture integration, since those were enterprise-tier features on NetBird's Team and Business plans. Also ask for the cost of ongoing operations: edition upgrades, monitoring of relays, log retention, and support. Confirm which features sit only in higher editions, such as Pomerium's directory sync and session recording, because they can change the total more than the per-seat rate does.
What buyers ask before hiring a ZTNA implementation partner
How much does a fixed-scope ZTNA rollout cost?
A fixed-scope rollout is priced from a written scope, so the number depends on what that scope includes. The main cost drivers are the number of applications being moved off the VPN, the number of user and device populations, the app types involved (web, SSH, RDP, databases, UDP), the identity provider and posture integrations, and whether the control plane and relays are built in your cloud, your data center or an air-gapped network. Some costs are one-time, such as design, migration and testing. Others recur, such as infrastructure, licenses for commercial editions and ongoing support. DeployOpen does not publish a price list. Ask for a quote that separates one-time work from recurring items and lists the applications, environments and integrations by name. Also ask who pays for each licence, since self-hosted open-source software has no license fee but a managed or enterprise edition does.
How long does a ZTNA migration from a VPN take?
The timeline is set by the number of applications to migrate, how many of them need client software versus browser access, and how long the cutover takes for each user group. Other pace setters are identity provider changes, device posture work, change approvals in regulated environments and the time needed to run the old VPN and the new access path side by side. A realistic plan moves applications in waves, starting with low-risk web apps and expanding to SSH, databases and UDP services once policies are proven. DeployOpen agrees timelines in writing before work starts, so ask for a phased plan with a named milestone for each wave and a written list of the dependencies that could move those dates.
What does the work need from our own team?
Expect your team to provide decisions and access, not just approvals. You will need owners for the identity provider, the device management or posture data source, the network and firewall changes, the DNS and certificate process, and each application being moved. Security will need to approve the access policies and the logging design, and compliance staff should confirm which evidence they need. Your team also has to test real user workflows, since only the application owners know what a working session looks like. Ask the partner to produce a RACI table in the scope document so each responsibility is named before the project starts.
Can our team run a self-hosted ZTNA without a partner?
Yes, many engineering teams can run self-hosted ZTNA, and the open-source projects publish documentation for installation. The harder work is operational: keeping the controller or management plane, relays and identity integration patched, handling backups and upgrades, designing policies that do not drift, and producing audit evidence. For example, a NetBird self-hosting deployment still requires the operator to handle backups, upgrades and scaling, and it depends on public ports and a domain. Assess your team on those tasks, not on the first install. A partner is most useful for design review, migration planning, hardening and handover, while your staff keep day-to-day control.
What support follows go-live after a ZTNA rollout?
Support after go-live usually covers three things: keeping the software current, responding to incidents and adjusting policies as applications and people change. Upgrades matter because ZTNA components sit on the access path, so a release needs testing before it reaches production. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and these are priced separately from the rollout. Ask in writing what response times apply, which versions are covered, who performs upgrades, how backups are verified, and how access logs are retained and exported. Also ask who handles vendor support for any commercial editions you choose, because open-source projects and paid plans offer different support paths.
Does a ZTNA partner guarantee that the VPN will be retired?
A partner can plan and carry out the migration, but retirement of the VPN depends on your decisions about which users, applications and networks still need it. Some legacy systems, vendor tools or protocols may keep the VPN in place for a period. A good scope names the applications that will move, the criteria for retiring each VPN route, and the owner who signs off on removal. Ask the partner to list the services that cannot move yet, along with the reason and the planned date to revisit them.
How DeployOpen scopes and delivers ZTNA evaluations and implementations
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source ZTNA platforms inside the client's own cloud accounts, data centers or air-gapped networks. We start from the written answers to the questions on this page, so the evaluation, the build and the handover all follow the same evidence about where the control plane and relays run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the apps, user groups, device types and protocols (web, SSH, RDP, databases, UDP) each candidate must cover.
- We record where each component runs, what traffic and metadata it can see, and how offline behavior is handled, for each shortlisted option.
How we build
- We deploy the chosen controller or coordination server, relays or routers and identity provider integration in the client's own environment.
- We test posture signal integration, per-application policies and revocation behavior against the answers the vendor or partner gave in writing.
- We configure logs for access decisions and session activity so they can be exported to the client's existing SIEM.
How we hand over
- Handover includes architecture and data flow documentation, runbooks for onboarding and revoking users and devices, and a record of each open question.
- We document the edition and licensing in use, including which features depend on a paid or enterprise edition.
- We prepare control evidence for the client's compliance assessors, but independent auditors and certification bodies issue any audit report or certification.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades, backup and restore checks, and re-testing when new applications move behind the ZTNA layer.
- Security testing of the deployed access layer, including applications, APIs and infrastructure, can be scoped as a separate engagement.
