Join our Newsletter — 33% off our NHI Course
Home› Guides› Network Access Control (NAC) Guide
Guide Network Security

Network Access Control (NAC) Guide

← All guides
By Lalit Choda, NHI Mgmt Group Updated 16 October 2026 15 min read
On this page

Most office networks still give a working connection to anything plugged into a wall port or joined to the corporate Wi-Fi, before anyone checks what the device is. Network access control (NAC) closes that gap by authenticating devices and users at the switch port or access point and deciding which segment, ACL or quarantine they land in. This guide covers IEEE 802.1X, EAP methods, RADIUS and its hardening, MAC Authentication Bypass for devices without supplicants, dynamic authorisation and Change of Authorization, guest access, posture checks and a phased rollout. It is written for network engineers, identity teams and security architects deploying or auditing wired and wireless NAC. Compliance-based access to applications is covered separately in the Device Trust and Posture Guide.

Key takeaways

  • 802.1X is the foundation, MAB is the exception. Certificate-based 802.1X authenticates the device cryptographically; MAC Authentication Bypass only checks a MAC address that Cisco's own guide says can be defeated by spoofing.
  • Use EAP-TLS and retire password-based methods. Microsoft recommends moving from PEAP-MSCHAPv2 to PEAP-TLS or EAP-TLS, and Credential Guard, enabled by default on eligible devices from Windows 11 22H2, blocks single sign-on for MS-CHAPv2.
  • Harden RADIUS itself. Blast-RADIUS (CVE-2024-3596) lets a man in the middle forge an Access-Accept for non-EAP methods; always send and require Message-Authenticator and move towards RADIUS over TLS.
  • Authorisation matters more than authentication. The value of NAC is placing each device into the right VLAN or ACL and changing it mid-session with RADIUS Change of Authorization (RFC 5176).
  • Roll out in monitor mode first. Logging every authentication without blocking builds the device inventory and MAB list you need before any port enforces.

How NAC works: 802.1X, EAP and RADIUS

IEEE 802.1X-2020, "Port-Based Network Access Control", lets an administrator restrict LAN ports "to secure communication between authenticated and authorized devices". It has three roles.

  • Supplicant: software on the device, such as the Windows Wired AutoConfig and WLAN AutoConfig services or wpa_supplicant on Linux. RFC 3748 calls this the EAP peer.
  • Authenticator: the switch or wireless access point, which RADIUS calls the network access server (NAS). Until authentication succeeds, the port passes only EAP over LAN (EAPOL, Ethertype 0x888E) frames. As a pass-through authenticator it does not "have to understand each authentication method" and relays EAP inside RADIUS.
  • Authentication server: a RADIUS server such as FreeRADIUS, Microsoft Network Policy Server (NPS) or a commercial NAC policy server. It runs the EAP method, checks the directory or certificate, and returns Access-Accept or Access-Reject with authorisation attributes.
ProtocolTransportPurposeStandard
EAPOLLayer 2, Ethertype 0x888ECarries EAP between supplicant and switch or APIEEE 802.1X-2020
EAPInside EAPOL or RADIUSFramework for authentication methodsRFC 3748
RADIUS authentication and accountingUDP 1812, UDP 1813Authenticator to server; session start, stop and interim recordsRFC 2865, RFC 2866
RADIUS dynamic authorisationUDP 3799Server-initiated CoA-Request (43) and Disconnect-Request (40)RFC 5176
RADIUS over TLS (RadSec)TCP 2083Mutually authenticated, encrypted RADIUSRFC 6614 (Experimental)
TACACS+TCP 49Administrator login and command authorisation on network devices, not endpoint NACRFC 8907

The same 802.1X standard underpins MACsec Key Agreement for IEEE 802.1AE link encryption, which is worth knowing when a site needs encrypted wired links as well as admission control.

Choosing EAP methods

MethodCredentialMain weaknessVerdict
EAP-TLS (RFC 5216, RFC 9190 for TLS 1.3)Client and server certificatesNeeds PKI and certificate lifecyclePreferred for managed devices
TEAPTunnel with machine and user credentials chainedNewer; supplicant and server support variesGood where both machine and user must be proven
PEAP-MSCHAPv2 and EAP-MSCHAPv2Domain passwordMicrosoft says MS-CHAPv2 endpoints are "subject to similar attacks as for NTLMv1"; credentials captured if the server certificate is not validatedRetire
EAP-TTLS with PAPPassword in a TLS tunnelCleartext password at the server; same certificate validation riskOnly for unmanaged or legacy cases
EAP-MD5Password hash challengeRFC 3748 lists no dictionary attack protection and no mutual authenticationDo not use
  • Validate the server: with any tunnelled method, the supplicant profile must pin the issuing CA and the expected RADIUS server name. If users can click through a certificate prompt, a rogue access point can collect their credentials.
  • EAP-TLS 1.3 improves privacy: RFC 9190 states "A client supporting TLS 1.3 MUST NOT send its username" in the clear, uses an anonymous outer identity such as @realm, and makes certificate revocation checking mandatory.
  • Machine versus user authentication: machine certificates let a Windows device reach domain controllers before logon; user authentication after logon can change the VLAN. Decide which one your policy keys on.

MAC Authentication Bypass and devices without supplicants

Printers, IP phones, cameras, badge readers, medical and building devices often cannot run 802.1X. MAB lets the switch learn the device's MAC address and send it to RADIUS as the username and password, with Service-Type set to 10 (Call-Check) so the server can tell MAB requests apart.

  • Timing: by default MAB starts after 802.1X times out. Cisco gives the formula (max-reauth-req + 1) x tx-period, which with defaults of 2 and 30 seconds is about 90 seconds. DHCP and PXE clients may give up first, so tune the timers or set the order so MAB runs before 802.1X on ports dedicated to such devices.
  • Spoofing: a MAC address is an identifier, not a credential. Give MAB devices a downloadable ACL that allows only what that device class needs (a printer reaching print servers, a camera reaching its recorder), never a full user VLAN.
  • Device profiling: NAC platforms classify devices from DHCP options, the OUI in the MAC address, CDP and LLDP, HTTP user agents and SNMP. Alert when a MAC registered as a printer suddenly behaves like a Windows laptop.
  • MAC database: Cisco recommends building the list before deployment from purchasing records, voice platforms and monitor-mode RADIUS logs. Assign an owner to every entry and expire entries not seen for 90 days.
  • Randomised MACs: phones and laptops now use private Wi-Fi addresses by default, which breaks MAC-based allow lists and guest registration. Use 802.1X or a portal for these, not MAB.

Authorisation: VLANs, ACLs and Change of Authorization

RFC 3580 defines how RADIUS assigns a VLAN after 802.1X: Tunnel-Type 13 (VLAN), Tunnel-Medium-Type 6 (802) and Tunnel-Private-Group-ID carrying the VLAN ID (1 to 4094). NAS-Port-Type distinguishes Ethernet (15) from 802.11 wireless (19), so one policy server can treat wired and wireless differently.

  • Dynamic VLAN or ACL: VLANs are coarse and require routing changes; downloadable or named ACLs (Filter-Id) enforce per-port policy without re-addressing the device. Many deployments use a VLAN per broad role and ACLs inside it.
  • Quarantine VLAN: place failed or non-compliant devices where they can reach only remediation services (patch, EDR, MDM enrolment, DNS, DHCP). Never make it a quiet route back to the user network.
  • Guest access: captive portal web authentication on a guest SSID or port, sponsor approval or self-registration with time limits, and internet-only routing.
  • BYOD: onboard personal devices through MDM enrolment or an onboarding portal that installs a per-device certificate, then place them in a BYOD role with internet and a short list of published applications, not the corporate VLAN.
  • Change of Authorization: RFC 5176 lets the server send a CoA-Request to UDP 3799 to change a live session, for example moving a device to quarantine when EDR raises an alert, or a Disconnect-Request to force re-authentication. Reauthentication can also be scheduled with Session-Timeout and Termination-Action RADIUS-Request (1).
  • Host modes: use single-host or multi-domain (one data and one voice device) on access ports. Multi-host mode authorises everything behind the first device and is how unmanaged hubs bypass NAC.
  • Port security: the older switch-local control limits the number of MAC addresses per port and can make learned addresses sticky. It stops casual hub use but not spoofing, and Cisco's MAB guide advises disabling it on ports that run MAB because the two features conflict.
  • First-hop protections: DHCP snooping, Dynamic ARP Inspection and IP Source Guard tie IP and MAC to the port. MITRE lists DHCP snooping and DAI against ARP cache poisoning (T1557.002).

Posture assessment and where it stops

Posture checks ask whether the device meets policy (patch level, disk encryption, EDR running) before or during access. RFC 5209 describes the Network Endpoint Assessment model of posture collectors on the endpoint and validators on the server, and names Trusted Computing Group's Trusted Network Connect, Microsoft's Network Access Protection and Cisco's Network Admission Control as earlier architectures.

  • Know the limits: RFC 5209 lists "Detecting or handling lying endpoints" as out of scope and notes that a compliant endpoint may still be vulnerable. A compromised device can report a healthy posture.
  • NAP is gone: Microsoft deprecated NAP, HRA and HCAP in Windows Server 2012 R2 and they are not available in Windows Server 2016 or later, so NPS alone provides no posture checks.
  • Agent versus agentless: persistent or dissolvable agents give rich posture data; agentless NAC relies on profiling, scanning and integrations with MDM and EDR consoles to pull compliance state. Agentless is easier to deploy and covers IoT, but its posture view is only as current as the integration.
  • NAC versus ZTNA: NAC controls admission to the local network; zero trust network access controls access to individual applications from anywhere. Most organisations need NAC for campus and branch ports, plus posture-aware application access for remote work. See the Conditional Access Guide.

Securing the RADIUS infrastructure

  • Blast-RADIUS: CVE-2024-3596 uses an MD5 chosen-prefix collision to forge "a valid protocol accept message in response to a failed authentication request". The researchers state: "Nearly all RADIUS/UDP implementations are vulnerable to our protocol attack when using non-EAP authentication methods." PAP is vulnerable by default; EAP is protected because it requires Message-Authenticator. Patch servers and network devices, then configure both sides to always send and require Message-Authenticator.
  • RADIUS over TLS: RFC 6614 carries RADIUS over TLS on TCP 2083 with mandatory mutual authentication. RFC 9765 (RADIUS/1.1) updates it to remove MD5. Use it across untrusted links, especially between sites and cloud-hosted NAC services.
  • Shared secrets: RFC 3580 recommends secrets of at least 16 octets and different secrets for 802.1X and PAP. Use a unique, random secret per network device, store them in a secrets manager, and rotate them when staff with access leave.
  • Dynamic authorisation sources: RFC 5176 requires the device to "silently discard" CoA and Disconnect packets from untrusted sources. Restrict UDP 3799 to the policy servers and add Event-Timestamp for replay protection.
  • Availability: run at least two RADIUS servers per site or region and configure a critical authentication VLAN for when all are unreachable. Note that the NPS role is not available on Windows Server Core.

Where identity fits

NAC is device identity at the network edge, and most of it rests on non-human credentials.

  • Machine certificates: EAP-TLS is only as strong as certificate issuance and revocation. Auto-enrol from a dedicated issuing CA, bind certificates to hardware where possible (TPM), and revoke on device retirement. See the Machine Identity, PKI and Certificate Lifecycle Guide.
  • Headless devices are identities too: every MAB entry is an unauthenticated non-human identity with network access. Give each an owner, a device class and a narrow policy. See the Device and IoT Identity Guide.
  • NAC service accounts and secrets: policy servers hold directory bind accounts, MDM and EDR API credentials and RADIUS shared secrets for every switch. Treat them as privileged and vault them. See the Service Account Security Guide.

Rolling out NAC in phases

  1. Inventory and prerequisites: confirm switch and AP firmware support 802.1X, MAB, CoA and downloadable ACLs; deploy redundant RADIUS servers; issue machine certificates; push supplicant profiles by Group Policy or MDM with server certificate validation pinned.
  2. Monitor mode: enable 802.1X and MAB on ports but permit traffic whether authentication passes or fails. Review RADIUS logs to find devices with no supplicant, wrong certificates or unknown MACs, and build the MAB database.
  3. Low-impact mode: apply a pre-authentication ACL that allows only DHCP, DNS, PXE and paths to remediation and domain controllers, then open full access on success. This is the first point where unauthenticated devices lose access.
  4. Closed mode by ring: enforce on one floor or site, then by building, with wireless often first because SSIDs are easier to change than wired ports. Keep voice VLAN and critical device ports for later rings.
  5. Add dynamic authorisation: introduce role-based VLANs or ACLs, quarantine, posture and CoA once basic enforcement is stable.
  6. Rollback: keep port configuration in templates so a site can return to monitor mode with one change, test the critical authentication VLAN by taking RADIUS offline in a lab, and give the service desk a documented way to whitelist a device temporarily with an expiry.

Choosing an approach

  • Wireless only: WPA2 or WPA3-Enterprise with EAP-TLS on corporate SSIDs and a separate guest SSID delivers most of the value at low cost, and is the right first step for small organisations.
  • Wired campus: worthwhile where public or semi-public spaces have live ports (reception, meeting rooms, factories, hospitals). T1200 Hardware Additions describes attackers plugging in devices such as a Raspberry Pi; MITRE's mitigation is "network access control policies, such as using device certificates and the 802.1x standard".
  • IoT-heavy estates: profiling and MAB with tight ACLs, plus segmentation of device classes, matter more than posture.
  • Large organisations: centralise policy, but place RADIUS close to sites or ensure WAN resilience, and integrate with MDM, EDR and the SIEM so CoA can act on threat signals.

Detection and measurement

  • Log sources: RADIUS authentication and accounting records, NPS events in the Windows Security log (6272 access granted, 6273 access denied), switch syslog for port authentication state, and DHCP logs for new MAC addresses, which MITRE lists as a detection signal for T1200.
  • Accounting: RADIUS accounting Start, Interim-Update and Stop records tie a MAC, IP address, user and switch port together for a time window, which is what incident responders need to find a device physically.
  • Alerts: repeated MAB attempts with changing MACs on one port, a known MAC appearing on two ports at once, a device class change for a known MAC, and CoA or Disconnect packets from unexpected sources.

Metrics:

  • Percentage of access ports and SSIDs in closed or low-impact mode.
  • Percentage of authentications using EAP-TLS versus MAB versus password methods.
  • Number of MAB entries without an owner or not seen in 90 days.
  • Unknown devices detected per week and median time to classify or block them.
  • Percentage of network devices sending and requiring Message-Authenticator, or using RADIUS over TLS.

Framework mapping

FrameworkReferenceRelevance
NIST SP 800-53 Rev. 5IA-3, IA-3(1), IA-3(4)Device identification and authentication; supplemental guidance names 802.1X with EAP and RADIUS with EAP-TLS
CIS Controls v8.113.9 (IG3); 1.1, 1.2Port-level access control "utilizes 802.1x, or similar network access control protocols"; asset inventory and handling unauthorised assets
ISO/IEC 27001:2022A.8.20, A.8.22, A.5.15Networks security, segregation of networks, access control
MITRE ATT&CKT1200 with M1035; T1557.002 with M1037Rogue hardware on the network; ARP poisoning countered by DHCP snooping and DAI

Common failure patterns

  • Monitor mode forever: the project logs everything and never enforces, so NAC appears in audit reports but blocks nothing.
  • MAB as the default path: laptops that fail 802.1X fall back to MAB and get full access, turning a spoofable MAC into the real control.
  • Unvalidated server certificates: supplicants that accept any RADIUS certificate hand PEAP-MSCHAPv2 credentials to rogue access points.
  • Fail-open without a plan: a RADIUS outage either blocks the whole site or, through a broad critical VLAN, quietly admits everything.
  • Static, shared RADIUS secrets: one short secret on every switch, unchanged for years, with RADIUS over UDP across the WAN and no Message-Authenticator.
  • Multi-host ports: a desk hub authorises the first device and every device behind it.

Practitioner checklist

  • Deploy redundant RADIUS servers with Blast-RADIUS patches and Message-Authenticator required both ways.
  • Issue machine certificates and move managed devices to EAP-TLS; retire PEAP-MSCHAPv2.
  • Pin the trusted CA and server name in every supplicant profile.
  • Build an owned, expiring MAB database and give each device class a narrow downloadable ACL.
  • Run monitor mode, then low-impact, then closed mode by site, with one-change rollback.
  • Define quarantine and guest networks that reach only remediation or the internet.
  • Restrict CoA (UDP 3799) to policy servers and use unique per-device shared secrets.
  • Enable DHCP snooping, Dynamic ARP Inspection and IP Source Guard on access switches.
  • Integrate NAC with MDM and EDR so threat signals trigger CoA.
  • Report the metrics above monthly until all in-scope ports enforce.

Standards and references

Related NHI Mgmt Group resources: Device Trust and Posture Guide · Device and IoT Identity Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Zero Trust Identity Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Written and reviewed by Lalit Choda, NHI Mgmt Group. Last updated 16 October 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org