802.1X Authentication Failing: Where to Start Troubleshooting

Starting Point: Understand Where the Failure Is

802.1X authentication involves at least four distinct systems: the endpoint supplicant, the switch port (authenticator), the RADIUS server (ISE), and ISE's internal policy engine. A failure at any layer produces a different symptom signature. The worst approach is to jump straight to ISE logs or start modifying port configurations without first isolating which layer is failing.

The structured approach:

1. Confirm the physical layer and port state
2. Confirm dot1x is enabled and operating on the port
3. Confirm RADIUS connectivity between the switch and ISE
4. Examine ISE authentication logs for the specific failure reason
5. Examine EAP exchange details if the failure is in the authentication phase
6. Check ISE policy — authorization rule evaluation

This order matters. There is no value in examining ISE logs if the switch is not reaching ISE at all. There is no value in checking ISE policy if the EAP exchange is failing before ISE even receives a complete authentication request.

Layer 1: Physical and Port State

Before touching authentication configuration, confirm the basics.

SW9300# show interface GigabitEthernet1/0/5 status

Sample output:

Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/5                      connected    1          a-full  a-100 10/100/1000BaseTX

If status shows notconnect or err-disabled, authentication has not started. Fix the physical layer or clear the err-disabled state first.

SW9300# show interface GigabitEthernet1/0/5

Check for input errors, CRC errors, or interface resets — these indicate cabling or NIC issues that can cause intermittent authentication failures.

If the port is in err-disabled:

SW9300# show interface GigabitEthernet1/0/5 | include err-disabled
GigabitEthernet1/0/5 is down, line protocol is down (err-disabled)

Identify the cause:

SW9300# show errdisable recovery

Common 802.1X-related err-disable causes: security-violation (port security conflict), dot1x-timeout (not typically err-disable but worth checking), bpduguard. Fix the underlying cause before re-enabling:

SW9300# interface GigabitEthernet1/0/5
SW9300(config-if)# shutdown
SW9300(config-if)# no shutdown

Layer 2: Confirm dot1x Port State

SW9300# show dot1x interface GigabitEthernet1/0/5 details

Sample output for a port where dot1x is enabled but authentication is failing:

Dot1x Info for GigabitEthernet1/0/5
-----------------------------------
PAE                       = AUTHENTICATOR
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30

Dot1x Authenticator Client List
--------------------------------
EAP Method                = PEAP
Supplicant                = a4b1.c2d3.e4f5
   Auth SM State          = AUTHENTICATING
   Auth BEND SM State     = RESPONSE
   Time                   = 00:00:28

Auth SM State = AUTHENTICATING and Auth BEND SM State = RESPONSE after 28 seconds means the switch sent an EAP request to the supplicant and is waiting for a response that has not arrived. This points to a supplicant-side problem — the Windows Wired AutoConfig service is not running, the supplicant is not configured, or the endpoint's NIC is not passing EAPOL frames.

Compare this to a RADIUS-side failure:

   Auth SM State          = HELD
   Auth BEND SM State     = IDLE

HELD means the last authentication attempt failed and the switch is in a quiet period before trying again. This is the signature of authentication completing at the EAP level but being rejected by RADIUS — wrong credentials, invalid certificate, policy mismatch.

SW9300# show authentication sessions interface GigabitEthernet1/0/5

Sample output:

          Interface:  GigabitEthernet1/0/5
        MAC Address:  a4b1.c2d3.e4f5
         IP Address:  Unknown
           Username:  Unknown
              Status:  Unauthorized
              Domain:  UNKNOWN
   Security Policy:  Should Secure
   Security Status:  Unsecured

Status: Unauthorized with Username: Unknown indicates the switch never received an EAP Identity from the supplicant. The EAPOL exchange has not started. Check the supplicant configuration. In a Windows 10/11 environment, verify:

• Wired AutoConfig service (dot3svc) is running: sc query dot3svc
• The correct network profile is applied
• The NIC adapter settings show the correct 802.1X authentication method

Status: Unauthorized with a username present means the switch received the identity, completed the EAP exchange with ISE, but received an Access-Reject. This is an ISE policy or credential issue.

Layer 3: Confirm RADIUS Reachability

SW9300# show aaa servers

Sample output:

RADIUS: id 1, priority 1, host 10.0.0.10, auth-port 1812, acct-port 1813
     State: current UP, duration 3d02h, previous duration 0s
     Dead: total time 0s, count 0
     Authentication: #sent 1432, #received 1280
     Retransmission: #sent 152, #late responses 0

#sent 1432, #received 1280 with Retransmission: #sent 152 indicates the switch is reaching ISE but 10% of packets are being retransmitted — a sign of latency or ISE performance issues. If retransmissions are consistently high, check network path between switch and ISE, and check ISE CPU/memory utilization.

If state shows DEAD or current DOWN:

     State: current DEAD, duration 00:02:15, previous duration 3d02h
     Dead: total time 135s, count 1

This is a complete loss of RADIUS connectivity. See Article 22 — RADIUS Server Unreachable in 802.1X: Causes and Fixes for the full diagnostic procedure.

Test connectivity directly:

SW9300# test aaa group ISE-SERVERS test-user test-password new-code

This sends a test Access-Request to ISE. A successful response:

Attempting authentication test to server-group ISE-SERVERS using radius
User was successfully authenticated.

A failure:

User authentication request was rejected by server.

Rejection from ISE means RADIUS connectivity is working but ISE is rejecting the test credential — expected if test-user does not exist in ISE. What matters here is that ISE responded at all.

If the command times out with no response, RADIUS is unreachable — check firewall rules, routing, and the ip radius source-interface configuration.

Layer 4: ISE Authentication Logs

Navigation: Operations > RADIUS > Live Logs

Filter by:

• MAC Address (Calling-Station-ID) — most reliable filter
• Username — if you have it
• NAS IP Address — narrows to failures from a specific switch

Each failed authentication entry shows a Failure Reason field. This is the most direct path to the root cause. Common failure reasons:

Click on any failed log entry to open the Authentication Detail Report. This shows the complete authentication sequence, which policy set was evaluated, which rules matched, and what ISE returned.

Navigation: Operations > Reports > Endpoints and Users > Authentication Summary

For repeated failures from the same endpoint, run this report filtered by MAC address or username over a 24-hour window. Patterns in failure reasons across multiple attempts reveal consistent misconfigurations rather than one-off issues.

Layer 5: EAP Exchange Analysis

When ISE shows the authentication is reaching the EAP exchange phase but failing, use debug on the switch to see exactly where the EAP conversation breaks.

SW9300# debug dot1x events
SW9300# debug dot1x packets
SW9300# debug radius authentication

Trigger an authentication attempt (disconnect and reconnect the endpoint, or run authentication restart on the port):

SW9300# interface GigabitEthernet1/0/5
SW9300(config-if)# authentication restart

A healthy PEAP exchange in debug dot1x events:

*Mar 19 09:22:01.001: dot1x-ev: Received EAPOL Start on Gi1/0/5
*Mar 19 09:22:01.002: dot1x-ev: Sending EAP Request Identity to a4b1.c2d3.e4f5
*Mar 19 09:22:01.150: dot1x-ev: Received EAP Response Identity from a4b1.c2d3.e4f5
*Mar 19 09:22:01.151: dot1x-ev: Sending RADIUS Access-Request for a4b1.c2d3.e4f5
*Mar 19 09:22:01.280: dot1x-ev: Received RADIUS Access-Challenge
*Mar 19 09:22:01.281: dot1x-ev: Sending EAP Request (TLS Start) to a4b1.c2d3.e4f5
*Mar 19 09:22:01.450: dot1x-ev: Received EAP Response (TLS) from a4b1.c2d3.e4f5
... [TLS handshake packets] ...
*Mar 19 09:22:02.910: dot1x-ev: Received RADIUS Access-Accept
*Mar 19 09:22:02.911: dot1x-ev: 802.1X Authentication success for a4b1.c2d3.e4f5

A PEAP failure where the TLS handshake completes but MSCHAP fails:

*Mar 19 09:22:01.001: dot1x-ev: Received EAPOL Start on Gi1/0/5
*Mar 19 09:22:01.002: dot1x-ev: Sending EAP Request Identity to a4b1.c2d3.e4f5
*Mar 19 09:22:01.150: dot1x-ev: Received EAP Response Identity from a4b1.c2d3.e4f5
*Mar 19 09:22:01.151: dot1x-ev: Sending RADIUS Access-Request for a4b1.c2d3.e4f5
*Mar 19 09:22:01.280: dot1x-ev: Received RADIUS Access-Challenge
... [TLS handshake completes] ...
*Mar 19 09:22:02.850: dot1x-ev: Received RADIUS Access-Reject
*Mar 19 09:22:02.851: dot1x-ev: 802.1X Authentication failed for a4b1.c2d3.e4f5
*Mar 19 09:22:02.852: dot1x-ev: Setting hold-off timer 60s for Gi1/0/5

The Access-Reject after a completed TLS handshake points to credential validation failure (wrong username/password, AD account issue) or ISE authorization policy rejection. At this point, ISE's Live Logs have the specific failure reason.

A failure where the TLS handshake itself does not complete:

*Mar 19 09:22:01.280: dot1x-ev: Received RADIUS Access-Challenge
*Mar 19 09:22:01.281: dot1x-ev: Sending EAP Request (TLS Start) to a4b1.c2d3.e4f5
*Mar 19 09:22:31.281: dot1x-ev: SuppTimeout expired for a4b1.c2d3.e4f5
*Mar 19 09:22:31.282: dot1x-ev: Authentication failed - Supplicant timeout

Supplicant timeout during TLS handshake means the endpoint received the TLS Start but did not respond. Causes: supplicant not configured for this EAP method, Windows prompting the user for certificate trust but UI is suppressed, or the ISE certificate is not trusted by the endpoint's certificate store.

Disable debug after collection:

SW9300# undebug all

Layer 6: ISE Policy and Authorization

If ISE is accepting the authentication (Access-Accept) but the endpoint behavior is still wrong — landing in the wrong VLAN, no dACL applied, or being placed in the Auth-Fail VLAN — the issue is in ISE's authorization policy, not authentication.

Navigation: Operations > RADIUS > Live Logs > [Click on entry] > Authentication Detail

Scroll to the Authorization Policy section of the detail report. It shows:

• Which Policy Set matched
• Which Authorization Rules were evaluated
• Which Authorization Profile was returned
• The specific RADIUS attributes sent in the Access-Accept

If the endpoint is landing in the wrong VLAN, compare the VLAN in the detail report against what you expect. If ISE is sending VLAN 40 (Auth-Fail) when you expect VLAN 10, the authorization rule matching is returning the wrong profile.

Navigation: Policy > Policy Sets > [Policy Set] > Authorization Policy

Review rule order. ISE evaluates authorization rules top to bottom and stops at the first match. If a catch-all rule is above a more specific rule, the catch-all always wins. Check:

1. Rule conditions — is the AD group condition correct?
2. Rule order — is the correct rule above the catch-all default?
3. Authorization Profile — does the profile have the correct VLAN assignment and dACL?

For VLAN assignment details and specific authorization profile troubleshooting, see Article 23 — Dynamic VLAN Assignment Not Working in 802.1X: Troubleshooting Guide.

Troubleshooting

Symptom: Authentication fails intermittently — some endpoints authenticate, others do not, with no pattern

Cause: RADIUS shared secret mismatch between the switch configuration and the ISE Network Device entry. When the shared secret is wrong, RADIUS packet authentication (the Message-Authenticator attribute) fails and ISE silently drops the packet or returns a generic error. Intermittency occurs when some packets happen to not include Message-Authenticator (e.g., test packets), while production 802.1X packets always include it.

Fix: Verify the shared secret on both ends. On the switch:

SW9300# show running-config | section radius server ISE-PRIMARY
radius server ISE-PRIMARY
 address ipv4 10.0.0.10 auth-port 1812 acct-port 1813
 key ISEsecret123

On ISE: Administration > Network Resources > Network Devices > [Device] > Authentication Settings > Shared Secret. Retype the shared secret on both ends — even one character mismatch causes complete authentication failure. After changing the key on the switch, the key is stored encrypted in running config; use more system:running-config to verify if needed.

Symptom: Authentication succeeds (dot1x shows Authorized) but the endpoint has no network access

Cause: Authorization succeeded but the dACL being applied is denying traffic, or the VLAN assignment placed the endpoint on an isolated segment. The port shows Authorized from the 802.1X perspective, but IP connectivity is blocked by policy.

Fix: Check the applied policy:

SW9300# show authentication sessions interface GigabitEthernet1/0/5 details

Look at the ACS ACL line (dACL name) and Vlan Group. Then check what that dACL contains:

SW9300# show ip access-lists xACSACLx-IP-RestrictedAccess-12345678

If the dACL has deny ip any any as the first matching rule or is missing permit statements for required traffic, the endpoint is connected but blocked. Correct the dACL in ISE:

Navigation: Policy > Policy Elements > Results > Authorization > Downloadable ACLs > [dACL Name]

Also verify the dACL is being downloaded correctly — see Article 24 — dACL Not Applying Correctly in 802.1X.

Symptom: Only the first endpoint to connect on a multi-auth port succeeds; subsequent endpoints fail with no error in ISE logs

Cause: The port is configured for single-host mode instead of multi-auth. In single-host mode, the switch only allows one authenticated MAC address on the port. Subsequent endpoints are blocked at the switch level and their EAPOL frames are never forwarded to ISE.

Fix: Verify and correct the host mode:

SW9300# show authentication sessions interface GigabitEthernet1/0/5

Check the current host mode:

SW9300# show running-config interface GigabitEthernet1/0/5 | include host-mode
 authentication host-mode single-host

Change to the appropriate mode. For a port with multiple data endpoints:

SW9300(config)# interface GigabitEthernet1/0/5
SW9300(config-if)# authentication host-mode multi-auth

For a port with a PC and an IP phone, use multi-domain. For host mode details, see Article 13 — 802.1X Authentication Host Modes: Single-Host, Multi-Host, Multi-Domain, Multi-Auth.

Quick Reference: Failure Signature Matrix

What's Next: Article 21 — Client Stuck in Unauthorized State: Diagnosing 802.1X Port Issues — goes deeper into the specific scenario where the port stays Unauthorized, covering EAPOL capture analysis, supplicant diagnostics, and the switch-side state machine in detail.