How to use this zero trust network access requirements checklist
If your organization relies on a corporate VPN that grants users broad access to the whole network, the first job is to decide what that access should shrink to. Before choosing a ZTNA approach, settle who and which devices need access, which application types must work (web, SSH, RDP, databases and UDP services), which identity provider and device posture signals will make access decisions, whether clients are required or a clientless browser path is acceptable, where the control plane must run, and what logging and edition limits you can live with. The checklist that follows groups these questions into functional, security, integration, operational and compliance requirements, so that each group can be owned by the team that answers it.
Treat every item as a claim to verify, not a box to tick. For each requirement, ask for a written response from the vendor or partner and confirm it in a proof of concept using one real application from each access pattern you need to support. For example, a web app behind single sign-on, an SSH bastion path and a database reached over a private network are three different tests, and a platform that handles the first well may not handle the others the same way. Record who approved each answer and what remains open, since those gaps will shape the migration plan.
This page does not recommend a platform. The same checklist applies to OpenZiti, NetBird, Headscale and Pomerium alike, because they make different trade-offs in how they connect users, how they handle applications and where their components run. Use the checklist to narrow the field, then compare the shortlisted options against the same written questions so that the decision rests on your requirements rather than on a product's default design.
Which users, devices and applications must the requirements cover
This table lists the user, device and application coverage questions to settle before choosing a ZTNA design, with why each matters and how to verify it. Read each row as a test you run against a candidate design, not as a feature claim. The main takeaway is that protocol and client coverage differs between products, so verify UDP, RDP and database paths in your own environment before you commit.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Employees on managed laptops | Most access policy can rely on device identity and posture, so this group defines the baseline client rollout. | Enroll a sample of company-managed devices on each OS you run and confirm access to one web app, one SSH host and one database. |
| Employees on unmanaged or personal devices | Unmanaged endpoints usually need stricter policy, clientless access or denial, which changes the design. | Decide whether these devices may reach any app. Test a browser-only path and confirm the policy blocks the overlay client. |
| Contractors and vendors | Third parties often need narrow, time-limited access to a few systems, and their identities may come from outside your directory. | Confirm the identity provider can federate external accounts, and test that a contractor group sees only its assigned routes. |
| Web applications | Browser apps are the simplest migration target and can often be reached without a client, depending on the product. | Access one internal web app through the candidate design and confirm that session expiry and logout behave as your policy requires. |
| SSH and RDP | Administrative access carries the highest audit burden, and session recording is often a separate feature or edition. | Open an SSH session and an RDP session through the design. Confirm which session events are logged and whether recording is included in your edition. |
| Databases and Kubernetes APIs | Database ports and cluster APIs are high-value targets, and clients or drivers may need specific network paths. | Connect a database client and kubectl through the design. Confirm TLS to the database remains in place and that access logs record the identity. |
| UDP and non-HTTP services | Voice, some monitoring agents and custom protocols depend on UDP, and not every product supports it on every client. | Test the specific UDP service end to end, including reconnect after a network change. Verify against the current product documentation, since Pomerium Zero and NetBird list different protocol and client coverage. |
| Per-application versus whole-network access | Per-app access limits lateral movement, while subnet routes restore the network-level model that many teams are trying to shrink. | Write one policy that allows a single service and confirm a second host on the same subnet is unreachable from the same identity. |
Client versus clientless access: which pattern fits each app
Clientless access uses an identity-aware reverse proxy, such as Pomerium, that sits in front of internal web applications. The user signs in through the identity provider in a browser, and the proxy evaluates policy for each route before forwarding the request. Nothing is installed on the user device for this path, which makes it the lightest option for contractors and unmanaged laptops, although the device still needs a current browser.
- Device requirements: A supported browser and access to the identity provider. No agent or VPN client is required for web routes.
- Application requirements: The app must be served over HTTP or HTTPS and must work correctly behind a proxy, including its session cookies and redirects.
- Network requirements: Only the proxy needs a network path to the internal app. Users never reach the app network directly.
- App types covered: Internal web apps and dashboards. Pomerium also lists native SSH, TCP and UDP access through its CLI or desktop app, so confirm whether those routes need a client on the device.
- Logging: Every request can be checked against policy and recorded, which helps when auditors ask who opened which page.
Confirm with the vendor which features (such as session recording or device posture) sit in the community edition and which sit in the enterprise edition before you commit to this pattern.
Client-based overlay access installs an agent or tunneler on the user device and creates an encrypted network path to the services it is allowed to reach. This pattern covers network-level and non-web protocols, including databases, RDP, SSH and UDP-based services, that a browser cannot carry. Overlay tools such as NetBird and OpenZiti built on WireGuard or mTLS fit this model.
- Device requirements: An installed client on each managed laptop or server, with enrollment, key handling and update processes planned in advance.
- Application requirements: Usually none, because the app keeps its normal address and protocol. Applications with fixed IP allow lists may need changes.
- Network requirements: A routed path from the overlay to the target network, and outbound connectivity from clients to the coordination or relay components.
- App types covered: Non-web protocols, database consoles, RDP, SSH and UDP services.
- Posture signals: Device checks are usually available in higher tiers, so confirm which posture features your chosen edition includes.
Check how the client is distributed and updated on each operating system you must support, since that effort recurs for the life of the deployment.
Embedded SDK access puts identity and encryption inside the application itself. OpenZiti supports this as one of three deployment models that can be mixed with network access through an edge router in a trusted zone and host access with a tunneler beside the service. The SDK model suits applications your own engineers can modify, because the service needs no listening ports and no separate client on the network path.
- Device requirements: None beyond the application itself, since the app handles its own connection to the overlay.
- Application requirements: Source access or a vendor-supported integration path, plus development and testing effort. SDKs are available for Go, C, Python, Node.js, Java, Swift and C#.
- Network requirements: Services can be dark, with no open inbound ports, because the service connects outbound to an edge router.
- App types covered: Custom internal services and APIs your team owns. Packaged commercial applications usually fall under the other two patterns.
- Revocation: Revoking access terminates active connections immediately, which is useful when a contractor's access ends.
Confirm the SDK language and release status with the vendor, and plan a test cycle for each application you embed.
Most organizations do not fit one pattern. Web apps, SSH hosts, database access and custom services often sit side by side, and each needs a different path. A practical design assigns each application to one primary pattern and records the reason, so auditors and application owners can see why a route is served the way it is.
- Inventory first: List every app with its protocol, owner, user group and whether the team can change its code.
- Default by protocol: Route browser apps through a proxy, non-web protocols through an overlay, and owned services through an SDK where the effort is justified.
- Shared identity: Use one identity provider and one group model across all patterns so policy stays consistent.
- Operational load: Each pattern adds its own client, certificate or policy process, which recurs with every new user and app.
- Migration path: Start with clientless routes for quick wins, then move non-web traffic as the VPN is retired.
Ask any implementation partner to show which pattern they would assign to each app in your inventory and what evidence they would keep for that decision.
Security requirements to write into the design
These six requirements define what the access decision must enforce before any ZTNA product is shortlisted. Each one maps to a design choice that a vendor or partner can fail, so each card names what to confirm in documentation or a test before accepting it. Treat the list as acceptance criteria, not as a feature wish list.
MFA enforced at the access decision
The requirement is that the access decision itself checks strong authentication, not only the login page of the identity provider. Confirm whether the ZTNA component re-evaluates authentication strength on every new session, and whether a user who signed in with a weak factor is blocked from sensitive routes. The test to run: sign in with a password-only account against a route that requires MFA and confirm the connection is refused. For regulated workloads, the HIPAA access control and FTC Safeguards MFA requirements both depend on this behavior being enforced, not assumed.
Device posture and unknown device approval
Posture signals such as managed status, OS version, disk encryption and EDR presence should feed the access decision. Decide in advance who approves a device that has never enrolled, and whether approval is automatic, manual or blocked until MDM enrolls it. Confirm which posture checks are native to each product and which require a paid tier or a third-party integration. The test to run: enroll an unmanaged laptop and confirm it cannot reach a protected application until an approver accepts it.
Encryption between clients, relays and apps
Every hop should be encrypted, including the relay path used when peer-to-peer connectivity fails. Confirm where encryption ends: with overlay tunnelers, encryption typically covers tunneler to tunneler, while SDK-based access can extend it application to application. Ask who holds keys on relay servers and whether a relay can read payload content. The test to run: capture traffic on a relay path and confirm the payload is unreadable, then document the answer for the transmission security control.
Least-privilege policies by group or attribute
Access should be granted per application and per group or attribute, not per network range. Write the policy matrix before deployment: which roles reach which routes, which ports and which hours. Confirm whether the product can express attribute conditions such as device state or identity claims, or only static group membership, and whether directory group changes take effect without manual edits. The test to run: remove a user from a group and confirm access to that single application ends while other routes remain available.
Dark services with no inbound ports
A protected service should accept no inbound connections from the internet or from unapproved networks. Confirm that the connector or tunneler dials out to the control or relay point, and that firewall rules on the protected network need no inbound openings. Check this against the actual network scan, not the vendor diagram. The test to run: scan the service's address from outside the approved path and confirm no listening port answers, then confirm the application still works for an authorized user.
Fast revocation of active sessions
Disabling an account or removing a policy should end sessions that are already open, not only block the next login. Confirm the maximum time between a revocation in the identity provider and the termination of an active tunnel, and whether that depends on token lifetime, a polling interval or a push event. Record the answer as the revocation standard in your design. The test to run: open a live session, revoke access, and time how long the session continues to carry traffic.
Where the control plane, relays and logs must run
Decide first where the control plane sits, because it determines who can see identity data, coordination metadata and access logs. There are three practical models: a fully self-hosted control plane, a managed control plane with a self-run data plane, and a fully managed service. NetBird's self-hosted quickstart runs management, signal, relay and STUN from one combined configuration, with a dashboard, a Traefik reverse proxy and an embedded Dex identity provider. Pomerium Zero is the managed-control-plane model: the customer runs the Pomerium Core cluster, and Pomerium hosts the control plane and management console, so application traffic stays in the customer's environment. Confirm for each vendor exactly what metadata the hosted control plane receives, where its logs are stored and in which jurisdiction.
Map each component to what it holds. The identity provider holds user and group records. The coordination or controller layer holds device registrations, policies and routing metadata. Relays carry traffic when a direct path fails, so their placement determines whether encrypted application traffic transits infrastructure you do not operate. Logs hold who connected to what and when, which is often the regulated record. For EU data sovereignty or air-gapped networks, the usual answer is to self-host the control plane, relays and log store inside the required boundary. OpenZiti's public routers are the only internet-facing entry points by design, while private routers make outbound connections only. Confirm with the vendor whether any component phones home, and test it in an isolated lab before committing.
Self-hosting moves operating work to your team. NetBird's documentation states that self-hosted operators handle backups, upgrades and scaling themselves. The quickstart needs a Linux VM with at least 1 CPU and 2 GB of memory, a public domain, TCP ports 80 and 443 and UDP port 3478 open, and Docker with the Compose plugin. Certificates come from Let's Encrypt by default through Traefik, so plan for renewal failures, DNS changes and the public exposure that the domain implies. Ask any implementation partner for a written runbook covering backup and restore tests, a version upgrade procedure, how the control plane scales with users and devices, and who owns the certificate lifecycle.
Identity provider and posture signals to settle first
This sequence fixes who can sign in, how they prove who they are, and which device signals count before any ZTNA product is chosen, so the access policies written later have reliable inputs. The output is a written identity and posture baseline that the platform team, the identity team and the security team all sign off on.
Inventory identity sources and directories
The identity owner lists every place user accounts and groups live: Microsoft Entra ID, Okta, Keycloak, LDAP or Active Directory, and any contractor or partner directories. For each source, record who administers it, which users it holds, whether it is the authoritative record for employment status, and whether it can be reached from the network where the ZTNA control plane will run. Done when each source has an owner and a one-line purpose.
Confirm the identity provider for ZTNA login
The identity owner decides which provider will authenticate users to the ZTNA layer and confirms that the chosen product supports it. Pomerium uses OAuth 2.0 and OpenID Connect for user identity and documents a list of providers that includes Entra ID, Google, Keycloak, Okta and Ping. NetBird can connect external SSO providers through its embedded Dex identity provider. Ask the product vendor to confirm the exact protocol and version support for your provider, and do not assume a listed provider covers every tenant configuration. Done when a written compatibility note names the provider, protocol and any known gaps.
Map SSO groups to access policy
The identity team defines the groups that will drive access, such as engineering, finance-systems or vendor-imaging, and maps each to the applications and networks it may reach. Groups should be stable, owned and named by business function rather than by person. Confirm that group claims pass through the login flow into the ZTNA policy engine and that nested or dynamic groups behave as expected. Done when a table links each group to its target routes and an owner signs it.
Confirm SCIM provisioning and directory sync tiers
The identity team verifies how accounts are created, changed and removed in the ZTNA tool. NetBird lists SCIM provisioning in its Team plan, and Pomerium reserves directory sync for its Enterprise edition, so the tier that includes these features must be confirmed against your requirements before purchase. Ask whether leavers are removed automatically and how quickly active sessions end after removal. Done when provisioning is either automated and tested with a leaver, or a manual procedure with a named owner is documented.
Decide MFA methods and enforcement points
The security team decides which second factors are acceptable for each user group and whether the ZTNA layer enforces MFA itself or relies on the identity provider's policy. The FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system at covered financial institutions, and HIPAA's access control and authentication requirements at 45 CFR 164.312 apply to ePHI systems. Confirm which factors the identity provider supports and whether the ZTNA product can check that MFA was satisfied. Done when a written MFA matrix covers each user group and access path.
Define device posture inputs
The endpoint and security teams list the device signals the policy will use, such as disk encryption, OS patch level, managed-device status and EDR presence. NetBird lists device posture checks in its Business tier, and Pomerium names FleetDM device posture as an external data integration in its Enterprise edition, so each signal must be matched to a product tier and a data source. Confirm which signals the product reads natively and which need an integration. Done when each signal has a source, a tier and an owner.
Decide what happens when a signal is missing
The security team writes the fallback for each posture input, such as an unmanaged device, a stale check-in or an unreachable posture source. Options include denying access, allowing read-only access to low-risk apps, or routing the user to a remediation page. Also decide whether Rego-based or attribute-based policy logic is needed, since Pomerium reserves Rego policies for Enterprise and documents attribute-based policies in its Zero plans. Test one missing signal in a lab to confirm the behavior. Done when the fallback rules are written and a test record shows the expected result.
Confirm edition limits before selecting a product
The platform owner compares the identity and posture requirements against the edition tables for each candidate, including NetBird's Team and Business features and Pomerium's Zero and Enterprise differences. Ask the vendor in writing which features are included in the self-hosted edition, which need a managed control plane, and which are only in the enterprise tier. Done when the signed requirements list shows each feature, the edition that provides it and the vendor's written confirmation.
Logging, audit and evidence questions
Which access events should a ZTNA platform log?
At minimum, log session starts and ends, denied connection attempts, policy and route changes, and administrator actions on the control plane. Each record should carry the user or device identity, the target application or route, the time, and the policy decision. Ask each vendor or open-source project to show a sample export of every event type, because the set of events a platform emits varies by product and edition. NetBird lists activity and traffic event logging, and its audit event logging appears on the Team plan. Pomerium Zero lists access and audit logs, while some control-plane features sit in its Enterprise edition. Confirm the exact event list against your own test deployment rather than the marketing page.
Where do ZTNA logs go, and how long are they kept?
Logs usually land in one of three places: the control plane's own store, a log pipeline you operate, or a SaaS log service. Retention is set by the platform, by your log pipeline, or by both, so ask who holds the data at each hop. Confirm three things: whether logs leave your environment, whether the control plane or relay can see application payloads (end-to-end encryption in OpenZiti SDK mode differs from tunneler mode), and how long each store retains records before deletion. Retention periods should come from your own policy and regulator requirements, not from a vendor default. Write the answer into the design before procurement.
Is SSH session recording included or restricted by edition?
Session recording is an edition question, and you should confirm it before design. Pomerium's pricing page places SSH session recording and playback in its Enterprise edition, while native SSH access is listed for its Zero plans. NetBird lists SSH with central access policies, but this page does not supply a recording feature for it, so confirm that directly with NetBird. If you need recorded privileged sessions with approval workflows, the requirement may point toward a dedicated privileged access tool instead of a ZTNA overlay. Ask vendors for written confirmation of which features are included in the edition you plan to run.
How do ZTNA logs feed a SIEM such as Wazuh?
Most ZTNA platforms export events in a structured format, through an API, a log stream or a syslog-style forwarder, and the SIEM ingests them with a parser or decoder. Wazuh can collect logs from files and syslog sources and apply rules to them, so the integration usually means exporting ZTNA events to a file or stream that a Wazuh agent or collector reads. Confirm the export method, the field names, and the event timestamps for each platform, and test that alerts fire on a denied request and on a policy change. Plan for the SIEM's own storage and retention, which adds ongoing cost. DeployOpen can implement and test this integration as part of a fixed-scope engagement, with scope agreed in writing first.
How do ZTNA logs map to HIPAA 45 CFR 164.312 audit controls?
The HIPAA Security Rule at 45 CFR 164.312 requires access control with unique user identification, audit controls that record and examine activity in systems containing ePHI, person or entity authentication, and transmission security. ZTNA logs can support the audit control requirement and the unique identification requirement when each event ties to an individual identity, not a shared account. They do not satisfy the rule by themselves. You still need to define which systems hold ePHI, review the logs on a schedule you document, and retain them under your own policy. Ask each platform whether events identify the person and device, and whether logs are tamper resistant. The rule's text is the authoritative source, and your compliance counsel or assessor should confirm how it applies to your environment.
How do ZTNA logs support FTC Safeguards 16 CFR 314.4 monitoring?
The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to implement multi-factor authentication for anyone accessing an information system, encrypt customer information in transit and at rest, and monitor and log the activity of authorized users. ZTNA logs can provide evidence for the monitoring and logging element and for MFA enforcement, provided the identity provider records authentication method and the policy enforces it. Encryption evidence requires separate records from the platform configuration. Confirm with your own compliance team which systems fall in scope, how long logs must be kept, and how alerts are reviewed. The rule text governs, and this page does not give a legal reading of it.
Does DeployOpen issue audit reports for these logging controls?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, including log configuration, retention settings, SIEM integration and evidence packs mapped to control requirements. Independent auditors and certification bodies issue audit reports, attestations and certifications. Ask your assessor early which evidence they expect, such as configuration exports, sample log records, change history and access reviews, so the implementation produces what they will request. Engagements are fixed-scope, with deliverables agreed in writing before work starts.
What does logging and evidence work add to the cost of ZTNA?
Logging adds cost in four places: the log storage and retention you operate or pay for, the SIEM ingestion and analyst time, the engineering to map events to controls, and the evidence work during assessment. Some managed tiers include audit logging only in higher-priced plans, such as NetBird's Team and Business plans, so price the edition that includes the events you need. Ask each vendor for the exact plan that includes audit logs, traffic logs and any export feature, and ask DeployOpen for a written scope that lists the log sources, SIEM target, controls mapped and evidence delivered. A quote follows from that scope.
Operational requirements and how to verify them
This table lists the operational requirements a ZTNA control plane and its relays must meet after go-live, with the reason each matters and the check that proves it works. Use it to turn vendor claims into tests you can run in your own environment. Treat every row as incomplete until a restore, failover or upgrade has been rehearsed.
| Requirement | Why it matters | How to verify |
|---|---|---|
| High availability of the control plane | If the management plane is down, users may not be able to authenticate or receive new policy, and some platforms depend on a single coordination service. Confirm which components are clustered and which are single instances. | Ask for the reference topology for your chosen product. Test a controller or management node failure in staging and record whether existing sessions survive and new sessions fail. |
| Relay and edge router failover | Relays or edge routers carry traffic when direct peer-to-peer paths fail. NetBird uses relay fallback, and OpenZiti uses public routers as entry points, so a single relay can become the bottleneck. | Run two relay or router paths, stop one during an active session, and measure how long clients take to reconnect. Repeat from a network where direct paths are blocked. |
| Backup and restore | The control plane holds identities, groups, policies and certificates. A lost database can mean every client must re-enrol. NetBird's self-hosting documentation makes backups the operator's job. | Take a backup of the control plane database and configuration, restore it into a clean host, and confirm that a test user, device and policy still work. Record the time taken and the steps used. |
| Certificate and key lifecycle | Overlay and proxy designs issue certificates for identities and services. Expired or unrotated certificates cause outages that look like access failures. | List every certificate and its renewal method, including the ACME setup for the reverse proxy. Force a renewal in staging and confirm the client trust chain updates. |
| Upgrade cadence and release tracking | Projects publish releases frequently. For example, NetBird v0.81.2 was published on October 16, 2026, after v0.81.0 on October 15, 2026, and Pomerium v0.33.4 was published on October 2, 2026. Your team needs a named owner and a rule for which releases are adopted. | Check the GitHub releases page for your product before each planning cycle, and confirm whether a release is a prerelease. Keep a dated upgrade rehearsal in staging with the exact versions you will run in production. |
| Monitoring and alerting | Silent failures, such as an expired certificate or a stalled relay, look like user complaints. Access logs also need to reach your SIEM to satisfy audit expectations. | Define alerts for control plane health, relay availability, failed authentications, policy changes and certificate expiry. Trigger each alert on purpose and confirm it reaches the on-call channel. |
| Log export and retention | Access and audit logs must be retained and reviewed according to your regulatory obligations. Some editions limit log streaming or session recording. | Confirm which logs the edition produces, where they are stored and how they reach your SIEM. Check the edition feature list for traffic logging and session recording before you rely on them. |
| Staffing and on-call coverage | A self-hosted ZTNA control plane needs people who can handle identity provider changes, network issues and urgent revocations. Coverage gaps leave remote access broken or unrevoked. | Write a runbook with named roles for the control plane, network, identity and security. Test an after-hours revocation drill and confirm the on-call person can complete it alone. |
| Support hours and escalation | Vendor support, partner support and internal support cover different parts of the stack. Gaps between them slow incident response. | Ask each supplier for its support hours, response channels and escalation path in writing. Confirm which edition or contract includes enterprise support, and map each incident type to one owner. |
Edition limits that change the requirements list
Write down every required feature before you compare products, and check which edition includes it. Open source cores and paid editions do not draw the line in the same place. Pomerium Core is Apache-2.0 and self-run, but the Zero plans add a managed control plane, and the Enterprise edition reserves directory sync, external device posture integrations such as FleetDM, Rego policies, RBAC for administrators, session management and SSH session recording and playback. If your requirements include administrator role separation or recorded SSH sessions, those items move the design from a free core to an Enterprise contract before any architecture work begins. The Zero Business plan also caps a deployment at 5 clusters, 100 routes, 100 policies and 5 custom domains, so a large application estate may hit those limits quickly. Count your routes and policies per environment now, not after rollout.
NetBird splits its features across tiers in a different way. Its free tier covers up to 5 users and 100 machines, while SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging appear in Team. Device approvals, MDM and EDR device controls, posture checks and traffic logging and streaming appear in Business. For a regulated environment, this means that a requirement such as device posture enforcement or traffic logs for an auditor is a tier decision, not a configuration task. Also confirm whether a self-hosted deployment gets the same feature set as NetBird Cloud, since the pricing page describes the hosted plans and the self-hosting quickstart describes a different deployment path. Ask the vendor for that answer in writing.
Before you cost the design, ask each candidate vendor or partner to confirm, in writing and for the exact version you plan to deploy, which edition provides each required feature, including audit logs, log export, SCIM, posture signals and administrator roles. Pricing pages change, and a feature shown on a marketing page may be limited to a hosted plan. Record the answers next to the requirement they satisfy so the checklist and the quote refer to the same edition. Any gap that remains after this exercise is a cost to add, a compensating control to design, or a reason to drop that option.
Questions buyers ask before choosing a ZTNA design
How long does ZTNA requirements gathering take?
The length depends on how many applications are in scope, how many identity sources must be connected, and how many edition or hosting decisions are still open. A team with a short, well-documented application list and one identity provider can settle the core choices quickly. A team with many legacy applications, several directories and unresolved questions about where the control plane runs will spend most of its time on discovery, not design. Ask any implementation partner to list the assumptions behind its estimate and to state which of them would change the timeline if they proved wrong.
Who on our team needs to be involved in the requirements?
Three groups carry most of the decisions. Identity owners confirm the workforce and contractor populations, group structure, multi-factor rules and which identity provider is authoritative. Application owners describe each internal app, its protocol (web, SSH, RDP, database or UDP), its users and the traffic it expects. Network and security approvers decide on device posture signals, logging destinations, data residency and who may approve exceptions. Without the application owners, the app inventory is usually incomplete, and that gap tends to surface during migration rather than before it.
Can our own team design and run ZTNA without outside help?
A capable platform or security team can run a small pilot with OpenZiti, NetBird, Headscale or Pomerium using public documentation. The harder work is the surrounding design: mapping users and groups to access policies, deciding which applications move first, handling posture and logging, and planning how the VPN runs alongside the new path during cutover. Teams should check whether they have people who can own the control plane backups, upgrades and certificate renewal over time. An outside partner can take on any part of that work under a written, fixed scope, and the team can keep the operating responsibilities it wants to retain.
What drives the cost of a ZTNA project up or down?
Costs fall into a few components. Migration effort is the largest variable and grows with each application, especially those that need custom routing, legacy protocols or changes to the application itself. Control plane hosting is a recurring infrastructure cost that depends on where the controller, relays and proxies run. The support model adds a recurring cost, whether the team handles upgrades and incidents alone or buys a retainer. Managed services are priced differently: NetBird's cloud pricing page lists Free for up to 5 users and 100 machines, Team at 6 euros and Business at 12 euros per user per month, and custom Enterprise pricing, and Pomerium's pricing page lists Zero Business at $9 per user per month billed monthly. Compare these published plans against the self-hosted cost model, and ask for a quote that separates one-time migration work from recurring hosting and support.
Which edition features should we decide before the design starts?
Edition choices change what the design can include, so settle them early. NetBird's published pricing places SSO and MFA with an enterprise identity provider, SCIM provisioning and audit event logging in its Team tier, and device approvals, MDM and EDR device controls, posture checks and traffic logging in Business. Pomerium reserves directory sync, FleetDM-based device posture, Rego policies, administrator RBAC and SSH session recording for its Enterprise edition. Confirm with each vendor whether a feature you need is in your chosen tier and whether the license terms allow the self-hosted deployment you plan.
Does the ZTNA control plane have to run in our own infrastructure?
It does not have to, but the answer shapes compliance evidence, data handling and support. Self-hosting keeps the controller, coordination services and logs inside your environment, and NetBird's self-hosting quickstart notes that operators then handle backups, upgrades and scaling themselves. Pomerium Zero is a middle option: the customer runs the Pomerium Core cluster while Pomerium hosts the control plane and management console, so application traffic stays in the customer environment. Confirm which component holds which data, where relays sit and what a provider can see before you commit.
How do we request a fixed-scope quote for ZTNA work?
Send a written requirements summary and let the scope follow from it. Include the application inventory with protocols and user counts, the identity providers and groups in scope, the device and posture signals required, the logging destinations and retention you need, and the edition and hosting decisions you have made. Ask for deliverables, acceptance criteria, exclusions and a timeline in writing. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope, so the quote follows from the written scope rather than a published price list.
What evidence will auditors expect from a ZTNA deployment?
Auditors generally look for unique user identification, strong authentication, encrypted transport and logs of who accessed what. The HIPAA Security Rule at 45 CFR 164.312 requires access control with unique user identification, audit controls, person or entity authentication and transmission security. The FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system and monitoring of authorized user activity. Decide early which access and audit logs the platform must export, how long they are kept and who reviews them. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any opinion or certification.
How to turn this checklist into a written scope
The checklist becomes a written scope only after the requirements are signed off by the people who own the outcome: the CISO or security lead for policy, the identity team for the identity provider and groups, the application owners for each app, and the network team for routes and firewall changes. Each requirement should be recorded with its owner, its acceptance test and its status. Requirements that stay open at this point, such as whether contractors need SSH or whether UDP services must be reachable, should be named as open items with a decision date, not carried silently into the scope. Ask the implementation partner to restate the requirements in their own words before any fixed price is discussed, so both sides agree on what "covered" means.
Next, run a proof-of-concept test for each app type on the list: a browser-based web app, an SSH host, an RDP session, a database port, a UDP service, and a managed device compared with an unmanaged one. For each test, record the identity provider login path, the posture signal used (if any), whether a client or a clientless path is used, the logs produced and the behavior when access is revoked. Keep a decision record for every requirement that states the option chosen, the option rejected, the reason, and the evidence. This record is what a compliance assessor or internal auditor will later ask to see, so it should live in the client's own repository, not in a consultant's inbox.
The migration plan should describe how the existing VPN keeps running next to the new path during cutover, app by app, with a named rollback step for each application. Agree in writing which users and groups move first, how the VPN route is removed only after the new path has passed its tests, and who approves each step. Confirm that the scope names the support window, the handover of the control plane and the items the client must provide, such as DNS names, certificates and identity provider access. A fixed-scope statement built this way makes clear what is delivered, what is tested, and what remains the client's responsibility.
How DeployOpen scopes, delivers and supports ZTNA selection and implementation
DeployOpen turns the requirements in this checklist into a written scope, then plans, implements, hardens, documents and hands over the chosen open-source ZTNA platform inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we scope
- We confirm the user groups, devices and app types (web, SSH, RDP, databases, UDP) that the access design must cover.
- We record which identity provider, posture signals and logging destinations the design must integrate with, and which edition limits apply.
- We agree the written scope, deliverables and timeline before work starts, with ongoing support available as a retainer.
How we build
- We deploy the selected control plane, such as an OpenZiti controller or a self-hosted NetBird or Pomerium stack, in your environment.
- We configure identity provider connections, group-based policies and posture checks, then test each app type against the written requirements.
- We run security testing on the deployed access paths and document the encryption, logging and dark-service settings that result.
How we hand over
- We deliver architecture records, configuration documentation, runbooks and a per-application migration register for your team.
- We document the compliance evidence the design supports, such as access logs and authentication settings, for your assessors to review.
- We walk your operators through backups, upgrades and scaling responsibilities so ownership of the platform is clear after go-live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers covering the platform after handover.
- We track upstream releases for the components in your design and scope any upgrade or re-test as written work.
- We confirm with you which compliance conclusions belong to your independent auditors, since DeployOpen prepares evidence but does not issue attestations.
