Zero trust network access (ZTNA) connects a user to one specific application after checking who they are and whether their device is in good shape, instead of putting them on the whole network the way a traditional VPN does. Nothing is trusted just because it is "inside." For most small and mid-sized businesses it is a gradual change to how remote access works, not a weekend rip-and-replace project.
The phrase gets attached to almost every security product on the market, which makes it hard to tell what you are actually being offered. This guide sticks to the networking side: what changes, what it needs from your circuits and devices, and how to tell whether you are ready.
Why the old model stopped fitting
The traditional office network works like a building with one locked front door. Get through the door, by being at a desk or by connecting to the VPN, and you can walk down most of the corridors. The firewall faces outward. Inside, devices largely trust each other.
That design made sense when the applications, the files and the people were all in one place. Three things changed it:
- The applications left. Email, file storage, accounting and CRM moved to cloud services that never sat behind the office firewall in the first place.
- The people left. Hybrid work means company data is used from home networks, hotels and phones on cellular data.
- Stolen passwords got cheap. If one set of VPN credentials gets an attacker onto the whole network, the front door is the only defence that matters, and it only has to fail once.
A VPN also tends to drag traffic through the office. A remote employee on a full-tunnel VPN who opens a cloud app sends that traffic to the office first, then out to the cloud, then back again. The office circuit carries it twice.
How ZTNA works
A check before every connection
With ZTNA, a user asks for a specific application, not for the network. Before the connection is allowed, a policy engine checks several things:
- Identity. The user signs in through your identity provider, the system that already handles your company logins, with multi-factor authentication.
- Device posture. Is this a company-managed laptop? Is the disk encrypted, the operating system current, the security software running?
- Context. Which application, from where, at what time, and does that match what this person normally does?
If the checks pass, the user reaches that one application. They do not get an address on the office network, and they cannot scan for or browse to anything else. If the checks fail partway through a session, access can be cut.
The broker and the connector
Most ZTNA services put a broker in the cloud between the user and the application. At the office or in your cloud account, a small piece of software called a connector makes an outbound connection to that broker. Users reach the application through the broker, so you do not need to open inbound ports on your firewall for remote access at all. To someone scanning the internet, the application is not visible.
Agent or no agent
Agent-based ZTNA installs software on each device, which allows the posture checks above and works for most kinds of traffic. Agentless ZTNA works through a web browser and suits contractors or personal devices you do not manage, but usually only for web applications. Many businesses end up using both: agents for staff, browser access for outsiders.
ZTNA and VPN side by side
| Traditional remote-access VPN | ZTNA | |
|---|---|---|
| What the user connects to | The network | Specific applications |
| Trust after sign-in | Broad, usually for the whole session | Checked per application, can be re-checked |
| Device health checks | Optional and often skipped | Built into the policy |
| Inbound ports on your firewall | Yes, the VPN gateway listens on the internet | Usually none; connectors dial out |
| Cloud app traffic | Often hairpins through the office | Goes direct; only private app traffic is brokered |
| Contractor access | Hard to limit to one system | Simple to scope to one application |
| Main dependency | The VPN appliance and office circuit | The identity provider and the ZTNA service |
What zero trust is not
Zero trust is a set of principles, not one box. The US National Institute of Standards and Technology describes it in its zero trust architecture guidance (SP 800-207) as an approach built around never granting access on network location alone. ZTNA is the part of that approach that handles remote access to applications. It does not replace patching, backups, email filtering or a firewall at the office. It is also not instant. Getting device management, identity and application inventories in order is most of the work, and that work is worth doing whether or not you buy a ZTNA product.
If you are also evaluating secure web filtering, cloud firewalling and SD-WAN as one bundle, that wider package is called SASE, covered in SASE explained. ZTNA is one component of it and can be bought on its own.
What it changes on your network
- Fewer open doors. Once remote access runs through connectors, the VPN listener on your firewall can eventually be switched off. Internet-facing VPN appliances are a frequent target for attackers, so retiring one is a real reduction in exposure.
- Less load on the office upload. Remote staff stop pulling cloud traffic through the office, so the office circuit only carries traffic for the applications that actually live there.
- The identity provider becomes critical. If sign-in is down, so is access. Ask how your identity and ZTNA providers handle outages, and keep a documented break-glass account.
- The office circuit still matters. Applications hosted in the office are now reached through a connector over your internet connection. A single circuit with no backup is still a single point of failure for everyone working remotely.
- The firewall gets simpler, not redundant. You still need a properly sized firewall at the office for the people and devices there.
A worked example
A hypothetical illustration. The company and figures are invented to show the arithmetic.
Take a 45-person firm. On a typical day 30 people work remotely on a full-tunnel VPN. They use two applications hosted in the office, an accounting system and a file server, plus cloud email, video calls and a CRM. Say each remote user averages 4 Mbps at busy times. That is 120 Mbps arriving over the VPN, and most of it, the cloud traffic, goes straight back out of the same circuit. The office line is carrying the same video call twice.
Now move to ZTNA. Only traffic for the two office-hosted applications reaches the office, perhaps a fraction of the 120 Mbps. Cloud traffic goes from each home directly to the cloud service. Three outside bookkeepers get access to the accounting system and nothing else, where before they had VPN accounts that could reach every shared drive. The VPN listener can be turned off once the last user moves. Nothing about the circuit had to change to make that happen, but the firm now knows exactly which systems remote users depend on, which is the information it needs to decide whether the office deserves a backup line.
A sensible adoption order
- List the applications. Which systems do remote users reach, where does each one live, and who needs it? Many businesses find the list is shorter than they thought.
- Get identity in order. One identity provider, multi-factor authentication for everyone, and old accounts removed.
- Manage the devices. You cannot check device health on laptops nobody manages. Enforce updates and disk encryption first.
- Pilot one application with one group. Contractors are a good start, because limiting them to one system is the clearest win.
- Move the remaining applications one at a time, keeping the VPN as a fallback during the change.
- Retire the VPN listener and close the inbound ports once nobody uses them.
- Review the policies on a schedule, especially when people change roles or leave.
Businesses with only cloud applications and nothing hosted in the office may find they need very little ZTNA at all. Strong identity and device management may already cover most of the risk.
Questions to ask your provider
- Which of my applications can this protect: web only, or also file shares, remote desktop and older client-server software?
- Does it need an agent on every device, and which operating systems and phones are supported?
- Which device health checks can the policy use, and does it work with the device management tools I already have?
- Where are your brokers located, and what does that do to latency for my users?
- What happens to access if your service or my identity provider has an outage?
- Can I run it alongside my current VPN during migration?
- How is it licensed: per user, per application, or by bandwidth?
Getting the access and the circuits right together
Zero trust changes where traffic flows, so it is worth looking at the circuits at the same time as the security tooling. We handle the connectivity side and coordinate the network and security pieces on our cybersecurity and managed network services, and we will tell you plainly if your current setup already does the job. Several Tier 1 carriers bid on your address, the carrier pays us so there is no markup, and the quote is free with a same-day response. Send us your address, call 478-758-8091 or text (347) 870-0965. If your team is mostly remote, internet for remote and hybrid teams covers the home side.
