802.1X & NAC Complete Guide: Cisco ISE Lab Tutorials

802.1X is the IEEE standard for port-based network access control: the gatekeeper that decides whether a device gets on your network before a single user frame passes through. Combined with Cisco ISE as the policy server and a supplicant on the endpoint, it lets you enforce who and what connects to every wired port and wireless SSID, at scale, with central policy.

This is the cluster overview for the full PingLabz 802.1X and Cisco ISE series: 31 articles covering fundamentals, EAP methods, switch configuration, host modes, dynamic VLANs, dACLs, troubleshooting, and enterprise rollout strategy. We will work through what 802.1X actually does, the three roles in the protocol, the EAP methods you need to choose between, and a minimum-viable IOS XE + ISE configuration, with links into the deeper articles where you need them.

What 802.1X Solves

Without 802.1X, any device that plugs into an Ethernet port or connects to your Wi-Fi gets Layer 2 access immediately. The only authentication that exists is whatever lives in firewalls and applications above. That model worked when networks were physically constrained (only employees could reach the cables). It does not work in 2026 when conference rooms have wall jacks, BYOD is universal, contractors come and go, and IoT devices outnumber humans.

802.1X moves authentication down to the port. A device cannot send any non-EAPOL traffic until it has been identified, authenticated, and authorized. The port enforcement is hardware-level: the switch's data-plane drops frames from unauthorized supplicants before they reach the network.

The three things 802.1X gives you in production:

Identity-based access. Users authenticate with credentials, certificates, or both. Devices authenticate with MAC addresses (MAB) or certificates. The same port enforces different policies based on who connected.
Dynamic policy. ISE can return a VLAN, an ACL, an SGT, or a redirect URL based on attributes (group membership, posture, device type, time of day). The same physical port becomes guest, employee, or quarantine on demand.
Zero-trust foundation. Together with TrustSec/SGTs, 802.1X is how Cisco's macro-segmentation story works. Every flow has an identity attached.

The intro is in What Is 802.1X? Port-Based Network Access Control Explained.

The Three Components: Supplicant, Authenticator, Authentication Server

Role	What it is	What it does	Examples
Supplicant	The endpoint requesting access	Provides credentials/certs to the authenticator	Windows native, NAM, macOS, Linux wpa_supplicant, IP phones, printers
Authenticator	The network access device	Enforces port state; relays EAP between supplicant and AAA server via RADIUS	Cisco Catalyst switch, C9800 wireless controller, ISR/ASR
Authentication Server	The AAA / RADIUS server	Evaluates credentials against identity stores; returns Accept/Reject + attributes	Cisco ISE, FreeRADIUS, Microsoft NPS, Aruba ClearPass

The protocol between supplicant and authenticator is EAPOL (EAP over LAN, Ethertype 0x888E for wired). Between authenticator and AAA server it is RADIUS (UDP 1812 for auth, 1813 for accounting). The switch is the bridge that translates between the two. 802.1X Components Explained walks the architecture.

The Authentication Flow, Step by Step

Port is in the unauthorized state. Only EAPOL frames pass.
Switch sends EAPOL-Identity-Request, OR supplicant sends EAPOL-Start.
Supplicant responds with EAPOL-Identity-Response (the username).
Switch wraps the response in a RADIUS Access-Request and sends it to ISE.
ISE selects an EAP method based on policy and starts the EAP exchange (PEAP, EAP-TLS, etc.).
Switch tunnels EAP-Request/Response messages between supplicant and ISE for the entire EAP conversation. The switch does not decrypt or inspect anything inside.
ISE evaluates final credentials, applies authorization policy, and returns a RADIUS Access-Accept (with optional VLAN, dACL, SGT, URL-Redirect) or Access-Reject.
Switch transitions the port to authorized state and applies the returned attributes. Data traffic now flows.

The full flow with packet captures is in 802.1X Authentication Flow Step by Step: From EAPOL Start to RADIUS Accept. The packet-level EAPOL detail is in EAPOL Explained: How 802.1X Traffic Moves Over the Wire, and RADIUS specifics in Understanding RADIUS in 802.1X Authentication.

What those eight steps actually look like on the wire is illuminating. Turn on debug dot1x events and debug radius authentication on the switch, plug a properly-configured PEAP supplicant into the port, and you get this:

! Documented EAP-PEAP/MSCHAPv2 successful auth (Cisco IOS XE debug output)
*Apr 11 13:00:01.123: dot1x-ev:[Gi0/1] Received EAPOL pkt (EAPOL_START)
*Apr 11 13:00:01.124: dot1x-ev:[Gi0/1] Sending EAPOL packet (EAP_REQ/Identity)
*Apr 11 13:00:01.156: dot1x-ev:[Gi0/1] Received EAPOL pkt (EAP_RESP/Identity, length=21)
*Apr 11 13:00:01.157: RADIUS: Send Access-Request to 10.20.0.20:1812 id 1645/12
*Apr 11 13:00:01.160: RADIUS: Received from id 1645/12 10.20.0.20:1812, Access-Challenge
*Apr 11 13:00:01.161: dot1x-ev:[Gi0/1] Sending EAPOL packet (EAP_REQ/PEAP)
*Apr 11 13:00:01.190: dot1x-ev:[Gi0/1] Received EAPOL pkt (EAP_RESP/PEAP)
*Apr 11 13:00:01.220: RADIUS: Send Access-Request to 10.20.0.20:1812 id 1645/13
*Apr 11 13:00:01.225: RADIUS: Received from id 1645/13 10.20.0.20:1812, Access-Challenge
   (PEAP TLS tunnel established, MSCHAPv2 inner exchange follows)
*Apr 11 13:00:01.310: RADIUS: Send Access-Request to 10.20.0.20:1812 id 1645/16
*Apr 11 13:00:01.315: RADIUS: Received from id 1645/16 10.20.0.20:1812, Access-Accept
*Apr 11 13:00:01.316: dot1x-ev:[Gi0/1] Sending EAPOL packet (EAP_SUCCESS)
*Apr 11 13:00:01.317: %AUTHMGR-5-START: Starting 'dot1x' for client (aabb.cc00.6400) on Interface Gi0/1
*Apr 11 13:00:01.318: %DOT1X-5-SUCCESS: Authentication successful for client (aabb.cc00.6400) on Interface Gi0/1
*Apr 11 13:00:01.320: %AUTHMGR-5-SUCCESS: Authorization succeeded for client (aabb.cc00.6400) on Interface Gi0/1

Notice that the switch sees the entire conversation but understands none of it. The Access-Request / Access-Challenge ping-pong between switch and RADIUS is opaque to the switch: each EAPOL frame from the supplicant gets wrapped, forwarded to RADIUS in an EAP-Message attribute, and the RADIUS response is unwrapped and forwarded back as EAPOL. Only the final Access-Accept tells the switch what to do, by which time the supplicant and RADIUS have already proven the user's identity inside the TLS tunnel that the switch could not see into. This is by design - the authenticator is deliberately a dumb relay so that adding new EAP methods does not require switch firmware updates.

EAP Methods: PEAP, EAP-TLS, EAP-FAST, EAP-TTLS

EAP is a framework, not a protocol. Inside the EAP wrapper, you pick a specific method. The choice is consequential and not as simple as "use the most secure one":

Method	Server cert?	Client cert?	Credentials	Best for
EAP-TLS	Yes	Yes	Mutual cert auth, no password	Highest security; corporate-managed devices with PKI
PEAP-MSCHAPv2	Yes	No	Username/password inside TLS tunnel	Most common in mixed environments; weakest of the modern methods
EAP-TTLS	Yes	No	Username/password (or other) inside TLS tunnel	Like PEAP but more flexible inner methods; less common in Cisco environments
EAP-FAST	Optional	Optional	PAC-based shared secret	Cisco-led, PAC provisioning is the operational headache
EAP-MD5	No	No	Plain MD5 challenge	Never. Deprecated.

The two real choices in 2026 are EAP-TLS (where you have the PKI in place) and PEAP-MSCHAPv2 (where you do not). EAP-TLS is genuinely more secure (no password material on the wire, even encrypted) but operationally heavier (you need a working enrollment story for every device). PEAP is the pragmatic default if your endpoints are domain-joined Windows machines. Detail in How EAP Works in 802.1X: EAP Methods Compared.

Cisco ISE: The Policy Engine

Cisco ISE (Identity Services Engine) is the AAA server for the Cisco ecosystem. You can run 802.1X with FreeRADIUS or Microsoft NPS, but ISE is what almost every Cisco-shop deployment uses because of its identity store integration (AD, LDAP, certificates, internal users), policy granularity, and TrustSec/SGT integration.

The ISE constructs you must understand:

Network Device. A switch or WLC registered with ISE, including the shared RADIUS secret.
Identity Store. Where ISE looks up usernames and certs. AD, internal users, certificate authentication profiles.
Policy Set. Conditions that select an authentication and authorization workflow.
Authentication Policy. "If MAB, use Internal Endpoints. If 802.1X, use Active Directory."
Authorization Policy. "If user is in Domain Users group AND device is compliant, return VLAN 10 + permit-all dACL."
Authorization Profile. The attribute bundle returned in the RADIUS Access-Accept (VLAN, dACL, SGT, URL).

The end-to-end walkthrough that brings the components together is in Introduction to Cisco ISE, and the full wired deployment guide in Cisco ISE 802.1x Wired Configuration: A Practical Step-by-Step Guide.

Minimum Viable Switch Configuration on IOS XE

The smallest possible 802.1X port configuration:

! Global
Switch(config)# aaa new-model
Switch(config)# aaa authentication dot1x default group radius
Switch(config)# aaa authorization network default group radius
Switch(config)# dot1x system-auth-control

Switch(config)# radius server ISE-PSN-01
Switch(config-radius-server)#  address ipv4 10.10.10.10 auth-port 1812 acct-port 1813
Switch(config-radius-server)#  key 7 [secret]

! Port
Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)#  switchport mode access
Switch(config-if)#  switchport access vlan 10
Switch(config-if)#  authentication port-control auto
Switch(config-if)#  authentication host-mode multi-domain
Switch(config-if)#  dot1x pae authenticator
Switch(config-if)#  mab
Switch(config-if)#  authentication order dot1x mab
Switch(config-if)#  authentication priority dot1x mab
Switch(config-if)#  spanning-tree portfast
Switch(config-if)#  spanning-tree bpduguard enable

This is the exact authenticator config running in the PingLabz 802.1X reference lab (an iosvl2 switch facing a wpa_supplicant Alpine host on Gi0/1 and a FreeRADIUS server on Gi0/0). Pulled live with show running-config:

! From the PingLabz lab (iosvl2 15.2 ADVENTERPRISEK9-M)
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
dot1x system-auth-control

radius server PINGLABZ-RAD
 address ipv4 10.20.0.20 auth-port 1812 acct-port 1813
 key PingLabzRadius!

interface GigabitEthernet0/1
 description To HOST1 supplicant
 switchport mode access
 authentication port-control auto
 authentication periodic
 authentication timer reauthenticate server
 mab
 dot1x pae authenticator
 dot1x timeout tx-period 10
 spanning-tree portfast

Three things to notice. First, port-control auto is what actually enables enforcement; without it the switch attempts authentication but never blocks. Second, mab falls back to MAC Authentication Bypass for devices without a supplicant (printers, IP cameras, IoT). Third, multi-domain host mode allows one voice device + one data device per port, which is the dominant pattern for modern enterprises.

Two quick checks confirm the global state is right before you touch a port:

SW1# show dot1x
Sysauthcontrol                  Enabled
Dot1x Protocol Version          3

SW1# show dot1x all summary
Interface       PAE     Client          Status
--------------------------------------------------------
Gi0/1           AUTH    none            UNAUTHORIZED

Sysauthcontrol Enabled is the global dot1x system-auth-control command confirmed loaded. The summary shows Gi0/1 in the UNAUTHORIZED state with no client, which is what every dot1x-configured port looks like before a supplicant has been seen. The status will flip to AUTHORIZED in the same column the instant authentication succeeds.

The single most useful per-session view (this is the illustrative output from an actual production-style authenticated session):

Switch# show authentication sessions interface Gi1/0/1 details

            Interface:  GigabitEthernet1/0/1
          MAC Address:  0050.b6c1.1a2b
         IPv4 Address:  10.10.10.55
            User-Name:  alice@example.com
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  multi-domain
     Oper control dir:  both
      Session timeout:  N/A
    Common Session ID:  0A0A0A1400000123ABCD1234
      Acct Session ID:  0x0000000A
               Handle:  0x12000123
       Current Policy:  POLICY_Gi1/0/1

Method status list:
       Method           State
       dot1x            Authc Success

And the RADIUS server side of the picture. show aaa servers is the first command to run when authentication is failing intermittently or universally - the counters tell you immediately whether the switch is even talking to RADIUS:

SW1# show aaa servers
RADIUS: id 1, priority 1, host 10.20.0.20, auth-port 1812, acct-port 1813
     State: current UP, duration 376s, previous duration 0s
     Dead: total time 0s, count 0
     Authen: request 4, timeouts 4, failover 0, retransmission 3
             Response: accept 0, reject 0, challenge 0
             Response: unexpected 0, server error 0, incorrect 0, time 0ms
             Transaction: success 0, failure 1
     Author: request 0, timeouts 0, failover 0, retransmission 0
             Response: accept 0, reject 0, challenge 0
     Account: request 0, timeouts 0, failover 0, retransmission 0
             Request: start 0, interim 0, stop 0

The pattern above (this is real output from the lab during a deliberately broken RADIUS state) is the canonical "RADIUS server unreachable" signature: State current UP but timeouts equal to request count and zero accepts, rejects, or challenges. State UP just means the switch has not yet dead-marked the server based on consecutive timeouts; it does not mean RADIUS is actually answering. A healthy RADIUS server shows accepts (and occasional rejects) climbing alongside requests, with timeouts at zero or near zero.

Per-feature deep dives in Basic 802.1X Port Configuration and Configuring Cisco ISE as a RADIUS Server for 802.1X.

Host Modes: How Many Devices Per Port?

Host mode	Behavior	Use for
single-host	Strictest. One MAC; second MAC errdisables the port.	High-security ports; lab/test only in most environments
multi-host	One MAC authenticates, all others piggyback (no per-MAC enforcement).	Avoid; gives up most of the point of 802.1X
multi-domain (MDA)	One voice device + one data device, separately authenticated.	Standard enterprise default with IP phones
multi-auth	Each MAC authenticated independently.	Conference rooms, hubs behind a port, virtualized hosts

Detail in 802.1X Authentication Host Modes.

Whichever host mode is in effect, the per-interface dot1x timers and limits are what govern how aggressively the port retries and times out. The PingLabz lab port (default settings except for an explicit dot1x timeout tx-period 10) reports:

SW1# show dot1x interface GigabitEthernet0/1 details
Dot1x Info for GigabitEthernet0/1
-----------------------------------
PAE                       = AUTHENTICATOR
QuietPeriod               = 60
ServerTimeout             = 0
SuppTimeout               = 30
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 10

Dot1x Authenticator Client List Empty

TxPeriod is the interval between EAP-Request/Identity frames the switch sends when no supplicant has replied yet. QuietPeriod is how long the port waits after a failed authentication before retrying. MaxReq caps the EAP-Request retries before the switch declares the supplicant absent and moves to MAB or the fallback action. Tune these in production, especially QuietPeriod, which is the difference between "snappy reconnect after a printer power-cycle" and "user blames you for the network being slow."

Dynamic VLANs, dACLs, and Other Authorization Goodies

The point of 802.1X is not just yes/no but what-policy. Five common authorization outcomes:

Dynamic VLAN assignment. ISE returns Tunnel-Type=VLAN, Tunnel-Medium-Type=802, Tunnel-Private-Group-ID=NN, and the switch puts the port into VLAN NN. Dynamic VLAN Assignment with 802.1X and Cisco ISE.
Downloadable ACLs (dACLs). ISE pushes a per-session ACL that the switch programs in hardware. Lets you express user-specific filtering without provisioning ACLs on every switch. Downloadable ACLs (dACLs) with Cisco ISE and 802.1X.
Guest VLAN / Auth-Fail VLAN / Critical VLAN. What happens when the supplicant fails (Auth-Fail VLAN), is absent (Guest VLAN), or RADIUS is unreachable (Critical VLAN). Guest VLAN, Auth-Fail VLAN, and Critical VLAN in 802.1X.
Web Authentication fallback. If 802.1X and MAB both fail, redirect to a captive portal. Common for guest scenarios. Web Authentication as a Fallback in 802.1X.
Change of Authorization (CoA). ISE can push a new policy mid-session without making the supplicant reauthenticate from scratch. Critical for posture remediation and re-evaluation. Change of Authorization (CoA) in 802.1X.

802.1X with IP Phones (Multi-Domain Authentication)

The IP phone use case is so common it has its own host mode. The phone authenticates first (often via certificate) and lands in the voice domain. The PC behind the phone authenticates separately and lands in the data domain. The switch enforces VLAN segregation between them. Configuration plus a real-world walkthrough in 802.1X with IP Phones.

Phased Deployment: Don't Turn 802.1X On in One Day

The single biggest lesson from production 802.1X deployments: roll out in phases. Going from "no 802.1X" to "closed mode everywhere" overnight will lock out half your users on day one and you will be reverting at 9 AM.

Mode	What it does	Use for
Monitor mode	Authenticates everyone, but allows access regardless of result. Logs to ISE.	Phase 1: discovery. Find all the unsupplicantable devices.
Low-impact mode	Pre-auth ACL allows DHCP/DNS/PXE/etc. Failed auth still gets limited access.	Phase 2: production rollout with a safety net.
Closed mode	No traffic until authenticated. Strictest.	Phase 3: target end-state for high-security segments.

Detail in Monitor Mode vs Low-Impact Mode vs Closed Mode and Phased 802.1X Deployment Strategy for Enterprise Networks.

RADIUS Resilience and Scale

If your single ISE PSN dies and Critical VLAN is not configured, your network goes dark. Two articles cover the production-grade design:

And for the macro-segmentation story (SGTs), Cisco TrustSec and SGTs.

Troubleshooting: When Authentication Fails

Universal first-step commands:

Switch# show authentication sessions interface Gi1/0/1 details
Switch# show aaa servers
Switch# debug radius authentication
Switch# debug dot1x events

The debug output for a real failed authentication (wrong password, RADIUS returns Access-Reject) looks like this. Notice how the RADIUS exchange completes - the server is reachable - but the final response is a reject rather than an accept:

! Documented EAP-PEAP failed auth (wrong password)
*Apr 11 13:05:14.001: dot1x-ev:[Gi0/1] Received EAPOL pkt (EAPOL_START)
*Apr 11 13:05:14.002: dot1x-ev:[Gi0/1] Sending EAPOL packet (EAP_REQ/Identity)
*Apr 11 13:05:14.040: dot1x-ev:[Gi0/1] Received EAPOL pkt (EAP_RESP/Identity, length=21)
*Apr 11 13:05:14.041: RADIUS: Send Access-Request to 10.20.0.20:1812 id 1645/22
*Apr 11 13:05:14.045: RADIUS: Received from id 1645/22 10.20.0.20:1812, Access-Challenge
*Apr 11 13:05:14.090: RADIUS: Send Access-Request to 10.20.0.20:1812 id 1645/24
*Apr 11 13:05:14.094: RADIUS: Received from id 1645/24 10.20.0.20:1812, Access-Reject
*Apr 11 13:05:14.095: dot1x-ev:[Gi0/1] Sending EAPOL packet (EAP_FAIL)
*Apr 11 13:05:14.096: %DOT1X-5-FAIL: Authentication failed for client (aabb.cc00.6400) on Interface Gi0/1
*Apr 11 13:05:14.098: %AUTHMGR-5-FAIL: Authorization failed or unapplied for client (aabb.cc00.6400) on Interface Gi0/1

Contrast with the empty-port case (real capture from the lab when a port has no supplicant on the other side at all):

SW1# show logging | include DOT1X
*May 11 13:59:40.859: dot1x-ev:[Gi0/1] No DOT1X subblock found for port down
*May 11 13:59:41.273: dot1x-ev:DOT1X Supplicant not enabled on GigabitEthernet0/1

Two lines and silence. The switch is sending EAP-Request/Identity every TxPeriod seconds and getting nothing back, so there is no debug output to print. This is what "client stuck Unauthorized" looks like 99% of the time: not a misconfigured RADIUS, not a wrong cert - a missing or misconfigured supplicant on the endpoint.

Symptom-to-cause translation:

Symptom	Likely cause	First check
`show aaa servers` shows timeouts equal to requests, zero accepts/rejects	RADIUS unreachable (routing, ACL, RADIUS daemon down, wrong port, wrong source interface)	Ping RADIUS from the switch sourced from the same SVI; check `ip radius source-interface`; check no ACL blocks UDP/1812
Requests have rejects but no accepts	Wrong shared secret, unknown user, or supplicant misconfigured (wrong EAP method, wrong identity)	Check `show aaa servers` reject count vs ISE auth log; verify shared secret on both sides; verify supplicant credentials
`show dot1x all summary` stays UNAUTHORIZED with no debug output	No supplicant on the endpoint, or supplicant disabled, or wrong EAPOL ethertype on a hop	Capture on the port; confirm EAPOL Ethertype 0x888E appearing from the supplicant side
Port flaps between AUTHORIZED and UNAUTHORIZED every few minutes	Reauth timer too aggressive, or session-timeout returned by RADIUS that the supplicant cannot meet	Check `authentication periodic` and `authentication timer reauthenticate`; review Session-Timeout AV-pair in Access-Accept
Authentication succeeds but the port is in the wrong VLAN	Dynamic VLAN attributes missing from Access-Accept, or VLAN does not exist on the switch	Check ISE authz profile (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID); `show vlan brief` for VLAN existence
One port works, the adjacent identical port does not	Per-port config drift, or the interface inherits from a different template	Diff `show run interface` for both; check `access-session inherit` if IBNS 2.0

The Full 802.1X Cluster, in Reading Order

Hands-on 802.1X - configure the authenticator

Configure the switch as 802.1X authenticator with port-control auto and dot1x pae authenticator. Real switch-side config + the show commands that matter. Plus seven other security labs in the cluster. Open the PingLabz CCNA Labs library.

Open the 802.1X lab

Frequently Asked Questions

What does 802.1X stand for?

802.1X is the IEEE standard number, not an acronym. The full name is "IEEE 802.1X-2020 Port-Based Network Access Control." It defines how an authenticator (switch or wireless access point) controls access to a network at the port level using EAP-based authentication.

What is the difference between 802.1X and Cisco ISE?

802.1X is the IEEE standard defining the protocol. Cisco ISE is a product that acts as the authentication server (the AAA/RADIUS endpoint) in an 802.1X deployment. You can run 802.1X with FreeRADIUS, NPS, or any RADIUS-speaking server; ISE provides Cisco-specific features (TrustSec/SGT, posture, dACLs, profiling).

What is MAB and when do I use it?

MAB (MAC Authentication Bypass) authenticates a device by its MAC address when no 802.1X supplicant is present. It is the fallback for printers, IP cameras, IoT, and anything else without an EAP supplicant. Configure 802.1X first, MAB second, in the authentication order. MAB Configuration has the syntax.

EAP-TLS vs PEAP, which one should I use?

EAP-TLS is more secure (mutual cert auth, no password material on the wire) but requires a working PKI for every endpoint. PEAP is operationally simpler (server cert + username/password) and works well with domain-joined Windows. Most enterprises use PEAP-MSCHAPv2 for Windows users and EAP-TLS for high-security devices and BYOD.

What ports does 802.1X / RADIUS use?

EAPOL uses Ethertype 0x888E directly on Layer 2 (no IP, no UDP). RADIUS auth between switch and ISE uses UDP 1812 (modern) or UDP 1645 (legacy). RADIUS accounting uses UDP 1813 (modern) or UDP 1646 (legacy).

What is monitor mode and why is it important?

Monitor mode is an 802.1X deployment mode where the switch authenticates every device but allows access regardless of result. It is the safe way to roll 802.1X out: you discover every printer, camera, and rogue device on your network without locking anyone out. Spend a couple of weeks in monitor mode before tightening to low-impact, then closed.

Key Takeaways

If you take one thing away from this guide, make it this: 802.1X is operationally complex but conceptually simple. Three roles (supplicant, authenticator, authentication server). Two protocols (EAPOL and RADIUS). One state machine on every port (unauthorized to authorized). Pick your EAP methods deliberately, deploy in phases, and configure Critical VLAN before you ever turn closed mode on. Bookmark this page, work through the cluster articles in order, and lab every change. By the time you finish you will be able to design a wired NAC rollout from scratch and troubleshoot one at 3 AM.

802.1X Complete Guide: Port-Based Network Access Control