WPA2-Enterprise and 802.1X Simplified

Simplifying WPA2-Enterprise and 802.1X

WPA2-Enterprise has been around since 2004 and is still considered the gold standard for wireless network security, delivering over-the-air encryption and a high level of security. But don’t think that it’s gotten any easier to deploy in that time. Regardless of whether you are deploying it for the first time or a seasoned expert, there are always unique challenges ready to give you a headache.

Table of Contents

WPA2-PSK and WPA2-Enterprise: What’s the Difference?



Also known as WPA2-PSK (PSK standing for “Pre-Shared Key), this involves a single password to get on the wireless. It’s generally accepted that a single password to access Wi-Fi is safe, but only as much as you trust those using it. Otherwise, it’s a trivial thing for someone with the password to intercept the information. This is why WPA2-PSK is usually considered as insecure.

There are only a few situations in which WPA2-PSK should be deployed:

  • The network has just a few devices, all of which are trusted. This could be a home or small office.
  • As a way to restrict casual users from joining an open network when unable to deploy a captive portal. This could be a coffee shop or guest network.
  • As an alternative network for devices not compatible with 802.1X. An example being game consoles in a student dorm.



To improve the effectiveness of PSK, updates to WPA3-PSK offers greater protection by improving the authentication process. WPA3-PSK uses Simultaneous Authentication of Equals (SAE) to make brute-force dictionary attacks far more difficult for a hacker. This protocol requires interaction from the user on each authentication attempt, causing a significant slowdown for those attempting to brute-force through the authentication process.



Deploying WPA2-Enterprise requires a RADIUS server, which handles the task of authenticating access. The actual authentication process is based on the 802.1X policy and comes in several different systems labelled EAP. Because each device is authenticated before it connects, a personal tunnel is effectively created between the device and the network.



The biggest improvement that WPA3-Enterprise brings is it requires server certificate validation to be configured to confirm the identity of the server to which the device is connecting.


Deploying WPA2-Enterprise and 802.1X

There are just a few components that are needed to make 802.1X work. Really, if you already have access points and some spare server space, you really have all the hardware you need to make secure wireless happen. Sometimes you don’t even need the server: some access points come with built in software that can take care of it (though only for the smallest of small deployments). Regardless of whether you pay for management solutions or build one yourself from open source tools, the quality and ease of 802.1X is entirely a design aspect.

The Components of 802.1X



In order for a device to participate in the 802.1X authentication, it must have a piece of software called a supplicant installed in the network stack.  The supplicant is necessary as it will participate in the initial negotiation of the EAP transaction with the switch or controller and package up the user credentials in a manner compliant with 802.1X.  If a client does not have a supplicant, the EAP frames sent from the switch or controller will be ignored and the switch will not be able to authenticate.
Fortunately, almost all devices we might expect to connect to a wireless network have a supplicant built in. SecureW2 provides a 802.1X supplicant for devices that don’t have one natively.

Thankfully, the vast majority of device manufacturers have built in support for 802.1X. The most common exceptions to this might be consumer gear such as game consoles, entertainment devices or maybe some printers. Generally speaking, these devices should be less than 10% of the devices on your network and are best treated as the exceptional cases they are.


Switch / Access Point / Controller

The switch or wireless controller plays an important role in the 802.1X transaction by acting as a sort of ‘broker’ in the exchange.  Until a successful authentication, the client will not have network connectivity, the only communication will be between the client and the switch in the 802.1X exchange.  The switch/controller will initiate the exchange by sending an EAPOL-Start packet to the client when the client connects to the network.  Client responses will be forwarded to the correct RADIUS server based on the configuration in the Wireless Security Settings.  When the authentication completes, the switch/controller will make a decision to allow the device on the network based on the status and possibly the attributes contained in the access_accept packet sent from the RADIUS server.

If the RADIUS server sends an Access_Accept packet as a result of an authentication, it may contain certain attributes which may provide the switch information on how to connect the device on the network.  Common attributes will specify which VLAN to assign a user or maybe a set of ACLs the user should be given once connected.  This is commonly called ‘User Based Policy Assignment’ as the RADIUS server is making the decision based on user credentials.  Common use cases would be to push guest users to a ‘Guest VLAN’ and employees to an ‘Employee VLAN’.


Identity Store

The Identity Store refers to the entity where the username and passwords are stored. In most cases, this is Active Directory or potentially an LDAP server. In most cases, any RADIUS server will be able to connect to your AD or LDAP instance to validate users. There are a few caveats to this where LDAP is used, specifically around how the passwords are hashed in the LDAP server. If your passwords are not stored in cleartext or an NTLM hash, you will need to chose your EAP methods carefully as certain methods such as EAP-PEAP may not be compatible. This is not an issue of RADIUS servers, it the problem is the password hash.

Developing more robust WPA2-Enterprise networks take more work, like setting up a PKI or Certificate Authority. But on the flip-side, you can make any of these upgrades without buying new hardware or making changes to the infrastructure. As an example, rolling out guest access or changing the authentication method. One upgrade many institutions have been doing recently is switching EAP methods from PEAP to EAP-TLS after seeing noticeable improvement in connection time and roaming ability. Again, improved wireless without changing a single piece of hardware.

802.1X Authentication Methods


Password-Based Authentication

The vast majority of authentication methods rely on username/password. It’s the easiest to deploy since most institutions already have some sort of credentials set up, but you’re still susceptible to all of the problems of passwords without an onboarding system (see below).

For password based authentication, there are basically 2 options: PEAP and EAP-TTLS. They both are functionally similar, but TTLS is not supported in any Microsoft OS before Windows 8 without using a third party 802.1X supplicant like our Enterprise Client. At this point, most institutions have deployed or made the switch to PEAP. However, you can’t deploy PEAP without either using Active Directory (a proprietary Microsoft service) or leaving your passwords unencrypted.


Token-Based Authentication

Tokens used to always be physical devices in the form of key fobs or dongles that would be distributed to users, generating numbers in sync with a server to add extra validation to a connection. But dongles are expensive and get out of sync with the servers from time to time, but at least you could carry them around. They also could have advanced features like fingerprint scanners or plug in with USB.

Physical tokens are still in use, but their popularity is waning as smartphones have made them redundant. What you used to have on a fob can now be put into an app. There are also many other ways to do two-factor authentication outside of the EAP method itself, like using text messages or emails to validate a device.


Certificate-Based Authentication

Certificates have long been a mainstay of authentication in general, but have not typically been deployed in BYOD settings since it requires getting users to install them on their own devices. However, once a certificate is installed, they are amazingly convenient. They are not affected by password change policy, they are far safer than username/password, and devices authenticate faster.

SecureW2’s PKI services, combined with the JoinNow onboarding client create a turnkey solution for certificate-based Wi-Fi authentication. Organizations can now seamlessly get certificates on devices, and manage them easily with our powerful certificate management features.

WPA2-Enterprise Challenges

In our experience, we’ve found that the average WPA2-Enterprise network suffers from some combination of these 4 problems:


Drawback #1: Device variation

When IEEE created the 802.1X protocol in 2001, there were not a lot of devices that networks had to deal with in regards to wireless access. Since then, the number of device manufacturers has exploded with the rise of mobile computing. To put it in perspective, there are more flavors of Android today than there were entire operating systems in 2001.

Support for 802.1X is inconsistent across devices, even of the same OS. And each device has unique characteristics that can make them behave unpredictably. This problem is made worse by drivers and software installed on the device.


Drawback #2: MITM and delivering certificates

While WPA2 sets ups a very secure connection, you also have to be sure that the users will only connect to the official network. A secure connection is meaningless if it’s to a honeypot or imposter signal. Institutions often sweep for and detect rogue access points, including Man-in-the-Middle attacks, but users can still be vulnerable off-site. A person with a laptop can quietly gather user credentials at a bus stop, coffee shop, or anywhere devices might pass through and try to auto-connect.

Even if the server has a certificate properly configured, there’s no guarantee that users won’t connect to a rouge SSID and accept any certificates presented to them. The best practice is to actually install the public key on the user’s device to automatically verify the certificates presented by the server.


Drawback #3: The Password change problem

Networks that have set up passwords to expire on a regular basis face additional burden with WPA2-Enterprise. Each device will lose connectivity until reconfigured. This was less of a burden in eras when each user was only issued one device, but in today’s modern BYOD setting, users have multiple devices which all will want to connect to the internet. Depending on how the password changes are rolled out or the users’ abilities to manage passwords, this can be a burden on some helpdesks.

It’s even worse on networks that have unexpected password changes due to data breaches or security vulnerabilities. In addition to having to roll out new credentials site-wide, IT has to deal with the influx of help desk tickets related to Wi-Fi.


Drawback #4: Changing user expectation

The hardest part about WPA2-Enterprise, by far, is training the users. Users today have incredibly high expectations for ease of use. They also have more options than ever before to work around official access. If the network is too hard to use, they’ll use data. If the certificate is bad, they will ignore it. If they can’t access something they want, they will use a proxy.

For WPA2-Enterprise to work, you need to make it as easy to use as everything else users out there are used to, without sacrificing security.

Simplifying WPA2-Enterprise with JoinNow

JoinNow is an automation technology that tackles many of the WPA2-Enterprise challenges in two critical ways:


Improving User Experience

The key to understanding why WPA2-Enterprise can be such a pain for some networks is understanding the decision tree presented to users. Besides the dozen or so choices presented to the user, there are hundreds of settings on the device that can affect how it connects. As far as the relationship between your network and your user is concerned, all of the millions of possible configurations are useless except for one.

The SecureW2 JoinNow suite was created to reduce the millions of possible user paths down to one through automation. An IT staff creates and manages the wireless profiles for a network. That profile is then delivered to the users as they enter the connection process. Everything between those two steps is completely automated and can even be hosted in the cloud. This elegant solution has several features:

  • JoinNow automatically accounts for variation in devices and configures each properly
  • Certificates are installed automatically
  • Password changes no longer affect connectivity
  • Seamless user experience

In addition, you can expect more stable roaming and less network downtime. And the best part is that networks don’t have to spend time policing users, since mistakes have been removed from the process. We even take extra steps like check for problematic drivers or install software the user will need to use network resources as part of the process.


Enhancing 802.1X Management

To help on the backend, we created a suite of tools that fill in the gaps of traditionally managed WPA2-Enterprise networks. In addition to the automated deployment, we can give admins powerful authentication down to the device level. Now if people are failing to connect, you can know who and why. This takes a lot of the guesswork out of troubleshooting. We also have all of the tools you might need to deploy more powerful networks by connecting your existing infrastructure. All of this can be managed by a single, stateless back end in the cloud.

Find out more about the JoinNow family of products here, or sign up for a 30 day trial for free and see if it can simplify your network.

Talk to an Expert

Need some help with 802.1X? Get a free 1 on 1 session with one of our engineers.
  • Email addresses from free providers (Gmail, Hotmail, etc.) will not be accepted.
  • This field is for validation purposes and should be left unchanged.