While WPA2-PSK and WPA3-SAE are really secure once a connection has been established, my understanding is that if you have access to the Wi-Fi password you can impersonate the AP without any problems. I'm starting to add more and more IoT devices to my network, and I'm growing worried that any of these could leak the IoT Wi-Fi password and compromise all the devices in that network, mostly when it comes to smart locks and power infrastructure like solar inverters. Because of this I've been searching for a way to assign a different password to each device without having to add a new Wi-Fi network for each device or device class.

WPA Enterprise is the first thing that came to mind, and here's a list of EAP protocols that I thought might work for this:


These authentication mechanisms only require a pre-shared key, however I'm not sure if any of these will be compatible with devices that expect to be authenticated using WPA2-PSK or WPA3-SAE. Is something like this possible? If not, could you propose any alternatives?

2 Answers 2


The options you listed are part of WPA Entreprise. They are not suitable for a station which only supports WPA personal (i.e. WPA1-PSK, WPA2-PSK, WPA3-SAE).

If your device can only do WPA2-PSK, your options are:

  1. use a different PSK for each station MAC address (this could work very well for IoT devices);
  2. let the access point/RADIUS try to check several PSKs (this might not scale very well with a high number of PSKs).

I have described some support for these options at the end of this section.

If your device can only do WPA3-SEA, it might support password identifiers. This is an extension of WPA3-SEA which let the station send a password identifier (i.e. a login) as part of the SAE handshake. This let you have one PDK per station without the hacks mentioned in the previous paragraph.

  • I'm looking into "wpa_psk_file" right now, it seems promising! Thanks for the answer! I'll report back when I have time to take a more in depth look.
    – Facundo
    Commented Nov 21, 2022 at 1:18
  • (maybe bad) idea: still have a "master" password and use the station mac address as some sort of salt to derive the ppsk programatically on a local and stateless radius server.
    – Facundo
    Commented Nov 21, 2022 at 1:28
  • 1
    In the referenced link you mention that "Alternatively, the same effect could be achieved using an external RADIUS server.", however I was not able to find any info on doing RADIUS+WPA Personal. Do you have any links in hand to show how something like this could be achieved?
    – Facundo
    Commented Nov 21, 2022 at 12:10
  • 1
    @Facundo, sorry I don't have anything more than this thread spinics.net/lists/hostap/msg09089.html . It apparently needs wpa_psk_radius=2 in hostapd and your RADIUS server should return a Tunnel-Password based on the MAC address found in the Calling-Station-Id RADIUS Request attribute but I'm no expert on RADIUS. If you manage to do that, please tell me more about that!
    – ysdx
    Commented Nov 21, 2022 at 12:31
  • github.com/latelee/hostapd/commit/… suggests the MAC address would be found in User-Name (!) instead (or in addition?).
    – ysdx
    Commented Nov 21, 2022 at 12:38

As ysdx mentioned in their excellent answer, hostapd has a feature that allows one to specify different PSKs based on the station MAC address. This can be achieved either by using the wpa_psk_file or wpa_psk_radius configs.

Based on this I decided to make a lightweight OpenWRT package with a set of scripts to assign different passwords and attributes to each station based on its MAC address. It works in a similar way to stateless password managers, it grabs the station address and a "master password" and hashes them together to produce the PSK. The advantage of using this approach is that no storage or sync is required between the different APs thus roaming is not affected. Also I consider it more robust since no centralized database is needed, any AP can generate the PSKs on their own.

The package and its dependencies occupy less than 100K of flash storage.

Here's the link to the gh repo.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .