Wi-Fi · WPA · NIST SP 800-153

Wi-Fi WPA Hardening in 2026: KRACK, WPS, PMF and the SSID/PSK Constants You Forgot in Source

May 2, 2026 10 min read 802.11i · PMF · SAE

Wi-Fi has been "solved" for so long that most teams stopped paying attention to it. WPA2-PSK won, the WPA3 transition is happening, and the security mailing lists moved on to bigger fish. The problem is that "solved" only works if your fleet has actually adopted the modern profile. Most haven't — especially not the firmware codebases that ship with hardware products. This is a 2026 hardening guide for Wi-Fi configuration as it appears in source, with detection rules you can wire into CI today.

The protocol layer cake (and which layers are still broken)

Static red flag #1: WEP / WPA-TKIP still configured

The static signature is unambiguous. Whether the codebase is hostapd config, ESP-IDF, Android Wi-Fi configuration, iOS profiles or a Cisco IOS template, WEP and WPA-TKIP appear as named constants:

anti-pattern (hostapd) 
wpa=1                       # WPA1 only
wpa_pairwise=TKIP           # broken cipher
auth_algs=3                 # accepts WEP shared-key
ieee80211w=0                # PMF disabled
anti-pattern (ESP-IDF) 
wifi_config_t cfg = {
    .sta = {
        .threshold.authmode = WIFI_AUTH_WEP, // !!
    },
};

Both are exact-string detections. Any reference to WIFI_AUTH_WEP, WPA_PSK with TKIP, wpa=1, auth_algs=3, or SECURITY_WEP goes on the wireless dashboard.

Static red flag #2: WPS still on

Wi-Fi Protected Setup was supposed to make pairing easier. It also made it a one-tool-away brute-force surface. Pixie Dust recovers WPS PINs offline against affected chipsets in seconds; Reaver brute-forces the rest online in hours. Despite this being known since 2011, WPS continues to ship enabled by default on consumer routers and "easy setup" IoT gateways.

The static signature in firmware:

If WPS is "needed for setup," it should be a transient state — enabled during commissioning, disabled before the device is considered provisioned. Any code path that leaves WPS on permanently is a finding.

Static red flag #3: hardcoded SSID + PSK

This is the most reliable signature in firmware codebases — reliable enough that it produces real demos:

anti-pattern (ESP-IDF, sdkconfig) 
CONFIG_ESP_WIFI_SSID="AcmeCorp-Internal"
CONFIG_ESP_WIFI_PASSWORD="summer2024"
anti-pattern (Arduino) 
const char* ssid     = "AcmeCorp-Internal";
const char* password = "summer2024";
WiFi.begin(ssid, password);

Both are obvious. The SF365 SecretScanner ships a dedicated ESP-IDF Wi-Fi Credentials pattern (CONFIG_(ESP_)?WIFI_(SSID|PASSWORD|PASS|PSK)) that catches them as Critical findings. The Arduino-style version is caught by a generic "credential constant near WiFi.begin / esp_wifi" rule.

The fix isn't "move them to a config file." The fix is provisioning — SmartConfig, BLE-based commissioning, QR-code provisioning, or the device's own AP for first-boot setup. Whatever the choice, the credentials should never live in git.

Static red flag #4: Protected Management Frames off

Deauthentication frames are the original Wi-Fi denial-of-service: they are unauthenticated 802.11 management frames and any nearby device can spoof them. PMF / IEEE 802.11w cryptographically protects management frames so the spoofed deauth no longer works. PMF has been a "should" since 2009, a "must" for Wi-Fi Alliance certification since 2018, and is mandatory for WPA3.

If your firmware accepts WPA2 connections without PMF, you are accepting deauth-flood denial-of-service as a feature.

Static red flag #5: open SSIDs that "shouldn't be there"

Most products go through a phase where engineers are debugging on an open AP — "factory mode," "service mode," "engineering mode." That AP is supposed to be off in production. Often it is not.

The KRACK lesson: patch your supplicant

KRACK was a 2017 protocol-level attack on the WPA2 4-way handshake. Affected supplicants — wpa_supplicant, iwd, embedded BLE/Wi-Fi combos — all received patches. Nine years on, the failure mode that lingers is not unpatched wpa_supplicant; it is firmware that uses an old, vendored, never-updated copy of the supplicant code. The static check is "what supplicant version are we shipping, and is it on the patched line?" SF365's SCA engine treats embedded supplicant builds the same way it treats npm packages — vendored, version-aware, CVE-tracked.

The 2026 target profile

The detection rules SF365 ships

The SF365 Wireless Security Engine ships five Wi-Fi rules:

All five tie back to the WIFI.01–07 controls of the SF365 Wireless Security Baseline (synthesised from NIST SP 800-153 and IEEE 802.11i), so the same finding shows up as both an engineering issue and a compliance gap.

One last reminder. The threat to your Wi-Fi-connected product isn't usually a clever new attack — it's that nobody updated the configuration when WPA3 became table stakes. Static analysis is well-suited to this kind of drift detection. Wire it into CI and let it tell you when you regress.

SF365 ships Wi-Fi static checks today

Five rules, mapped to NIST SP 800-153 + IEEE 802.11i, on the source you already have in git.

Show Me the Wi-Fi Detections