Wi-Fi Generations From 802.11b to Wi-Fi 7 and Wi-Fi 8, With Security

Wi-Fi has gone through seven major generations since the first 802.11 standard was approved in 1997: 802.11b and 802.11a in 1999, 802.11g in 2003, then Wi-Fi 4, 5, 6 and 7, with Wi-Fi 8 (IEEE 802.11bn) projected for approval in 2028. Each one added speed and efficiency, while security moved from WEP to WPA, WPA2 and WPA3 because researchers kept breaking the older designs.

That is the short answer. The longer one matters if you buy, configure or ship wireless equipment, because the generation printed on a box tells you very little about whether a device is safe to run. A Wi-Fi 7 access point can still be configured with WPA2 in transition mode, and the most damaging attacks of the last decade, KRACK and FragAttacks, hit every generation at once because they lived in the shared protocol and in the software stacks that implement it. This post walks through both tracks, the radio and the security, with dates checked against the IEEE 802.11 Working Group, the Wi-Fi Alliance, the FCC and the researchers who found the flaws.

Key takeaways

• The IEEE writes the 802.11 amendments (b, a, g, n, ac, ax, be, bn). The Wi-Fi Alliance certifies products and, since 3 October 2018, gives the major generations simple names: Wi-Fi 4 (802.11n), Wi-Fi 5 (802.11ac), Wi-Fi 6 (802.11ax) and on to Wi-Fi 7 (802.11be).
• The FCC opened 1,200 MHz of 6 GHz spectrum (5.925 to 7.125 GHz) for unlicensed use in an order adopted on 23 April 2020. That band is what Wi-Fi 6E and Wi-Fi 7 add.
• Wi-Fi 7 adds 320 MHz channels in 6 GHz, multi-link operation (MLO) and 4K QAM. IEEE 802.11be was approved on 26 September 2024 and published on 22 July 2025.
• Wi-Fi 8 (802.11bn, Ultra High Reliability) targets 25 percent gains in throughput, tail latency and packet loss, not a headline speed jump. Approval is projected for May 2028.
• WEP is broken and should never be used. KRACK (2017) was a flaw in the WPA2 standard itself; FragAttacks (2021) combined three design flaws present since 1997 with many implementation bugs; Dragonblood (2019) found design and implementation issues in WPA3's SAE handshake.
• Every one of those was fixed in software, which makes wpa_supplicant, hostapd and Wi-Fi firmware components to track like any other dependency.

The dated timeline: radio and security side by side

The table below combines the IEEE approval dates, Wi-Fi Alliance programme dates and the security research that forced changes. IEEE dates are the Standards Board (RevCom) approval dates from the IEEE 802.11 official timelines page, which is a more precise anchor than "the year it came out".

Products often ship well before the IEEE amendment is final: Wi-Fi 6 was named in 2018, but 802.11ax was approved in February 2021. The IEEE also eventually rolls each amendment into a consolidated revision of 802.11 and marks the amendment as superseded, which is why the timelines page lists 802.11b, 802.11g and 802.11i as superseded on 8 March 2007.

The spec comparison table

This table compares the generations on the parameters that drive real behaviour. The peak rate column is the theoretical maximum PHY rate commonly quoted for each amendment, with every optional feature switched on at once: the widest channel, the most spatial streams, the densest modulation and short guard intervals. No consumer device reaches it.

The Wi-Fi Alliance's own pages describe Wi-Fi 7's gains relatively rather than as one big number: 320 MHz channels offer twice the throughput of Wi-Fi 6, and 4K QAM gives about 20 percent higher transmission rates than Wi-Fi 6's 1024 QAM, according to the Wi-Fi CERTIFIED 7 page. The IEEE's 802.11be task group defined the amendment as capable of "a maximum throughput of at least 30 Gbps", per the TGbe status page.

Treat the peak rate column as headroom, not a promise: a two stream phone on an 80 MHz channel sees a fraction of it.

Generation by generation: what each one added

802.11 (1997): the starting point

The first 802.11 standard was approved on 26 June 1997. It defined low data rates in the 2.4 GHz band and a security mechanism called Wired Equivalent Privacy, or WEP. The name tells you the goal: make a radio link about as private as a cable. As the security section below explains, it did not get there.

802.11b and 802.11a (1999): Wi-Fi goes mainstream

Both amendments were approved on 16 September 1999. 802.11b stayed in 2.4 GHz and raised the rate to 11 Mbps, which was enough to make wireless networking practical for laptops. 802.11a moved to 5 GHz and used orthogonal frequency division multiplexing (OFDM) to reach 54 Mbps. 802.11b was the one most people met first.

802.11g (2003): OFDM in 2.4 GHz

802.11g was approved on 12 June 2003. It brought OFDM and 54 Mbps to the 2.4 GHz band while staying backward compatible with 802.11b clients. That compatibility has a cost every later generation also pays: slow legacy clients eat airtime.

Wi-Fi 4, 802.11n (2009): MIMO and wider channels

802.11n was approved on 11 September 2009, and the Wi-Fi Alliance's generation page dates Wi-Fi CERTIFIED n to the same year. It introduced multiple input, multiple output (MIMO), which sends several spatial streams at once over multiple antennas, and it allowed two 20 MHz channels to be bonded into 40 MHz. It also worked in both 2.4 and 5 GHz.

Wi-Fi 5, 802.11ac (2013 standard, 2014 certification): wide channels in 5 GHz

802.11ac was approved on 9 December 2013. The Wi-Fi Alliance lists Wi-Fi CERTIFIED ac as introduced in 2014 and describes Wi-Fi 5 as mostly dual band. The amendment itself operates in 5 GHz, with 80 and 160 MHz channels, 256-QAM, explicit beamforming and downlink multi-user MIMO (MU-MIMO), which lets an access point send to several clients in the same transmission.

Wi-Fi 6, 802.11ax (2018 name, 2021 standard): efficiency over speed

Wi-Fi 6 was the first generation designed mainly for crowded networks rather than for a single fast client. The Wi-Fi Alliance's generation page lists its features as OFDMA, which shares a channel among several clients at once; multi-user MIMO serving more devices at once; 160 MHz channels; target wake time (TWT), which schedules when battery powered devices wake to talk; 1024 QAM; and transmit beamforming. It dates Wi-Fi CERTIFIED 6 to 2018, the year the name was announced, while the IEEE approved 802.11ax on 1 February 2021.

OFDMA matters most in an office. Instead of giving the whole channel to one client per transmission, it splits the channel into resource units (RUs) so many small transmissions, such as voice frames and acknowledgements, share one slot.

Wi-Fi 6E (2020 to 2021): the 6 GHz band

Wi-Fi 6E is Wi-Fi 6 extended into the 6 GHz band. It is not a new IEEE amendment; it is a new band. The Wi-Fi Alliance's generation page says Wi-Fi 6 "added the 6 GHz band" to 2.4 and 5 GHz, and it counts Wi-Fi 6E and tri-band Wi-Fi 7 together in its 6 GHz chipset figures.

The regulatory step that made it possible in the United States was the FCC's Report and Order FCC 20-51, adopted on 23 April 2020 and released on 24 April 2020. It made 1,200 MHz of spectrum available for unlicensed use in the 6 GHz band, 5.925 to 7.125 GHz. The order splits the band into four sub-bands, U-NII-5 through U-NII-8, based on which licensed incumbents use each part, and it authorises two kinds of access point:

• Standard-power access points in U-NII-5 (5.925 to 6.425 GHz) and U-NII-7, which must use an automated frequency coordination (AFC) system to avoid interfering with fixed microwave links. The order says these can be deployed anywhere, for example in hotspot networks and rural broadband.
• Low-power indoor access points across the entire 6 GHz band, without AFC.

Other countries opened all or part of the 6 GHz band under their own rules, on their own timetables and with different amounts of spectrum. Outside the United States, check your national regulator's current rules for channels and power classes.

Wi-Fi 7, 802.11be (2024): MLO, 320 MHz and 4K QAM

The Wi-Fi Alliance introduced Wi-Fi CERTIFIED 7 in 2024. The IEEE approved 802.11be on 26 September 2024 and published it on 22 July 2025. The Alliance's Wi-Fi 7 page lists five headline features:

1. 320 MHz channels in the 6 GHz band, double the widest Wi-Fi 6 channel.
2. Multi-link operation (MLO), which lets a device use links in more than one band at once and balance traffic across them for throughput and reliability.
3. 4K QAM (4096-QAM), packing 12 bits into each symbol instead of 10.
4. 512 compressed block ack, which cuts acknowledgement overhead.
5. Multiple RUs to a single station, so a scheduler can give one client non-adjacent pieces of a channel, for example around a busy or punctured section.

The IEEE TGbe pages also record design work on 16 spatial streams, preamble puncturing, multi-AP coordination and low latency access. Multi-AP coordination comes back as a central theme in Wi-Fi 8.

MLO is the feature with security and operational consequences. A multi-link device presents one logical association made of several radio links, so key management, management frame protection and roaming all had to be defined across links. That is new code in drivers, firmware, wpa_supplicant and hostapd, and new code is where implementation bugs live. The hostapd project's own security advisory list includes a 2026 advisory on multi-link parsing, a reminder that the newest features need the same patch discipline as the oldest.

Why the Wi-Fi Alliance introduced generational names in 2018

On 3 October 2018 the Wi-Fi Alliance announced that products based on 802.11ax would be called Wi-Fi 6, and it retroactively named 802.11n as Wi-Fi 4 and 802.11ac as Wi-Fi 5. Its president and CEO, Edgar Figueroa, framed the problem this way: "For nearly two decades, Wi-Fi users have had to sort through technical naming conventions."

The release said the numbering would let devices show the generation in a status bar icon, and that certification programmes based on major IEEE releases would use generational names starting with Wi-Fi 6.

The trap for security teams: a generation name describes radio capability, not which security modes are enabled or whether firmware is current. Record those separately in asset inventories.

What 802.11bn (Wi-Fi 8) is targeting, and when

Wi-Fi 8 is the name the Wi-Fi Alliance uses for the next generation, which it describes on its generation page as focused on reliability: higher reliability, deterministic low latency and high speeds across signal conditions, with access points able to coordinate rather than compete for spectrum.

The IEEE work behind it is Task Group BN, 802.11bn, titled Ultra High Reliability (UHR). According to the TGbn status page, the project's PAR was approved in July 2023 and the amendment covers operation between 1 GHz and 7.250 GHz. Its objectives are framed as improvements over Wi-Fi 7 (EHT):

• At least one mode that increases MAC throughput by 25 percent at some signal to noise level.
• At least one mode that reduces 95th percentile latency by 25 percent.
• At least one mode that reduces MPDU loss by 25 percent, including when a client moves between networks.
• Lower power consumption for access points, including mobile access points, and better peer to peer operation.
• Backward compatibility and coexistence with legacy devices in 2.4, 5 and 6 GHz.

The schedule has slipped a little, as IEEE schedules usually do. Draft 1.0 finished its first working group letter ballot in July 2025 rather than the projected May 2025, and Draft 2.0 finished its ballot in July 2026 rather than May 2026. Draft 3.0 is projected for January 2027, sponsor ballot from May 2027, final working group approval in March 2028 and Standards Board approval in May 2028.

Comment topics at that meeting included multi-AP coordination (MAPC), coordinated beamforming, roaming and security; they are open topics, not a frozen feature list. Expect pre-standard products, and firmware that changes, before the standard is final.

The security track: WEP to WPA3

How WEP failed and what replaced it

WEP shipped with the 1997 standard. It combined the RC4 stream cipher with a short, per-packet initialisation vector and a static shared key, and it used a CRC checksum for integrity rather than a cryptographic message authentication code. Around 2001, academic researchers showed that this design leaked keystream through IV reuse, let an attacker modify packets without detection, and allowed the key to be recovered from captured traffic.

The industry's response came in two steps. WPA was an interim certification that kept older hardware usable through a firmware change. The lasting fix was IEEE 802.11i, approved on 24 June 2004, which defined the Robust Security Network with AES-based CCMP encryption and the 4-way handshake for deriving fresh session keys. WPA2 is the Wi-Fi Alliance certification built on 802.11i. Management frames, such as deauthentication messages, remained unprotected until 802.11w, approved on 11 September 2009, added protected management frames (PMF).

WEP's legacy is that it is still there. The researchers behind both KRACK and FragAttacks both go out of their way to warn against falling back to WEP.

What KRACK showed (2017)

KRACK, short for key reinstallation attacks, was found by Mathy Vanhoef at imec-DistriNet, KU Leuven. According to krackattacks.com, vendors were notified around 14 July 2017, CERT/CC sent a broad notification on 28 August 2017, and the work was presented at ACM CCS on 1 November 2017.

In plain terms, the WPA2 4-way handshake lets an access point resend its third message if it thinks the client missed it. A client that receives that message again reinstalls the session key it already has, and in doing so resets the counters that guarantee each packet uses a unique nonce. Reusing nonces with the same key breaks the encryption's core assumption, so traffic can be decrypted or replayed and, with some ciphers, forged. KRACK did not reveal the Wi-Fi password.

Was it a protocol flaw or an implementation flaw? Both, and that is the lesson. The site states that the weakness is in the Wi-Fi standard itself, so any correct implementation of WPA2 was likely affected. On top of that, the most severe variant was an implementation bug: wpa_supplicant 2.4 and later, used by Linux and by Android 6.0 and higher, installed an all-zero key instead of reinstalling the real one. Ten CVE identifiers were assigned, in the range CVE-2017-13077 to CVE-2017-13088.

The practical guidance was also instructive. Patch both clients and access points, since patching one side is not enough. Changing the Wi-Fi password does not help. And moving to WPA3 was not required to fix it, because the patches were backward compatible. For more background, see our explainer on what the KRACK attack is.

What WPA3 changes (2018)

The Wi-Fi Alliance introduced WPA3 on 25 June 2018. The announcement described three main changes:

• WPA3-Personal replaces the pre-shared key handshake with Simultaneous Authentication of Equals (SAE). SAE is a password authenticated key exchange, which means an attacker who records a handshake cannot take it away and guess passwords offline at leisure. The release says it makes password guessing harder for third parties even when users pick passwords weaker than typical complexity advice.
• WPA3-Enterprise 192-bit mode gives the equivalent of 192-bit cryptographic strength with a consistent set of algorithms for networks carrying sensitive data.
• Protected Management Frames are required on all WPA3 networks.

The same release introduced transition mode, which lets WPA3 and WPA2 devices share a network during migration, and stated that WPA2 remained mandatory for all Wi-Fi CERTIFIED devices at that time.

Today the Wi-Fi Alliance's security page says WPA3 is mandatory for Wi-Fi CERTIFIED devices, that WPA3 networks require PMF and block outdated legacy protocols, and that PMF is required for all new certified devices. The same page describes Wi-Fi Enhanced Open, which provides unauthenticated encryption on open networks with no shared passphrase and works alongside captive portals. Our posts on WPA2 vs WPA3 for office Wi-Fi and WPA3 Enhanced Open go deeper on both.

What Dragonblood found (2019)

Less than a year after WPA3 launched, Mathy Vanhoef and Eyal Ronen published Dragonblood, an analysis of SAE's Dragonfly handshake. Findings were disclosed in April 2019, with further results in August 2019 and January 2020, and the paper appeared at IEEE Symposium on Security and Privacy in May 2020. The issues fell into four groups:

• Downgrade attacks. In transition mode, a client could be pushed onto a rogue WPA2-only network, which reopens offline dictionary attacks. A separate downgrade could push clients onto weaker cryptographic groups.
• Timing side channels when Brainpool curves or MODP groups were used. The researchers report that NIST curves were not affected by this timing leak.
• Cache side channels, where memory access patterns while building the handshake could leak information about the password.
• Denial of service, where forged handshake messages could make an access point do expensive work.

The researchers describe the downgrade, cache and denial of service issues as design flaws, with several other issues specific to particular implementations. The Alliance issued updated recommendations in late 2019, and the standard moved toward a more side channel resistant way of deriving the password element, known as hash to element (H2E). The hostapd project shipped advisories 2019-1 through 2019-7 for SAE and EAP-pwd issues, a second side channel update as 2022-1, and in 2024 an advisory titled "incomplete SAE H2E downgrade protection for group negotiation".

The lesson is not that WPA3 is weak, but that a new handshake takes years and several patch rounds to settle, and transition mode keeps the old attack surface alive.

What FragAttacks showed (2021)

FragAttacks, short for fragmentation and aggregation attacks, was also Mathy Vanhoef's work, carried out at NYU Abu Dhabi. The FragAttacks site went public on 11 May 2021, after a nine month coordinated disclosure supervised by the Wi-Fi Alliance and ICASI. The paper, "Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation", appeared at USENIX Security 2021.

It identified three design flaws in the 802.11 standard: the aggregation attack (CVE-2020-24588), the mixed key attack (CVE-2020-24587) and the fragment cache attack (CVE-2020-24586). The site says several of these flaws have been part of Wi-Fi since its 1997 release and that they affect all modern Wi-Fi security protocols, including WPA3. Alongside them were a larger set of implementation flaws in specific products, which the researcher notes were often easier to exploit than the design flaws.

The defensive advice is worth repeating because it applies to every generation: update all devices, do not depend on unpatched IoT devices, use HTTPS, and stop using WEP. The site is also clear that PMF (802.11w) and EAP-TLS do not prevent these attacks, and that disabling fragmentation and pairwise rekeys only reduces risk.

Protocol flaws and implementation flaws, side by side

Every row ends in "patch the software". A newer generation of hardware did not fix any of them on its own.

Is WPA3 required for Wi-Fi 6E and Wi-Fi 7 certification?

Here is what the sources we checked say. The Wi-Fi Alliance's security page states that WPA3 is mandatory for Wi-Fi CERTIFIED devices and that PMF is required for all new certified devices. Its Wi-Fi 6 and Wi-Fi 7 generation pages do not list security requirements at all.

In practice this means a newly certified Wi-Fi 6E or Wi-Fi 7 device should support WPA3 and PMF. It does not mean a network built from those devices is running WPA3. An access point can still be configured for WPA2 or transition mode for older clients, and many are. Check your equipment's documentation for what it enforces in each band, including whether it limits 6 GHz to WPA3 or Enhanced Open. Certification tells you what a device can do; your configuration decides what it does.

Choosing a security mode: a decision table

Step by step: check what your devices actually support and run

This walkthrough reads capabilities and versions. Nothing here changes or erases anything.

1. On a Linux laptop or server

# Which interface and which driver?
iw dev

# What is the current link: band, channel width, MCS, signal
iw dev wlan0 link

# Full capability dump: look for "HE" (Wi-Fi 6), "EHT" (Wi-Fi 7),
# 6 GHz frequencies (5955 MHz and up), and supported ciphers
iw list | less

# Which security a NetworkManager profile uses
nmcli -f 802-11-wireless-security connection show "Office WiFi"

# Versions of the user space Wi-Fi stack
wpa_supplicant -v
hostapd -v   # only on access points or hotspots that run hostapd

Update wpa_supplicant through your package manager rather than by hand, so security fixes keep arriving.

2. On macOS

# Current network: PHY mode (802.11ax, 802.11be), channel, width, security
system_profiler SPAirPortDataType

Look at "PHY Mode", "Channel" and "Security" for the current network. A line such as "WPA2/WPA3 Personal" means the network is running in transition mode.

3. On Windows

# Current connection: radio type, authentication, cipher, band, channel
netsh wlan show interfaces

# What the adapter and driver support, including WPA3 and 6 GHz
netsh wlan show drivers

show drivers lists the authentication and cipher pairs the driver supports in infrastructure mode. If WPA3-Personal is missing, update the Wi-Fi driver from the PC or chipset maker before blaming the access point.

4. On an access point you control

If you run hostapd directly, for example on a Linux router or a lab access point, a WPA3-Personal only configuration looks like this. Values are illustrative; check the documentation shipped with your hostapd version.

interface=wlan0
ssid=office-wpa3
wpa=2
wpa_key_mgmt=SAE
rsn_pairwise=CCMP
ieee80211w=2          # management frame protection required
sae_require_mfp=1
sae_pwe=2             # allow both hunting-and-pecking and hash-to-element
sae_password=use-a-long-random-passphrase-here

On commercial access points, look for the equivalent settings: "WPA3 Personal" rather than "WPA2/WPA3", "PMF required" rather than "optional", and the firmware version on the status page.

5. In the products you build or buy

If you build Linux or Android based devices, wpa_supplicant and hostapd are components in your image, alongside the vendor's Wi-Fi driver and firmware blobs. Find them in the SBOM for each release:

# CycloneDX SBOM: list Wi-Fi stack components and versions
jq -r '.components[]
  | select(.name | test("wpa_supplicant|hostapd|wpasupplicant|hostap|linux-firmware|wireless-regdb"))
  | "\(.name) \(.version) \(.type)"' firmware-sbom.cdx.json

# Check the same SBOM for known vulnerable components
safeguard scan --sbom firmware-sbom.cdx.json

CycloneDX has firmware and device component types, so a vendor that documents its Wi-Fi firmware properly can list it in the same file.

A home or office upgrade checklist

1. Inventory clients first. List every device that joins the network and its best supported generation and security mode.
2. Decide on 6 GHz. Wi-Fi 6E and Wi-Fi 7 only help clients that support 6 GHz, and 6 GHz signals attenuate faster through walls. Plan access point placement for it, not for 2.4 GHz.
3. Plan security before speed. Choose WPA3-Personal or WPA3-Enterprise for the main SSID, Enhanced Open for guests and a separate segment for legacy IoT. Avoid transition mode on the main network if you can.
4. Require PMF wherever all clients support it.
5. Check the firmware support window. Ask how long the vendor ships security updates and how they announce them.
6. Update the firmware on day one, before deployment, then turn on automatic or scheduled updates if the device supports them.
7. Update client drivers too. KRACK and FragAttacks needed fixes on both sides of the link.
8. Keep 2.4 GHz at 20 MHz and use 80 or 160 MHz on 5 GHz only where the spectrum is clean.
9. Disable what you do not use, such as WPS and remote administration from the internet.
10. Follow a written baseline. NIST SP 800-153, Guidelines for Securing Wireless Local Area Networks (February 2012), is old on specific protocols but still a sound frame for treating every client, access point and controller as part of one system to secure and monitor across its lifecycle.
11. Record what you deployed: model, firmware version, SSIDs, security modes and the date. Our guide on securing a wireless network with WPA3 and controls and picking a router for working from home cover the configuration side in more detail.

Common mistakes

• Treating the generation as a security label. Wi-Fi 7 describes the radio. A Wi-Fi 7 network in WPA2/WPA3 transition mode has the same downgrade exposure Dragonblood described.
• Believing the number on the box. Theoretical PHY rates assume the widest channel and the most spatial streams. A two stream phone will never see them.
• Leaving transition mode on forever. It exists for migration. Set a date to retire WPA2 on the main SSID.
• Patching only the access point. KRACK's own guidance says patching one side is not enough. Clients, drivers and IoT devices all need updates.
• Keeping a WEP or open SSID for one old device. Retire the device or isolate it on its own network with no route to anything that matters.
• Assuming PMF stops everything. FragAttacks explicitly is not prevented by 802.11w. PMF fixes forged management frames, not every flaw.
• Forgetting the software inside your own products. A shipped device's supplicant, access point daemon and firmware are your components to track.

FAQ

What is the difference between Wi-Fi 6 and Wi-Fi 6E?

Wi-Fi 6E is Wi-Fi 6 (802.11ax) operating in the 6 GHz band as well as 2.4 and 5 GHz. The radio features are the same; the extra band gives more and wider clean channels. In the United States the band was opened by the FCC order adopted on 23 April 2020.

Is Wi-Fi 7 worth upgrading to?

It helps when you have Wi-Fi 7 clients, use 6 GHz, and need either very high throughput or the reliability of multi-link operation. If most of your devices are Wi-Fi 5 or Wi-Fi 6 and your internet link is the bottleneck, better placement and a properly configured WPA3 network will usually do more.

What is Wi-Fi 8 and when is it coming?

Wi-Fi 8 is the Wi-Fi Alliance's name for the generation based on IEEE 802.11bn, Ultra High Reliability. It targets 25 percent improvements in throughput at some signal levels, tail latency and packet loss, plus access point coordination. The IEEE projects final approval in May 2028; products usually appear earlier.

Is WEP still safe to use?

No. WEP's flaws are in its design, and both the KRACK and FragAttacks researchers explicitly advise against it. Retire or isolate any device that only supports WEP.

Was KRACK fixed by WPA3?

No, KRACK was fixed by backward compatible patches to WPA2 implementations on clients and access points. The KRACK site says WPA3 was not required for the fix. WPA3 brought separate improvements, such as SAE and mandatory PMF.

Does WPA3 protect against FragAttacks?

No. The FragAttacks site states the design flaws affect all modern Wi-Fi security protocols, including WPA3. Vendor firmware, driver and supplicant updates are the fix.

What is WPA3 transition mode and is it safe?

Transition mode lets WPA3 and WPA2 clients share one SSID. It is useful during migration, but Dragonblood showed it can be used to downgrade WPA3 clients to WPA2. Use it temporarily, or put legacy clients on a separate SSID.

What are the maximum Wi-Fi speeds for each generation?

Commonly quoted theoretical peaks are 11 Mbps for 802.11b, 54 Mbps for 802.11a and g, 600 Mbps for Wi-Fi 4, about 6.9 Gbps for Wi-Fi 5, about 9.6 Gbps for Wi-Fi 6 and 6E, and at least 30 Gbps as the IEEE's design target for Wi-Fi 7. Real throughput is much lower.

Where Safeguard fits

Safeguard does not configure access points, manage wireless devices, scan firmware binaries or monitor radio traffic, and nothing in your Wi-Fi upgrade depends on it. The honest connection is component inventory. KRACK, Dragonblood and FragAttacks were all fixed in software, and much of that software is open source that ships inside products: wpa_supplicant in Linux and Android images, hostapd in routers, hotspots and appliances, plus regulatory databases and firmware packages. If you build those images, or receive SBOMs from the vendors who build them, Safeguard can ingest and analyse those SBOMs, match the listed components against vulnerability databases and show which of your products contain a given component and version. When the next hostapd or wpa_supplicant advisory lands, that is how you find which releases carry the affected version. Our post on using SBOMs to find affected products fast walks through that workflow.

Fix it without waiting for upstream

A Wi-Fi upgrade is mostly hardware and configuration, but every fix in this post, from KRACK to FragAttacks, shipped as software: supplicants, access point daemons, drivers and firmware packages built from open source components. If you build or ship devices with Wi-Fi, those components sit in your images next to every other dependency, so the same patch discipline applies, while the radio firmware itself still has to come from your chip or device vendor.

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 and SBOM workflows, not wireless configuration. You can download Safeguard and follow the CLI docs to try them on your own projects.

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 a Linux based device image, the same terminal scan can run against the SBOM you generate for each firmware release, so the wpa_supplicant and hostapd versions inside it are checked before the image ships.

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

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the component to bump is a pinned Wi-Fi stack package in a build recipe or manifest you own.

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

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your products list a particular hostapd or wpa_supplicant version in their SBOMs, and get the answer from your own data.

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

Quick check

Sources

• IEEE 802.11 Working Group: official 802.11 timelines
• IEEE 802.11 TGbn (Ultra High Reliability) status update
• IEEE 802.11 TGbe (Extremely High Throughput) status update
• Wi-Fi Alliance: Wi-Fi CERTIFIED 7
• Wi-Fi Alliance: Wi-Fi CERTIFIED 6 and the Wi-Fi generations
• Wi-Fi Alliance: Security
• Wi-Fi Alliance: Wi-Fi Alliance introduces Wi-Fi 6 (3 October 2018)
• Wi-Fi Alliance: Wi-Fi Alliance introduces Wi-Fi CERTIFIED WPA3 security (25 June 2018)
• FCC 20-51: Unlicensed Use of the 6 GHz Band, Report and Order (adopted 23 April 2020)
• Mathy Vanhoef: Key Reinstallation Attacks (KRACK)
• Mathy Vanhoef: FragAttacks
• Mathy Vanhoef and Eyal Ronen: Dragonblood, analysing WPA3's Dragonfly handshake
• hostapd and wpa_supplicant security advisories
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks

Last reviewed: 23 October 2026. IEEE 802.11bn dates are projections from the task group and may move; check the linked IEEE pages for the current schedule.