WPA Enterprise Wi-Fi with 802.1X and RADIUS: Setup Guide
Advanced4 minInnovialabs editorial team
In short
WPA Enterprise replaces one shared password with personal credentials or certificates checked by a RADIUS server via 802.1X, so you can revoke a single user, see who connected and put each person in the right VLAN.
Why a shared Wi-Fi password stops working
With WPA2/WPA3-Personal everyone uses the same pre-shared key. In a small team that is fine; as the office grows, the problems pile up:
- When an employee leaves, the only way to cut them off is to change the password on every device.
- Logs show MAC addresses, not people, so you cannot tell who was on the network.
- The password spreads through chats, sticky notes and guests' phones.
- With WPA2-Personal, anyone who knows the key and captures a device's handshake can decrypt that device's traffic.
- Everyone lands in the same network segment, regardless of role.
WPA Enterprise solves this: each user or device authenticates individually through 802.1X, and a RADIUS server decides who gets in and with which settings.
How 802.1X works
There are three roles:
- Supplicant — the laptop or phone.
- Authenticator — the access point (or a switch port for wired 802.1X).
- Authentication server — the RADIUS server.
The flow:
- The client connects to the SSID. The access point blocks all traffic except EAP messages.
- The access point wraps the client's EAP messages into RADIUS requests and forwards them to the server. It does not check passwords itself.
- The client and the server run an EAP method, usually inside a TLS tunnel.
- On success the server sends Access-Accept with keying material and optional attributes such as a VLAN number.
- The client and the access point derive unique encryption keys for this session.
Choosing an EAP method
| Method | What the user presents | Pros | Cons |
|---|---|---|---|
| EAP-TLS | Client certificate | Strongest, no passwords to steal | Requires a certificate authority and a way to deploy certificates (MDM, group policy) |
| PEAP-MSCHAPv2 | Username and password | Easy, works with Active Directory | Safe only if clients validate the server certificate |
| EAP-TTLS/PAP | Username and password | Works with LDAP and other directories | Same requirement to validate the server certificate |
The critical point for password-based methods: the client must validate the server certificate (trusted CA plus the expected server name). Otherwise an attacker can set up a fake access point with the same SSID and collect credentials. Modern operating systems increasingly refuse to connect without this setting, which is a good thing.
A practical rule: start with PEAP or TTLS for people, plan EAP-TLS for company-managed laptops.
RADIUS server options
- FreeRADIUS — open source, runs on Linux, very flexible, configured with text files.
- Microsoft NPS — a Windows Server role, natural choice if you already have Active Directory.
- Built-in RADIUS in Wi-Fi controllers, routers or NAS devices — enough for a small office with a simple user list.
- Cloud RADIUS services — managed, often integrate with cloud directories and certificate deployment.
Pick based on where your user accounts live, whether you need certificates, and redundancy: two RADIUS servers are better than one, because when RADIUS is down, nobody can connect.
Per-user VLAN assignment
RADIUS can tell the access point which VLAN to put the user in. Three standard attributes are used:
"anna" Cleartext-Password := "test-only"
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-Id = "20"
This is the FreeRADIUS users file format, suitable for a lab; in production you would map groups from a directory rather than store passwords in a file. With PEAP or TTLS, make sure attributes set during inner authentication reach the outer reply — check how your server version handles this.
For dynamic VLANs to work, the access point must support them and its switch port must be a trunk carrying all the VLANs RADIUS can return.
Setup checklist
- Decide on the user directory and EAP method.
- Issue a server certificate (internal CA or public) and install the RADIUS server.
- Register each access point as a RADIUS client with a long random shared secret.
- Create an SSID with WPA2-Enterprise or WPA3-Enterprise, point it to the RADIUS server (ports 1812 for authentication, 1813 for accounting).
- Configure VLANs and trunk ports on the switches.
- Push Wi-Fi profiles with the CA and server name to managed devices.
- Test with one account: login, VLAN, logs, then disable the account and confirm access is gone.
Keep a separate guest SSID and a separate isolated SSID for printers and IoT devices that cannot do 802.1X.
Common mistakes
- Clients configured to skip server certificate validation.
- One RADIUS server with no backup.
- A short, guessable RADIUS shared secret.
- Wrong time on the server, which breaks certificate checks.
- Server certificate expiring unnoticed — set a reminder.
- Trying to force cameras and printers onto the enterprise SSID.