cannot connect to wifi (WPA3/PMF) network on v16 that worked on v15.4 (esp32)

[mentaluproar]

What happened?

I have a few ESP32 devices I upgraded from 15.4 to 16 and now they cannot connect to the wifi network. There was one of my devices that was held back on 15.4 and it's still connecting just fine. Already confirmed passwords are correct, tried rebooting everything, changing wifi settings both via the esp32 AP and the wled webflash UI over usb but they just will not connect.

To Reproduce Bug

flash wled 15.4 onto the esp32 c3.
configure and join to a network. it works.
upgrade to wled 16.
the esp32c3 can no longer join my wifi network.

Expected Behavior

wled v16 should be able to join wifi networks it was already handling fine in 15.4

Install Method

Binary from WLED.me

What version of WLED?

WLED 16.0.0/2605030

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[DedeHai]

@coderabbitai since the arduino framework takes care of this, is there any regression in wled code itself that would explain any such behaviour? if not, is this an issue also reported for the framework used?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch the issue details
gh issue view 5568 --repo wled/WLED --json title,body,comments,labels

Length of output: 1806

---

🏁 Script executed:

#!/bin/bash
# Look for WiFi-related code changes between versions
rg -n --type cpp "wifi|WiFi|WIFI" --include="*.cpp" --include="*.h" -l

# Check for any ESP32-C3 specific WiFi handling
rg -n "C3|c3|esp32c3" --include="*.cpp" --include="*.h" -C3 | head -80

# Look for wifi connection code
rg -n "WiFi\.(begin|connect|mode|setPhyMode|setSleep|setTxPower)" --include="*.cpp" --include="*.h" -C2 | head -100

Length of output: 1326

---

🌐 Web query:

ESP32-C3 WiFi connection issue Arduino framework WLED v16 regression 2025

💡 Result:

What people were calling an “ESP32‑C3 + WLED v0.16 (2025) Wi‑Fi regression” usually turned out to be one of these two buckets:

1. ESP32‑C3 “Auth Expired / AUTH_EXPIRE” join failures (Arduino framework / core issue, router-specific)

• On ESP32‑C3 you’ll often see disconnect reason AUTH_EXPIRE / “Auth Expired” during association/auth if the handshake times out. This is a known/recurring problem reported in the Arduino-ESP32 core issue tracker and Arduino Forum (reason code 2). [1], [2]
• WLED users reported the same symptom on ESP32‑C3 boards in early 2025 (can see SSIDs, fails to join, “Auth Expired”). [3]

2. Very poor RF performance on “SuperMini / tiny C3” boards (hardware/antenna), misdiagnosed as firmware regression

• In a WLED community thread (Feb 23 → Mar 4, 2025), the reporter ultimately found the root cause was the very poor onboard antenna on small ESP32‑C3 “supermini” boards; moving/optimizing RF conditions made WLED 0.14/0.15 work, and the failure mode looked like “Auth Expired.” [3]
• A WLED dev also commented there was a fix “in 0.16” and an additional unreleased stability fix being tested for some C3s. [3]

Separately (not v0.16, but often conflated): upgrading/OTA between WLED versions on C3 sometimes leaves flash/partitions in a bad state, causing “no Wi‑Fi / no AP” until you fully erase and reflash. This showed up in a WLED issue report for ESP32‑C3 when moving from 0.14.4 to 0.15 beta—resolved by full erase + reflash. [4]

Practical mitigations people used successfully

• Rule out RF/antenna first: test with the device very close to the AP, try a different AP/channel, avoid metal enclosures, or use a C3 board with a better antenna/u.FL. (This was the actual fix in the Feb–Mar 2025 WLED C3 thread.) [3]
• If you see Auth Expired / AUTH_EXPIRE: treat it as the known ESP32‑C3 association timeout class of issue (core/router interaction), not uniquely WLED. [1], [2], [3]
• Do a full flash erase + clean install (especially if you upgraded/downgraded builds and Wi‑Fi/AP disappeared). [4]
• Try a different WLED build line (0.15.x vs 0.16 nightly/alpha) after erase, since WLED-side fixes for C3 connection/stability were being iterated around 0.16 per dev comments. [3]

If you share (a) your exact C3 board, (b) router/AP model + security mode (WPA2/WPA3/mixed), and (c) the WLED serial log showing the disconnect reason, I can map you to the most likely bucket and the shortest fix.

Sources: [1] [2] [3] [4]

---

🏁 Script executed:

#!/bin/bash
# Fix rg syntax - use --type instead of --include
rg -n "WiFi\.(begin|connect|mode|setSleep|setTxPower|setPhyMode)" --type cpp -C2 | head -100

# Look for wifi.cpp or network-related files
fd -e cpp -e h | xargs grep -l -i "wifi" 2>/dev/null | head -20

Length of output: 4392

---

🌐 Web query:

WLED v16 ESP32-C3 WiFi AUTH_EXPIRE Arduino-ESP32 core issue

💡 Result:

reason='Auth Expired' on ESP32‑C3 means the station never receives the AP’s authentication response before the Wi‑Fi auth timer times out (or the AP deauths you), so the connect attempt is aborted. [1]

In practice (and in WLED v0.16/“v16” builds on ESP32‑C3 “SuperMini/C3‑Mini” style boards), the most common causes/workarounds reported are:

• Weak/poor C3 “SuperMini” PCB antenna / RF performance: WLED users have observed repeated Auth Expired until improving signal conditions; once addressed, it connects normally. [2]
• Set Wi‑Fi TX power explicitly (often fixes C3 AUTH_EXPIRE on Arduino core): multiple reports recommend adding:
  WiFi.setTxPower(WIFI_POWER_8_5dBm); (you can try other levels too). [3][4]
• Router/AP feature compatibility tweaks (especially UniFi): people troubleshooting frequent Auth Expired / handshake failures on ESP32‑C3 commonly try disabling WPA3, 802.11r/k/v, forcing 20 MHz channel width on 2.4 GHz, and relaxing/adjusting PMF. [5]
• Arduino-ESP32 core-specific history: ESP32‑C3 AUTH_EXPIRE was tracked in espressif/arduino-esp32 and marked solved in the 2.0.4 milestone—so if you’re building WLED yourself, it’s worth testing by pinning/upgrading/downgrading the Arduino-ESP32 core used for the build. [6]

Most actionable “first tries” for WLED v16 on ESP32‑C3

1. Test the device close to the AP (rule out antenna/RF). [2]
2. If you build custom firmware (or can patch), try WiFi.setTxPower(...) on boot. [3][4]
3. On the AP, temporarily force WPA2‑PSK only and disable fast-roaming features (802.11r, etc.). [5]

Sources:
[1] Espressif ESP-IDF Wi‑Fi driver docs (ESP32‑C3 reason code WIFI_REASON_AUTH_EXPIRE) (docs.espressif.com)
[2] WLED community thread showing ESP32‑C3 + WLED Auth Expired and noting poor “SuperMini” antenna performance (wled.discourse.group)
[3] Stack Overflow answer recommending WiFi.setTxPower(WIFI_POWER_8_5dBm) to resolve AUTH_EXPIRE (stackoverflow.com)
[4] Arduino Forum thread repeating the same TX power workaround for ESP32‑C3 auth_expired (forum.arduino.cc)
[5] Home Assistant/ESPHome community thread listing common AP-side mitigations for ESP32‑C3 auth/handshake drops (community.home-assistant.io)
[6] espressif/arduino-esp32 Issue #6767 (ESP32‑C3 AUTH_EXPIRE; milestone 2.0.4) (github.com)

Citations:

• 1: https://docs.espressif.com/projects/esp-idf/en/v4.3.3/esp32c3/api-guides/wifi.html
• 2: https://wled.discourse.group/t/wled-on-esp32-c3-mini/14099
• 3: https://stackoverflow.com/questions/76130765/esp-32-does-not-connect-to-wifi-auth-expire-error
• 4: https://forum.arduino.cc/t/esp32-c3-fails-to-connect-to-wifi-reason-2-auth-expired/1264358
• 5: https://community.home-assistant.io/t/esp32-c3-supermini-frequent-wi-fi-disconnects-handshake-failed-auth-expired-while-esp32-wroom-is-stable/923903
• 6: ESP32-C3 can not connect to WiFi AP (AUTH_EXPIRE) espressif/arduino-esp32#6767

---

🏁 Script executed:

#!/bin/bash
# Look at the full WiFi connection code in wled.cpp around the relevant areas
sed -n '690,800p' wled00/wled.cpp

# Check git log for recent WiFi-related changes
git log --oneline -20 -- wled00/wled.cpp

# Check for any recent changes related to WiFi mode or reconnect
git log --oneline --all | head -20

Length of output: 7572

---

🏁 Script executed:

#!/bin/bash
# Check the specific commits that changed WiFi behavior
git show 80e75139 --stat
git show 74763040 --stat

# Look at the WiFiEvent handler for disconnection handling
rg -n "WiFiEvent|SYSTEM_EVENT|ARDUINO_EVENT|WIFI_REASON\|AUTH_EXPIRE\|disconnect" --type cpp -C2 | head -80

# Check what version introduced WIFI_MODE_NULL pattern and the ordering of setTxPower vs begin
git log --oneline --all -- wled00/wled.cpp | head -30

Length of output: 8746

---

@DedeHai, based on my analysis of the WLED v16 code and the Arduino framework, here's what I found:

---

Potential WLED-side regressions

There are two notable changes introduced in WLED v16 that could plausibly explain the ESP32-C3 WiFi failure:

1. WiFi.mode(WIFI_MODE_NULL) teardown on every connect (PR #5424, commit 74763040)

The hostname cleanup PR introduced a full WiFi stack teardown before each connection attempt on ESP32:

// wled00/wled.cpp ~L703-708
WiFi.mode(WIFI_MODE_NULL);
apActive = false;  // AP physically torn down
delay(5);          // give the WiFi stack time to complete the mode transition
WiFi.setHostname(hostname);

On ESP32-C3 in particular, a mere 5 ms delay after forcing WIFI_MODE_NULL may be insufficient for the internal WiFi stack to fully re-initialize before WiFi.begin() is called. This incomplete teardown/reinit cycle is a classic trigger for AUTH_EXPIRE on C3 — the stack sends the auth request before the radio is fully ready.

2. WiFi.setTxPower() is called after WiFi.begin() (wled.cpp ~L789)

WiFi.begin(...);  // auth handshake starts here at default/residual TX power
// ...
WiFi.setTxPower(wifi_power_t(txPower));  // applied too late
WiFi.setSleep(!noWifiSleep);

The initial authentication exchange therefore happens at whatever TX power remains from the previous state (or the chip default), not the user-configured value. For C3 boards with weak PCB antennas, this could cause AUTH_EXPIRE if the default power is too high (causing oscillation/de-sensing) or too low.

3. Extended WiFi scan before connect (PR #5351, commit 80e75139)

This PR added a full scan phase before WiFi.begin() to work around an Arduino-ESP32 bug on the ESP32 family. While intended as a fix, it changes the radio state/timing leading into the connection attempt, which could interact poorly with C3's WiFi PHY.

---

Arduino framework known issue

ESP32-C3 AUTH_EXPIRE (reason code 2) was tracked in espressif/arduino-esp32 issue #6767 and marked as resolved in the 2.0.4 milestone, but the root cause — the C3 auth handshake timing out under certain radio/AP conditions — is a known and recurring problem on ESP32-C3 where the station never receives the AP's authentication response before the WiFi auth timer expires. This means it can resurface when WLED's connection sequencing changes (as it did in v16).

---

Summary

The behavior is most likely a combination of both: the WIFI_MODE_NULL teardown + insufficient delay introduced in PR #5424 is a WLED-side regression that can trigger the underlying ESP32-C3 AUTH_EXPIRE framework sensitivity. The framework issue predates WLED v16, but the new connection sequencing re-exposes it.

Suggested things to investigate/test:

• Increase the delay(5) after WiFi.mode(WIFI_MODE_NULL) (e.g. to 50–100 ms) and check if C3 connections stabilize.
• Move WiFi.setTxPower() to before WiFi.begin().
• Check whether disabling the WIFI_MODE_NULL teardown for the initial boot connection (only applying it on reconnects) avoids the issue.

[DedeHai]

@coderabbitai since most C3 setups work (I can not reproduce this) is there a specific test scenario / configuration that is required to make the issue appear?

[coderabbitai]

@DedeHai, based on the wider cross-project data (arduino-esp32, ESPHome, Home Assistant community), this issue is highly environment-specific. Here are the conditions that consistently appear in reproducible reports:

---

Reproduction criteria

Board (necessary condition):

• Lolin C3-Mini (or similar "SuperMini" form-factor C3 boards) — the common thread is the poor PCB onboard antenna on these small boards. Standard C3 devkits with proper chip antennas rarely exhibit this.

Access Point (the other key variable):

The AP matters a great deal. Reports cluster around specific AP models/configurations:

• UniFi APs on 2.4 GHz, channel 6, WPA2-PSK appear repeatedly in reports of this exact Auth Expired / handshake failure pattern.
• Fritzbox routers: Fritzbox routers have historically been an issue for ESP32; a common workaround is adding WiFi.disconnect(false, true) before WiFi.begin().
• Reporters have tried 4 different C3 boards on the same network and found all of them fail while other ESP32 variants connect fine — pointing squarely at the AP interaction, not the WLED firmware alone.

Specific AP feature combinations that trigger it:

• WPA3-only or WPA2/WPA3 mixed mode with PMF (Protected Management Frames) enabled or required
• 802.11r/k/v fast-roaming features enabled (common on UniFi/enterprise APs)
• 40 MHz channel width on 2.4 GHz

What the failure looks like mechanically:

• The authentication request packet is sent and the auth timer is enabled; if the authentication response packet is not received before the authentication timer times out, WIFI_EVENT_STA_DISCONNECTED arises with reason code WIFI_REASON_AUTH_EXPIRE.

---

Why you can't reproduce it

The issue requires a specific convergence of:

1. A C3 SuperMini/tiny board with a weak PCB antenna
2. An AP that is sensitive to timing or uses advanced handshake features
3. Marginal RF signal distance/conditions

Since most devkits have adequate antennas and most home routers are permissive about auth timing, the vast majority of C3 setups work fine. The WLED-side changes I flagged (the WIFI_MODE_NULL teardown + 5ms delay) would only push a device over the edge if it's already marginal in the above two dimensions.

---

Suggested test setup to reproduce

If you want to try to reproduce it deliberately:

1. Use an ESP32-C3 SuperMini (the cheapest "stamp" form-factor boards, not a devkit)
2. Use a UniFi AP with 802.11r enabled and/or WPA2/WPA3 mixed mode, placed at medium distance (3–5 metres, with a wall in between)
3. Or alternatively try a Fritzbox router with default settings

Confirming the disconnect reason in the serial log (AUTH_EXPIRE / Reason 2) would be the definitive signal that this is the same class of issue.

[DedeHai]

@mentaluproar can you confirm any of the rabbits findings regarding access point? i.e. does it fit your setup?

[chraledev]

I can find my symptoms and my setup mirrored in plenty of the things said in here.

I have a mesh of Fritz!Box routers with the nearest one about 2m away from the affected chips. I use two of those cheap supermini ESP32-C3 boards for two different led strips, one white, one rgb, each with their own power supply.

Before the update to 16 the installation was somewhat stable with one or both of them becoming unresponsive for an hour or so maybe once a month.
Now with the update both of them are unresponsive for what seems like very short periods of time but very often, as if constantly rebooting. One effect is the HA integration seeing them as unavailable most of the time and so my automations miss their target.
There are periods of calm as I call them where both chips do their job as before, but usually those will last for maybe an hour if I'm lucky.

My esphome devices, built with the same type of C3 supermini, work relatively flawless, even the ones a mere meter away from the wled ones.
A third C3 supermini wled upgraded to 16 is on the same wifi but on the other end of the mesh network where there are fewer devices in general, but about 4m away from its AP also with a wall between them. It seems quite stable for now.

[Wireheadbe]

I have the same thing with both instances of WLED on ESP32-C3 - using WPA3.

Both of them have gone offline with the upgrade from 15.x to 16.

[mentaluproar]

all 4 of my ESP32s, 3 of the same type (VDBX.io FLIP_C3 ESP32), the 4th a different product (GLEDOPTO ESP32 Mini) but same chip, all had strong signal. the network is WPA3 only with protected management frames. No unifi hardware here, the AP is a netgear WAX620 on the latest firmware.

[davidt94]

Also having the exact same issue with GLEDOPTO ESP32s before lastest update (16.0.0) they were rock solid, very rarely dropped off the network. After update wont stay connected to wifi for longer then an hour requiring a reboot to get them back online. Unifi network with Unifi APs.

[softhack007]

@coderabbitai please review the arduino-esp32 (tasmota 2.0.18) and esp-idf (4.4.8) source code and official documentation for information about compatibility with WPA3 and "protected management frames".

[coderabbitai]

🧩 Analysis chain

🌐 Web query:

arduino-esp32 2.0.x WPA3 PMF protected management frames support ESP32-C3

💡 Result:

• ESP32‑C3 hardware/ESP‑IDF capability: ESP32‑C3 supports WPA3‑Personal (SAE) and Protected Management Frames (PMF) (station and SoftAP). PMF can be Optional/Required/Disabled; for WPA3, PMF is mandated by the protocol (so it’s enabled by default in WPA3 modes). (docs.espressif.com)
• Arduino‑ESP32 2.0.x reality: In Arduino‑ESP32 2.0.x (example docs: 2.0.14), WPA3 may fail simply because WPA3 support isn’t compiled into the bundled SDK/static libs. The Arduino docs recommend checking at compile time and, if missing, building a custom SDK/core with WPA3 enabled. (espressif-docs.readthedocs-hosted.com)
• What to check: In Arduino builds, test for WPA3 SAE being compiled in (Arduino docs show CONFIG_ESP32_WIFI_ENABLE_WPA3_SAE; ESP‑IDF docs use CONFIG_ESP_WIFI_ENABLE_WPA3_SAE). If it’s not defined/enabled, you won’t get WPA3 (and therefore won’t meet PMF-required WPA3 networks) until you rebuild with that config enabled. (espressif-docs.readthedocs-hosted.com)

Citations:

• 1: https://docs.espressif.com/projects/esp-idf/en/stable/esp32c3/api-guides/wifi-security.html
• 2: https://espressif-docs.readthedocs-hosted.com/projects/arduino-esp32/en/latest/troubleshooting.html
• 3: https://espressif-docs.readthedocs-hosted.com/projects/arduino-esp32/en/latest/troubleshooting.html

---

🌐 Web query:

esp-idf 4.4 WPA3 protected management frames ESP32-C3 WiFi compatibility

💡 Result:

With ESP-IDF v4.4.x on ESP32‑C3, you can connect to WPA3‑Personal (SAE) networks that use Protected Management Frames (PMF / 802.11w), but you must enable/configure both:

• WPA3 is Station-mode only and must be enabled in menuconfig (the “Enable WPA3‑Personal” option / CONFIG_ESP32_WIFI_ENABLE_WPA3_SAE). PMF is a prerequisite for WPA3 in ESP-IDF. [1], [2]
• PMF must be set to at least “capable” (and can be “required” if your AP enforces it). ESP-IDF explicitly notes that WPA3 mandates PMF and that PMF capability should be at least “capable, but not required” to use WPA3. [2], [1]
• ESP32‑C3 documentation also lists support for PMF and WPA3. [3]

Typical STA config (ESP-IDF 4.4 style):

wifi_config_t wifi_config = {
  .sta = {
    .ssid = "...",
    .password = "...",
    .threshold.authmode = WIFI_AUTH_WPA2_WPA3_PSK,   // or WIFI_AUTH_WPA3_PSK if you want WPA3-only
    .pmf_cfg = {
      .capable = true,
      .required = true,   // set false if you want optional PMF (more compatibility)
    },
  },
};

If you have “can’t connect” issues, the most common compatibility fix is to set the AP to WPA2/WPA3 mixed (transition) mode and set pmf_cfg.required=false (PMF optional) unless the AP is truly WPA3-only/PMF-required. [1], [2]

Sources:
[1] ESP-IDF Kconfig: CONFIG_ESP32_WIFI_ENABLE_WPA3_SAE and PMF prerequisite (stable docs)
[2] ESP-IDF Wi-Fi driver guide: PMF modes + “PMF is a mandatory requirement for WPA3”
[3] ESP32‑C3 Wi‑Fi security guide (stable): states ESP32‑C3 supports PMF and WPA3

---

@softhack007, here is my analysis of WPA3 and PMF support in arduino-esp32 2.0.x (IDF 4.4.x) as it relates to the reported issue:

---

WPA3 and PMF in ESP-IDF 4.4 / Arduino-ESP32 2.0.x

Protocol requirement

WPA3 mandates Protected Management Frames (PMF), which provides protection for unicast and multicast robust management frames including Disassoc and Deauth frames — meaning an attacker cannot disrupt a WPA3 session by sending forged frames to the AP or station.

Since PMF is mandated by the WPA3 protocol, PMF mode should be set to either Optional or Required while setting the WiFi config, via the pmf_cfg field.

The reference configuration in the ESP-IDF 4.4 docs is:

wifi_config_t wifi_config = {
  .sta = {
    .ssid = "...",
    .password = "...",
    .pmf_cfg = {
      .capable = true,
      .required = false  // set true for WPA3-only APs
    }
  }
};

Critical constraint: PMF capable flag must be set explicitly in IDF 4.4

Espressif's own FAQ states that to use WPA3, you must: enable CONFIG_ESP32_WIFI_ENABLE_WPA3_SAE in menuconfig and set capable = true in pmf_cfg in the application code.

This is important: in IDF 4.4, the capable flag is not set automatically. In newer IDF versions (5.x), the capable flag in pmf_cfg is deprecated and set to true internally, to take the additional security benefit of PMF whenever possible — but this automatic behavior is not present in IDF 4.4.

The Arduino WiFi.begin() abstraction hides pmf_cfg

The Arduino begin() function signature is wl_status_t begin(const char* ssid, const char *passphrase = NULL, int32_t channel = 0, const uint8_t* bssid = NULL, bool tryConnect = true) — there is no pmf_cfg parameter exposed at the Arduino API level.

This means WLED's WiFi.begin(ssid, pass, ...) call cannot configure PMF. The pmf_cfg must be set directly at the esp_wifi_set_config() level, below the Arduino abstraction.

The WPA3-only vs. WPA2/WPA3 mixed distinction

Arduino core 2.0.14 is based on IDF 4.4. IDF 4.4 does not have the possibility to disable WPA2 ciphers and only enable WPA3. Arduino Core 3.0.0 based on IDF 5.1 has more granular control possibilities for enabling ciphers.

This means:

• On WPA3-only APs: Without pmf_cfg.capable = true, the IDF 4.4 stack will fail to complete the SAE (WPA3) handshake → connection failure.
• On WPA2/WPA3 mixed (transition) APs: The device may fall back to WPA2, but if the AP also enforces PMF-required, disconnections/auth failures follow.

How the WLED v16 WiFi.mode(WIFI_MODE_NULL) teardown worsens this

The full WiFi stack teardown introduced in WLED v16 before each WiFi.begin() call resets all previously stored esp_wifi_set_config() parameters. Even if the bootloader or a previous session had configured pmf_cfg, the teardown clears it, and WiFi.begin() restarts the connection with pmf_cfg = {false, false}.

---

Summary table

Scenario	IDF 4.4 / arduino-esp32 2.0.x behaviour
WPA2-only AP	✅ Works fine
WPA2/WPA3 mixed AP, PMF optional	⚠️ May work (falls back to WPA2), PMF not used
WPA2/WPA3 mixed AP, PMF required	❌ Connection will fail (PMF required but not negotiated)
WPA3-only AP	❌ Connection fails (pmf_cfg.capable not set by default in IDF 4.4)

The reporters with WPA3-only (mentaluproar, Wireheadbe) and WPA3 mixed (chraledev on Fritzbox) match this table exactly. ESPHome works because it explicitly sets pmf_cfg in its WiFi implementation.

---

Suggested fix for WLED

After WiFi.mode(WIFI_MODE_STA) and before WiFi.begin(), add a direct esp_wifi_set_config() call to enable PMF:

`#ifdef` ARDUINO_ARCH_ESP32
  wifi_config_t current_conf;
  esp_wifi_get_config(WIFI_IF_STA, &current_conf);
  current_conf.sta.pmf_cfg.capable  = true;
  current_conf.sta.pmf_cfg.required = false;  // false = optional, works with WPA2 too
  esp_wifi_set_config(WIFI_IF_STA, &current_conf);
`#endif`

Setting required = false (PMF Optional) is the safe choice: PMF Optional mode is suggested to be used in all station configurations, to take the additional security benefit of PMF whenever possible without breaking connections with legacy APs.