ZTNA vs NAC: network access control compared

What network access control does

Network access control sits behind your switches, wireless controllers and sometimes VPN headends. When a device connects, the network asks a policy server what to do, and the answer depends on who the user is, what the device is, how it is connecting and whether it is healthy. Typical mechanisms:

• 802.1X authentication with certificates or credentials over RADIUS, for devices that can take part
• MAC authentication bypass (MAB) and device profiling for printers, cameras and other devices that cannot
• Posture checks on managed endpoints before full access is granted
• Guest and BYOD onboarding portals
• An outcome: a VLAN, a downloadable access list, a security group tag, a guest redirect or quarantine

Cisco Identity Services Engine is a well-known example: see Cisco ISE on our Cisco site for how it handles 802.1X, profiling, posture and TrustSec segmentation.

What ZTNA does

Zero trust network access works one layer up and from anywhere. It does not care which switch port a user is on; it cares whether this user, on this device, in this context, should reach this application right now. A policy engine evaluates the request, and a connection is brokered to the one application through a connector or enforcement point. The step-by-step flow is on how zero trust network access works.

ZTNA vs NAC comparison

Why being on the LAN should not mean access

Traditional NAC answers "can this device join?", and historically joining the network was treated as permission to reach most of it. Zero trust guidance rejects that. The NCSC's ZTNA design requirements say access must be authorised by policy before any connection is established, and that being on the corporate network or at a known location is not enough. One of its anti-patterns is trusting network location, including office IP ranges. And one of the NCSC's zero trust design principles is simply "Don't trust any network, including your own".

So NAC is necessary but not sufficient. It keeps unknown devices off the network and puts known ones in the right place; ZTNA, or an equivalent application-level policy, then decides what users can reach from there. Without the second half, a compromised laptop that passes NAC still reaches everything its VLAN can.

Why most organisations need both

The two cover different gaps:

• IoT, OT and shared devices. Printers, cameras, building systems and lab equipment cannot run a ZTNA client. NAC identifies them and segments them; ZTNA cannot.
• Remote and hybrid users. NAC has nothing to say about a laptop on home broadband; ZTNA is built for it.
• Users in the office. This is where they overlap. With NAC alone, office users are trusted by segment. With on-premises ZTNA enforcement, the same per-app policy applies at a desk as at home.
• Context sharing. NAC knows a great deal about devices on the network, and that context can feed access decisions elsewhere.

Segmentation sits between the two. NAC places devices in segments, and microsegmentation limits what each machine can talk to inside them; see network segmentation vs microsegmentation.

A Cisco example: ISE, Secure Access and universal ZTNA

Cisco's portfolio shows how the two can join up. Cisco ISE provides NAC on the LAN, and its security group tags can drive fine-grained segmentation policy in Cisco Secure Access, Cisco's security service edge. Cisco's universal ZTNA then applies the same per-user, per-application policy whether people are remote or on site: Secure Access defines policy and posture, Cisco Secure Firewall Threat Defense enforces it for on-premises resources, and Cisco Secure Client acts as the enforcement point on the device.

The result is that an office user is no longer trusted just because ISE admitted their laptop to the right VLAN; they still need policy approval for each application. See Cisco universal ZTNA for the components, and Cisco ZTNA on our Cisco site for how Secure Access handles client-based and clientless access.

SASE vs network access control

People also ask how SASE compares with NAC. They sit at different points. SASE secures traffic leaving users and branches: to the internet, to SaaS and, through ZTNA, to private apps, with SD-WAN connecting the sites. NAC secures the local network edge, deciding which devices may plug in. A SASE platform does not authenticate a printer on a switch port, and a NAC platform does not filter a remote user's web traffic. Organisations with office networks and remote staff often need both, ideally drawing identity from the same identity provider. See ZTNA vs SASE for what SASE contains.

Questions to answer before buying either

A short checklist keeps the two projects from overlapping or leaving gaps:

1. Which devices on site cannot run an agent or client (printers, cameras, building and OT systems), and how are they identified and segmented today?
2. Are office users trusted simply by being on the LAN or a particular VLAN, and which applications could they reach if their laptop were compromised?
3. Do you want the same per-application policy for users in the office as for users at home, or is remote access the priority?
4. Which identity provider and device management platform will both NAC and ZTNA draw on, and are their groups and device records accurate?
5. Where will allow and deny decisions from NAC and ZTNA be logged, so an investigation can follow a user and a device across both?

The answers usually show whether you need NAC first (lots of unmanaged devices on site), ZTNA first (mostly remote users), or a joined-up design such as on-premises ZTNA enforcement with NAC context.

How Forever Systems helps

We can look at what NAC you have today, which devices and users it covers, and where ZTNA or on-premises zero trust enforcement would close the gaps, then propose a phased design. Scope is confirmed at quote; ask us for a quote for any licences. Contact us to talk it through.