This is the single most common error in 802.1X questions. Students assume the switch "checks" credentials the way a login form does. The switch does no such thing. The 802.1X roles are precisely separated:
- Supplicant (client): provides credentials
- Authenticator (switch/AP): relays credentials; enforces the port state based on the server's decision
- Authentication server (RADIUS): validates credentials; has all the authentication intelligence
The switch has no knowledge of any password database. It does not know if "password123" is valid for user "jsmith". It forwards the credential exchange between the supplicant and the authentication server, and then acts on the server's reply (Access-Accept = open port; Access-Reject = keep port blocked).
Why this separation matters: One RADIUS server can authenticate users across thousands of switches and access points. When an employee's password changes or their account is disabled in Active Directory, this affects every switch and AP instantly — because no switch stores any credentials. The switch's job is enforcement; the server's job is intelligence.
The exam question pattern: "During 802.1X authentication, which component verifies the user's credentials against the corporate directory?" → Authentication server (RADIUS). "Which component blocks the network port until authentication succeeds?" → Authenticator (switch/AP). These are not the same component and they are not interchangeable.
Students frequently associate 802.1X and EAP exclusively with wireless security, likely because WPA2/WPA3-Enterprise (the enterprise Wi-Fi standard) uses 802.1X. This association causes students to miss questions where 802.1X is deployed on wired Ethernet switches.
The threat model for wired ports:
- An organization may have hundreds of active Ethernet ports in conference rooms, hallways, lobbies, cafeterias, and publicly accessible areas
- Without 802.1X, any device physically plugged into these ports gets immediate network access — the physical cable is the only "security"
- An attacker, contractor, visitor, or disgruntled employee with brief physical access can plug in a device and get full internal network access in seconds
- With 802.1X on the switch port, the device gets no network access until it authenticates — physical connectivity is necessary but not sufficient
The exam question pattern: "An employee discovers that a contractor plugged an unknown device into a network jack in a conference room. The device received a DHCP address and began scanning internal systems. Which technology would have prevented this?" → 802.1X (port-based NAC) on the wired switch port. The question is about a wired switch port, not Wi-Fi — but the answer is still 802.1X.
The correct mental model: EAP/802.1X is a framework for access control at the point of network connection — whether that connection is wired Ethernet or wireless. The authenticator can be a wired switch or a wireless access point. The same three-component model (supplicant, authenticator, authentication server) applies in both cases.
The exam tests the distinction between EAP methods, particularly EAP-TLS vs. PEAP. Students confuse them because both use TLS. The critical difference is which side needs a certificate and what credential is used for authentication.
EAP-TLS — both sides have certificates:
- Client device presents a certificate issued by the organization's internal CA → proves this is an authorized device
- Authentication server presents a certificate → proves this is the real server (prevents rogue server attacks)
- No password is ever used or transmitted — certificate IS the credential
- Highest security: an attacker with stolen credentials cannot authenticate from an unauthorized device (no cert)
- Highest deployment cost: every device needs a cert from a PKI; you must operate an internal CA
PEAP — only the server has a certificate:
- Authentication server presents a certificate → client verifies the server is legitimate; creates TLS tunnel
- Client device has no certificate → identifies itself with username/password (MSCHAPv2) inside the TLS tunnel
- The password is protected by the TLS tunnel — not sent in plaintext
- More common: no client certs required; natively supported by Windows, macOS, iOS, Android
- Trade-off: stolen credentials authenticate from any device — device identity is not separately verified
The exam question pattern: "An organization needs to ensure that only organization-issued devices, not user-owned devices, can authenticate — even with valid credentials. Which EAP method meets this requirement?" → EAP-TLS (requires a device certificate that only org-issued devices have). "Which EAP method requires a PKI with certificates provisioned on every client device?" → EAP-TLS. "Which enterprise EAP method is natively supported by all major operating systems and requires no client-side certificate infrastructure?" → PEAP.
Students learn that RADIUS returns Access-Accept or Access-Reject and stop there. The exam tests the broader RADIUS AAA model (Authentication, Authorization, Accounting) and the specific capability to return VLAN assignments with Access-Accept.
The three functions of RADIUS in 802.1X:
- Authentication: Is this identity valid? Validates credentials against Active Directory or the RADIUS database. Returns Access-Accept (valid) or Access-Reject (invalid).
- Authorization: What should this device be allowed to access? The Access-Accept message can carry attributes that tell the switch which VLAN to assign the device to, which ACL to apply, what bandwidth limits to enforce. The VLAN assignment is based on user identity or group membership. An employee on the "Staff" AD group → VLAN 10 (staff). A contractor → VLAN 30 (restricted). A guest (failed auth) → VLAN 99 (internet-only).
- Accounting: Log it. RADIUS accounting records: who connected (username), from where (switch IP, port ID), when they connected, how long the session lasted, how much data was transferred. This creates the audit trail required by compliance frameworks.
The exam question pattern: "An organization wants to automatically assign employees to the corporate VLAN and contractors to a restricted VLAN when they authenticate to the wired network — without manually configuring each switch port. Which capability enables this?" → RADIUS authorization returning dynamic VLAN assignments as part of the Access-Accept response.
The implication for incident response: RADIUS accounting logs record exactly which user was connected to which switch port at which time. If a security incident occurs, the RADIUS accounting log can tell investigators: "User jsmith connected to switch HQ-SW-04, port GigabitEthernet0/12 at 14:33, disconnected at 15:47." This is the accountability benefit that simple MAC-address-only access control cannot provide.
Scenario A: A hospital IT director is designing 802.1X port security for three network segments: (1) the clinical workstation network (nurses' stations, physician terminals accessing patient records), (2) the medical device network (infusion pumps, cardiac monitors, imaging equipment — mostly 5–10 year old embedded systems), and (3) the administrative network (HR, finance, scheduling — standard corporate laptops). For each segment, recommend: which EAP method (or alternative) to use, and justify the choice based on the security requirements and the device types involved.
Show Answer
1. Clinical workstation network — PEAP with MSCHAPv2:
Clinical workstations are typically hospital-managed Windows PCs used by nurses and physicians who authenticate with their AD credentials. PEAP integrates seamlessly with Active Directory via RADIUS/NPS, requires no client certificates (reducing PKI complexity), and is natively supported by Windows. Each clinician's identity is verified at each workstation login. The RADIUS server can return VLAN assignments based on role (physicians → clinical data VLAN, nurses → nursing VLAN) to enforce access segmentation. EAP-TLS would add device-level verification, which is ideal for the most sensitive access, but the PKI management complexity for potentially hundreds of workstations may exceed the hospital's IT resources. PEAP is the right balance of security and operational feasibility.
2. Medical device network — MAC Authentication Bypass (MAB):
Infusion pumps, cardiac monitors, and imaging equipment from older generations do not have 802.1X supplicant software. Firmware on these devices cannot be updated to add 802.1X support, and replacing all devices is cost-prohibitive and clinically disruptive. MAB is the only viable option: each device's MAC address is registered in the RADIUS server database, and ports assigned to these devices fall back to MAB when no EAP response arrives. The critical mitigation: place all MAB devices on a dedicated, heavily restricted VLAN with firewall rules limiting connectivity to only the specific clinical systems they need (e.g., the imaging server, the nursing station app, the infusion pump management server). MAB is weaker than EAP (MAC addresses can be spoofed), but the restricted VLAN limits what a spoofed device could reach. Physical security of medical device ports also reduces the spoofing risk.
3. Administrative network — EAP-TLS:
HR and finance systems contain the most sensitive non-clinical data (employee PII, payroll, contracts). The administrative network is the most valuable target for an insider threat or contractor with physical access. EAP-TLS is appropriate here because the hospital can issue machine certificates to all administrative laptops during IT provisioning. EAP-TLS ensures only hospital-issued administrative laptops can connect — a contractor's personal laptop or a rogue device cannot authenticate even with valid AD credentials. The hospital's IT team manages a manageable set of administrative workstations (not hundreds of clinical workstations), making PKI management feasible. The additional security assurance of device-level identity justifies the PKI overhead for this segment.
Scenario B: A security analyst discovers that a rogue Raspberry Pi was plugged into an Ethernet port under a conference table in a branch office. It obtained a DHCP address, connected to the internal network, and ran an ARP scan for 3 hours before being discovered. The organization uses 802.1X on the headquarters network but never deployed it to branch offices due to the cost of upgrading older branch switches. The CISO asks: "Why didn't 802.1X stop this?" Explain why the attack succeeded, what would have happened if 802.1X had been deployed, and what the practical deployment challenge is at the branch office.
Show Answer
Why the attack succeeded:
802.1X was not deployed at the branch office. The branch switches — older hardware — do not support 802.1X. When the Raspberry Pi was plugged in, the switch had no mechanism to challenge it for credentials. The switch simply forwarded traffic as soon as a link was established. The DHCP server (probably at headquarters, accessible via WAN) issued the Pi a valid internal IP address. The Pi was now a fully connected internal device, indistinguishable from any other on the network. Physical access to the conference room was the only barrier — and conference rooms are accessible to many people, including visitors, vendors, and cleaning staff.
What would have happened with 802.1X deployed:
If the branch switch supported 802.1X, the switch would have immediately sent an EAP-Request/Identity to the Pi when it connected. The Pi (running a generic Raspbian OS without 802.1X supplicant configuration) would not respond with valid credentials. After the authentication timeout, the switch would either: (a) keep the port blocked entirely — the Pi gets no network access at all, or (b) place the port in a Guest VLAN — the Pi gets internet access but no access to internal systems. The ARP scan would have reached only other Guest VLAN devices, not the internal network. The attack would have been stopped at the point of connection.
The practical deployment challenge:
802.1X requires switch hardware support. Older switches (common in branch offices that received the organization's hand-me-down equipment after headquarters upgrades) may not support 802.1X at all, or may support it only in a limited, non-standard way. Upgrading branch office switches to 802.1X-capable hardware requires capital expenditure and a deployment project for every branch location. This is the real-world deployment challenge: organizations often deploy 802.1X at headquarters first (where the equipment is newest and the IT team is largest) and delay branch rollout due to cost and logistics. This creates exactly the disparity seen here — headquarters is protected; branches are not.
Scenario C: A mid-size insurance company deploys 802.1X with PEAP across its entire wired and wireless network. Three weeks after deployment, the help desk receives 200 calls in one morning: employees cannot connect to the network from their laptops. The RADIUS server shows zero authentication attempts in the last 45 minutes. Wireless works for some employees but not others. Which failure is most likely, and how should the IT team verify and resolve it?
Show Answer
Most likely failure: RADIUS server outage or network path to RADIUS server down.
The key symptom is that the RADIUS server shows zero authentication attempts in 45 minutes — not failed attempts, but zero attempts. This means the authenticators (switches and APs) are not reaching the RADIUS server at all. The switches and APs are either: (a) configured with the wrong RADIUS server IP or shared secret (less likely — this would have failed from day one), or (b) the RADIUS server is down or unreachable — the network path between the branch locations and the RADIUS server is broken.
Why wireless works for some: Wireless devices that were already authenticated before the RADIUS server went down may have cached or extended their session (depending on reauthentication interval configuration). Devices that are trying to connect for the first time or reauthenticate cannot reach the RADIUS server, so authentication fails and the port stays blocked. Devices with shorter reauthentication timers have already been kicked off; devices with longer timers are still connected on their existing session.
Verification steps:
- Check the RADIUS server itself — is the service running? Is the server up? Check the RADIUS server's own logs for any error messages.
- Test connectivity from an authenticator (switch) to the RADIUS server: can the switch reach the RADIUS server's IP via ping? Is there a firewall rule blocking UDP 1812 (RADIUS authentication) or UDP 1813 (RADIUS accounting)?
- Check if a network change was made in the last 45 minutes: router change, firewall rule update, VLAN modification that broke the path from switches to the RADIUS server.
- Check if the RADIUS server's IP address changed (DHCP lease expiry? Server migration?) and whether the switch configurations still point to the correct IP.
Resolution and prevention: Restore the RADIUS server or the network path to it. For prevention: deploy a secondary RADIUS server (hot standby or active-active pair) so that authenticators have a failover if the primary server is unavailable. Configure authenticators with both primary and secondary RADIUS server addresses. Consider deploying a local RADIUS server at large branch offices so that branch authentication does not depend on WAN connectivity to headquarters.