Wi-Fi 7 MLO Security Explained: WPA3, MLD Addresses and Defenders

Wi-Fi 7 Multi-Link Operation (MLO) lets one device talk to an access point over several radio links at once, for example 5 GHz and 6 GHz, while authenticating once. The access point and client each appear as a multi-link device (MLD) with one MLD address plus a separate address per link; pairwise keys are derived once from the two MLD addresses and group keys are handed out per link.

For defenders that means three practical changes. Security is now WPA3 with Protected Management Frames, because the Wi-Fi Alliance requires both for certified devices. Monitoring has to watch every link, not one channel. And the newest parsing code in access points and clients needs the same patch discipline as everything else: the hostapd project published a June 2026 advisory on missing multi-link parsing validation. This post goes one level deeper than our Wi-Fi generations explainer, with every fact checked against IEEE, Wi-Fi Alliance, FCC, hostapd, wpa_supplicant and Linux wireless sources.

Key takeaways

• One association, several links. IEEE 802.11be (Wi-Fi 7) was approved by the IEEE Standards Board on 26 September 2024 and published on 22 July 2025. MLO is the feature with the most security consequences.
• Two kinds of address. Each MLD has an MLD MAC address, and each affiliated radio has its own link address. Linux iw prints the first as "Connected to" and lists the second under each link.
• Keys are derived once, at the MLD level. In hostapd 2.11 the pairwise key derivation uses the AP MLD address and the client's MLD address whenever the association is multi-link, so one pairwise key covers every link.
• Group keys are per link. The 4-way handshake carries separate MLO GTK, IGTK and BIGTK key data elements, each tagged with a link ID, plus an MLO Link element that lists every link's address.
• WPA3 and PMF are the baseline. The Wi-Fi Alliance says WPA3 is mandatory for Wi-Fi CERTIFIED devices, that WPA3 networks require PMF and disallow legacy protocols, and that PMF is required for all new certified devices.
• WPA2 clients still connect, as legacy single-link stations. They cannot be multi-link devices, so they get none of the MLO behaviour, and mixing them in usually means a separate SSID or transition mode with its own trade-offs.
• Randomise both address layers. IEEE 802.11bh-2024 (approved the same day as 802.11be) standardises operation with randomized and changing MAC addresses. An MLD address that never changes undoes link address randomisation.
• Capture needs one radio per link. A sniffer on one channel sees one slice of an MLO session. Filter on link addresses, merge captures and expect encrypted management frames.
• 6 GHz rules shape coverage. The FCC's 2020 order created standard power access points (36 dBm EIRP, under automated frequency coordination) and low power indoor access points (30 dBm EIRP, integrated antennas, no battery power). The FCC approved the first seven AFC systems on 23 February 2024.
• Wi-Fi 8 is about reliability. IEEE 802.11bn (Ultra High Reliability) targets 25 percent gains in throughput at a given signal level, 95th percentile latency and packet loss over Wi-Fi 7, with final approval projected for May 2028.

A dated timeline of Wi-Fi 7, MLO and 6 GHz

Dates come from the IEEE standards pages and 802.11 task group reports, the Wi-Fi Alliance, the FCC, and the hostapd and wpa_supplicant release notes and advisories listed under Sources.

The IEEE page for 802.11be also notes that the PDF is available at no charge through the IEEE GET program, so you can read the normative text yourself rather than relying on summaries.

Single link vs multi-link: what actually changes

The table compares a classic single-link association (Wi-Fi 6 or 6E, or a Wi-Fi 7 client that does not use MLO) with a multi-link association. "Source" points to where we confirmed the behaviour.

What is Multi-Link Operation, and what are an MLD and its link addresses?

The Wi-Fi Alliance's Wi-Fi 7 page describes multi-link operation as support for "more efficient load balancing of traffic among links, resulting in increased throughput and enhanced reliability". It lists MLO next to 320 MHz channels in 6 GHz, 4K QAM, 512 compressed block ack and multiple resource units per station.

Under the hood, 802.11be introduces the multi-link device. An access point that does MLO is an AP MLD: a logical entity that owns several affiliated access points, typically one per band. A client that does MLO is a non-AP MLD: a logical entity that owns several affiliated stations. Each affiliated AP or station is a normal radio with its own channel and its own link address. The MLD sits above them and has its own MLD MAC address, which is what upper layers and the security association bind to.

You can see the split directly in Linux. The iw utility (version 6.17, from kernel.org) prints two different things when a client is connected over MLO:

• iw dev wlan0 link prints "Connected to" followed by the AP MLD address, and then one "Link N BSSID" line per active link with that link's BSSID. If the reported MLD addresses disagree across links, iw prints a warning about "inconsistent MLD address information".
• iw dev lists the interface and, for a multi-link interface, a block headed "MLD with links:", with each link's ID, link address and channel.

The Linux kernel's cfg80211 documentation describes the same split from the AP side: for a station that completed association with an AP affiliated with an MLD, the driver reports the association link ID, and an mld_addr field "for MLO STA connection, filled with MLD address of the station", or all zeros for a non-MLO station.

In hostapd, the access point side, two configuration options define the AP MLD. mld_ap=1 makes a BSS part of an AP MLD, and mld_addr sets the AP MLD MAC address; per the 2.11 sample configuration, if it is not set "the current interface hardware address will be used as the AP MLD MAC address".

A practitioner write-up on MLO association uses the terms upper MAC (U-MAC) for the MLD level and lower MAC (L-MAC) for each link, and makes a point that matters for anyone troubleshooting: the client starts association on one band, "the connection itself spans multiple links", and traffic can move between links without "a traditional roaming process".

How a multi-link association is set up, conceptually

The sequence below is a plain language summary, not an implementation guide.

How does 802.11be authenticate once and derive keys for several links?

The short answer: authentication and the pairwise master key security association (PMKSA) belong to the MLD, the pairwise transient key (PTK) is derived from MLD addresses and shared by all links, and the group keys are per link.

The clearest public evidence is in hostapd's own source code, version 2.11. When hostapd computes the pairwise key, it calls two helper functions for the authenticator address and the supplicant address. In multi-link associations (when the station has an association link ID), the authenticator address is the AP MLD address and the supplicant address is the peer's MLD address; otherwise they are the BSSID and the station's MAC address. The same inputs go into the usual key derivation function together with the two nonces from the handshake. That one choice explains a lot:

• One PMKSA for the MLD. Because the identities in the key hierarchy are MLD addresses, the security association is not tied to the link on which authentication happened. Adding a link does not require new authentication.
• One PTK across links. The practitioner write-up describes the same result in plain terms: the MLD level handles key derivation, "allowing the same unicast encryption keys to be used across multiple links."
• Per-link group keys. Broadcast and multicast traffic is still per radio. hostapd defines four key data encapsulation (KDE) selectors for this, each under the 00-0F-AC organisation identifier: 16 for the MLO GTK, 17 for the MLO IGTK, 18 for the MLO BIGTK and 19 for the MLO Link KDE. The GTK, IGTK and BIGTK variants carry a link ID field, so a station receives one set of group keys per link. Beacon protection keys (BIGTK) therefore protect each link's beacons separately.
• Per-link confirmation. The MLO Link KDE carries the link ID and the link's MAC address, and has a flag for including the link's RSN element information. Including the RSN information gives the client a protected copy of what each link advertised, so a forged beacon on one link that claims weaker security can be detected. hostapd's parser checks that each MLO Link KDE has the expected length before trusting it.

Which AKMs and ciphers show up with Wi-Fi 7?

hostapd 2.11 added "support for new SAE AKM suites with variable length keys". In the source these are AKM suite selectors 00-0F-AC:24 (SAE-EXT-KEY) and 00-0F-AC:25 (FT-SAE-EXT-KEY), and the configuration parser accepts both names in wpa_key_mgmt. Deployment guides for Wi-Fi 7 commonly pair SAE-EXT-KEY with GCMP-256 and beacon protection. The Wi-Fi Alliance's WPA3 specification, which holds the detailed certification requirements, now sits behind a member login, so we could not confirm the exact per-generation requirement text; check it with your access point vendor's documentation before you design around a specific AKM or cipher.

What about enterprise networks?

MLO does not change what 802.1X and EAP do; it changes how many links the resulting keys cover. The RADIUS exchange still happens once, and the resulting PMK feeds the same MLD-level derivation. Our 802.1X and EAP explainer covers the authentication side. Two recent hostapd items matter here: advisory 2024-1 dealt with RADIUS protocol forgery attacks, and advisory 2026-5 covers incomplete validation of the RADIUS Message-Authenticator attribute in hostapd. If hostapd is your RADIUS server or authenticator, keep it current.

Why does Wi-Fi 7 certification require WPA3 and PMF, and what happens to WPA2 clients?

The Wi-Fi Alliance security page states three things plainly: WPA3 "is mandatory for Wi-Fi CERTIFIED devices"; WPA3 networks "require use of Protected Management Frames (PMF)" and "disallow outdated legacy protocols"; and "PMF is required for all new certified devices". Since every Wi-Fi CERTIFIED 7 product is a new certified device, it ships with WPA3 and PMF.

There are good design reasons for this, beyond policy:

• PMF protects the control plane that MLO depends on. With MLO, management frames do more work: they set up links, carry multi-link elements, and handle link changes. PMF protects unicast management action frames from eavesdropping and forging and protects multicast ones from forging, per the Wi-Fi Alliance. Without PMF, a forged disassociation or a forged action frame on one link would be easier to inject.
• SAE removes offline guessing of captured handshakes. WPA2-Personal handshakes can be captured and guessed against offline. SAE does not allow that. With one handshake covering every link, a weak handshake would weaken every link at once.
• Beacon protection becomes practical per link. BIGTK lets a client check that beacons really come from its AP. MLO delivers one BIGTK per link.

So what happens to a WPA2-only laptop?

A device that only supports WPA2 is, by definition, not a Wi-Fi 7 certified device, so it is not an MLD. It can still join a Wi-Fi 7 access point as an ordinary single-link station on one affiliated AP; the Linux cfg80211 documentation explicitly covers "non-MLO STA connections when the AP [is] affiliated with an MLD". What it cannot do is use MLO, and it pulls the network's security towards the weakest member if you let it share an SSID.

Whether a given access point allows MLO on a transition mode SSID is a product decision that we could not confirm against a public primary source, so read your vendor's documentation. Our post on WPA2 vs WPA3 for office Wi-Fi covers transition mode trade-offs in more depth, and WPA3 Enhanced Open covers guest networks.

How does MAC randomisation interact with MLD addresses?

MAC address randomisation exists so that nearby observers cannot track a device by its hardware address. With MLO there are now two layers of address, and both are visible at different moments:

• Link addresses appear in the headers of every frame on each link.
• The MLD address is carried in the Basic Multi-Link element of the association request, which is a management frame sent before any keys exist, and in the Multi-Link element of AP beacons and probe responses. hostapd's advisory 2026-1 describes exactly this parsing path: "frames including information on affiliated links" in both AP and station modes.

The consequence is simple. If a client randomises its link addresses but keeps a stable MLD address, a passive listener can link sessions through the MLD address. Good implementations randomise both, and change them together. The IEEE has standardised the network side of this problem: IEEE 802.11bh-2024, approved on 26 September 2024, specifies "operation with randomized and changing MAC addresses" so that networks can keep providing customer support, diagnostics and device arrival detection "in the absence of unique MAC address-to-STA mapping".

On Linux with wpa_supplicant, address policy is set with mac_addr (per network or globally) and preassoc_mac_addr for scanning. The 2.11 sample configuration documents mac_addr=1 as "use random MAC address for each ESS connection" and mac_addr=2 as random but keeping the OUI with the locally administered bit set. How a given driver maps that policy onto MLD and link addresses depends on the driver and kernel version, so verify the result rather than assuming it:

# Show the MLD-level and per-link addresses wpa_supplicant is using
sudo wpa_cli -i wlan0 status | grep -E '^(address|bssid|ap_mld_addr)='
sudo wpa_cli -i wlan0 mlo_status

status prints address= (your own address) and, when links are valid, ap_mld_addr=. mlo_status prints, per link, link_id, freq, ap_link_addr and sta_link_addr. Reconnect and run both again: if sta_link_addr changes but the MLD-level address you see in the AP's client table does not, your randomisation stops at the link layer.

For network operators, randomisation affects anything keyed on MAC addresses: DHCP reservations, captive portals, network access control and wireless IDS allow lists. Key those on the MLD address where your platform exposes it, and plan for that address to change over time too. Our network cards explainer covers MAC randomisation on wired and wireless interfaces more broadly.

What do 320 MHz channels, 4096-QAM and the 6 GHz rules change for coverage and monitoring?

The Wi-Fi Alliance says 320 MHz channels in 6 GHz "provide twice the throughput of Wi-Fi 6" and that 4K QAM "achieves 20% higher transmission rates than Wi-Fi 6's 1024 QAM". The IEEE scope for 802.11be is at least 30 Gbit/s maximum throughput measured at the MAC data service access point, between 1 and 7.250 GHz, with backward compatibility in 2.4, 5 and 6 GHz.

Worked example: why 4K QAM needs short range

QAM packs bits into each symbol. 1024 QAM carries 10 bits per symbol (2 to the power of 10 is 1024); 4096 QAM carries 12 bits (2 to the power of 12 is 4096). The raw gain is 12 divided by 10, which is 1.2, or 20 percent, matching the Alliance's figure. The catch is that denser constellations need a cleaner signal, so 4K QAM only kicks in close to the access point. For a defender, the practical lesson is that peak rates are short range; do not size coverage or a capture plan around them.

Worked example: how much spectrum one 320 MHz channel takes

The 6 GHz band in the FCC's 2020 order runs from 5.925 to 7.125 GHz, which is 1,200 MHz. A single 320 MHz channel uses 320 divided by 1,200, about 27 percent, of that span. In the U-NII-5 sub-band (5.925 to 6.425 GHz, 500 MHz) a 320 MHz channel takes 64 percent. Wide channels mean fewer non-overlapping channels, more contention between neighbouring networks and, for monitoring, a capture radio that must itself support 320 MHz to see full-width frames. The iw 6.17 channel parser accepts a 320MHz width, but the radio and driver must support it.

The FCC's 6 GHz device classes

The FCC approved the first seven AFC systems on 23 February 2024, which its chief engineer called "a major milestone" for 6 GHz unlicensed use. hostapd exposes the regulatory class through he_6ghz_reg_pwr_type, with values for indoor, standard power, very low power, indoor enabled and indoor standard power access points.

What this means for coverage and monitoring

• Indoor low power 6 GHz cells are small. A 5 dBm/MHz PSD limit spread across a wide channel leaves less power per MHz than standard power. Expect more access points for full 6 GHz coverage, which means more radios to monitor.
• Outdoor 6 GHz is AFC territory. Standard power needs AFC, so an outdoor 6 GHz link that suddenly drops power or changes channel may be following AFC instructions, not failing or under attack.
• Rogue detection must cover 6 GHz. An unauthorised 6 GHz access point is invisible to a sensor that only scans 2.4 and 5 GHz.
• Wide channels change interference patterns. A neighbour's 320 MHz network can overlap all of your 6 GHz channels at once.

How do wireless IDS and packet capture work when traffic is spread across links?

A wireless intrusion detection sensor or a packet capture laptop listens on one channel per radio. With MLO, a single client session can be split across two or three channels in different bands. Several things change.

You need one capture radio per link. If the AP MLD uses a 5 GHz and a 6 GHz link, capture both, at the same time, with radios that support each channel width. Then merge the captures by timestamp.

Filter by link address, map by MLD address. Frames on the air carry link addresses. The practitioner write-up warns that "you need to use the link-specific MAC address to filter client traffic, not the MLD MAC address". Build a mapping table from the association request (MLD address and per-link profiles) or from your AP's client table, then follow each link address separately.

Most of what matters is encrypted. Data frames are encrypted with the PTK as always. With PMF, robust management action frames are protected too. A sensor sees headers, timing, unprotected frames such as beacons and association requests, and the 4-way handshake messages, but not the content.

Detection logic built for one link misreads MLO. Common wireless IDS checks were written for single-link behaviour:

Malformed multi-link elements are worth alerting on. hostapd's 2026-1 advisory describes issues reachable "by sending invalid Management frames without needing authentication or user action on the target device". A sensor that flags malformed Multi-Link elements gives early warning while devices are patched.

For the general picture of how traffic is intercepted on wired and wireless media, see how attackers intercept network traffic.

What do hostapd and wpa_supplicant need for MLO, and how do you check driver support on Linux?

On Linux, three layers must all support MLO: the radio firmware and driver, the kernel's cfg80211 and mac80211 (which expose MLO through nl80211 attributes such as the MLO link ID and the MLD address), and user space (hostapd for access points, wpa_supplicant for clients). hostapd and wpa_supplicant 2.11, released on 20 July 2024, list EHT/IEEE 802.11be/Wi-Fi 7 support as "preliminary". The kernel documentation still describes WIPHY_FLAG_SUPPORTS_MLO as "a temporary flag gating the MLO APIs", so a driver must opt in.

On the build side, hostapd's multi-link code is compiled only with the CONFIG_IEEE80211BE build option, which is also the condition named in advisory 2026-1.

Step by step: check what your Linux machine supports and is using

Run these on a client laptop or a Linux access point. Nothing here changes the system.

1. Record versions.

uname -r                       # kernel version (cfg80211/mac80211 MLO support)
iw --version                   # iw 6.x prints MLD and link details
wpa_supplicant -v | head -1    # client side
hostapd -v 2>&1 | head -1      # access point side, if installed

2. Check that the radio advertises EHT (Wi-Fi 7) capabilities.

iw list | grep -E 'Wiphy|EHT Iftypes|EHT-MCS Map \(BW = 320\)'

Lines such as "EHT Iftypes" show which interface types (managed, AP) the radio supports for 802.11be. An "EHT-MCS Map (BW = 320)" line means 320 MHz rates are advertised.

3. See whether nearby access points are MLDs.

sudo iw dev wlan0 scan | grep -E 'BSS |SSID:|MLD MAC|Maximum Number of Simultaneous Links'

An AP MLD's beacons include a Multi-Link element; iw prints the AP MLD's address as "MLD MAC" and, when present, the "Maximum Number of Simultaneous Links".

4. Check whether your own connection is multi-link.

iw dev wlan0 link
iw dev

A multi-link connection shows "Connected to" the AP MLD address followed by a "Link N BSSID" line per link; iw dev shows "MLD with links:" and a "link addr" per link.

5. Ask wpa_supplicant directly.

sudo wpa_cli -i wlan0 status
sudo wpa_cli -i wlan0 mlo_status
sudo wpa_cli -i wlan0 mlo_signal_poll

status includes key_mgmt, pairwise_cipher and, for MLO, ap_mld_addr. Confirm key_mgmt is an SAE or 802.1X variant and not WPA-PSK.

6. Check per-link station statistics on an access point.

sudo iw dev wlan0 station dump

On a multi-link AP, iw prints a "Link N:" section per link for each station, which helps confirm that clients actually use more than one link.

Example: a WPA3-only AP MLD in hostapd

This is a minimal, illustrative sketch for a lab access point using options documented in the hostapd 2.11 sample configuration. One configuration file runs per radio; both share the SSID, passphrase and mld_ap=1. Check your driver's documentation for how it groups radios into one AP MLD, since that part differs between drivers.

# /etc/hostapd/wlan0-6g.conf  (6 GHz link; a matching file is needed for the 5 GHz radio)
interface=wlan0
ctrl_interface=/var/run/hostapd
ssid=lab-wifi7
country_code=US
hw_mode=a
channel=37
# Channel width (op_class, eht_oper_centr_freq_seg0_idx) depends on your driver; see hostapd.conf
ieee80211ax=1
ieee80211be=1             # EHT requires ieee80211ax=1, or hostapd refuses to start
he_6ghz_reg_pwr_type=0    # 0 = indoor AP (low power indoor)

# Security: WPA3-Personal only, PMF required
wpa=2
wpa_key_mgmt=SAE SAE-EXT-KEY
rsn_pairwise=CCMP GCMP-256
ieee80211w=2              # PMF required
sae_pwe=1                 # hash-to-element only
beacon_prot=1             # beacon protection (BIGTK)
ssid_protection=1         # SSID protection in the 4-way handshake (off by default in 2.11)
sae_password=use-a-long-random-passphrase-here

# Multi-link
mld_ap=1
mld_addr=02:00:00:aa:bb:01   # same AP MLD address in every link's file

Notes on the choices:

• hostapd refuses ieee80211be=1 without ieee80211ax=1 ("Cannot set ieee80211be without ieee80211ax").
• ssid_protection=1 enables the mitigation hostapd 2.11 added for the SSID confusion issue tracked as CVE-2023-52424; the ChangeLog says it is "disabled by default for now".
• sae_pwe=1 uses hash-to-element only. hostapd 2.11 also fixed "SAE H2E rejected groups validation to avoid downgrade attacks" (advisory 2024-2).
• Do not reuse an example passphrase. Generate one, and rotate it when people leave.

After starting the AP, run iw dev on it and on a client to confirm both links are up and that the client reports "MLD with links".

What are the known weaknesses and open issues?

We looked for research on MLO-specific security in the IEEE and academic literature and did not find a peer-reviewed attack paper focused on MLO at the time of writing. What does exist publicly falls into four groups.

1. Implementation bugs in the new parsing code

The hostapd project's advisory 2026-1, published 5 June 2026, says vulnerabilities in "parsing and use of received multi-link (MLO/EHT/IEEE 802.11be/Wi-Fi 7) information" were found in both hostapd and wpa_supplicant. In AP mode they can cause denial of service through process termination and "small memory corruption" that the maintainers judged unlikely to be exploitable in practice; in station mode they can cause denial of service and memory corruption. Both can be reached with invalid management frames, without authentication. Affected: hostapd v2.11 and later snapshots before v2.12 built with CONFIG_IEEE80211BE, and wpa_supplicant v2.11 and later snapshots before v2.12. The fixes add link ID validation and length checks on the Basic Multi-Link element in association, scan result parsing, association rejection and reconfiguration paths. The maintainers also reviewed similar code and added stricter validation "to minimize risk for unknown issues or issues enabled by future extensions".

The lesson is general: a new information element with nested per-link profiles is new attack surface, in every vendor's firmware, not only in open source.

2. PMKSA caching logic

Advisory 2026-2, published 9 July 2026, affects all versions of wpa_supplicant. With drivers that select the target AP internally, wpa_supplicant did not consistently enforce that a cached PMKSA entry matched the same network configuration and key management option. A misbehaving AP could make a client reuse an unrelated cached entry, which "could allow bypassing expected authentication steps"; the attacker would need a valid credential for some configured network. The advisory says it does not apply where the target uses WPA3-Personal (SAE), although SAE-derived entries could be misused against WPA2-Personal or 802.1X networks. This is not an MLO bug, but MLO makes the MLD-level PMKSA central, so cache handling deserves attention.

3. Older protocol issues that still apply

MLO inherits the base protocol. The SSID confusion issue (CVE-2023-52424) led hostapd 2.11 to add optional SSID protection in the 4-way handshake. SAE side channel and downgrade fixes appear in advisories 2019-1, 2019-6, 2022-1 and 2024-2. KRACK and FragAttacks, covered in our Wi-Fi generations post and KRACK explainer, were fixed by patches on both sides of the link.

4. Open design questions defenders should track

• Unprotected pre-association frames. Beacons, probe responses and association requests still travel before keys exist and now carry more information (Multi-Link elements and MLD addresses). Beacon protection helps after association; it cannot protect the first frames a client sees.
• Privacy of the MLD address. As above, a stable MLD address can undo link address randomisation.
• Visibility gaps. Security tools that assume one channel per client may misclassify or miss MLO behaviour.
• Post-quantum key exchange. IEEE lists project P802.11bt, "Enhancements for Post-Quantum Cryptography", which plans AKM suites, signature and key establishment algorithms, a password authenticated key exchange and handshake changes for PQC. It is a project, not a standard yet.

What does Wi-Fi 8 (802.11bn, Ultra High Reliability) plan to add?

According to the TGbn status page, 802.11bn adds an Ultra High Reliability capability for both isolated and overlapping networks, defined as at least one mode that:

• increases throughput by 25 percent at at least one signal to interference and noise level, compared with Wi-Fi 7 (EHT);
• reduces 95th percentile latency by 25 percent; and
• reduces MAC protocol data unit loss by 25 percent, "especially for transitions between BSSs".

It also aims to reduce access point power consumption, including mobile APs, and improve peer to peer operation. The task group's comment resolution lists include roaming, multi-AP coordination topics (coordinated beamforming, spatial reuse and TDMA) and "Security", and a November 2025 session list explicitly includes MLO and security. The schedule shows D2.0 balloted in July 2026, D3.0 planned for January 2027, an initial sponsor ballot in May 2027, and final approvals projected for March and May 2028.

The Wi-Fi Alliance's own page frames Wi-Fi 8 the same way: reliability, deterministic low latency, and access points that "collaborate instead of competing for spectrum". For defenders, multi-AP coordination and smoother roaming will mean even more management signalling between devices, which makes PMF, beacon protection and careful parsing more important, not less. The security details are still in draft, so treat any claim about specific Wi-Fi 8 security features as provisional until the amendment is approved.

Step by step: a defender's MLO rollout checklist

1. Inventory radios and software versions. For every access point and Linux client, record firmware, driver, kernel, hostapd and wpa_supplicant versions. Vendor access points embed these components too; ask the vendor which versions and whether advisory 2026-1 is fixed.
2. Decide the SSID plan. WPA3-only SSID with MLO for modern devices; a segmented legacy SSID for WPA2 devices; Enhanced Open for guests.
3. Require PMF and enable beacon protection. Confirm on the controller and from a client with wpa_cli status.
4. Turn on SSID protection where supported. In hostapd it is ssid_protection=1.
5. Set the 6 GHz power class correctly. Indoor low power or standard power with AFC; record the choice for each AP.
6. Map MLD and link addresses. Export your AP client table with MLD and link addresses and feed it to your monitoring.
7. Extend sensors to every band in use. Including 6 GHz, with 320 MHz capable radios if you use 320 MHz channels.
8. Update detection rules. Correlate by MLD address; alert on PMF disabled, unprotected deauths and malformed Multi-Link elements.
9. Patch on a schedule. Track hostapd and wpa_supplicant advisories and vendor firmware releases; v2.12 or a rebuilt v2.11 with the listed commits fixes 2026-1.
10. Re-test randomisation. Reconnect clients and confirm that link and MLD addresses both change according to your policy.

Common mistakes

• Treating MLO as a speed toggle. It changes identity, key handling and monitoring. Plan it like a security change.
• Keeping a transition mode SSID forever. Transition mode is for migration windows. Move legacy devices to their own segmented SSID.
• Assuming PMF is on because the box says Wi-Fi 7. Verify from a client. Mixed configurations and legacy SSIDs can still run with PMF optional.
• Filtering captures on the MLD address. Frames on the air carry link addresses. Map first, then filter.
• Monitoring 2.4 and 5 GHz only. 6 GHz is where Wi-Fi 7's wide channels live, and where a rogue AP could hide from an older sensor.
• Ignoring the MLD address in privacy reviews. Link randomisation without MLD randomisation still allows tracking.
• Skipping wpa_supplicant updates on Linux laptops. Advisory 2026-1 affects the client side too, and 2026-2 affects all versions.
• Using a short SAE passphrase because "SAE stops offline guessing". It stops offline guessing of captured handshakes, not online guessing or a passphrase shared too widely.
• Building a hostapd image without tracking it. If you ship hostapd or wpa_supplicant inside a router image or embedded Linux build, you own its patching.

FAQ

What is MLO in Wi-Fi 7?

Multi-Link Operation lets a Wi-Fi 7 client and access point use several radio links, usually in different bands, as one association. Traffic can be balanced across links or moved between them without a roam, which the Wi-Fi Alliance says increases throughput and reliability.

What is an MLD address?

It is the MAC address of a multi-link device as a whole, separate from the address of each radio link. Pairwise keys are derived from the AP MLD address and the client MLD address, and Linux iw shows it as "Connected to" for a multi-link connection.

Does Wi-Fi 7 require WPA3?

Yes for certified devices. The Wi-Fi Alliance says WPA3 is mandatory for Wi-Fi CERTIFIED devices and that PMF is required for all new certified devices, which includes every Wi-Fi CERTIFIED 7 product.

Can WPA2 devices connect to a Wi-Fi 7 router?

Usually yes, as single-link legacy clients on one band, if the router offers a WPA2 or transition mode SSID. They cannot use MLO. The safer pattern is a separate, segmented SSID for legacy devices.

Is Wi-Fi 7 more secure than Wi-Fi 6?

The cryptography is the same family (WPA3, SAE, PMF), but Wi-Fi 7 certification makes WPA3 and PMF the baseline and adds per-link beacon protection keys. It also adds new parsing code, which has already needed security fixes, so patching matters as much as ever.

Does MAC randomisation still work with Wi-Fi 7 MLO?

It can, but both the link addresses and the MLD address need to change. A stable MLD address in association frames lets observers link sessions even if link addresses rotate. IEEE 802.11bh-2024 standardises how networks operate with randomized and changing addresses.

How do I know if my Linux laptop is using MLO?

Run iw dev wlan0 link. A multi-link connection shows the AP MLD address after "Connected to" and a "Link N BSSID" line per link. iw dev shows "MLD with links:", and wpa_cli -i wlan0 mlo_status lists each link's frequency and addresses.

Can I capture Wi-Fi 7 MLO traffic with Wireshark?

You can capture each link with a monitor mode radio that supports that band and channel width, then merge the captures. You need one radio per link, and data and protected management frames stay encrypted unless you have the keys.

What is AFC in 6 GHz Wi-Fi?

Automated frequency coordination is a database service that tells standard power 6 GHz access points which frequencies and power levels they can use without interfering with licensed microwave links. The FCC approved the first seven AFC systems on 23 February 2024.

When is Wi-Fi 8 coming?

IEEE 802.11bn's schedule projects final working group approval in March 2028 and Standards Board approval in May 2028. Its goal is reliability: 25 percent improvements in throughput at a given signal level, tail latency and packet loss over Wi-Fi 7.

Where Safeguard fits

Safeguard does not configure access points, monitor radio traffic, run a wireless IDS, scan firmware or manage devices, and nothing in this post depends on it. The honest connection is narrower. hostapd, wpa_supplicant, iw and the Linux kernel are open source components, and the advisories above show that the newest Wi-Fi code needs the same patch tracking as any library. If your team builds router images, embedded Linux or container images that include these components, you can describe them in an SBOM and scan that SBOM, or the repositories and images you build, with Safeguard (safeguard scan --sbom <file>, --dir . or --image <name>). Safeguard matches the components against vulnerability databases, ranks findings with reachability analysis and evaluates your policies and gates before a build ships. It cannot see the firmware inside an access point you bought; for that, the fix has to come from the vendor.

Wireless stacks such as hostapd, wpa_supplicant and the drivers beneath them ship as open source components, and the multi-link parsing advisory shows that new protocol features arrive as new code to patch. The practices below apply to the open source components and images you build and ship, even though they cannot reach the firmware inside an access point you bought.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and coding assistant workflows, not Wi-Fi configuration or monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo is a real CLI session: install, open the interactive terminal with safeguard, ask it to fix a lodash CVE, and watch it read the finding and advisory, ask before each command, edit package.json to lodash 4.17.21, run npm install and npm test with approval, print a summary and push nothing. The same approval flow applies if your repository builds an embedded Linux or router image and you need to move a pinned hostapd or wpa_supplicant version after an advisory.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. If you build images on a lab machine next to your test access points, the local runner scans those repositories and SBOMs without giving a hosted service access to your source.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once connected, you can ask which of your projects carry a given component and version, for example a hostapd build, and get answers from your own Safeguard data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEEE SA: IEEE 802.11be-2024 (PAR approval, board approval and publication dates, scope; also lists P802.11bt, post-quantum cryptography)
• IEEE SA: IEEE 802.11bh-2024, Operation with Randomized and Changing MAC Addresses
• IEEE 802.11: TGbe (EHT) status update
• IEEE 802.11: TGbn (Ultra High Reliability) status update and timeline
• IEEE 802.11: Official timelines
• Wi-Fi Alliance: Wi-Fi CERTIFIED 7 and Wi-Fi 8
• Wi-Fi Alliance: Security (WPA3, Enhanced Open, Protected Management Frames)
• FCC: FCC opens 6 GHz band to Wi-Fi and other unlicensed uses (April 2020)
• FCC 20-51: Report and Order and Further Notice of Proposed Rulemaking, Unlicensed Use of the 6 GHz Band
• FCC news release: FCC approves Wi-Fi management systems to operate in 6 GHz band (23 February 2024)
• FCC fact sheet: Unlicensed use of the 6 GHz band, geofenced variable power devices (8 January 2026)
• hostapd and wpa_supplicant security advisories
• hostapd advisory 2026-1: Missing multi-link parsing validation in wpa_supplicant and hostapd
• hostapd advisory 2026-2: Missing network context validation for PMKSA caching
• hostapd 2.11 release (ChangeLog, hostapd.conf and source)
• wpa_supplicant 2.11 release (ChangeLog, wpa_supplicant.conf and source)
• iw 6.17 release (source)
• Linux wireless: iw documentation
• Linux kernel: cfg80211 subsystem documentation
• mrncciew: Wi-Fi 7 MLO association overview (practitioner write-up)

Last reviewed: 23 October 2026. IEEE 802.11bn dates are projections and may move; check the TGbn status page for the current schedule.