Network access control, or NAC, decides whether a device or user may connect to a network, and with what reach, based on credentials and, often, the device's condition. The common building blocks are IEEE 802.1X port authentication and a RADIUS server. NAC controls who gets in. It does not inspect what they do afterward.
How does NAC work in practice?
NIST SP 800-41 Rev. 1 describes NAC, also called network access protection, as a check performed on incoming connections. Access is allowed or refused based on the user's credentials and the results of health checks on the user's computer. The guide lists items such as whether antimalware and personal firewall software are current and correctly configured, and how long since the last malware scan.
On wired and wireless LANs the usual mechanism is IEEE 802.1X, which provides what RFC 3580 calls "network port authentication". It has three roles. The supplicant is the device asking for access. The authenticator is the switch or wireless access point that holds the port closed. The authentication server verifies the credentials the supplicant presents. In centrally managed setups that server speaks RADIUS, and the authenticator acts as a RADIUS client.
So the sequence is simple: a device connects, the port allows only authentication traffic, the device proves who it is, the RADIUS server answers yes or no, and the switch opens the port.
What can the answer include?
More than yes or no. RFC 3580 describes how a RADIUS server can tell the authenticator to place a user on a particular VLAN, using tunnel attributes, and notes that this lets a wireless host remain on the same VLAN as it moves. That is the basis of policies such as staff devices on one segment, guests on another, and failed health checks in a quarantine segment with access only to update servers.
Where does NAC fall short?
Four gaps come up often.
Devices that cannot run a supplicant. Printers, cameras and many IoT devices cannot do 802.1X, so sites fall back to identifying them by hardware address, which is a weak identity that can be copied. Put them in a restricted segment and treat their identity as low confidence.
One time checks. A device that passes at connection can be compromised an hour later. NAC is a gate at the door, so you still need monitoring inside.
Trust by location. NIST SP 800-207 on zero trust argues the opposite stance: network location alone does not imply trust, and access should be granted per session under dynamic policy that considers the state of the client identity and the asset. NAC can feed that model with identity and device state, but a flat network behind the gate undoes the benefit.
Operations. A RADIUS outage can lock out working devices. Plan redundancy and a safe failure mode before rollout.
A constructed example
A hospital like site has laptops, infusion pumps, badge readers and guest phones. Laptops use certificates and 802.1X and land on the staff VLAN if their patch and antimalware checks pass. Badge readers and pumps cannot authenticate that way, so they sit on dedicated VLANs by port, with rules allowing only the controllers they talk to. Guests get an isolated network. The security team learns the most from the first month's list of devices nobody knew existed.
How to check or apply this
- Inventory every wired port, wireless network and device type. You cannot control access for devices you have not counted.
- Decide the identity for each class: certificate, user credential or fixed port assignment for devices that cannot authenticate.
- Define segments and what each can reach, including a quarantine segment for failed checks.
- Start in monitor mode: log what would be denied, fix the surprises, then enforce.
- Build redundancy for the RADIUS service, and test what happens to ports when it is unreachable.
- Keep checking after admission. Pair NAC with logging and segment level rules so a compromised admitted device has limited reach.
- Review the exception list every quarter, since fallback rules tend to accumulate.
Quick check
Is NAC the same as a firewall?
No. NAC decides whether a device or user is admitted to the network. A firewall controls what traffic may pass between networks. NIST notes some firewalls include NAC style checks for remote users, so the functions can sit in one product.
Does 802.1X require RADIUS?
No. RFC 3580 notes 802.1X does not require a backend authentication server, though central management of authentication is why most deployments add one.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- RFC 3580, IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
