Does WPA3 stop deauth attacks?

Correcting yourself in public is the price of writing about your own field, so let me pay it up front.

Seven weeks ago I published a report separating the two different attacks that get filed under the single word "jammer". That part still holds, and I would write it the same way today. Real RF jamming floods the band with noise and does not care what your encryption is. A deauthentication attack is a different animal: it forges a protocol message rather than shouting over it. Two attacks, one word, different fixes.

Then I gave the fix for the second one, and I overstated it. I wrote that WPA3 makes Protected Management Frames mandatory, which authenticates the disconnect commands so a forged one gets rejected, and that this "closes the deauth door." The first half of that sentence is accurate. The last four words are not, and I should have checked harder before writing them.

The reason I know is that the exact question has been tested by people who do this properly, and the answer is in the title of their paper's conclusion. I have added a dated correction to Report 005. This report is the long version of what that correction says.

What a deauth attack actually is

Wi-Fi carries two broad kinds of traffic. Data frames are your video, and on any encrypted network they are protected. Management frames are the housekeeping: joining, leaving, announcing, disconnecting. For most of Wi-Fi's life those were sent in the clear, unauthenticated, on the polite assumption that nobody would lie in them.

People lie in them. The attack, as Schepers, Ranganathan and Vanhoef describe it, is old and blunt:

an adversary can spoof the client or infrastructure and trivially inject deauthentication frames into the network, succesfully disconnecting the client from the network.

That is the whole thing. You forge a "you are disconnected now" message with your neighbour's router address on it, and the camera believes it. The paper is explicit that this is not a theoretical concern and names the application by hand: an adversary can, in their words, "disconnect a surveillance device such as a Wi-Fi IP camera from its network to prevent any video feedback." They note that low-cost Wi-Fi "deauthers" are readily available for less than ten dollars.

That price is the part worth sitting with. This is not a nation-state capability. It is a board that costs less than lunch, and it does not require the illegal transmitter that true RF jamming does.

What WPA3 actually changed

The standards bodies saw this coming and fixed it, in the sense that they fixed part of it.

The IEEE 802.11w amendment defined Management Frame Protection, also called Protected Management Frames, and it was folded into the 2012 revision of the base 802.11 standard. It adds confidentiality, integrity, origin authenticity and replay protection to a category the standard calls robust management frames. Deauthentication and disassociation frames are in that category. So a forged eviction notice now fails an integrity check and gets dropped.

The Wi-Fi Alliance then made MFP mandatory in WPA3. That is the basis for the advice you see everywhere, including in my own earlier report: turn on WPA3, and the deauth problem goes away.

It is a real improvement. The classic attack from 2003 does not work against a properly configured MFP link. The trouble is what "the deauth problem" turns out to include.

The finding

In 2022, Domien Schepers and Aanjhan Ranganathan of Northeastern University and Mathy Vanhoef of imec-DistriNet at KU Leuven published "On the Robustness of Wi-Fi Deauthentication Countermeasures" at the ACM WiSec conference. Vanhoef is the researcher behind KRACK and FragAttacks, so this is not a fringe group taking a swing at a standard.

They did two things. They read the standard looking for gaps in the rules for handling these frames, and they tested real implementations: the Linux kernel, hostap, IWD, macOS, iOS, iPadOS, Windows and Android. Their abstract states the result without hedging:

Altogether, these vulnerabilities allow an adversary to disconnect any client from personal and enterprise networks despite the usage of MFP. Our work highlights that management frame protection is insufficient to prevent deauthentication attacks, and therefore more care is needed to mitigate attacks of this kind.

Their conclusion repeats it plainly: "we find usage of MFP is insufficient to protect against deauthentication attacks."

One clarification that matters for how you read this. Their threat model deliberately excludes radio jamming. In their words, the adversary "targets its victims solely on the Medium Access Control (MAC) layer and does not leverage any physical-layer techniques (e.g., jamming the channel) to disconnect the client." Everything they broke, they broke with an ordinary Wi-Fi adapter running standard commercial hardware, sending frames that are legal to transmit. That is a lower bar than owning a jammer, not a higher one.

The hole is in the beacon

Of the techniques they found, one deserves the attention of anyone running cameras, because of how it fails.

An access point continuously broadcasts beacon frames announcing itself and its configuration. A beacon is a management frame. It is not, however, a robust management frame, which means MFP does not cover it. The protection everyone is told to enable simply does not apply to this message.

So the attack becomes: forge a beacon that advertises a configuration the client cannot support, for example an invalid bandwidth setting, and the client's own kernel decides the network has become unusable and disconnects itself. No forged deauthentication frame is needed. The device evicts itself, correctly following the rules, on the strength of an announcement nobody authenticated.

The consequence for a camera fleet is the ugly part. The researchers note that these beacon-based attacks "may disconnect multiple clients from the network at once," in contrast to the handshake-based techniques that have to target one device at a time. One forged broadcast, every camera on the network goes dark together. Which is, functionally, indistinguishable from the jammer everyone is worried about, achieved without one.

There is a fix for the fix. Beacon protection, using a protected Management MIC element, was proposed and has been implemented in the Linux kernel and hostap. But it needs hardware or firmware support in the client's network card, and the paper reports that surveys at the time "found none of the APs supported protected beacon frames." None.

The adoption number

Here is the figure that reframes the whole consumer conversation. Citing surveys from October and December 2021, the paper reports that 4.84% of encrypted networks supported MFP.

And then: "merely 0.01% of encrypted networks made its usage mandatory."

Supporting MFP and requiring it are different settings. A network that merely supports it will still happily accept a client that does not use it, which means the protection is negotiable, and an attacker gets a vote. One in ten thousand encrypted networks actually required the thing WPA3 is supposed to make mandatory.

Those numbers are from late 2021 and adoption has certainly risen since; the paper itself expected it to. I have not found a comparable survey for 2026 and I am not going to invent one. But the gap it exposes is structural rather than temporal. WPA3 makes MFP mandatory within WPA3. Your network is not running WPA3 because a standards body published it. It is running whatever mode keeps the oldest device in your house connected, and in a home with a decade of accumulated smart gadgets, that is usually a mixed mode that quietly makes the strong setting optional.

Every camera vendor's compatibility promise is a pull in that direction.

What this changes, and what it does not

I want to be careful not to overcorrect into fatalism, because the practical guidance barely moves. It just moves for a better reason.

Turn WPA3 on anyway. It closes the classic attack, it is strictly better than not having it, and if your gear supports requiring MFP rather than merely supporting it, require it. Nothing here is an argument for leaving it off. What changes is that you can no longer treat it as the end of the problem, or as a substitute for the architecture.

The architecture is the actual answer, and it is the same one I gave in Report 005 and would give again in Report 500, because it does not depend on which attack you face:

Wire the cameras that matter and record locally. A PoE camera writing to an on-site recorder has no wireless link to deauthenticate and no beacon to forge. This is the only measure on the list that is indifferent to the entire class of attack, which is why it keeps being the answer.

Make loss of signal an alarm. This is the one I will keep pushing until people are tired of hearing it. Every attack in that paper produces the same observable: a device stops reporting. If your system treats a camera going quiet as an event that wakes something up, then the attacker's own move becomes the trip wire, and you do not need to know whether it was a jammer, a forged beacon, or a dead battery. If your system treats it as a gap to be filled in silently, you will find out tomorrow.

Do not let the alarm path ride the same Wi-Fi. A panel with a cellular route home survives the loss of the network the cameras were on. One radio failure should not silence both the sensors and the notification.

I spent my Army career as a Counter-IED and Electronic Warfare Officer, and the reason this paper reads as familiar rather than surprising is that it is the oldest lesson in the trade. You do not secure a link by finding the version of it that cannot be attacked. There isn't one. You secure it by assuming it will be denied to you, instrumenting the denial so you notice it, and making sure the thing you actually needed, in this case a recording and an alert, does not live entirely inside the link you just lost.

Disclosure, because I build in this category rather than only writing about it: I help design the AI security systems for a veteran-owned (SDVOSB) home-security company run by a fellow combat veteran and his father, who has three decades in the trade. I do not own that company and earn nothing from this link. Full policy here. I flag it because it cuts against selling you more wireless gear: a fleet of cameras that all fail together on one forged frame is a weakness whether or not my code is in the box.

What I could not confirm

The paper is from May 2022. Its per-implementation results describe the software versions tested at that time (hostap 2.9 and 2.10, Linux 5.15.0, macOS 12.3, iOS and iPadOS 15.4, Android 12, Windows 10), and the authors state they made responsible disclosures to the affected vendors. I have not verified which of those specific vulnerabilities were patched, or whether any given device you own is affected today. Do not read this report as a claim that a current iPhone or a current router is vulnerable to a particular technique. Read it as a claim about what management frame protection does and does not cover by design, which is the part that has not changed.

The authors say they worked with industry partners to propose updates to the IEEE 802.11 standard to address the gaps they found. I could not confirm whether those proposals were adopted into a later revision. The current base standard is behind a paywall I did not clear, and I am not going to characterise the contents of a document I have not read. If beacon protection has since become widespread, that is a meaningful improvement and this report will get a dated correction saying so.

The 4.84% and 0.01% figures are the paper's citation of third-party surveys from October and December 2021. I did not open the underlying survey. Treat them as a snapshot of that moment, not of today.

I have no data on how often real burglaries use a deauther rather than an RF jammer. The police reports I read for Report 005 did not distinguish the two, and from the outside, as I said then, you often cannot tell. Nothing in this report should be read as a claim about the prevalence of either.

None of this rests on my own research; my published work is in microwave spectroscopy, not wireless protocol security. The technical claims here are the cited authors', quoted from their paper.

The signal

The useful lesson is not that WPA3 is bad. It is about where a security guarantee stops, and how rarely anyone reads that far.

"WPA3 makes protected management frames mandatory" is a true sentence, and I repeated it as though it were the answer. What it actually means is that a specific list of frame types gets a signature. Beacons were not on the list. The guarantee was precise, and my summary of it was not, and the distance between those two things is exactly where a ten-dollar board lives.

So when your installer says the system is secured with WPA3, the follow-up question is not whether it is enabled. It is the same question as always: what happens the second a camera stops talking? If the honest answer is that the video quietly stops and nobody is told, then the encryption on the link was never the thing protecting you.