{"id":1212,"date":"2026-04-13T21:01:09","date_gmt":"2026-04-14T01:01:09","guid":{"rendered":"https:\/\/casioaktech.com\/?p=1212"},"modified":"2026-04-14T14:06:41","modified_gmt":"2026-04-14T18:06:41","slug":"extensible-authentication-protocol-eap-quick-reference-guide","status":"publish","type":"post","link":"https:\/\/casioaktech.com\/index.php\/2026\/04\/13\/extensible-authentication-protocol-eap-quick-reference-guide\/","title":{"rendered":"Extensible Authentication Protocol (EAP) Quick Reference Guide"},"content":{"rendered":"\n

In this guide I want to break down the different Extensible Authentication Protocol (EAP) methods, and their use cases. This guide isn’t a deep dive into the framework itself, but rather a quick way to understand which method best fits your current situation. Let’s have a quick introduction to the protocol.


Extensible Authentication Protocol<\/strong>

EAP is a framework of the authentication process, it allows the authentication server to select an authentication method supported by the Supplicant<\/em>. This includes transporting the challenges, responses, and messages, which may include or protect credentials depending on the method used.<\/p>\n\n\n\n


The supplicant is client software running on a device that provides user or device credentials, this may be built into the operating system itself, or 3rd party. The authentication server is most commonly a Remote Authentication Dial-In User Service (RADIUS) server. A RADIUS server is used for Authentication, Authorization, and Accounting (AAA).

Authentication<\/em><\/strong> – Confirms who the device\/user is using a username\/password or certificate.
Authorization<\/strong><\/em> – Determines what that device\/user can access.
Accounting<\/strong><\/em> – Logging\/Tracking activity (logon\/logoff times, duration, etc.)

EAP does NOT<\/span><\/strong><\/em> verify the identity of the supplicant. The authentication is completed through one of the methods carried inside this protocol. The goal of this guide is to help you understand which best fits different situations, and the pros and cons of the most widely adopted methods.
<\/p>\n\n\n\n


***I won’t go into much detail to avoid confusion with terms, But it is important to note that the Supplicant does not communicate directly to the authentication server. These messages are relayed by the Authenticator<\/strong> at layer 2 such as a switch or access point using Extensible Authentication Protocol over LAN (EAPoL) over both wired and wireless networks. These messages are then forwarded to the authentication server using RADIUS at layer 3.***<\/em>

DISCLAIMER: This is NOT<\/span> a complete list of all EAP methods!!!<\/strong><\/em><\/p>\n\n\n\n

Common EAP Methods<\/strong><\/p>\n\n\n\n

EAP-TLS (Transport Layer Security)<\/h2>\n\n\n\n

This method uses two certificates, one for the supplicant, the other for the authentication server; both of which need to be valid and trusted.
This is the most secure method in common use today as it uses TLS to create an encrypted tunnel and removes the need for username\/password authentication used in other methods like (PEAP & EAP-TTLS) altogether. <\/p>\n\n\n\n


Why would you want to use a certificate instead of a password?<\/em><\/p>\n\n\n\n

Stubby Answer: To reduce the available attack surface.<\/p>\n\n\n\n

Not So Stubby Answer: Even though TLS creates an encrypted tunnel, password-based authentication methods still rely on shared secrets and credential-derived exchanges. Even when this data is encrypted there are still ways of capturing the authentication exchange with Man in the Middle or On Path attacks. This occurs when sensitive data between two devices is intercepted in the middle, captured and sent on as if nothing has happened.
Your next thought might be.. “Why is this a big deal? Isn’t the data encrypted with TLS?” <\/p>\n\n\n\n

Yes it is. However the attacker now has a copy of the authentication exchange. This can then be subjected to offline brute-force or dictionary attacks using commonly available tools such as Hashcat or John the Ripper.
This risk is especially relevant if the client does not properly validate the authentication server\u2019s certificate, allowing an attacker to impersonate a legitimate network.
EAP-TLS eliminates this concern by not relying on password based authentication at all with the use of a certificate to authenticate the supplicant.

This is by far the most secure EAP method in use today; and should be your first choice if adoption is possible in your environment.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n



The increased security comes at a significant cost though; This means every device you want to access your network will need a certificate issued to it. This can be a challenge to implement when you have thousands of devices. This can be managed with your preferred Mobile Device Management (MDM) software for your Microsoft, Apple, and Google devices. I won’t get into specific MDM tools in this article for brevity; But the key to making this method viable is a centralized tool that allows you to install valid certificates on the supplicant devices.
Although being able to deploy a certificate to your favorite WiFi enabled smart toilets, or Becky from finance’s macbook she got for Christmas last year isn’t exactly an easy process without centralized management tools.

What is EAP-TLS not ideal for?

Internet of Things (IoT) devices like your smart toilet that often lack good security practices; and likely won’t even support this method of authentication.
Bring Your Own Devices (BYOD) such as personal laptops, smartphones, tablets, etc. People don’t appreciate the IT department touching their personal devices; and it is not an effective use of IT resources.<\/p>\n\n\n\n

Primary Use Case:<\/strong>
Centrally managed devices that support supplicant certificates.
Windows PCs, Apple devices & Chromebooks<\/p>\n\n\n\n

\n
\n

Pros<\/strong><\/p>\n\n\n\n