802.1X Authentication Troubleshooting Guide: Fix EAP, RADIUS and Certificate Failures

When 802.1X fails, the user sees "can't connect to this network" and the switch or access point logs a timeout, while the real cause sits in one of three places that each team assumes belongs to someone else: the supplicant, the RADIUS conversation, or the certificates. This guide is a structured method for finding which, using the evidence each component already produces. It covers wired and wireless 802.1X with EAP-TLS, PEAP and EAP-TTLS, RADIUS server and network device behaviour, certificate and trust failures, and the newer causes that appeared after Blast-RADIUS hardening, EAP-TLS 1.3 and Windows Credential Guard. It is for network engineers, identity and PKI teams and service desk escalation staff. Design and rollout of certificate-based access is in the 802.1X and EAP-TLS Enterprise Wi-Fi Guide; this page is about fixing it when it breaks. Where examples name RADIUS server products, they are listed alphabetically (FreeRADIUS, Microsoft NPS) and the method applies to any server.

Key takeaways

• Find the last successful step first. Every 802.1X attempt passes EAPOL start, identity, RADIUS Access-Request, EAP method negotiation, TLS handshake, policy match and Access-Accept. Locate the step where it stops before changing anything.
• The RADIUS server log is the single best source. A request that never appears there is a network device, reachability or shared secret problem; a request that appears and is rejected carries a reason you can act on.
• Certificates cause most failures. Microsoft's own troubleshooting guidance names invalid, expired, untrusted-chain and revocation-check failures as the most common cause. Check both directions: the client trusting the server, and the server trusting the client.
• Large certificate chains break quietly. RFC 9191 notes that many access points drop EAP sessions that do not finish within 40 to 50 round trips, so oversized chains and TLS 1.3 can look like random timeouts.
• Recent hardening changes create new failures. Requiring Message-Authenticator after Blast-RADIUS, and Credential Guard blocking single sign-on for MSCHAPv2, both produce failures that did not exist before an update. Check change history early.

How an 802.1X attempt flows, and where it fails

Three parties take part: the supplicant (the client device), the authenticator (switch port or wireless access point or controller) and the authentication server (RADIUS). The supplicant speaks EAP over LAN (EAPOL) to the authenticator, which relays EAP inside RADIUS Access-Request and Access-Challenge packets, using the EAP-Message attribute, to the server. RFC 3580 states that all RADIUS packets used with 802.1X must be authenticated and integrity protected, and that the Message-Authenticator attribute protects packets in a RADIUS EAP conversation.

Triage: the first five minutes

1. Scope the failure: one user, one device type, one site, one SSID or switch, or everyone? Everyone at once points to the RADIUS server, its certificate or a shared change. One device type points to the supplicant profile or an operating system update.
2. Check what changed: server certificate renewal, CA change, RADIUS server patch, network operating system upgrade, client operating system feature update, Group Policy or MDM profile change. Most outages follow one of these.
3. Find the attempt in the RADIUS log: search by MAC address (Calling-Station-Id), username or device name and time. Present and rejected, present and accepted, or absent are three different investigations.
4. Read the client's own reason: on Windows, the WLAN-AutoConfig or Wired-AutoConfig Operational log reports the profile used, the authentication method and the failure reason. On other platforms, the network settings or supplicant log shows certificate trust prompts and failures.
5. Test with a known-good device: one device with a fresh certificate and a correctly managed profile, on the same port or SSID. If it works, the problem is client-side.

Reading the RADIUS server evidence

FreeRADIUS

• Debug mode: the FreeRADIUS documentation recommends running the server in debug mode with radiusd -X and making small, discrete configuration changes, checking each result. Debug output shows whether datastores are connected, whether test packets are accepted, how each packet is processed and whether the response holds the attributes you expect. Read the whole output, not only the last line.
• Where it stops: in debug output, follow one request through the EAP module, the TLS handshake and the policy sections. A request that never appears means the packet did not arrive or came from an address not configured as a client.
• Known-good baseline: save a copy of a working configuration, so a failing change can be compared with it line by line.
• Blast-RADIUS settings: FreeRADIUS recommends adding require_message_authenticator and limit_proxy_state, set to auto, to the security section of radiusd.conf; upgrading does not set them. The project warns that on some unusual network configurations packets from real clients may be discarded, and that some wireless controllers may need upgrading before stricter settings work.

Microsoft NPS

• Audit first: NPS writes accepted attempts as Security event 6272 and rejected attempts as 6273, with 6274 for discarded requests. Confirm auditing with auditpol /get /subcategory:"Network Policy Server"; the expected setting is Success and Failure. If it shows No auditing, enable it with auditpol or the Group Policy setting Audit Network Policy Server under Advanced Audit Policy Configuration, Logon/Logoff.
• Read the whole event: each 6272 or 6273 names the connection request policy and the network policy that matched, and the Reason Code at the bottom of the message. Reason code 16 means authentication failed because of incorrect credentials; check the account, lockout and which domain controller handled the request.
• Client and secret problems: NPS event 13 means a RADIUS message arrived from an address not in the RADIUS clients list. Event 18 means an Access-Request carried an invalid Message-Authenticator attribute, usually a shared secret mismatch.
• Configuration checks: Microsoft lists a valid NPS server certificate, the device in RADIUS Clients, matching shared secrets, ports 1812, 1813, 1645 and 1646 open through firewalls, complete policy conditions and the correct authentication method under the network policy's Constraints tab.

Network device side

Whatever the server, check the authenticator's view: is the RADIUS server marked dead, which server was tried, how many retransmits, and what the port or client session state shows. A server marked dead after timeouts fails every request until the dead timer expires, which looks like an outage even after the root cause is fixed.

Certificate and trust failures

Certificate problems split into two directions, and the fix for one does nothing for the other.

• Server certificate profile: Microsoft's NPS requirements include a Subject value, a DNS name in the SAN if a SAN is used, and the Server Authentication EKU (1.3.6.1.5.5.7.3.1). Client certificates need Client Authentication (1.3.6.1.5.5.7.3.2), with the UPN or the device FQDN in the SAN.
• Revocation: RFC 9190 asks implementations to check revocation of every certificate in the chain except the trust anchor, and requires EAP-TLS 1.3 servers to support OCSP stapling. A CRL that has expired or cannot be fetched from the RADIUS server's network will reject valid clients.
• Windows CAPI2 log: for chain building and revocation errors on Windows clients or NPS, enable the CAPI2 Operational log (it is off by default) under Applications and Services Logs, Microsoft, Windows, CAPI2, reproduce the failure, then read the chain errors.

Device certificates used for 802.1X are machine identities: they need an owner, an inventory, renewal monitoring and revocation on device retirement. Most "sudden" certificate outages are expiry that nobody was watching. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Fragmentation, timeouts and EAP-TLS 1.3

EAP-TLS carries certificates in EAP packets that must be fragmented and acknowledged one at a time. RFC 9191 records the constraints: RADIUS packets are limited to 4096 octets and can carry roughly 4000 octets of EAP per message, typical EAP fragment sizes are only 1020 to 1500 octets, and many access points drop EAP sessions that do not complete within 40 to 50 round trips. It recommends that certificate chains should not contain more than four intermediate certificates.

• Symptom: authentication succeeds on wired ports but fails or is slow on wireless; or works for some clients and times out for others with larger certificates.
• Evidence: a capture on the authenticator or server shows the TLS exchange restarting or stopping partway through the server certificate.
• Fixes: remove unneeded intermediates and certificates the client does not need from the server's chain, use ECC keys to reduce size, check that the network path does not drop fragmented UDP between authenticator and server, and check authenticator EAP timeout and retry settings.
• TLS 1.3: RFC 9190 defines EAP-TLS with TLS 1.3. Mismatched TLS version support between supplicant and server, or older authenticator firmware with tight round-trip limits, can make a server upgrade look like a client failure. Test a pilot group first and keep the ability to cap the server at TLS 1.2 during rollback.

Password-based methods and Credential Guard

PEAP-MSCHAPv2 and EAP-MSCHAPv2 depend on reusable credentials, which is why Windows Credential Guard treats them like NTLMv1. Microsoft states that when Credential Guard is running, single sign-on is blocked for MS-CHAP, so devices using 802.1X wired or wireless connections that rely on it are forced to reauthenticate manually in every new Windows session. Credential Guard is enabled by default on eligible devices upgraded to Windows 11, version 22H2, and on domain-joined Windows Server 2025 servers that are not domain controllers.

• Symptom: after a Windows upgrade, machine or user SSO to Wi-Fi stops and users are prompted for credentials, or pre-logon network access fails so Group Policy and logon scripts break.
• Fix: Microsoft's resolution is to move to certificate-based authentication such as EAP-TLS or PEAP-TLS, which Credential Guard does not block. Disabling Credential Guard is the faster but less secure option and should be a time-boxed exception, not the answer.
• Other inner-method failures: wrong password or lockout (NPS reason code 16), expired passwords that the supplicant cannot change inside the tunnel, and machine account passwords out of sync with the domain.

Policy, VLAN and post-authentication problems

An Access-Accept does not mean the user has a working connection. RFC 3580 defines VLAN assignment through three RADIUS attributes: Tunnel-Type set to VLAN (13), Tunnel-Medium-Type set to 802, and Tunnel-Private-Group-ID carrying the VLAN ID as a string (1 to 4094).

Blast-RADIUS hardening side effects

CVE-2024-3596 (Blast-RADIUS) led vendors to require the Message-Authenticator attribute on Access-Request packets and to restrict Proxy-State. Turning these on protects RADIUS, but authenticators or proxies that do not send Message-Authenticator on every request, typically older firmware or non-EAP requests such as PAP-based management logins, will start failing. Plan it like any change:

1. Inventory every RADIUS client: switches, controllers, VPN concentrators, proxies.
2. Upgrade authenticator firmware so it sends Message-Authenticator, then enable the server setting in audit or auto mode where the product offers one.
3. Watch for discarded or rejected requests per client for a full business cycle, then enforce.
4. Roll back per client, not globally, if a device cannot be upgraded, and record it as an exception with an end date.

Background and the move to RADIUS over TLS are in the RADIUS Security Guide.

Packet captures that settle arguments

• Client side: filter on EAPOL to see whether the authenticator sent EAP-Request/Identity, what identity was returned and where the TLS exchange stopped.
• Server side: filter on RADIUS (UDP 1812) or EAP to see whether Access-Requests arrive, whether they carry Message-Authenticator, and whether the server answered with Access-Challenge, Accept or Reject.
• Both at once: Microsoft's guidance is to capture on the client and the server together. A request seen leaving the authenticator and never reaching the server is a network path problem, which no amount of certificate work will fix.
• Test tools: a command-line EAP test client such as eapol_test from the wpa_supplicant project can run a full EAP exchange against the server from a host configured as a RADIUS client, which separates server problems from authenticator problems.

Captures contain usernames, device identifiers and certificate details. Store them as sensitive data and delete them when the case closes.

Monitoring and measurement

Most 802.1X tickets can be prevented by watching a few signals in the SIEM or network management platform:

• Reject rate: rejects as a percentage of attempts, per site and per authenticator; alert on step changes, not absolute numbers.
• Top reject reasons: the five most common reasons each week; a new reason in the top five usually follows a change.
• Certificate expiry horizon: days to expiry for RADIUS server certificates (alert at [60] days) and the count of client certificates expiring in the next [30] days.
• RADIUS server health: requests per second, response time and dead-server events from each authenticator.
• Fallback use: share of sessions on MAB or guest fallback, which rises when supplicant profiles break.
• Mean time to resolve 802.1X tickets: should fall as runbooks and evidence collection mature.

Common failure patterns

• Server certificate renewed on the day it expired: the new certificate came from a different issuing CA that clients did not trust, and every device failed at once. Renew weeks ahead and stage the trust first.
• Turning off server validation to "fix" it: clients told not to validate the server certificate will connect to any RADIUS server, including an evil twin access point (MITRE ATT&CK T1557.004 Evil Twin). The fix becomes the vulnerability.
• Auditing switched off: NPS auditing disabled or FreeRADIUS logging reduced, so the first incident has no evidence and teams guess.
• Changing several things at once: a certificate, a policy and firmware changed in one window, so nobody knows which fixed or broke it. Change one thing and retest.
• Fixing the client for a server problem: reimaging devices when the access request never reached the server. Confirm presence in the server log first.
• Permanent exceptions: a port left in open mode or MAB "until the fix", never revisited. Give every exception an owner and an end date.

Framework mapping

Practitioner checklist

• RADIUS server auditing or logging is on, retained and searchable by MAC address, username and time.
• A known-good test device and an EAP test client are available to every escalation engineer.
• RADIUS server certificate expiry is monitored, with renewal at least [60] days before expiry and the trust chain staged on clients first.
• Client profiles pin the trusted root and the RADIUS server name; server validation is never disabled as a fix.
• Certificate chains have no more than four intermediates, and fragment size and EAP timeout settings are documented per authenticator model.
• CRL and OCSP endpoints are reachable from the RADIUS servers and monitored.
• Every RADIUS client sends Message-Authenticator, and server-side enforcement is on or scheduled with per-client exceptions recorded.
• PEAP-MSCHAPv2 is on a migration plan to certificate-based EAP before Credential Guard reaches the estate.
• Runbooks list the evidence to collect for each step of the flow, and captures are handled as sensitive data.

Standards and references

• IETF: RFC 3580, IEEE 802.1X RADIUS Usage Guidelines
• IETF: RFC 9190, EAP-TLS 1.3
• IETF: RFC 9191, Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods
• Microsoft Learn: Troubleshoot 802.1X authenticated wireless and wired access
• Microsoft Learn: Network Policy Server troubleshooting guidance
• Microsoft Learn: Credential Guard considerations and known issues
• FreeRADIUS: Troubleshooting
• FreeRADIUS: Security (BlastRADIUS guidance)

Related NHI Mgmt Group resources: the 802.1X and EAP-TLS Enterprise Wi-Fi Guide, the RADIUS Security Guide, the Network Access Control (NAC) Guide, the Wi-Fi Security Guide and the AD CS Security Guide.