NAC vs ZTNA: What Actually Differs, and Which One You Need

Network Access Control decides whether a device may join a network. Zero Trust Network Access decides whether an identity may reach an application. NAC operates at Layers 2 and 3, at the switch port. ZTNA operates at Layers 4 to 7, at the application. One controls the door to the building; the other controls the door to each room.

That distinction is clean enough to fit in a search result, and it is where most articles stop. It does not tell you which one to buy, and for a mid-market team with one network engineer, that is the only question that matters. So the rest of this piece is the decision: eight scenarios, what each technology genuinely cannot see, and what running both actually costs.

What NAC does, precisely

NAC validates the identity and security baseline of a hardware station before it is allowed to move frames across an access switch or wireless access point. The governing standard is IEEE Std 802.1X-2020, and it defines three roles: the supplicant (client software on the endpoint), the authenticator (the switch port or access point) and the authentication server (usually RADIUS under RFC 2865).

The mechanism is worth understanding because it explains most of NAC’s operational pain. The switch port maintains two logical channels. The uncontrolled port passes only EAPOL traffic, the protocol used for authentication itself. The controlled port stays blocked to everything else until authentication succeeds. On success, the RADIUS server returns an Access-Accept carrying vendor-specific attributes, and the switch moves the controlled port to authorised, assigns a dynamic VLAN, or installs a downloadable ACL.

Two secondary mechanisms handle what 802.1X cannot. MAC Authentication Bypass captures the source MAC address of a device that never answers the EAPOL identity request and submits it to RADIUS as a credential. Agentless profiling reads DHCP option strings, HTTP user-agent strings, ARP traffic and LLDP or CDP frames to classify hardware without any software on it. Both exist because printers and cameras cannot run supplicants, and both are weaker than certificate-based authentication by design.

What ZTNA does, precisely

ZTNA starts from the position that physical network presence conveys no trust at all. The authoritative definitions are NIST Special Publication 800-207 and the CISA Zero Trust Maturity Model version 2.0, and both split the architecture into two planes. The control plane holds the Policy Engine, which computes access decisions from enterprise policy and external signals, and the Policy Administrator, which instructs enforcement. The data plane holds the Policy Enforcement Point, the broker that terminates and mediates the actual session.

A session runs like this. The endpoint agent establishes an outbound-only mTLS control session to the broker, carrying credentials validated against an identity provider over SAML 2.0 or OpenID Connect, plus device posture telemetry. The Policy Engine evaluates context. Separately, a connector deployed next to the application holds its own outbound-only TLS connection to the broker. If policy permits, the broker stitches the two outbound tunnels together in memory, and the client reaches exactly one application socket — one fully qualified domain name, one port. Nothing adjacent, and nothing listening on the public internet.

The part that distinguishes it from a VPN is not the tunnel, it is tenets 6 and 7 of SP 800-207: verification continues through the session. If posture degrades or entitlements change, the broker revokes and tears down the data path mid-session rather than at the next re-authentication timer.

Side by side, including the blind spots

The row that matters is the one nobody prints. NAC’s authority ends the moment a device is admitted to a segment: it cannot read an encrypted payload, it does not restrict east-west traffic between two hosts on the same VLAN unless private VLANs or host firewalls are maintained meticulously, and it offers nothing whatsoever once the laptop is at home. ZTNA’s authority ends where agents cannot run: a badge reader, an HVAC controller, a PLC speaking Modbus or PROFINET, a camera. ZTNA is not weak against those devices. It is structurally blind to them.

Four situations where NAC is the right answer

Exposed physical ports in public or semi-public space. Academic buildings, bank branches, clinics, shops and warehouses have Ethernet drops that strangers can reach. 802.1X is the only standardised mechanism that keeps the controlled channel of that port shut until mutual authentication completes. Without it, anything plugged in gets an IP address and immediate ARP visibility into the broadcast domain. No application-layer broker can help, because the attack happens below the layer it operates at.

Fleets of headless hardware. Cameras, digital signage, barcode scanners, environmental sensors, IP telephony, medical monitors, industrial machinery. None of them run an agent or complete a browser-based login. NAC discovers them by DHCP and LLDP profiling and drops them into isolated VLANs, which is not elegant but is the only standardised option that exists.

Guest and BYOD onboarding at volume. You cannot require visitors, auditors and contractors to install corporate software or a root certificate on a personal phone. Captive portals, sponsor approval workflows and dynamic guest VLAN assignment give them internet access while keeping them off the management plane.

Frameworks that mandate port-level control. Defence networks, payment zones under PCI DSS physical access controls and industrial automation environments under IEC 62443 specify restrictions on physical attachment to the transmission medium. An auditor testing a control that requires cryptographic link-layer authorisation cannot be satisfied with an application proxy, however good the proxy is.

Four situations where ZTNA is the right answer

Remote and hybrid staff. Users on home broadband never touch the corporate LAN, so NAC has no enforcement point. Routing them through a VPN concentrator instead creates a bandwidth bottleneck and grants broad subnet admission, which is precisely the reach ransomware uses. ZTNA terminates at individual applications without placing the device on the internal network.

Third-party and contractor access. Consultants and suppliers need one ticketing system or one repository. Giving them VPN or on-premises Wi-Fi gives them a subnet. ZTNA scopes access to a single service FQDN and port, cloaks everything else, and removes the need to manage certificates on hardware you do not own.

Multi-cloud and SaaS-first estates. Workloads sit across on-premises virtualisation, AWS, Azure and Google Cloud. There is no shared Layer 2 fabric to apply a dynamic VLAN to, so NAC has nothing to enforce against. Connectors next to each workload give one identity-driven policy regardless of where the workload lives.

Mergers and cross-organisation work. Two networks that both use 10.0.0.0/8 cannot simply be joined. The conventional path is NAT rules, firewall peering and cross-domain directory trusts. ZTNA sidesteps network convergence entirely: connectors inside the acquired company let its staff reach parent applications on day one, federated through the identity provider, without routing a packet between the two networks. We covered the related pattern for administrative access in replacing legacy jump servers with ZTNA brokers.

Running both, and what it costs a small team

Plenty of vendors will tell you the answer is both. That is often correct and rarely costed. Here is the model from the research, for a representative organisation of 500 users and 250 headless endpoints.

These are modelled ranges for a mid-market estate, not quotations. The figure to argue about is not the licensing line, it is the FTE line. Running both requires coordination between a network engineer who owns switch policy and a security or identity person who owns application entitlement, and a team that has one of those people does not have two.

That constraint is why practitioners keep converging on the same design, usually called the coffee shop or clean-pipe model. The office LAN is treated as untrusted public transit, functionally a hotspot. NAC is stripped back to link-layer hygiene: 802.1X admits managed laptops to an internet-only VLAN with private VLAN rules that block client-to-client traffic, guests go to a captive portal that routes straight out, and headless hardware is profiled into micro-segmented VLANs governed by switch ACLs. Nothing on the switch fabric routes to a server subnet. Every application transaction, from headquarters or from home, goes through the ZTNA broker.

The elegance of that split is that the two policy sets cannot collide, because they govern different things: NAC governs link admittance, ZTNA governs application flow. Compare that with a dual deployment where the campus switch is enforcing dynamic VLAN isolation while a broker simultaneously tries to build Layer 7 tunnels across it, and you have two systems with an opinion about the same packet. The related move from static VLANs to policy-based separation is covered in our guide to identity-based isolation.

One terminology note, because it will come up in a vendor meeting. Several established NAC providers now market 802.1X RADIUS platforms as “Zero Trust NAC”. Under NIST SP 800-207, placing an endpoint on a broad subnet or VLAN confers implicit network-level trust, which is the thing zero trust is defined against. The products are not worse for it, but the label does not mean what the standard means, and it is worth asking which definition a vendor is using.

What NIS2, DORA and CyFun actually ask for

European regulation is layer-agnostic. It specifies outcomes, and both technologies can evidence parts of the same control.

The practical reading for a mid-market entity: ZTNA reaches evidence faster and with less engineering, because the logging is application-level and centralised by default. NAC is the only thing that satisfies controls written about physical attachment. If your scope includes offices with reachable network ports, you will need something at the link layer regardless of how good your application brokering is. Device health as an access signal is covered separately in our device posture guide for NIS2, and the identity side in conditional access policies for hybrid teams.

The case that the question itself is wrong

A network architect would say this comparison is malformed, and the objection is strong enough that it should be stated in full rather than answered around.

It is a category error. NAC controls whether a switch will process signals from a connecting endpoint. ZTNA mediates payload sessions across an IP network that already works. ZTNA cannot function without the physical and routing layer that NAC protects. Saying one replaces the other is like saying a TLS certificate replaces Ethernet cabling. Remove link-layer admission and the switching fabric is still exposed to DHCP starvation, ARP spoofing, rogue loops and broadcast flooding, all of which happen below anything a broker can observe.

Agent-based models have a hard architectural limit. In a building, laptops are a minority of network-attached devices. Cameras, badge readers, HVAC controls, printers, PLCs and telemetry systems have no interactive interface, no browser and no capacity to run an agent. A pure ZTNA architecture has no native answer for them and tends to treat them as an afterthought, which in practice means they sit unmanaged on an open network.

In-path brokering has a throughput cost. Terminating, inspecting and re-encrypting every session is fine for web applications, SaaS and SSH. It is not fine for multi-terabyte database replication, iSCSI and NFS storage traffic, compute clusters or local CAD rendering. Those depend on wire-rate hardware-accelerated Layer 3 switching. NAC authenticates the host once at line rate and then lets the ASIC do its job; a broker in that path is a bottleneck by construction.

All three are correct, and none of them make the question meaningless — they make it a question about scope rather than about replacement. The organisation that genuinely needs both is the one with campus buildings, an industrial or device-heavy estate, and high-throughput internal workloads. Plenty of mid-market organisations have none of those: a few offices, staff on laptops, applications in SaaS and a cloud tenancy, and internal traffic that is measured in megabits. For them the honest answer is not “both”, it is ZTNA for everything that matters plus switch-level hygiene for the ports, and the cost table above explains why calling that “NAC” would be an expensive misnomer. The architect’s objection is a warning against assuming your estate is the simple one, not an argument for buying two platforms by default.

How to decide

Answer three questions about your own estate and the shape of the answer appears.

Are there Ethernet ports a stranger can physically reach, in a reception area, a meeting room, a shop floor or a ward? If yes, you need link-layer admission control, and no amount of application brokering substitutes for it. Do you have a meaningful population of devices that cannot run an agent — cameras, controllers, machinery, medical equipment? If yes, you need profiling and segmentation for them specifically, and MAC Authentication Bypass on its own is not it, because a MAC address travels in cleartext in every frame and is trivially spoofed by anyone who can unplug a printer. Do your people and applications live largely outside the building? If yes, that is the majority of your risk and NAC does not reach it.

Most mid-market organisations answer yes to the third and partly to the first two. That combination points to a lean link layer and a serious application layer, not to two full platforms. If the application half of that is what you are working out, Jimber’s ZTNA and network isolation is built for exactly that shape of estate: EU-hosted, one platform rather than a stack, and no inbound listening ports to defend.

Book a demo if you want to see what the application layer looks like in practice, or talk to us if you would rather start by mapping which of your sites genuinely needs enforcement at the port.

Frequently asked questions

What is the fundamental difference between NAC and ZTNA?

NAC operates at Layers 2 and 3 and decides whether a device may join a network segment, enforcing at the switch port via 802.1X and RADIUS. ZTNA operates at Layers 4 to 7 and decides whether an identity may reach a specific application, brokering an encrypted tunnel without granting any network access.

Can ZTNA completely replace NAC?

For application access by managed laptops, effectively yes, because the network grants no application rights on its own. It cannot replace NAC where you must secure physically reachable Ethernet ports or manage headless devices that cannot run an agent. Those two requirements, not user access, are what keep NAC necessary.

How do IoT and agentless devices work under ZTNA?

They do not. Headless hardware such as IP cameras, HVAC sensors and PLCs cannot run agent software or complete a browser-based identity redirect, so a ZTNA broker cannot build a tunnel for them. These devices need NAC profiling and VLAN segmentation, or inline network isolation, rather than application brokering.

Is NAC part of a zero trust architecture?

It contributes to one without satisfying it. Under NIST SP 800-207, admitting a device to a broad VLAN confers implicit network-level trust, which contradicts the model. NAC is a valid link-layer control within a zero trust programme; several vendors market 802.1X platforms as “Zero Trust NAC”, which uses the term differently from the standard.

Why is 802.1X so difficult to implement and maintain?

It requires switch firmware, RADIUS, directory schemas, internal PKI and native client supplicants to stay aligned simultaneously. Common failures include newly imaged machines unable to reach the certificate authority through a closed port, Windows updates altering supplicant behaviour, and revocation checks failing because the port blocks external access before authentication.

Does ZTNA protect against physical Ethernet port tampering?

No. If an organisation drops link-layer controls entirely, an intruder can attach a device in an empty meeting room, obtain a DHCP address and run reconnaissance, ARP spoofing or denial-of-service against local switching infrastructure. All of that happens below the layer a ZTNA broker observes.

Is MAC Authentication Bypass safe for operational technology?

Not on its own. MAC addresses travel unencrypted in every Ethernet frame, so anyone with physical access can unplug a printer, spoof its address and inherit that device’s VLAN. MAB should always be paired with continuous profiling, switch-level access lists or automated port quarantine.

What is the coffee shop network model?

The office LAN is treated as untrusted public transit. Switch ports and Wi-Fi provide isolated internet access with client-to-client traffic blocked, and nothing routes to server subnets. All corporate application access runs through an always-on ZTNA broker, so the same policy applies whether the user is in the office or at home.

How does continuous verification differ between the two?

NAC evaluates posture mainly at connection time and re-checks on periodic re-authentication timers. ZTNA re-evaluates throughout the session: if device posture degrades or entitlements change, the broker revokes the token and tears down the data path immediately rather than at the next timer.

What happens to 802.1X if internet connectivity drops?

If the deployment depends on a cloud RADIUS service or cloud identity provider without a local survivability proxy, handshakes cannot complete during an outage. Devices connecting to a port or a wireless SSID are rejected and denied admission, which makes local fallback design a requirement rather than an optimisation.