Network Access Control (NAC) and 802.1X: Implementation Guide

IEEE 802.1X defines a port-based authentication framework with three roles:

• Supplicant -- the client device requesting network access (implemented in Windows, macOS, Linux via wpa_supplicant)
• Authenticator -- the network device enforcing access (managed switch, wireless AP, or VPN concentrator)
• Authentication Server (AS) -- the backend that validates credentials and returns an authorization decision (RADIUS server: Cisco ISE, FreeRADIUS, Aruba ClearPass, Forescout)

Authentication flow:

1. Device connects to a port or associates with an SSID
2. Authenticator places port in an unauthorized state -- only 802.1X EAP traffic is allowed
3. Supplicant sends an EAP-Start or the authenticator sends an EAP-Request/Identity
4. Supplicant provides identity and credentials via EAP
5. Authenticator encapsulates EAP in RADIUS and forwards to Authentication Server
6. Authentication Server validates credentials and returns RADIUS Access-Accept or Access-Reject
7. On Accept, the authenticator moves the port to authorized state; optionally assigns a VLAN via RADIUS attributes

RADIUS attributes used for authorization:

Fallback states: Define behavior for hosts that cannot run a supplicant (printers, IoT, legacy) via MAC Authentication Bypass (MAB) or a guest VLAN.

The EAP method determines what credentials the supplicant presents and how they are protected. This is the most consequential security decision in NAC design.

EAP method comparison:

EAP-TLS: the gold standard

EAP-TLS provides mutual authentication via X.509 certificates. The RADIUS server presents a server certificate; the client presents a client certificate issued by your PKI. Neither side trusts the other without a valid certificate from a trusted CA.

Advantages:

• No passwords to phish or brute-force
• Client certificate is bound to the device (machine certificate) or user (user certificate) or both
• Immune to credential stuffing and PEAP downgrade attacks

Disadvantages:

• Requires a PKI (internal CA or cloud PKI like Smallstep, EJBCA, AWS Private CA)
• Certificate lifecycle management adds operational overhead
• Initial deployment complexity is higher

PEAP/MSCHAPv2: the pragmatic choice

PEAP wraps MSCHAPv2 in a TLS tunnel, protecting credentials in transit. It is the most widely deployed EAP method because it works with Active Directory credentials without a PKI.

Critical PEAP security requirement: Supplicants must be configured to validate the RADIUS server certificate. Without this, an attacker with a rogue access point running FreeRADIUS can impersonate your RADIUS server and capture MSCHAPv2 challenge-response pairs, which are offline-crackable with Hashcat.

Enforce in Windows via Group Policy:

Computer Configuration > Windows Settings > Security Settings >
Wired Network (IEEE 802.3) Policies > [Policy Name] >
Security > Settings > IEEE 802.1X > Properties >
EAP Type: Protected EAP > Properties >
Validate server certificate: Enabled
Connect to these servers: radius.corp.example.com
Trusted Root Certificate Authorities: [Your Internal CA]

Recommended approach by org maturity:

• High maturity: EAP-TLS for managed devices (machine certs from internal PKI); MAB for IoT with device profiling
• Medium maturity: PEAP/MSCHAPv2 with certificate validation enforced; migrate to EAP-TLS over 18-24 months
• Starting out: PEAP/MSCHAPv2 with certificate validation; block MAB fallback except for explicitly allow-listed MAC addresses

A single RADIUS server is a single point of failure for your entire network. Design for redundancy and performance from the start.

Deployment topology:

                        +------------------+
                        |  Load Balancer   |  (optional for large deployments)
                        +--------+---------+
                                 |
              +------------------+------------------+
              |                                     |
    +---------+---------+               +-----------+---------+
    | Primary RADIUS    |               | Secondary RADIUS    |
    | (Active/Active)   |               | (Active/Active)     |
    +-------------------+               +-------------------+
              |                                     |
              +------------------+------------------+
                                 |
                    +------------+------------+
                    |  Active Directory /     |
                    |  LDAP / PKI Backend     |
                    +------------------------+

Switch and AP configuration (Cisco IOS example):

aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius

radius server PRIMARY
 address ipv4 10.0.1.10 auth-port 1812 acct-port 1813
 key 7 [encrypted-key]
 timeout 5
 retransmit 3

radius server SECONDARY
 address ipv4 10.0.1.11 auth-port 1812 acct-port 1813
 key 7 [encrypted-key]

interface GigabitEthernet1/0/1
 switchport mode access
 dot1x port-control auto
 dot1x host-mode multi-auth       ! allows phone + PC on same port
 mab                               ! MAC Auth Bypass fallback
 authentication order dot1x mab
 authentication priority dot1x mab
 spanning-tree portfast

RADIUS timeout configuration: Network devices retry RADIUS requests when the primary does not respond. Set timeout 5 and retransmit 2 -- this means a maximum 15 seconds before failing over to secondary. Plan for the worst: if both RADIUS servers are unreachable, define the failure behavior (open fail = allow all, closed fail = block all). Use authentication event server dead action authorize vlan [restricted-vlan] to place hosts in a restricted VLAN during RADIUS outages rather than open or closed fail.

FreeRADIUS vs. commercial RADIUS:

Basic 802.1X authenticates the device or user but does not verify whether the device is compliant. Posture assessment adds a health check before granting full network access.

Posture checks (varies by platform):

Posture-based VLAN assignment:

Define network tiers based on compliance state:

RADIUS CoA (Change of Authorization):

CoA (RFC 5176) allows the RADIUS server to push authorization changes to an already-connected session without requiring re-authentication. Use cases:

• Posture scan completes post-connection -- server sends CoA to move device from remediation to production VLAN
• SIEM detects anomalous behavior -- server sends CoA Disconnect to terminate the session
• EDR flags the device as compromised -- automated response sends CoA to quarantine VLAN

! Cisco IOS: enable CoA receiver
aaa server radius dynamic-author
 client 10.0.1.10 server-key [key]
 port 3799
 auth-type all

Guest and employee-owned devices represent the highest risk NAC population -- they are not domain-joined, may not have your endpoint agent, and you cannot enforce posture controls on them.

Guest network architecture:

Guest Device
    |
    v
[Guest SSID / Port] --> Guest VLAN (30)
    |
    v
[Firewall: deny all RFC 1918, allow 0.0.0.0/0 port 80/443]
    |
    v
Internet (no internal access)

Guest network must be completely isolated from internal VLANs. Common gap: guest VLAN is routed to an internal segment "just for printing." Every internal resource reachable from the guest VLAN expands your attack surface.

Captive portal for guest authentication:

Guest users authenticate via a web portal (Cisco ISE Guest Portal, ClearPass Guest, or cloud-based like Cloudflare Access). Issue time-limited credentials (8-24 hours) with a sponsor approval workflow for extended access.

BYOD (employee personal devices):

For employee BYOD, use certificate-based onboarding:

1. Employee authenticates to the BYOD portal with corporate credentials
2. Portal provisions a short-lived client certificate to the device
3. Device uses the certificate for 802.1X -- access is granted to a restricted BYOD VLAN
4. BYOD VLAN provides access to approved SaaS apps and web browsing; no access to sensitive internal servers

This avoids requiring MDM enrollment on personal devices while still enforcing authentication.

MAB for IoT and unmanaged devices:

MAC Authentication Bypass allows devices without 802.1X supplicants (printers, cameras, medical devices) to authenticate via their MAC address. MAC addresses are trivially spoofable, so treat MAB as a convenience mechanism, not a security control:

• Maintain a strict allow-list of approved MAC addresses in your RADIUS database
• Assign MAB devices to a dedicated IoT VLAN with micro-segmentation
• Monitor for new MACs appearing on MAB ports -- any unknown MAC should trigger an alert
• Use NAC device profiling (DHCP fingerprinting, CDP/LLDP, HTTP User-Agent) to verify device type matches claimed identity

The biggest risk in NAC deployment is blocking legitimate access. A phased rollout with monitoring mode prevents this.

Phase 1: Monitor mode (0 enforcement)

Deploy 802.1X in monitor mode: all authentication attempts are logged but all devices are granted access regardless of authentication outcome. This gives you 4-8 weeks of data on:

• Which devices successfully authenticate vs. fail
• Which devices fall back to MAB
• Which ports see unexpected devices
• RADIUS infrastructure performance under production load

Cisco monitor mode: authentication open on port configuration

Phase 2: Low-impact enforcement

Enable enforcement on a pilot group of ports (conference rooms, guest areas, a single floor). Use open authentication with VLAN assignment -- authenticated devices get the production VLAN, unauthenticated devices get a restricted VLAN. Observe for 2-4 weeks.

Phase 3: Full enforcement

Roll out enforcement building by building or switch by switch. Maintain an exception process for devices that cannot run 802.1X -- they should be explicitly MAB allow-listed with documented business justification.

Common rollout issues and resolutions: