A “ZTNA server” usually refers to one of the components that make Zero Trust Network Access work, rather than a single box. Most ZTNA services are made up of a controller that makes access decisions, gateways or edges that carry traffic, connectors that sit next to applications, and a client on the user’s device. In modern ZTNA, most of these run as a cloud service, so there is no server for you to install or patch.
The main components of ZTNA
- Controller (policy decision point). Checks the user’s identity, device posture and context against policy, and decides whether to allow each connection. It usually integrates with your identity provider and endpoint security tools.
- Gateway or edge (policy enforcement point). Carries the traffic between users and applications and enforces the controller’s decisions. In cloud-delivered ZTNA these run in the vendor’s points of presence.
- Connector. A lightweight piece of software deployed in a data center or cloud environment, next to the applications. It makes outbound connections only, so applications are not exposed to the internet and no inbound firewall rules are needed.
- Client or agent. Software on the user’s device that authenticates the user, reports device posture and routes application traffic. Some ZTNA products also offer browser-based, agentless access for web applications.
How a ZTNA connection works
- The user opens an application, and the client sends an access request.
- The controller verifies identity and device posture and checks policy.
- If access is allowed, the user is connected through the nearest gateway to the connector in front of that application.
- The session is monitored, and access can be revoked if the user’s or device’s risk changes.
Why the location of these components matters
Because user traffic passes through the gateways, their distance from users and how they handle poor connections directly affect application performance. This is where many ZTNA deployments fall short for remote workers on home and mobile networks.
How Cloudbrink’s architecture works
Cloudbrink’s service has four components:
- Brink App on user desktops and mobile devices, which handles zero trust checks and adapts to network conditions.
- FAST Edges, software-only edges deployed close to users: never more than 20ms away, with a median under 5.2ms.
- Brink Connector, a lightweight virtual machine that runs on ESX, KVM, AWS, Azure or GCP and keeps private applications dark to the internet.
- Brink SaaS, the single console for policy, management and visibility.
Policy is enforced by identity, device posture and location, with mTLS 1.3 and certificates rotated every eight hours. The Brink Protocol adapts in real time to keep performance LAN-like even at 20% packet loss. There is no hardware to buy or maintain. Learn more about High-Performance ZTNA.