802.1X Port-Based Access Control

802.1X defines three logical entities in every authentication exchange:

• •Supplicant — the client device (or its 802.1X client software) requesting access to the network
• •Authenticator — the network access device: a switch port or wireless access point. It blocks all traffic except EAPOL (EAP over LAN) frames until authentication succeeds, then opens the port
• •Authentication Server — almost always a RADIUS server, which validates credentials (against Active Directory, an internal certificate authority, or another identity store) and tells the authenticator whether to open the port and with what attributes (e.g., which VLAN to assign)

The authenticator's port starts in an unauthorized state — only EAPOL traffic is permitted. The supplicant initiates (or the authenticator solicits it with an EAP-Request/Identity), and the EAP conversation is relayed by the authenticator between the supplicant and the RADIUS server: EAP frames on the LAN side (EAPOL), encapsulated in RADIUS attributes on the backend side.

The actual credential exchange depends on the EAP method negotiated. Once the RADIUS server returns an Access-Accept, the authenticator transitions the port to authorized and normal traffic flows — often into a specific VLAN or with a specific ACL applied, based on RADIUS attributes returned alongside the accept.

802.1X itself doesn't define how credentials are verified — that's delegated to an EAP method. The choice matters a great deal for security posture:

A representative Cisco IOS access-port configuration enforcing 802.1X, and the corresponding client entry on a FreeRADIUS server:

aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius

radius server RAD1
 address ipv4 10.10.1.5 auth-port 1812 acct-port 1813
 key <shared-secret>

dot1x system-auth-control

interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 20
 authentication port-control auto
 authentication order dot1x mab
 authentication priority dot1x mab
 dot1x pae authenticator
 dot1x timeout tx-period 5
 mab
 spanning-tree portfast

• •PEAP deployed without enforcing client-side server certificate validation — this allows an attacker to stand up a rogue AP/RADIUS and harvest MSCHAPv2 credential hashes, which are crackable offline
• •No fallback for devices that can't speak 802.1X (printers, IoT, IP phones) — this either breaks those devices or pressures admins into disabling enforcement entirely; MAC Authentication Bypass (MAB) with strict downstream ACLs is the standard compromise, not full exemption
• •Overly long supplicant timeout/retry settings causing painful boot-time delays, which trains users and helpdesk to see 802.1X as a nuisance
• •Treating VLAN assignment from RADIUS as sufficient segmentation on its own, without ACLs or further microsegmentation for high-risk device classes
• •No monitoring on repeated authentication failures, which is a signal of both misconfigured devices and active credential-guessing

• •Prefer EAP-TLS with a managed PKI where device/certificate lifecycle can be automated (SCEP, an internal CA integrated with MDM) — it removes password-based attack surface entirely
• •If using PEAP, pin and enforce server certificate validation on every supplicant profile pushed via MDM/GPO
• •Use MAB only for devices that genuinely cannot support 802.1X, and place them in a restricted VLAN with tight ACLs rather than trusting them at parity with authenticated devices
• •Enable RADIUS accounting so you have an audit trail of which device/user was on which port/VLAN at what time — essential for incident response
• •Stage rollouts in monitor mode (open authentication with logging, no enforcement) before flipping to closed/enforced mode, to surface devices that will break beforehand

Everything above covers 802.1X's original job — deciding whether a port opens. Since the 802.1X-2010 revision, the same authenticated session can also negotiate MACsec (IEEE 802.1AE), which encrypts and integrity-protects traffic at Layer 2 between the supplicant and the authenticator (or between two switches on a trunk). This is a distinct capability from port-control and is easy to miss because most 802.1X deployments only ever use the NAC half.

MACsec Key Agreement (MKA), defined in 802.1X-2010, runs after successful EAP authentication and derives the session keys MACsec uses to encrypt frames on the wire. Unlike an IPsec or WireGuard tunnel, MACsec operates below IP entirely — it protects the physical link itself, including from an attacker who taps the cable or an intermediate device in a shared-media segment, which higher-layer VPNs don't cover.

The practical case for turning it on: point-to-point links between switches in a shared or physically-exposed space (a colo cross-connect, a cable run through non-secured areas, a campus fiber link you don't fully control end-to-end) benefit from MACsec in a way that VLAN-only segmentation never addresses, since VLAN tags carry no confidentiality guarantee at all. The cost is that it requires MACsec-capable hardware on both ends of the link — not universally available on lower-end switches — and adds another key-management surface to operate correctly.