802.1X Components Explained: Supplicant, Authenticator, and Authentication Server

The Three-Party Architecture

802.1X doesn't authenticate devices directly at the switch. It splits responsibility across three distinct roles, each with a specific job. Understanding these boundaries explains both how to configure the system and why failures happen where they do.

The architecture is defined in IEEE 802.1X-2010 and uses two separate protocols on two separate segments: EAPOL (EAP over LAN) between the supplicant and authenticator, and RADIUS between the authenticator and the authentication server. The authenticator sits in the middle, translating between these two protocols.

The Supplicant

The supplicant is the software on the endpoint that initiates and completes authentication. It presents identity and credentials, responds to EAP challenges, and drives the authentication state machine on the client side.

Windows Supplicant (Wired AutoConfig)

On Windows 10 and Windows 11, the built-in 802.1X supplicant is the Wired AutoConfig service (dot3svc). It must be running for 802.1X to function on wired connections.

Configuration path: Control Panel > Network and Internet > Network Connections > [Adapter] > Properties > Authentication

From there, you enable IEEE 802.1X authentication, select the EAP type (PEAP or Smart Card or other certificate for EAP-TLS), and configure the method-specific parameters — whether to validate the server certificate, which CA to trust, whether to use Windows logon credentials.

In enterprise deployments, this configuration is typically pushed via Group Policy rather than configured manually on each machine. The Group Policy path is:

Computer Configuration > Windows Settings > Security Settings > Wired Network (IEEE 802.3) Policies

Group Policy delivery matters because the supplicant must be configured before a user logs in for machine authentication to work. Machine authentication authenticates the computer account against Active Directory before any user is present — critical for scenarios like receiving Group Policy updates or running login scripts.

Cisco IP Phone 8800 Supplicant

The Cisco IP Phone 8800 series has a built-in 802.1X supplicant implemented in firmware. The phone supports EAP-MD5, EAP-TLS, and PEAP-MSCHAPv2 depending on firmware version. It's configured in CUCM (Cisco Unified Communications Manager) under the device's security profile.

The phone's identity in 802.1X is its device certificate (for EAP-TLS) or a configured username/password (for PEAP). In most deployments, Cisco IP Phones use either MAB (the switch recognizes the Cisco OUI in the MAC address and ISE maps it to a phone profile) or EAP-TLS with certificates provisioned through CUCM.

Phones also pass through PC port traffic — the laptop plugged into the phone's PC port has its own 802.1X authentication, independent of the phone's authentication. This is the multi-domain authentication model, covered in Article 17: 802.1X with IP Phones: Configuring Multi-Domain Authentication on Cisco IOS XE.

Non-802.1X Supplicants

Many devices — printers, IP cameras, building automation controllers, IoT sensors — have no 802.1X supplicant at all. For these, the fallback is MAC Authentication Bypass (MAB). The switch detects that no EAPOL is received, times out, and uses the device's MAC address as the authentication credential. ISE evaluates the MAC against its endpoint database and endpoint identity groups.

MAB is not as strong as 802.1X because MAC addresses can be spoofed. ISE profiling — identifying device type from DHCP fingerprint, HTTP User-Agent, and other signals — adds a layer of confidence by confirming that the device claiming to be a Cisco phone actually behaves like one. MAB configuration is covered in Article 12: MAC Authentication Bypass (MAB) Configuration on Cisco IOS XE and ISE.

The Authenticator

The authenticator is the network access device — in this lab, the Cisco Catalyst 9300 running IOS XE 17.9.x. It enforces the access decision but does not make it. Its jobs are:

1. Detect EAPOL frames from connected supplicants
2. Relay EAP messages between the supplicant and the authentication server
3. Enforce the port state (authorized or unauthorized) based on the authentication server's response
4. Apply policy attributes returned by the authentication server (VLAN, ACL, SGT)
5. Send RADIUS accounting to record session start, update, and stop events

IOS XE Port State Machine

Each 802.1X-enabled port on the Catalyst 9300 runs a state machine defined by the IEEE 802.1X standard. The relevant states from an operational standpoint:

UNAUTHORIZED — Initial state after link comes up. Port is blocked for all traffic except EAPOL frames (and any pre-authentication ACL traffic if using Low-Impact mode). The authenticator sends an EAPOL-Request/Identity to trigger the supplicant.

AUTHENTICATING — The supplicant has responded and EAP exchange is in progress. Traffic still blocked. The authenticator is forwarding EAP frames to the RADIUS server.

AUTHORIZED — Authentication succeeded. Port is open. Policy from the authentication server is applied. Traffic flows.

HELD — Authentication failed. Port stays blocked for the hold period (default 60 seconds on IOS XE) before retrying. Configurable with authentication timer restart on the interface.

In addition to these per-session states, each port has a PAE (Port Access Entity) state that reflects the authenticator's overall role on that port. On IOS XE, you verify port state with:

SW1# show dot1x all

Dot1x Info for GigabitEthernet1/0/1
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both
HostMode                  = MULTI_AUTH
ReAuthentication          = Disabled
ReAuthPeriod              = 3600 (Locally configured)
ReAuthAction              = Reauthenticate
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
MaxReq                    = 2
MaxAuthReq                = 2
TxPeriod                  = 30
RateLimitPeriod           = 0

IOS XE Authentication Manager

In IOS XE, 802.1X is managed by the Authentication Manager subsystem. Rather than configuring dot1x commands directly on every interface, the modern approach (introduced with IOS XE and recommended for all current deployments) uses policy maps applied to the interface through the Authentication Manager.

The Authentication Manager coordinates multiple authentication methods on the same port — 802.1X, MAB, and WebAuth — and determines the order, fallback behavior, and priority. This is what allows a port to try 802.1X first, fall back to MAB if no supplicant responds, and then optionally redirect to a web authentication portal if MAB also fails.

The full port configuration syntax for IOS XE 17.9.x is covered in Article 8: Basic 802.1X Port Configuration on Cisco IOS XE Switches.

What the Authenticator Does NOT Do

The authenticator does not inspect or validate credentials. It forwards EAP payloads it cannot read (they may be encrypted inside a TLS tunnel). It does not decide whether authentication succeeds — that is strictly the authentication server's role. It enforces the decision but doesn't make it.

This separation matters for troubleshooting: if authentication fails, the root cause is almost never the switch configuration (assuming the port is properly configured). It's either the supplicant, the RADIUS communication, or the authentication server policy. The switch is successfully relaying whatever is happening.

RADIUS Client Role

The authenticator is a RADIUS client. It has a shared secret with the RADIUS server, and it encapsulates EAP payloads inside RADIUS Access-Request packets. When ISE responds with Access-Accept, the switch reads the RADIUS attributes in the response and applies them:

• Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID — These three attributes together assign the VLAN. The switch moves the port to the specified VLAN.
• Filter-Id or Cisco-AVPair: ip:inacl — References a downloadable ACL name or defines an ACL inline.
• Cisco-AVPair: cts:security-group-tag — Assigns a Security Group Tag for TrustSec.

The switch applies these attributes immediately on receiving the Access-Accept. VLAN changes happen without port bounce in IOS XE (the port stays up; the VLAN membership changes dynamically).

The Authentication Server

The authentication server validates credentials, applies policy, and returns an access decision with policy attributes. In this lab — and in virtually every Cisco enterprise deployment — the authentication server is Cisco ISE 3.2.

Why Not Just Use a RADIUS Server?

A basic RADIUS server like FreeRADIUS or Microsoft NPS can authenticate 802.1X sessions against a user directory. But it can't do what ISE does:

• Profile devices based on network signals (DHCP, HTTP, SNMP) and return different policy for a corporate laptop vs. a personal phone
• Check endpoint posture (is the AV current? Is the disk encrypted?) before granting full access
• Dynamically change authorization mid-session using CoA (Change of Authorization)
• Provide sponsor-managed guest portals
• Correlate identity, device, posture, and location into a single policy decision
• Feed SGT assignments into TrustSec for policy enforcement throughout the network fabric

ISE is a purpose-built NAC platform. The policy model, integration points, and capabilities are covered in Article 6: Introduction to Cisco ISE: What It Is and Why It Matters for 802.1X.

ISE Policy Components

When the Catalyst 9300 sends a RADIUS Access-Request to ISE 3.2, ISE processes it through several policy layers:

Authentication Policy — Determines which identity store to query and which protocol to allow. Examples: "Use Active Directory for PEAP" or "Allow EAP-TLS with internal CA."

Authorization Policy — After identity is established, determines what access to grant. ISE evaluates conditions (identity group, endpoint group, device type, time of day, posture status) and returns a result (an Authorization Profile containing VLAN, dACL, SGT).

Policy Sets — In ISE 3.2, authentication and authorization policies are organized into Policy Sets. Each Policy Set matches on a network condition (typically the network device or network device group) and contains its own authentication and authorization sub-policies. This allows different policy logic for campus switches vs. VPN headends vs. wireless controllers — all in the same ISE deployment.

Navigation in ISE 3.2: Policy > Policy Sets

ISE as a RADIUS Server

ISE listens for RADIUS on UDP 1812 (authentication) and UDP 1813 (accounting). The Catalyst 9300 must be defined as a Network Device in ISE before it can submit RADIUS requests.

ISE Network Device definition path: Administration > Network Resources > Network Devices > Add

Required fields:

• Name (descriptive, e.g., SW-9300-01)
• IP Address or subnet (10.0.99.1 in this lab)
• RADIUS shared secret (ISEsecret123 in this lab — never use a simple secret in production)
• Device Type (used in policy conditions — e.g., "Cisco Catalyst" device type)
• Location (used in policy conditions — e.g., "Building-A")

The shared secret must match exactly between the switch's radius server configuration and ISE's network device definition. A mismatch produces RADIUS authentication failures with no useful error message from the switch — a common gotcha during initial setup.

ISE Identity Sources

ISE doesn't store passwords natively for most deployments. It queries external identity sources:

• Active Directory — The most common. ISE joins AD as a machine and can query user and computer accounts, group memberships, and machine certificates. For PEAP with MSCHAPv2, AD performs the actual password verification.
• LDAP — For non-AD environments (OpenLDAP, etc.)
• Internal Identity Store — ISE's built-in user and endpoint database. Useful for guest accounts and for MAB (MAC addresses stored as endpoints).
• Certificate Authority — For EAP-TLS, ISE validates client certificates against a trusted CA. The CA can be ISE's internal CA, Microsoft CA, or a third-party CA.

Identity source configuration in ISE 3.2: Administration > Identity Management > External Identity Sources

RADIUS Accounting

Beyond authentication, ISE receives RADIUS Accounting packets from the switch. These carry session information: when a session started, current statistics (bytes in/out), and when a session ended. ISE uses accounting data to populate its live sessions view and for audit logging.

ISE live sessions path: Operations > RADIUS > Live Sessions

This view shows every active authenticated session across all network devices — identity, endpoint MAC, IP, VLAN, assigned policy, session duration. Invaluable for real-time troubleshooting.

Change of Authorization (CoA)

One of ISE's most powerful features is CoA — the ability to push a policy change to an already-authenticated session without requiring re-authentication. The authenticator doesn't initiate CoA; ISE does. ISE sends a RADIUS CoA message (RFC 5176) to the switch, which then re-evaluates or terminates the session.

Common CoA use cases:

• Posture assessment completes after authentication: upgrade from limited to full access
• User is flagged (compromised credentials, policy violation): terminate session
• Device is newly profiled: re-authorize with correct policy for the identified device type

CoA requires the switch to be configured to accept CoA from ISE's IP address. This is covered in Article 19: Change of Authorization (CoA) in 802.1X: How It Works and How to Configure It.

How the Three Components Interact: The Authentication Exchange

Here is the sequence at a high level (detailed frame-by-frame analysis is in Article 7: 802.1X Authentication Flow Step by Step):

1. Supplicant sends EAPOL-Start or the authenticator sends EAPOL-Request/Identity after link comes up
2. Supplicant responds with EAPOL-Response/Identity containing its identity (username or MAC)
3. Authenticator wraps the identity in a RADIUS Access-Request and sends it to ISE
4. ISE and supplicant exchange EAP messages — relayed by the authenticator — to perform the credential verification (this may be multiple round-trips for PEAP or EAP-TLS)
5. ISE sends RADIUS Access-Accept (or Access-Reject) with policy attributes
6. Authenticator applies the policy and sends EAPOL-Success (or EAPOL-Failure) to the supplicant
7. Port transitions to authorized state; VLAN, dACL, SGT take effect

The two-segment, two-protocol design means failures can happen independently on either side. EAPOL issues are between switch and endpoint; RADIUS issues are between switch and ISE.

Verifying Component Status

On the Catalyst 9300, verify 802.1X authenticator status:

SW1# show authentication sessions interface GigabitEthernet1/0/1 details

            Interface:  GigabitEthernet1/0/1
          MAC Address:  a4b2.3cde.4567
         IPv6 Address:  Unknown
         IPv4 Address:  10.0.10.105
           User-Name:  CORP\jsmith
              Status:  Authorized
              Domain:  DATA
      Security Policy:  Should Secure
      Security Status:  Unsecure
         Oper host mode:  multi-auth
       Oper control dir:  both
        Session timeout:  N/A
    Common Session ID:  0A00630A0000001F2B8C3A00
      Acct Session ID:  0x0000001F
               Handle:  0x89000009
       Current Policy:  POLICY_Gi1/0/1

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Server Policies:
              Vlan Group:  Vlan: 10
              ACS ACL: xACSACLx-IP-PERMIT_ALL-5a7b3c2d

Method status list:
      Method           State
      dot1x            Authc Success

This output shows a successfully authenticated Windows endpoint:

• User-Name confirms PEAP authentication against Active Directory returned the domain username
• Status: Authorized — port is open
• Vlan Group: Vlan 10 — ISE assigned Data VLAN 10
• dot1x Method State: Authc Success — 802.1X completed successfully

On ISE, verify at Operations > RADIUS > Live Sessions — the session appears with matching MAC address, username, and policy applied.

Component Responsibilities Summary

What's Next: Article 3: How EAP Works in 802.1X: EAP Methods Compared — a detailed comparison of PEAP, EAP-TLS, EAP-FAST, and MAB, with guidance on which method to choose for different device types in enterprise deployments.