802.1X Authentication Flow Step by Step: From EAPOL Start to RADIUS Accept

The 802.1X authentication flow is a handshake involving three separate conversations happening simultaneously: the supplicant talking EAPOL to the switch, the switch talking RADIUS to ISE, and ISE enforcing policy against an identity store. Confusing one conversation with another is the root cause of most 802.1X troubleshooting dead ends.

This article maps every step in the correct sequence. The lab uses a Cisco Catalyst 9300 (IOS XE 17.9.x) as the authenticator, Cisco ISE 3.2 as the RADIUS server, and a Windows 11 endpoint as the supplicant.

For background on each individual component, see [Article 2: 802.1X Components Explained: Supplicant, Authenticator, and Authentication Server] and [Article 4: EAPOL Explained: How 802.1X Traffic Moves Over the Wire]. For a deep dive on EAP methods that run inside this flow, see [Article 3: How EAP Works in 802.1X: EAP Methods Compared].

The Three Conversations in One Flow

Before tracing each step, establish what each conversation carries:

• Supplicant ↔ Authenticator (Switch): Uses EAPOL — EAP over LAN. EtherType 0x888E. Layer 2 only, no IP involved. The switch is a pass-through for EAP payloads.
• Authenticator (Switch) ↔ Authentication Server (ISE): Uses RADIUS. The switch encapsulates EAP messages inside RADIUS Access-Request and Access-Challenge packets. UDP port 1812 for authentication.
• Authentication Server (ISE) ↔ Identity Store: Uses LDAP, Kerberos, or internal database lookups. This happens entirely inside ISE and is invisible to the switch.

The switch does not decrypt or interpret EAP payloads. It forwards them transparently between the supplicant and ISE. This is a critical point — the switch has no knowledge of which EAP method is in use. ISE and the supplicant negotiate EAP method directly.

Step-by-Step Authentication Flow

Step 1: Link Up and EAPOL-Start

When the endpoint connects to the switch port, the port enters the connecting state. Two triggers can begin authentication:

1. Switch-initiated: The switch sends an EAP-Request/Identity frame immediately after link-up, without waiting for the supplicant. This is the default behavior when dot1x pae authenticator is configured on the port.
2. Supplicant-initiated: The supplicant sends an EAPOL-Start frame. The EAPOL-Start is a broadcast (destination MAC 01:80:C2:00:00:03) with a zero-length body, signaling to the switch that the endpoint wants to authenticate.

In most Windows 10/11 deployments, the NIC driver sends EAPOL-Start within one to two seconds of link-up. The switch responds either way with an EAP-Request/Identity.

Step 2: EAP-Request/Identity

The switch sends an EAP-Request/Identity frame to the supplicant. This frame has:

• Code: 1 (Request)
• Type: 1 (Identity)

The destination MAC is the supplicant's unicast MAC. The frame asks the supplicant to reveal its identity — typically a username in the form user@domain.com or a machine identity like host/HOSTNAME.domain.com.

Step 3: EAP-Response/Identity

The supplicant replies with an EAP-Response/Identity frame containing the identity string. For PEAP and EAP-TLS, this is often an anonymous outer identity (anonymous@domain.com) to protect the real username from being exposed in cleartext. ISE uses the inner identity established inside the TLS tunnel for policy decisions.

The switch receives this frame and forwards it to ISE in its first RADIUS message.

Step 4: RADIUS Access-Request (EAP-Response/Identity)

The switch constructs a RADIUS Access-Request packet and sends it to ISE (10.0.0.10, UDP 1812). This packet includes:

• User-Name: The identity string from the EAP-Response/Identity frame
• NAS-IP-Address: The switch's management IP (10.0.99.1 in this lab)
• NAS-Port: The interface index of the authenticating port
• NAS-Port-Type: Ethernet (15)
• Called-Station-Id: Switch MAC address and optionally the port identifier
• Calling-Station-Id: Supplicant MAC address (critical for MAB and ISE endpoint identity)
• EAP-Message: The raw EAP payload (the EAP-Response/Identity bytes)
• Message-Authenticator: HMAC-MD5 of the entire packet using the shared secret (ISEsecret123 in this lab). Required for any RADIUS packet containing an EAP-Message attribute.

Step 5: RADIUS Access-Challenge (EAP-Request — Method Negotiation)

ISE responds with a RADIUS Access-Challenge. The EAP-Message attribute inside contains an EAP-Request for the EAP method ISE wants to use — for example, an EAP-Request/PEAP or EAP-Request/TLS.

The switch forwards this as an EAP-Request frame to the supplicant. The port remains unauthorized.

Step 6: EAP Method Negotiation

The supplicant either accepts the proposed EAP method or sends an EAP-Response/Legacy-Nak with a list of EAP methods it supports. ISE and the supplicant negotiate until they agree on a common method.

In a correctly configured PEAP deployment, this negotiation completes in one round trip. If ISE proposes EAP-TLS and the supplicant has no certificate, the supplicant sends a Nak proposing PEAP instead. ISE must have PEAP allowed in its Allowed Protocols configuration or authentication fails at this stage.

Step 7: EAP Method Execution (TLS Handshake / PEAP Tunnel)

For PEAP and EAP-TLS, this is where a TLS handshake occurs. The exchange may span multiple RADIUS Access-Challenge / Access-Request round trips as TLS records are fragmented and reassembled.

During this phase:

• ISE presents its server certificate to the supplicant. The supplicant must trust the issuing CA.
• For EAP-TLS, the supplicant also presents a client certificate. ISE validates it against a trusted CA.
• For PEAP, once the outer TLS tunnel is established, the inner EAP method (usually MSCHAPv2) runs inside the encrypted tunnel.

The switch forwards each EAP frame to ISE in a RADIUS Access-Request and relays each ISE response back to the supplicant as an EAP frame. The switch processes zero EAP payload content during this phase.

Step 8: Identity Store Lookup (Inside ISE)

Once ISE has the user credentials or client certificate, it performs an identity lookup:

• For PEAP-MSCHAPv2: ISE queries Active Directory (or its internal identity store) to validate the username and password.
• For EAP-TLS: ISE validates the client certificate's Subject Alternative Name or Common Name against Active Directory or an internal certificate store.

ISE then evaluates the Authentication Policy and Authorization Policy defined under Policy > Policy Sets to determine what Authorization Profile to return.

Step 9: RADIUS Access-Accept

If authentication and authorization succeed, ISE sends a RADIUS Access-Accept packet. This packet contains:

• EAP-Message: Final EAP-Success frame to be forwarded to the supplicant
• Tunnel-Type (64): VLAN (value 13) — for dynamic VLAN assignment
• Tunnel-Medium-Type (65): 802 (value 6)
• Tunnel-Private-Group-ID (81): VLAN ID (e.g., 10 for Data VLAN 10)
• Optionally: Filter-Id for a named ACL, or Cisco-AVpair with ip:inacl= entries for dACLs

If authentication fails, ISE sends a RADIUS Access-Reject with an EAP-Failure payload.

Step 10: EAP-Success and Port Authorization

The switch receives the RADIUS Access-Accept. It:

1. Forwards the EAP-Success frame to the supplicant (extracted from the EAP-Message attribute)
2. Processes the VLAN attributes and moves the port to the assigned VLAN
3. Moves the port to the Authorized state — traffic is now permitted

The supplicant receives the EAP-Success frame and considers the connection authenticated. The Windows supplicant triggers DHCP and begins normal network operations.

The entire flow — from EAPOL-Start to port authorization — typically completes in under two seconds on a healthy network.

Verifying the Flow on the Switch

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

            Interface:  GigabitEthernet1/0/1
               IIF-ID:  0x1D4A6B2C
          MAC Address:  a4b1.e9f0.3c22
         IPv6 Address:  Unknown
         IPv4 Address:  10.0.10.105
           User-Name:  CORP\jsmith
              Status:  Authorized
              Domain:  DATA
      Oper host mode:  multi-auth
    Oper control dir:  both
     Session timeout:  N/A
  Common Session ID:  0A006301000001B4E2D34F10
    Acct Session ID:  0x00000012
             Handle:  0xC5000013
     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-5f3a2b1c

Method status list:
       Method           State
       dot1x            Authc Success

Key fields to verify:

• Status: Authorized — the port has passed authentication and traffic is flowing
• User-Name — confirms ISE returned the authenticated identity
• Vlan Group: Vlan: 10 — dynamic VLAN assignment from ISE is active
• Method: dot1x / Authc Success — 802.1X succeeded (not MAB fallback)

What Changes When Authentication Fails

If ISE sends an Access-Reject, the switch sends EAP-Failure to the supplicant and keeps the port unauthorized. Depending on configuration, one of three things happens next:

1. Auth-Fail VLAN (VLAN 40): If authentication event fail action authorize vlan 40 is configured, the port moves to VLAN 40 with restricted access. See [Article 15: Guest VLAN, Auth-Fail VLAN, and Critical VLAN in 802.1X] for configuration detail.
2. Guest VLAN (VLAN 30): If no 802.1X supplicant is detected after a timeout, the port can fall to the Guest VLAN. This applies to devices that never send EAPOL-Start.
3. Port stays unauthorized: The default behavior — no traffic passes.

If ISE is unreachable, the switch cannot send a RADIUS Access-Request and authentication times out. If authentication event server dead action authorize vlan 50 is configured, the port moves to the Critical VLAN (VLAN 50).

Timing and Retry Behavior

The switch has configurable timers that control retry behavior:

• tx-period (default 30s): How long the switch waits for an EAP-Response before retransmitting an EAP-Request
• max-reauth-req (default 2): Number of retransmits before giving up and restarting
• quiet-period (default 60s): After a failed authentication, how long the switch waits before trying again

In production environments, reducing tx-period to 10 seconds and max-reauth-req to 3 significantly improves the user experience when a supplicant is slow to respond. See [Article 8: Basic 802.1X Port Configuration on Cisco IOS XE Switches] for timer configuration.

ISE Visibility: Live Logs

Every authentication attempt is visible in ISE under Operations > RADIUS > Live Logs. Each log entry expands to show every step of the authentication, including:

• Identity store lookup result
• Authentication policy match
• Authorization policy match
• Authorization profile applied (VLAN, dACL, SGT)

When troubleshooting, the ISE Live Logs are the first place to check. A failure at the identity store lookup means a credential or certificate problem. A failure at policy evaluation means a policy misconfiguration. An entry that never appears in Live Logs means the RADIUS packet never reached ISE — a network or shared secret problem.

Troubleshooting

Symptom: Port stays in Connecting state indefinitely, no EAP-Request/Identity sent.
Cause: dot1x pae authenticator is not configured on the interface, or dot1x system-auth-control is not enabled globally.
Fix: Verify with show dot1x all that 802.1X is enabled globally and that the interface shows PAE as authenticator.

Symptom: Authentication completes but port remains Unauthorized; ISE shows Access-Accept sent.
Cause: VLAN assignment attributes in the Access-Accept are malformed or the VLAN does not exist on the switch. The switch rejects the VLAN assignment and may keep the port unauthorized.
Fix: Verify VLAN 10 exists on the switch with show vlan brief. Confirm the Tunnel-Private-Group-ID in the ISE Authorization Profile is a plain integer string (no quotes, no vlan: prefix).

Symptom: ISE Live Logs show no entry for the authentication attempt.
Cause: RADIUS packets are not reaching ISE. Causes include: wrong ISE IP configured on the switch, shared secret mismatch (Access-Request dropped silently), or a firewall blocking UDP 1812.
Fix: Run debug radius on the switch to confirm Access-Requests are being sent and whether responses are received. Verify the shared secret matches on both the switch (radius server ISE config) and ISE (Administration > Network Devices). Check ISE's RADIUS live logs for rejected packets due to shared secret failure.

What's Next: [Article 8: Basic 802.1X Port Configuration on Cisco IOS XE Switches] — the complete IOS XE port configuration reference, covering host modes, timer tuning, fallback VLANs, and interface template application on the Catalyst 9300.