Defining the Problem
"Stuck in Unauthorized" is not a single failure. It is a symptom that covers at least five distinct failure scenarios, each with different root causes:
- The supplicant never sends EAPOL Start — the switch sits idle in the CONNECTING state
- The supplicant sends EAPOL Start but stops responding during EAP exchange — SuppTimeout
- The switch is not configured for dot1x on this port — no authentication is being attempted
- The EAP exchange completes but RADIUS returns Access-Reject — HELD state
- Authentication succeeds but the switch cannot apply the assigned policy — post-auth failure
The show authentication sessions output alone cannot distinguish between these. You need the dot1x detail output, debug traces, and in some cases ISE logs to identify which scenario applies.
Step 1: Read the State Machine
SW9300# show dot1x interface GigabitEthernet1/0/5 details
Sample output — supplicant not responding:
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 = Unknown
Supplicant = a4b1.c2d3.e4f5
Auth SM State = CONNECTING
Auth BEND SM State = IDLE
Time = 00:03:42
CONNECTING / IDLE after 3 minutes and 42 seconds is the clearest indicator that the supplicant has not started the EAP exchange. The switch has sent EAP Request Identity frames (TxPeriod = 30 means one every 30 seconds) and received nothing back.
Compare to post-failure state:
Auth SM State = HELD
Auth BEND SM State = IDLE
Time = 00:00:45
HELD means at least one complete authentication attempt has occurred and failed. The switch is now in a quiet period (QuietPeriod = 60 seconds) before retrying. The Time counter resets at each state transition.
And a state where authentication is in progress:
Auth SM State = AUTHENTICATING
Auth BEND SM State = RESPONSE
Time = 00:00:08
AUTHENTICATING / RESPONSE means the EAP exchange has started — the switch is actively communicating with ISE and waiting for the next EAP message.
SW9300# show authentication sessions interface GigabitEthernet1/0/5
Sample output with MAB also failing:
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
Runnable methods list:
Method State
dot1x Failed over
mab Running
dot1x Failed over and mab Running tells you dot1x has exhausted its retries and fallen back to MAB. If mab is also staying Running for more than a few seconds without showing Authc Success, ISE is rejecting the MAB request or the MAC address is not in ISE's endpoint database.
Step 2: Is dot1x Actually Enabled on This Port?
A common finding in new deployments and in switches inherited from another team: the port does not have authentication port-control auto configured. Without this, the port operates in force-authorized mode — it passes traffic without authentication.
SW9300# show running-config interface GigabitEthernet1/0/5
Sample output — dot1x configured correctly:
interface GigabitEthernet1/0/5
switchport mode access
switchport access vlan 10
authentication event fail action next-method
authentication event server dead action reinitialize vlan 50
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
mab
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast
Missing authentication port-control auto means the port is in force-authorized mode. The endpoint gets network access without authenticating. You will not see any dot1x activity in show dot1x interface because no authentication is being attempted.
Missing dot1x pae authenticator means the port is not acting as a dot1x authenticator at all. Even with port-control auto, if PAE is not set to authenticator, dot1x does not activate.
Missing mab when you expect MAB fallback means endpoints that cannot do dot1x (printers, cameras, IoT devices) will sit in Unauthorized permanently instead of falling back to MAC authentication.
Step 3: Enable Debug and Trigger Authentication
After reading the static output, enable event-level debug and force a re-authentication to capture a live trace:
SW9300# debug dot1x events
SW9300# debug dot1x packets
Then restart authentication on the port:
SW9300# clear authentication sessions interface GigabitEthernet1/0/5
Or from interface config:
SW9300(config)# interface GigabitEthernet1/0/5
SW9300(config-if)# authentication restart
Watch the console output. A healthy start looks like:
*Mar 19 10:15:00.001: dot1x-ev(Gi1/0/5): New client detected, MAC a4b1.c2d3.e4f5
*Mar 19 10:15:00.002: dot1x-ev(Gi1/0/5): Sending EAP Req/Identity to a4b1.c2d3.e4f5
*Mar 19 10:15:00.145: dot1x-ev(Gi1/0/5): Received EAPOL frame, type=0x00 (EAP Packet)
*Mar 19 10:15:00.146: dot1x-ev(Gi1/0/5): Received EAP Resp/Identity from a4b1.c2d3.e4f5, id=2
*Mar 19 10:15:00.147: dot1x-ev(Gi1/0/5): Forwarding Request to RADIUS
A supplicant that is not responding:
*Mar 19 10:15:00.001: dot1x-ev(Gi1/0/5): New client detected, MAC a4b1.c2d3.e4f5
*Mar 19 10:15:00.002: dot1x-ev(Gi1/0/5): Sending EAP Req/Identity to a4b1.c2d3.e4f5
*Mar 19 10:15:10.002: dot1x-ev(Gi1/0/5): SuppTimeout - Sending EAP Req/Identity to a4b1.c2d3.e4f5 (retry 1)
*Mar 19 10:15:20.002: dot1x-ev(Gi1/0/5): SuppTimeout - Sending EAP Req/Identity to a4b1.c2d3.e4f5 (retry 2)
*Mar 19 10:15:30.002: dot1x-ev(Gi1/0/5): MaxReq reached for a4b1.c2d3.e4f5, failing over
The switch sent EAP Request Identity three times (initial + 2 retries per MaxReq = 2) with no response. This is a supplicant problem.
Disable debug after collection:
SW9300# undebug all
Step 4: Supplicant-Side Diagnostics
If the debug output shows the switch sending EAP Request Identity but receiving nothing, the problem is on the endpoint. For Windows 10/11:
Check the Wired AutoConfig service. This service must be running for Windows to process 802.1X on wired adapters.
On the endpoint: services.msc → Wired AutoConfig → Status must be "Running." If it is stopped:
sc start dot3svc
sc config dot3svc start= auto
Check the network adapter's 802.1X settings. In Windows 11:
Control Panel > Network and Internet > Network Connections > right-click adapter > Properties > Authentication tab. The tab should show "Enable IEEE 802.1X authentication" checked with PEAP selected as the method.
If the Authentication tab is absent, the Wired AutoConfig service is not running, or a Group Policy is explicitly disabling 802.1X on this adapter.
Check Windows Event Viewer for supplicant events.
Event Viewer > Windows Logs > Security. Filter for Event ID 6272 (authentication success), 6273 (authentication failure), and 6274 (authentication discarded). Event ID 6273 includes a reason code in the event detail — reason code 22 = wrong credentials, reason code 16 = user cancelled authentication (often seen when the certificate trust prompt is suppressed).
Verify EAPOL frames are actually leaving the NIC. Use Wireshark on the endpoint, filter eapol. If you see EAPOL Start and EAP Response frames in the Wireshark capture but the switch debug shows nothing, the NIC is sending frames but they are not reaching the switch — check the physical layer (cable, switch port, NIC driver).
Step 5: Supplicant Responding but Auth Fails — HELD State
When the debug shows a complete EAP exchange followed by Access-Reject, and the port enters HELD state, the failure is at RADIUS. Check ISE:
Navigation: Operations > RADIUS > Live Logs
Filter by Calling-Station-ID (the endpoint MAC address in AA-BB-CC-DD-EE-FF format). Find the failed entry. The Failure Reason field will show the specific cause.
Common causes when the port goes to HELD:
Wrong EAP method configured on the supplicant. If the switch and ISE are configured for PEAP but the supplicant is sending EAP-TLS, ISE may reject it if EAP-TLS is not allowed in the ISE authentication policy.
Certificate not trusted. For PEAP, the endpoint must trust the ISE server certificate. If Windows does not trust the CA that signed the ISE certificate, the TLS handshake fails and the port stays unauthorized. Check:
Navigation: ISE > Administration > System > Certificates > System Certificates
Verify the ISE certificate's issuer. On the Windows endpoint, verify that issuer CA is in the Trusted Root Certification Authorities store (Computer account, not just User account).
User credentials incorrect. If PEAP-MSCHAPv2 is being used, the Windows domain credentials must be correct and the account must not be locked or expired. ISE failure reason 24423 (User rejected by AD) or 22040 (wrong password) confirms this.
Step 6: Authentication Succeeds but Port Stays Unauthorized
This is the most confusing scenario — debug dot1x events shows Access-Accept from RADIUS, but show authentication sessions still shows Unauthorized. This typically means:
Policy push failure. The Access-Accept contained a VLAN ID or dACL that the switch could not apply. Check:
SW9300# show authentication sessions interface GigabitEthernet1/0/5 details
If you see Authz Failed or the session shows authorized briefly then reverts:
SW9300# show logging | include Gi1/0/5
Look for log entries mentioning AAA AUTHOR failures or VLAN assignment errors.
VLAN does not exist on the switch. If ISE assigns VLAN 10 but VLAN 10 is not in the VLAN database or is not allowed on the trunk uplink, the authorization fails. Verify:
SW9300# show vlan brief
All VLANs referenced in ISE authorization profiles (10, 20, 30, 40, 50, 99) must be active in the switch VLAN database.
dACL download failure. If ISE is configured to send a dACL and the download fails (RADIUS fragmentation issue, dACL name mismatch), the switch may reject the session. For detailed dACL troubleshooting, see Article 24 — dACL Not Applying Correctly in 802.1X.
Timer Reference and Tuning
When investigating stuck-Unauthorized scenarios, the timer values determine how long each phase takes. Default values on IOS XE 17.9:
| Timer | Default | Function |
|---|---|---|
tx-period |
30s | How often the switch sends EAP Request Identity |
supp-timeout |
30s | Time to wait for supplicant response per EAP message |
server-timeout |
30s | Time to wait for RADIUS response |
quiet-period |
60s | Time in HELD state before retrying |
max-req |
2 | Number of EAP Identity retries |
reauth-max |
2 | Number of re-authentication retries |
In a conference room environment where guest devices connect and disconnect frequently, the default quiet-period of 60 seconds causes the switch to sit in HELD for a minute after each failed attempt. For guest-facing ports, reduce this:
SW9300(config-if)# dot1x timeout quiet-period 10
In high-latency branch office environments, the default server-timeout of 30 seconds may be too short if ISE is reached over a WAN link with 80ms+ RTT and processing load. Increase it:
SW9300(config-if)# dot1x timeout server-timeout 60
Guest VLAN and Auth-Fail VLAN as Fallback
In production, ports that host both managed and unmanaged devices should be configured with fallback VLANs so that the port does not simply stay blocked when authentication fails.
SW9300(config-if)# authentication event no-response action authorize vlan 30
SW9300(config-if)# authentication event fail action authorize vlan 40
no-response action authorize vlan 30 — places the port in Guest VLAN 30 if no EAPOL response is received within the timeout window. This handles non-802.1X capable devices (printers, IP cameras, older endpoints).
fail action authorize vlan 40 — places the port in Auth-Fail VLAN 40 if the endpoint sends EAPOL but authentication is rejected. This gives the endpoint limited access (typically HTTP only to a remediation page) rather than leaving it completely blocked.
For a full breakdown of these fallback mechanisms and when to use each, see Article 15 — Guest VLAN, Auth-Fail VLAN, and Critical VLAN in 802.1X: When and How to Use Them.
Troubleshooting
Symptom: Port enters HELD state immediately after physical connection, without ever sending EAP Request Identity
Cause: A pre-existing cached failed authentication from a previous session. The switch's dot1x state machine retained a HELD state from a previous attempt when the port briefly went down and came back up faster than the quiet-period expired.
Fix: Clear the authentication session and reset the state machine:
SW9300# clear authentication sessions interface GigabitEthernet1/0/5
If this happens repeatedly, check whether the port is flapping. Rapid link-up/link-down events can cause the state machine to carry over HELD state incorrectly. Enable debounce:
SW9300(config-if)# link debounce time 1000
This prevents the switch from processing link events that resolve within 1000ms — common with phones and laptops whose NICs bounce during boot.
Symptom: MAB fallback is configured but the port stays in Unauthorized after dot1x times out
Cause: MAB fallback requires authentication event no-response action authorize vlan OR authentication order dot1x mab with authentication priority dot1x mab. If only dot1x is in the order list, MAB never activates. Alternatively, MAB is in the order list but the MAC address is not in ISE's endpoint database.
Fix: First verify the configuration:
SW9300# show running-config interface GigabitEthernet1/0/5 | include authentication
authentication event fail action next-method
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication order dot1x mab and authentication event fail action next-method (or next-method) — both are needed for MAB fallback to work. next-method tells the switch to try the next method in the order list when dot1x fails.
Then check ISE: verify the endpoint's MAC is in Work Centers > Network Access > Identities > Endpoints or is being profiled automatically. If the MAC is not recognized, ISE returns Access-Reject for MAB and the port stays Unauthorized. Add the MAC to an endpoint group or enable profiling.
Symptom: 802.1X works for some users on the same port but not others — users with long usernames fail
Cause: RADIUS packet fragmentation. EAP-TLS with large certificate chains can exceed the RADIUS packet size limit (4096 bytes by default). If a user's certificate chain is particularly long, or if the RADIUS packet containing the Access-Request plus large EAP payload exceeds MTU, the packet may be fragmented or truncated.
Fix: On ISE, increase the EAP maximum fragment size:
Navigation: Administration > System > Settings > Protocols > EAP
Set "Maximum EAP Packet Size" to 1498 or lower to ensure RADIUS packets fit within a standard MTU without fragmentation. Also verify the MTU on the network path between switch and ISE:
SW9300# ping 10.0.0.10 size 1500 df-bit repeat 10
If large pings fail or show partial success, there is an MTU or fragmentation issue in the network between the switch and ISE.
What's Next: Article 22 — RADIUS Server Unreachable in 802.1X: Causes and Fixes — covers the complete diagnosis of RADIUS connectivity failures between the switch and ISE, including routing, firewall, shared secret, and ISE service health checks.
