802.1X and EAP Explained: Port-Based Network Access Control

IEEE 802.1X is the standard for port-based network access control: a switch port or Wi-Fi association stays closed to normal traffic until the connecting device proves who it is. The proof runs over EAP, the Extensible Authentication Protocol (RFC 3748), carried as EAPOL frames on the LAN and inside RADIUS to a central authentication server, which tells the switch or access point to open the port.

That is the short answer. The longer one matters because 802.1X is three protocols stacked on top of each other, and most real failures happen at the seams: a laptop that never checks which server it is talking to, a switch that trusts a RADIUS reply it cannot properly authenticate, or a port that is opened for one device and then quietly shared with another. This post walks through the roles, the frames on the wire, the EAP methods you will actually choose between, how the keys feed WPA2 and WPA3-Enterprise and MACsec, the weakness classes as concepts, and the configuration checks a defender can run. Every number and default here was checked against the IEEE page, the RFCs, NIST, or the official hostapd, wpa_supplicant, FreeRADIUS and Microsoft documentation on 23 October 2026.

If you came here deciding between certificates and a shared Wi-Fi password, the narrower post on Wi-Fi certificates vs shared passwords covers that choice. This post is the protocol underneath it.

Key takeaways

• IEEE 802.1X-2020 (published 28 February 2020, superseding 802.1X-2010) defines port-based network access control and the protocols that set up IEEE 802.1AE MAC Security (MACsec) associations. It does not define authentication methods; EAP methods do.
• Three roles: the supplicant (the device asking for access), the authenticator (the switch or access point that controls the port) and the authentication server (usually a RADIUS server). The authenticator is mostly a relay; the real conversation is between supplicant and server.
• On the LAN, EAP rides in EAPOL frames with EtherType 0x888E, often sent to the PAE group address 01:80:C2:00:00:03. Between authenticator and server, EAP rides in RADIUS EAP-Message attributes, protected by Message-Authenticator (RFC 3579).
• EAP-TLS (RFC 5216, March 2008, updated for TLS 1.3 by RFC 9190, February 2022) uses certificates on both sides and is the strongest common method. PEAP and EAP-TTLS build a TLS tunnel with only a server certificate and run a password method inside it.
• The single most common weakness is a client that does not validate the server certificate and name. wpa_supplicant's own documentation says that without a CA configured the "server certificate will not be verified. This is insecure."
• A successful EAP run exports a Master Session Key of at least 64 octets (RFC 5247). In Wi-Fi, the first 32 octets become the Pairwise Master Key used in the 4-way handshake. On wired links, MACsec Key Agreement can turn it into link encryption; without that, 802.1X authenticates the link once and protects nothing afterwards.

What 802.1X and EAP are for: the layer and the standards

The problem it solves

A network jack in a meeting room or an open Wi-Fi association gives whoever connects a place on your LAN. Before 802.1X, the usual answer was physical security, MAC address lists, or a single shared key. None of those identify a user or device in a way you can revoke individually. The IEEE 802.1X page describes the purpose plainly: port-based network access control "allows a network administrator to restrict the use of IEEE 802(R) LAN service access points" and to secure communication between authenticated devices.

The idea is simple. Each port, physical or logical, has a controlled side and an uncontrolled side. Before authentication, only authentication frames are allowed through the uncontrolled side. After the server says yes, the controlled side opens and normal traffic flows, often placed into a VLAN the server chose.

Where it sits

802.1X lives at the link layer. EAPOL is not IP traffic: it is an Ethernet frame type with its own EtherType, so a device with no IP address can authenticate. EAP itself is a framework that sits on top of whatever "lower layer" carries it. RFC 3748 notes EAP was developed for PPP dial-up and later adapted for wired IEEE 802 networks in 802.1X. Between the authenticator and the server, EAP travels inside RADIUS, which runs over UDP at the application layer. So a single login crosses link layer framing on one side and an IP application protocol on the other.

The defining standards

The 802.1X standard itself is an IEEE document; the RFCs are the IETF side. In practice you need both: the IEEE text for the port model and EAPOL, the RFCs for EAP, its methods and RADIUS.

The three roles: supplicant, authenticator, authentication server

Supplicant. Software on the connecting device. On Linux this is usually wpa_supplicant (which handles wired 802.1X as well as Wi-Fi); Windows, macOS, iOS and Android have their own built in supplicants. The supplicant holds the credential, a certificate and private key or a username and password, and the settings that decide which server it will trust.

Authenticator. The switch port or access point. It controls the port state and relays EAP between the supplicant and the server. RFC 3748 calls this "pass-through" behaviour: the authenticator does not need to understand the EAP method, only the outer packet. hostapd is the open source authenticator used in many Linux based access points, and it also supports wired authentication with driver=wired.

Authentication server. The EAP server, normally inside a RADIUS server such as FreeRADIUS. It runs the EAP method, checks the credential, and returns Access-Accept or Access-Reject, plus authorisation attributes such as a VLAN and the session key material.

One consequence of this split is spelled out in RFC 3748 section 7.13: authentication happens "between the peer and the authentication server, not between the peer and the authenticator." The supplicant cannot verify which switch or access point it is talking to using EAP alone. That is why the later key handshake (the Wi-Fi 4-way handshake, or MACsec key agreement on wired links) matters: it proves the authenticator actually received the key from the server.

How it works on the wire

The EAPOL exchange, start to finish

Here is a typical wired or Wi-Fi exchange with a TLS based method. Arrows show direction; the authenticator translates between EAPOL on the left and RADIUS on the right.

Supplicant                  Authenticator (switch/AP)            RADIUS server
    |                                |                                  |
    |-- EAPOL-Start (optional) ----->|                                  |
    |<-- EAP-Request/Identity -------|                                  |
    |-- EAP-Response/Identity ------>|-- Access-Request ---------------->|
    |   (often anonymous@realm)      |   EAP-Message + Msg-Authenticator |
    |                                |<-- Access-Challenge --------------|
    |<-- EAP-Request/TLS (Start) ----|   EAP-Message                     |
    |-- EAP-Response/TLS ClientHello>|-- Access-Request ---------------->|
    |<-- EAP-Request/TLS ServerHello,|<-- Access-Challenge --------------|
    |    certificate, ...            |                                  |
    |   ... more round trips, TLS handshake completes ...               |
    |                                |<-- Access-Accept -----------------|
    |                                |   EAP-Success, VLAN attributes,   |
    |                                |   key material for the port       |
    |<-- EAP-Success ----------------|                                  |
    |== Wi-Fi: 4-way handshake (EAPOL-Key) / Wired: MKA if MACsec ======|
    |   Controlled port opens; normal traffic flows                     |
    |-- EAPOL-Logoff (on disconnect)>|-- Accounting-Stop --------------->|

A few rules from RFC 3748 shape this flow. EAP is a lock-step protocol: one packet outstanding at a time, the authenticator drives retransmission, and the Identifier field matches each Response to its Request. EAP needs a lower layer with an MTU of at least 1020 octets and has no path MTU discovery, so methods that carry certificates (EAP-TLS and the tunnelled methods) fragment their own messages. RFC 3748 also says EAP does not permit untunnelled sequences of methods, because a peer could not prove that the same server handled every method in the chain.

On the RADIUS side, RFC 3748 (citing RFC 3579) says the authenticator relies on the RADIUS result to learn the outcome and does not look inside the encapsulated EAP packet. RFC 3580 repeats this: the authenticator should make the decision "solely based on the authentication result".

EAPOL frame layout

The EAPOL header is four octets, carried in an Ethernet frame with EtherType 0x888E. hostapd's source defines the same structure and type values.

On wired ports, hostapd's documentation describes sending EAPOL to the PAE group address 01:80:C2:00:00:03 as "the most common mechanism used in wired authentication", and adds a condition worth remembering: it "requires that the port is only used by one station."

EAP packet layout

Inside an EAP-Packet, RFC 3748 section 4 defines the format.

Every implementation must support Types 1 to 4. Nak (Type 3) is how a peer says "I will not do that method, here is what I would accept", which is also where negotiation can go wrong if a peer is too willing to accept something weak.

Ports and registrations

How RADIUS carries EAP and authorisation

RFC 3579 adds two attributes to RADIUS. EAP-Message (attribute 79) carries EAP packets, split across several attributes if needed. Message-Authenticator (attribute 80) is an HMAC-MD5 over the whole packet keyed with the RADIUS shared secret. RFC 3579 says it "MUST be used in any Access-Request, Access-Accept, Access-Reject or Access-Challenge that includes an EAP-Message attribute," and a server must silently discard a packet whose value is wrong.

RFC 3580 then describes how 802.1X uses ordinary RADIUS attributes:

• NAS-Port-Type tells the server what kind of port this is: Ethernet (15) or Wireless IEEE 802.11 (19).
• Called-Station-Id carries the switch or access point MAC address, and Calling-Station-Id carries the supplicant's MAC address.
• Tunnel-Type=VLAN (13), Tunnel-Medium-Type=802 and Tunnel-Private-Group-ID tell the authenticator which VLAN to place the device in. The VLAN ID is 12 bits, 1 to 4094.
• Session-Timeout with Termination-Action set to RADIUS-Request tells the authenticator when to re-authenticate rather than disconnect.

The RADIUS protocol itself, its shared secret and its MD5 based protections are covered in depth in how the RADIUS protocol works and how to secure it. For 802.1X the key point is that the authenticator trusts whatever the server sends back, so the RADIUS hop must be authenticated and integrity protected. RFC 3748 section 7.13 says the AAA protocol between authenticator and server "MUST support per-packet authentication, integrity, and replay protection."

Port states and re-authentication

Ports move between unauthorised and authorised. RFC 3580's accounting section lists the reasons a session ends, including re-authentication failure, an administrator forcing the port into the unauthorised state, and the port being disabled. hostapd's default re-authentication period is 3600 seconds (eap_reauth_period), and it documents that setting it to 0 disables re-authentication.

EAP methods compared

EAP is a framework; the method decides what is actually proven. The methods you will meet fall into three groups.

EAP-TLS: certificates on both sides

EAP-TLS (Type 13) runs a full TLS handshake inside EAP. The server presents a certificate, the client presents a certificate, and both prove possession of their private keys. There is no password to phish or replay. RFC 5216 (March 2008) defined it for TLS 1.0 to 1.2. RFC 9190 (February 2022) brought it to TLS 1.3 and, in its own words, "always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking."

The TLS 1.3 version changes several details defenders should know:

• Revocation is mandatory. With TLS 1.3, "the revocation status of all the certificates in the certificate chains MUST be checked (except the trust anchor)." EAP-TLS servers supporting TLS 1.3 must implement OCSP stapling, because the client usually has no network access yet and cannot reach an OCSP responder itself.
• No early data, no post-handshake authentication. RFC 9190 forbids TLS 1.3 0-RTT data and post-handshake client authentication in EAP-TLS.
• A commitment message. Because TLS 1.3 can send session tickets after the handshake, the server sends one byte of TLS application data, 0x00, to signal that it will send no more handshake messages.
• Key export. Key material is derived with the TLS exporter using the label EXPORTER_EAP_TLS_Key_Material, instead of the TLS 1.2 era pseudo random function.
• Server name matching. RFC 9190 says peers should be configured with trusted root CAs and one or more server names to match against the certificate's SubjectAltName. It warns that without name matching against a public root CA, "effectively any server can obtain a certificate that will be trusted."
• Anonymous outer identity. It recommends anonymous Network Access Identifiers such as @realm in the cleartext Identity response, so the user's name is not exposed before TLS starts.

RFC 9965 (May 2026) later updated both RFC 5216 and RFC 9190 to define the eap.arpa domain, which lets a peer signal that it wants limited, unauthenticated provisioning access, for example to enrol a certificate.

Tunnelled methods: PEAP, EAP-TTLS, EAP-FAST and TEAP

Tunnelled methods build a TLS tunnel where only the server presents a certificate, then run a second "inner" authentication inside it, usually a password.

• PEAP (Type 25) is defined by a Microsoft open specification rather than an RFC. Its common form carries EAP-MSCHAPv2 inside the tunnel. RFC 9427 (June 2023) specifies how PEAP and the other TLS based methods derive keys when used with TLS 1.3.
• EAP-TTLS version 0 (Type 21, RFC 5281, August 2008, Informational) tunnels RADIUS style attribute value pairs, so the inner method can be legacy PAP, CHAP, MS-CHAP, MS-CHAPv2 or an EAP method. The outer identity can be anonymous; the real identity travels only inside the tunnel.
• EAP-FAST (Type 43, RFC 4851, May 2007, Informational) is another tunnelled method; RFC 8996 and RFC 9427 update it. FreeRADIUS 3.2 notes it does not support TLS 1.3 for EAP-FAST.
• TEAP (Type 55) is the standards track tunnel method. TEAP version 1 was first published as RFC 7170 (May 2014) and is now RFC 9930 (February 2026), which obsoletes RFC 7170 and moves all TEAP text out of RFC 9427. Inside the tunnel it exchanges TLV objects, including a Crypto-Binding TLV that ties the inner authentication to the tunnel.

RFC 9427 also cleans up weak inner choices. It recommends deprecating inner methods that give no protected success or failure indication (inner PAP, CHAP and MS-CHAPv1 in EAP-TTLS) and says implementations "SHOULD use MS-CHAPv2 or EAP-MSCHAPv2 instead of MS-CHAPv1."

Methods to avoid on their own

EAP-MD5 (Type 4) is a bare challenge and response: no server authentication, no key material for encryption, and it is open to offline guessing if captured. RFC 3748 section 7.14 explains that EAP deliberately defines no cleartext password method, and that cleartext passwords "cannot be securely used within EAP, except where encapsulated within a protected tunnel with server authentication." The wpa_supplicant README still shows an EAP-MD5 wired example, which is useful as a lab test but not as a production design.

Method comparison table

The practical summary: EAP-TLS removes the password from the protocol. Every tunnelled method is only as strong as the client's decision about which server to trust.

How 802.1X keys feed WPA2, WPA3-Enterprise and MACsec

The EAP key hierarchy

RFC 5247 defines what a key generating EAP method hands to the lower layer. The Master Session Key (MSK) is at least 64 octets and may be passed from the EAP server to the authenticator over the AAA protocol. The Extended Master Session Key (EMSK) is also at least 64 octets and "is never shared with a third party." RFC 3748 makes the same distinction: the peer derives keys locally, while a separate authenticator has to receive key material from the server over the AAA protocol.

Wi-Fi: from MSK to the 4-way handshake

RFC 5247 explains that in IEEE 802.11, octets 0 to 31 of the MSK become the Pairwise Master Key (PMK). The access point and client then run the 802.11 4-way handshake using EAPOL-Key frames (EAPOL type 3) to prove both hold the PMK and to derive fresh traffic keys. This is the "secure association protocol" RFC 3748 asks for after EAP: it proves the access point is the one the server gave the key to, and it binds the keys to this association.

RFC 3580, written in 2003, noted that 802.1X itself "does not describe how to securely adapt IEEE 802.1X for use with 802.11" and left that to the then upcoming 802.11 security work. That work became WPA2-Enterprise. NIST SP 800-97 (February 2007) was the US government guide to it; NIST withdrew it on 31 December 2025 as technologically outdated and points readers to IEEE 802.11 itself.

The enterprise modes keep 802.1X and EAP for authentication; wpa_supplicant's key management list describes WPA-EAP as "WPA using EAP authentication". The Wi-Fi Alliance security page says WPA3 networks require Protected Management Frames and that PMF is "required for all new certified devices." In wpa_supplicant terms that means ieee80211w=2 with key_mgmt=WPA-EAP-SHA256 for PMF required, and the configuration file also documents WPA-EAP-SUITE-B and WPA-EAP-SUITE-B-192 key management for the higher security modes. For how the radio generations and security modes line up over time, see Wi-Fi generations from 802.11b to Wi-Fi 7 and Wi-Fi 8, and for the office Wi-Fi view of the change, WPA2 vs WPA3.

Wired: MACsec Key Agreement

On a wired port, plain 802.1X has a gap: once the port is authorised, nothing ties later frames to the device that authenticated. The IEEE 802.1X-2020 scope addresses this by covering the protocols "used to discover and establish the security associations used by IEEE 802.1AE(TM) MAC Security." That protocol is MACsec Key Agreement (MKA), and it rides in EAPOL type 5 frames with EAPOL version 3.

wpa_supplicant documents the supplicant side. macsec_policy=1 enables MACsec, macsec_integ_only chooses between encryption (default) and integrity only, and macsec_replay_protect enables replay protection, which the configuration file lists as disabled by default. A pre-shared mode uses a Connectivity Association Key (CAK) of 128 or 256 bits and a CAK Name (CKN). The alternative to a configured pre-shared CAK is to key MKA from the EAP session, which avoids a shared secret across ports; check your switch and supplicant documentation for which mode they support.

Versions and history

What is actually deployed today is a mix. EAP-TLS and PEAP with EAP-MSCHAPv2 dominate enterprise Wi-Fi. TLS 1.2 is still the common ceiling inside EAP: FreeRADIUS 3.2's shipped EAP configuration sets tls_min_version = "1.2" and tls_max_version = "1.2" and warns that many supplicants do not yet handle TLS 1.3 properly, while wpa_supplicant's configuration file describes tls_disable_tlsv1_3=0 as enabling TLS 1.3 and labels it "experimental - disabled by default". So RFC 9190 is the standard, but turning it on is a deliberate, tested change rather than a default.

Security properties and weakness classes

What 802.1X and EAP guarantee, and what they do not

RFC 3748 section 7.1 lists ten attacker goals in its threat model, from snooping identities to forcing weak methods, downgrading ciphersuites, and an attacker acting as an authenticator feeding wrong information to peer or server. That list is a good checklist for reviewing any design.

The weakness classes below are explained as concepts so you can recognise them in your own configuration. None of this is a how-to.

Client does not validate the server certificate

This is the big one for PEAP and EAP-TTLS. The client sends its password, or a response derived from it, through a TLS tunnel. If the client accepts any certificate, or any certificate from a public CA without checking the server name, then a rogue access point broadcasting the same network name can terminate the tunnel itself and receive the inner credential. RFC 3748 section 7.4 describes the general form: where EAP is tunnelled inside a protocol that does not require peer authentication, a rogue authenticator can sit in the middle. RFC 9190's server name guidance exists for the same reason. The broader pattern of trusting a certificate without checking who it belongs to is covered in certificate validation bypass and man in the middle risk.

Credential capture with inner MSCHAPv2

MSCHAPv2 is a challenge and response scheme built on a hash of the password; wpa_supplicant's documentation notes the stored form is a 16 byte MD4 based NtPasswordHash. If a client completes an inner MSCHAPv2 exchange with a server it should not trust, the captured exchange can be attacked offline to recover the hash or the password. RFC 3748 section 7.6 calls this out as offline dictionary attack exposure. The fix is not a better password; it is server validation on every client, and moving to EAP-TLS where you can.

Tunnel without binding

RFC 3748 lists the defences for tunnelled methods: mutual authentication inside the tunnel, cryptographic binding between the tunnel and the inner method, limiting which methods may run unprotected, and avoiding tunnels when a single strong method is available. TEAP includes cryptographic binding; older tunnelled deployments may not.

MAC authentication bypass as a fallback

Many devices, such as printers, phones and building systems, cannot run a supplicant. A common fallback is to authenticate by MAC address: the authenticator sends the device's MAC as Calling-Station-Id to RADIUS and the server looks it up. A MAC address is an identifier, not a secret. It is visible on the wire and can be set in software, so MAC based admission is equivalent to an allow list, not authentication. Treat those ports as lower trust and give them narrow VLANs.

Hub or second device behind an authorised port

802.1X authorises a port at the moment of authentication. On a wired port without MACsec, the switch then forwards frames; nothing in each frame proves it came from the authenticated device. If a small switch, a hub or an inline device sits between the authenticated host and the wall port, other traffic can share the open port. hostapd's note that the PAE group address method "requires that the port is only used by one station" is the implementation side of the same fact. Switch features that limit a port to one host or one MAC, and MACsec, are the structural answers. For how physical and Wi-Fi taps work in general, see how attackers intercept network traffic over copper, fiber and Wi-Fi.

Weak or forgeable RADIUS hop

The authenticator acts on Access-Accept. If the RADIUS hop crosses an untrusted network, uses a short shared secret, or accepts responses without Message-Authenticator, its decisions can be undermined. RFC 3580 section 5.2 points out the shared secret is open to offline dictionary attack from a captured packet and repeats RFC 2865's advice that it be "at least 16 octets". CVE-2024-3596, published 9 July 2024, describes RADIUS responses being forged by "a chosen-prefix collision attack against MD5 Response Authenticator signature." FreeRADIUS's configuration notes call requiring Message-Authenticator "the number one way to protect yourself" from that issue. RFC 9765 (April 2025, Experimental) goes further and defines RADIUS/1.1 over TLS with all MD5 based protection removed.

Negotiation and downgrade

EAP lets the peer reject a method with a Nak and suggest another. A supplicant configured to accept several methods, including weak ones, can be steered towards the weakest. RFC 3748 lists this as attack goal 6. The defence is to configure each client profile with exactly the method you intend.

Outer identity leakage

The EAP Identity response is sent before any tunnel exists. Without an anonymous outer identity, usernames are visible to anyone who can see EAPOL or RADIUS traffic. RFC 9190 recommends anonymous NAIs, and EAP-TLS with TLS 1.3 never discloses the peer identity in the clear.

Secure configuration, with defender-side checks

Only run these commands against systems you own or are authorised to test. Each comes from the implementation's official documentation, linked in Sources.

Supplicant settings that matter

For wpa_supplicant, these options in the network block decide whether the client can be tricked:

A minimal EAP-TLS profile for a wired port looks like this (paths and names are placeholders):

ap_scan=0
network={
    key_mgmt=IEEE8021X
    eap=TLS
    identity="anonymous@example.com"
    ca_cert="/etc/wpa_supplicant/radius-ca.pem"
    domain_match="radius.example.com"
    client_cert="/etc/wpa_supplicant/host.pem"
    private_key="/etc/wpa_supplicant/host.key"
    phase1="tls_disable_tlsv1_0=1 tls_disable_tlsv1_1=1"
}

For Wi-Fi, use key_mgmt=WPA-EAP-SHA256 with ieee80211w=2 to require Protected Management Frames, as the wpa_supplicant configuration file documents.

Check the live state of a supplicant:

# Current WPA/EAPOL/EAP state: shows EAP state, method, and whether the port is authorised
wpa_cli -i eth0 status

# 802.1X and 802.11 MIB counters
wpa_cli -i eth0 mib

The wpa_supplicant README lists status as "get current WPA/EAPOL/EAP status" and mib as "get MIB variables (dot1x, dot11)".

On Windows, Microsoft Learn documents these read only netsh lan checks for wired 802.1X:

netsh lan show interfaces
netsh lan show profiles
netsh lan show settings

The profile output shows whether 802.1X is enabled and enforced (oneXEnabled and oneXEnforced in netsh lan set profileparameter) and the authentication mode, such as machine only or machine or user. For Wi-Fi profiles, review the server validation settings that your management tooling pushes, since a profile without a trusted root and server name has the same weakness described above.

Authenticator settings that matter

In hostapd, the 802.1X and RADIUS settings to review are:

Check the authenticator's view of connected stations and port state:

# Overall interface and authenticator status
hostapd_cli -i wlan0 status

# Every station with its 802.1X and key state
hostapd_cli -i wlan0 all_sta

# 802.1X and RADIUS client MIB counters
hostapd_cli -i wlan0 mib

For managed switches, use the vendor's own command reference for the equivalent port authentication status view; the questions to answer are the same: which ports are in forced authorised mode, which allow multiple hosts, and which fall back to MAC based admission.

Authentication server settings that matter

In FreeRADIUS 3.2, the EAP module and client definitions hold the settings to review:

• In mods-available/eap, tls_min_version should be at least "1.2". The shipped file sets both minimum and maximum to 1.2 and explains why it does not default to 1.3.
• Set default_eap_type to the method you actually use. The shipped default is md5 at the top level, which is a lab convenience, not a production choice.
• If you use EAP-TLS, set check_crl or OCSP checking so revoked client certificates fail.
• In clients.conf, give each authenticator a long random secret (the shipped testing123 is for testing only, as the file says), and set require_message_authenticator = yes. The global default in radiusd.conf is in the security section.

Check the configuration and watch an authentication in a test environment:

# Check the configuration and exit; nonzero status means a problem
radiusd -XC

# Run in the foreground in full debug mode (test systems only)
radiusd -X

The radiusd man page describes -C as "Check the configuration and exit immediately" and notes the check is incomplete, so a clean result is necessary but not sufficient. It recommends radiusd -X when learning how the server behaves and raddebug for production servers. Debug output can include identities and protocol detail, so treat it as sensitive.

Network design and monitoring

NIST SP 800-153 (February 2012) adds design level guidance that still applies:

• Separate WLANs for each security profile, such as guest and internal, and keep devices on one from reaching the other.
• Have a policy on dual connected clients (wired and wireless at once, or several wireless networks), because a compromised wireless path can reach the wired side.
• Standardise, automate and centralise client and access point configuration so drift is detected and corrected.
• Monitor for attacks and vulnerabilities continuously, assess at least annually, and run periodic assessments at least quarterly unless continuous monitoring already covers it.

When to use 802.1X versus the alternatives

These are not exclusive. A common pattern is 802.1X with EAP-TLS for managed devices, MAC based admission into a locked down VLAN for devices that cannot do better, a separate personal mode network for guests, and application level access controls on top so that getting a LAN address is never enough on its own.

Common mistakes

• Leaving server validation off on clients. The single most damaging setting, and it is often the default on unmanaged devices when users are asked to "trust" a certificate prompt.
• Trusting a public CA without a server name. RFC 9190 is explicit that any server can obtain such a certificate. Use a private CA for RADIUS, or at least pin the exact name.
• Treating 802.1X on wired ports as encryption. Without MACsec it is admission control only.
• Allowing multiple hosts per port by default. Fine for a desk phone with a PC behind it when configured deliberately; risky as a blanket setting.
• MAC based admission into the main VLAN. That turns an allow list into a back door.
• Weak or reused RADIUS shared secrets. RFC 2865 asks for at least 16 octets; use longer random values, unique per authenticator, or move to RADIUS over TLS.
• Not requiring Message-Authenticator. Both hostapd and FreeRADIUS now default to requiring it in key cases; check older configurations and appliances.
• Leaving lab defaults in production. default_eap_type = md5 and secret = testing123 exist in shipped files for testing.
• No revocation path. If you cannot revoke a lost laptop's certificate and have the server reject it, EAP-TLS loses much of its value.
• Assuming TLS 1.3 is on. Check what your server and every client family negotiate before relying on RFC 9190's guarantees.
• Forgetting the software underneath. Supplicants, authenticators and RADIUS servers are built on TLS and crypto libraries that get vulnerabilities like any other dependency.

FAQ

What is 802.1X in simple terms?

It is a standard that keeps a network port or Wi-Fi connection closed until the connecting device proves who it is. The switch or access point asks for credentials over EAP, forwards them to a RADIUS server, and opens the port only if the server says yes.

What is the difference between 802.1X and EAP?

802.1X is the IEEE standard that controls ports and defines EAPOL, the way EAP is carried on a LAN. EAP (RFC 3748) is the IETF authentication framework, and EAP methods such as EAP-TLS or PEAP define how the credential is actually checked. 802.1X without EAP has nothing to authenticate with; EAP without a lower layer has nothing to run on.

What port does 802.1X use?

On the LAN, none in the TCP or UDP sense: EAPOL is an Ethernet frame type, 0x888E. Behind the switch or access point, RADIUS uses UDP 1812 for authentication and UDP 1813 for accounting, and RADIUS over TLS uses TCP 2083.

Is 802.1X encrypted?

The authentication itself is protected when you use a TLS based method such as EAP-TLS, PEAP or EAP-TTLS. The data you send afterwards is encrypted only if the link adds it: Wi-Fi does through WPA2 or WPA3-Enterprise keys derived from the EAP session, while wired Ethernet does only if MACsec is configured.

What is the difference between a supplicant, an authenticator and an authentication server?

The supplicant is the client software on the device. The authenticator is the switch or access point that controls the port and relays messages. The authentication server, usually RADIUS, checks the credential and decides.

EAP-TLS vs PEAP: which should I use?

EAP-TLS uses a certificate on the client as well as the server, so there is no password to capture, and it is the stronger choice. PEAP uses a password inside a TLS tunnel and is easier to roll out, but its security depends entirely on every client validating the server certificate and name.

Does WPA3-Enterprise still use 802.1X?

Yes. WPA3-Enterprise uses 802.1X and EAP for authentication, and the Wi-Fi Alliance requires Protected Management Frames on WPA3 networks.

What is MAC authentication bypass?

It is a fallback where the switch admits a device that cannot run 802.1X by sending its MAC address to the RADIUS server for lookup. It is convenient for printers and similar devices, but a MAC address is not a secret, so those devices should land in restricted network segments.

Can 802.1X work without RADIUS?

The 802.1X model only needs an authentication server, and some authenticators can run one internally; hostapd documents an integrated EAP server that processes EAP "without need for an external RADIUS server." In enterprise networks RADIUS is the normal choice because it centralises policy, logging and VLAN assignment.

Does EAP-TLS support TLS 1.3?

Yes, RFC 9190 (February 2022) defines EAP-TLS with TLS 1.3, adding mandatory revocation checking and identity privacy. Support in deployed clients and servers varies, so test before switching it on.

Fix it without waiting for upstream

The protocols in this post are implemented by software you deploy and depend on: supplicants, hostapd based access points, RADIUS servers and the TLS libraries underneath all of them, often shipped inside containers or appliance images. When one of those components has a vulnerability, the same remediation gaps apply as for any other dependency.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard does not sit on the wire, inspect EAPOL or RADIUS traffic, or act as a network access control system. What it does, and what these demos show, is tell you which versions of the software behind your 802.1X stack you are running and help you move them to fixed versions. Software composition analysis with a full transitive dependency inventory, SBOM generation in SPDX and CycloneDX, container scanning and vulnerability management with EPSS and KEV enrichment are generally available. You can download Safeguard and follow the CLI docs to try them.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at the container image you use for a RADIUS server, the same scan lists the server package and the TLS and crypto libraries inside it, with versions and known vulnerabilities, so you know what is really answering your Access-Requests.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the package to bump is a TLS library or a RADIUS server version pinned in a Dockerfile or manifest you maintain.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects or images include a particular version of a TLS library or RADIUS server, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEEE 802.1X-2020: Port-Based Network Access Control
• RFC 3748: Extensible Authentication Protocol (EAP), June 2004
• RFC 3579: RADIUS Support For EAP, September 2003
• RFC 3580: IEEE 802.1X RADIUS Usage Guidelines, September 2003
• RFC 2865: Remote Authentication Dial In User Service (RADIUS), June 2000
• RFC 5216: The EAP-TLS Authentication Protocol, March 2008
• RFC 9190: EAP-TLS 1.3, February 2022
• RFC 5281: EAP-TTLSv0, August 2008
• RFC 5247: EAP Key Management Framework, August 2008
• RFC 4851: EAP-FAST, May 2007
• RFC 7170: TEAP Version 1, May 2014
• RFC 9930: TEAP Version 1, February 2026
• RFC 9427: TLS-Based EAP Types for Use with TLS 1.3, June 2023
• RFC 9965: The eap.arpa. Domain and EAP Provisioning, May 2026
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1, March 2021
• RFC 9765: RADIUS/1.1, April 2025
• IANA: Extensible Authentication Protocol (EAP) Registry
• CVE-2024-3596 on cve.org
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks, February 2012
• NIST SP 800-97: Establishing Wireless Robust Security Networks (withdrawn 31 December 2025)
• Wi-Fi Alliance: Security
• hostapd: hostapd.conf reference configuration
• hostapd: hostapd_cli command table
• hostapd and wpa_supplicant: EAPOL definitions (eapol_common.h)
• hostapd and wpa_supplicant: common definitions including the EAPOL EtherType (common.h)
• wpa_supplicant: wpa_supplicant.conf reference configuration
• wpa_supplicant: README
• FreeRADIUS 3.2: EAP module configuration
• FreeRADIUS 3.2: clients.conf
• FreeRADIUS 3.2: radiusd.conf
• FreeRADIUS 3.2: radiusd man page
• Microsoft Learn: netsh lan

Last reviewed: 23 October 2026. TLS 1.3 support inside EAP varies by client and server version; check your implementation's documentation before relying on it.