IEEE 802.1X port-based network access control lets a managed Ethernet switch restrict network access until a connected device has been authenticated and authorized. A laptop can have a working cable and link light yet still be unable to reach the office network because the switch is waiting for an identity exchange. For a networking technician, the essential task is to determine whether the problem is the physical connection, the client supplicant, the switch, the authentication server, or the authorization policy—not to bypass security when a device fails to connect.

This material follows LLDP neighbor discovery and switch-port mapping in the Networking Technician curriculum. It extends Layer 2 switch security from protecting Ethernet traffic to examining how a port decides which device may use it. It assumes basic familiarity with managed Ethernet switches, switch-port troubleshooting and VLAN assignments.

Elementary Overview

A network port is like a door into a company’s computer network. The Ethernet cable is the hallway to that door, but plugging it in does not always mean the door opens. The switch may ask the connected computer to prove that it is allowed to enter. A separate authentication server checks the proof and tells the switch what access to allow.

This process is called 802.1X. A computer with approved credentials may be admitted to the correct network. A computer with expired credentials may be denied or sent to a restricted network, depending on the organization’s policy. Technicians should inspect the evidence before changing anything, because simply disabling the check could remove a deliberate protection.

The supplicant, authenticator, and authentication server

The three common operational roles are the supplicant, usually the endpoint’s authentication software; the authenticator, generally the network switch or wireless access point enforcing port access; and the authentication server, commonly a RADIUS-backed network access control service. The switch passes the authentication exchange between the endpoint and the server and then applies authorization decisions. The authentication server need not be physically next to the switch.

A device can be electrically connected but have an unauthorized controlled port. IEEE 802.1X supports restricted access while the authentication exchange occurs. The IEEE 802.1X working-group overview distinguishes controlled traffic from the exchange needed to establish authentication and, in relevant deployments, secure associations. It is important not to confuse the network’s physical link state with the access-control state.

EAPOL and RADIUS are different parts of the path

EAPOL means Extensible Authentication Protocol over LAN. On a typical wired network, the endpoint and switch exchange EAPOL frames on the local Ethernet segment. The switch then transports EAP information toward the authentication service, often using RADIUS. EAPOL is not a general Internet service or IP packet exchanged between the client and the distant RADIUS server. The IETF EAP specification defines the framework, while RADIUS support for EAP describes how EAP data can be carried across the authentication infrastructure.

A common sequence begins with link activation and an EAPOL start or identity exchange, followed by method negotiation and credential verification. The server responds with an authentication result and any supported authorization attributes. The switch can then permit the session, deny it, or place it under a defined access policy. Exactly which timers, fallback methods, VLAN assignments and states are used depends on the product and site configuration; Cisco’s wired 802.1X deployment guide provides a manufacturer example.

Wired authentication demonstration

This laboratory demonstration shows a Windows wired supplicant, an Aruba CX switch and a ClearPass RADIUS service. It includes the client certificate method, live authentication results and a policy-driven VLAN assignment, making it particularly useful for technicians learning to correlate the endpoint, access switch and authentication logs.

For a real maintenance case, first establish which device is actually attached. Compare port records with LLDP neighbors when applicable, and inspect the physical Ethernet cable and speed negotiation before investigating credentials. An LLDP neighbor may help identify an upstream device, but the absence of LLDP advertisements from a workstation is not evidence that its authentication failed.

EAP-TLS and certificate validation

EAP-TLS uses the TLS protocol to authenticate parties using certificates rather than relying solely on a network password. A client certificate identifies the endpoint or its user under the configured policy; the client must also validate the server identity and trusted certificate chain. Invalid certificates, expired validity periods, incorrect trust anchors, mismatched server names, and unsuitable certificate purposes can prevent successful authentication. RFC 5216 documents EAP-TLS, although real deployments must follow the security requirements of the specific operating system and authentication infrastructure.

A critical distinction is authentication versus authorization. Successful certificate validation may establish identity, but the policy can still deny admission or apply a limited network role. A server could accept the device yet return attributes that place it in a remediation VLAN or a restricted access-control list. Troubleshooting must therefore identify both the authentication result and the network permissions actually applied.

MAC Authentication Bypass and devices without a supplicant

Some printers, industrial controllers, phones and embedded devices cannot use the site’s preferred 802.1X supplicant. Network administrators may configure MAC Authentication Bypass (MAB) for such cases. The switch sends a device MAC address to an authentication service for policy evaluation. MAB is weaker than certificate-based authentication because Ethernet source addresses are not cryptographic credentials and can be copied or spoofed.

A technician should not assume that a session marked mab used 802.1X or that its success establishes the same assurance as EAP-TLS. The choice of an exception belongs to the security policy owner. It may require an approved device inventory, limited VLAN, restricted access-control rules, and scheduled review. Authentication and authorization method indicators should be captured before any changes.

Understanding session status

The most useful initial evidence is the switch’s authentication-session state. On supported Cisco Catalyst systems, read-only commands such as show authentication sessions or show authentication sessions interface Gi1/0/12 report the interface, MAC address, authentication method, domain, status and session identifier. Other Cisco releases and other switch vendors use different command families. The Cisco Catalyst 9000 troubleshooting reference includes examples with a successful dot1x session and with no active session.

Interpret the fields separately. dot1x is an authentication method; mab identifies MAC-based fallback. Authc Success means authentication succeeded, while Authz Success indicates authorization has been applied in the cited Cisco reporting model. A session may be authenticated but not authorized for ordinary production traffic. A missing entry might mean the port never initiated the expected authentication method, not necessarily that the remote server rejected it.

Separating physical, identity, and network failures

A structured troubleshooting sequence starts with read-only evidence. Confirm the approved ticket, switch, interface, asset identity, link state and current session status. Next inspect whether the supplicant is enabled and which authentication method and identity it is attempting. Compare relevant timestamps and session IDs across switch logs and RADIUS records. Only after a successful network authorization should the technician start diagnosing ordinary DHCP address assignment or DNS resolution as independent causes.

A packet capture can help confirm the presence or absence of local EAPOL exchanges. Use an authorized SPAN or port-mirroring session or equivalent test point, knowing that some captures omit ingress, egress, encrypted or control traffic depending on the platform. EAPOL traffic is local to the client-switch link, so a capture on an unrelated routed segment may never see those frames. Sensitive identity or credential-related captures must be handled under organizational access rules.

Video: authentication and authorization workflow

This independent instructional walkthrough explains the 802.1X actors, EAPOL, RADIUS authorization, downloadable access controls, change-of-authorization decisions and MAB exceptions. It complements the physical wired laboratory demonstration by showing how a complete identity transaction maps to the final switch-port policy.

A network access system may also support Change of Authorization (CoA) to revise a session policy after an initial decision, such as following a change in device posture. The switch may update a role or require a new authentication event. Troubleshooting should record both the original decision and any subsequent CoA event, rather than assuming that the first successful login remains the active policy for the whole session.

Worked example: a workstation with link but no access

A technician receives a ticket about a workstation on port Gi1/0/12. The interface shows link up at 1 Gb/s, and the expected MAC address appears, yet the machine cannot get a normal corporate address. The switch authentication table shows the session not authorized. The RADIUS log records an EAP-TLS rejection caused by a certificate chain that the server does not trust. The proper diagnosis is an identity-validation failure. Replacing the Ethernet cable, resetting VLAN trunking, or repeatedly renewing DHCP is not an evidence-based fix.

The authorized resolution is to send the certificate evidence to the identity or endpoint management owner, have the credential issue corrected through normal procedures, and test the session again. The technician then confirms authentication, the approved data VLAN or policy, and a successful DHCP exchange. The handoff should include the device ID, switchport, incident time, authentication method, session identifier, RADIUS failure reason and verified final state—but never an exposed private certificate key or password.

Service continuity and safe change control

An access switch may connect an IP phone, emergency endpoint, monitoring appliance or server with strict uptime requirements. Changing an authentication mode or resetting a port can interrupt the attached service. Confirm the connected system and maintenance permissions before invoking a reauthentication, clearing sessions or changing policies. Use out-of-band access where available to avoid losing management during a network change.

A temporarily unavailable RADIUS server is not the same event as an explicit credential rejection. Sites may use distinct critical-authentication or restricted-access behaviors during a server outage. Whether these mechanisms are enabled and which VLAN or access role they select are design decisions, not universal properties of 802.1X. Never switch to an open access mode simply to make a failed endpoint work.

Elementary Conclusion

802.1X helps a network switch check who or what is connected before allowing ordinary network traffic. The computer sends an identity request, the switch helps carry that request to a verification service, and the switch follows the resulting access policy. That is why a cable can work perfectly while the connected computer still has no network access.

The best technician learns to tell these failures apart. A broken cable, missing client authentication software, expired certificate, unreachable server and restricted VLAN can look similar to a user, but they need different fixes. Good records and careful checks restore access while preserving the protection the network was designed to provide.

Knowledge check

What are the three main roles in an 802.1X exchange? Why is EAPOL visible on the local link rather than at the routed RADIUS server? What does a MAB success fail to prove? Why can a certificate-valid client still have restricted access? Which records should be consulted before diagnosing a DHCP failure?

Review: The roles are supplicant, authenticator and authentication server. EAPOL carries EAP over the local LAN, while the switch usually relays information through RADIUS. MAB does not cryptographically verify device ownership. Authorization policy can restrict a successfully authenticated identity. First inspect the link, switch session, supplicant and RADIUS decision; then troubleshoot post-authorization IP configuration.

References and further reading

Primary technical references: IEEE 802.1X port-based network access control; Cisco’s wired 802.1X deployment guide; Cisco’s Catalyst session troubleshooting examples; IETF EAP framework, RFC 3748; EAP-TLS, RFC 5216; and EAP over RADIUS, RFC 3579. Apply commands and changes only after verifying the appropriate platform version and network change policy.

BitcoinVersus.Tech

BitcoinVersus.Tech publishes independent technology lessons and technical reporting.

BitcoinVersus.Tech Editor’s Note: We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support our work and help further secure the integrity of our research initiatives, please scan the QR code below to donate 5,000 sats.

For best results, display the QR code on a laptop or larger screen and scan it using a compatible Bitcoin wallet on a second device. Confirm the Bitcoin destination address before sending: 3C9o19EH5HSiwEPyCTmEKzxhNCbo2X6TTb.

BitcoinVersus.tech is not a financial advisor. This media platform reports on financial subjects purely for informational purposes.