What is ZTNA?
Zero trust network access (ZTNA) connects a user to one specific private application after verifying who the user is and whether their device is healthy, and it never puts the user on the internal network. It applies zero trust principles to remote access: no request is trusted because of where it comes from, every session is brokered, and access is granted per application rather than per network. ZTNA is usually delivered as a cloud service and is a core part of security service edge (SSE). Some vendors and older texts call the same idea a software-defined perimeter (SDP).
How ZTNA works
- A lightweight connector runs next to the applications in the data center or cloud network. It makes outbound connections to the ZTNA broker, so no inbound port is opened on the firewall and the applications have no public listening port for scanners to find.
- The user's agent, or a browser for clientless access, connects to the broker and asks for an application.
- The broker checks the user's identity with the identity provider, including how strongly they authenticated, and the device's posture: whether it is managed, patched and encrypted, and whether its EDR agent is running.
- If policy allows, the broker joins the user's connection to the connector for that one application. The user can reach that application and nothing else.
- Signals keep being evaluated during the session, so a device that falls out of compliance can lose access.
In the vocabulary of NIST SP 800-207, the broker acts as a policy enforcement point in front of the resource, backed by a policy decision point that evaluates each request.
Example: a contractor needs one application
A contractor needs the internal ticketing application from a laptop the company does not manage. With a traditional VPN, the contractor would get an internal IP address and could scan the network. With clientless ZTNA, the contractor opens a browser, signs in through the company's identity provider with MFA, and gets a session to the ticketing application only. Policy can add session controls for the unmanaged device, such as blocking downloads. The broker's log might record:
user=jdoe@partner.example device=unmanaged app=ticketing mode=clientless mfa=yes decision=allow session=browser-only
When the contract ends, disabling the identity removes access everywhere at once.
ZTNA vs. VPN
| Remote access VPN | ZTNA | |
|---|---|---|
| What the user gets | An address on the internal network | A session to named applications |
| Lateral movement | Possible unless per-group rules restrict it | No network path to other systems |
| Exposure | An internet-facing concentrator the organization must patch | Applications reachable only through the broker |
| Trust decision | Usually once, at connect time | Per request, using current identity and device signals |
| Typical use | Broad network access for staff and legacy applications | Remote users and third parties reaching private apps |
ZTNA has limits. It does not fix vulnerabilities inside the application, so an authorized user can still exploit an injection flaw; it only narrows who can reach it. Some legacy applications and protocols are hard to publish this way, and availability depends on the broker service.
ZTNA on the CompTIA Security+ exam
ZTNA falls under SY0-801 objective 3.2, which covers making architecture decisions that protect the infrastructure, as part of both zero trust architecture and security service edge. Scenario wording such as "access to a single internal application without network access", "contractor on an unmanaged device", "replace the VPN" or "applications should not be visible from the internet" points to ZTNA. Distractors include a full-tunnel VPN, which puts the device on the network; an inbound firewall rule allowing the contractor's IP address, which trusts location; NAC, which checks a device when it joins a network rather than per application; and a CASB, which governs SaaS use rather than access to private applications.