802.1X Port-Based Authentication: Supplicant, Authenticator, and RADIUS

802.1X authenticates a device before it is allowed to pass traffic on a switch port or wireless network. Until authentication succeeds the port carries nothing but the authentication exchange itself, which means an unauthorized device plugged into a conference room jack reaches nothing at all. It is the foundation of network access control and a reliable exam topic.

The three roles

The supplicant is software on the connecting device that presents credentials. Every modern operating system includes one.

The authenticator is the switch or wireless access point controlling the port. It does not decide anything; it relays the conversation and enforces the verdict by opening or keeping the port closed.

The authentication server is a RADIUS server holding the policy and the credential store, usually backed by a directory. It makes the decision and returns it, optionally with attributes telling the authenticator which VLAN to assign or which access list to apply.

The separation matters: credentials never live on the switch, so policy is managed in one place across hundreds of access points and switches.

How the exchange runs

EAP carries the authentication, and it rides differently on each hop. Between supplicant and authenticator it is EAP over LAN (EAPOL) on the local link; between authenticator and server it is EAP encapsulated in RADIUS. The authenticator translates between the two without understanding the contents.

That layering is why 802.1X supports so many credential types — the switch is a relay, so adding a new EAP method only requires the endpoints to agree.

On success the server returns an accept, the port opens, and the client proceeds to normal operations such as obtaining an address by DHCP. That ordering trips people up in troubleshooting: a client that cannot get an address may be failing authentication rather than failing DHCP.

EAP methods worth knowing

EAP-TLS uses certificates on both sides. It is the strongest option — no password exists to phish, steal, or spray — and the most work, because it requires a certificate authority and a way to enrol and renew device certificates. Where a PKI exists, this is the answer.

PEAP builds a TLS tunnel authenticated by a server certificate, then passes username and password credentials inside it, usually with MSCHAPv2. Easy to deploy against an existing directory, and its weakness is the client: if the supplicant is not configured to validate the server certificate and pin the expected authority, an attacker can stand up a rogue access point, present any certificate, and collect the credentials. Validate the server certificate, or PEAP provides far less than it appears to.

EAP-TTLS is similar with more flexible inner methods. EAP-FAST uses a protected credential in place of a certificate. All of them share the same rule: the tunnel is only as good as the client's willingness to check who it is talking to.

Handling devices that cannot authenticate

Printers, cameras, badge readers, and industrial equipment often have no supplicant, and the fallbacks are where most real deployments get complicated.

MAC Authentication Bypass checks the device's hardware address against an allowlist. It is convenient and weak — MAC addresses are trivially spoofed, and one observed from a printer's label is enough — so treat it as inventory control rather than authentication, and put those devices on a restricted VLAN.

Guest and restricted VLANs place unauthenticated devices somewhere with internet access and nothing else. Web authentication redirects a browser to a portal for users without a configured supplicant.

Dynamic VLAN assignment is the feature that makes all this useful: the RADIUS server returns the VLAN with the accept, so a contractor's laptop, a corporate laptop, and a printer land in different segments from the same physical port. That is network access control doing real work rather than acting as a binary gate, and it is the practical on-ramp to threat scope reduction: identity decides which segment a device lands in, not which patch panel it was plugged into.

Deployment notes

Start in monitor mode, which authenticates and logs but does not enforce. It reveals every device that would have been blocked, and the list is always longer than expected. Move to enforcement once the exceptions are handled.

Plan for failure. If the RADIUS server is unreachable, the switch's configured behavior decides whether the network stays up, so deploy redundant servers and choose the failure mode deliberately. Remember that 802.1X authenticates at connection time on a wired port — a hub or an unmanaged switch behind an authenticated device can carry unauthenticated traffic unless multi-authentication mode is configured.

Feed authentication logs into your SIEM. Repeated failures on a port, a new device appearing in a restricted VLAN, or MAB used where certificate authentication is expected are all worth an alert.

Exam angles

Name the three roles and know that EAPOL runs supplicant to authenticator and RADIUS runs authenticator to server. Identify EAP-TLS as certificate-based and strongest, and PEAP as tunneled password authentication requiring server certificate validation. Know MAB as the fallback for devices without supplicants and that it is spoofable. Recognize dynamic VLAN assignment as the mechanism for role-based segmentation, and monitor mode as the safe rollout path.