WiFi Deauthentication Detection Guide

WiFi deauthentication detection comes down to counting management frames. A deauth attack is a flood of spoofed deauthentication or disassociation frames that forcibly disconnect clients — the building block behind evil-twin and handshake-capture attacks. The frames are unauthenticated in the original 802.11 standard, so they are trivial to forge; the upside for defenders is that a wireless IDS sees the flood plainly. This guide ships the detection, explains why 802.11w/WPA3 helps and where it falls short, and lists the hardening.

A deauth flood is endpoint/network denial of service — T1498 — Network Denial of Service — and it is usually a precursor to adversary-in-the-middle, T1557. Detecting it early flags the recon before the real attack lands.

What is a WiFi deauthentication attack?

A deauthentication attack abuses a design flaw in 802.11: management frames — including deauth and disassociation — are sent unauthenticated and unencrypted, even on a WPA2/WPA3 network that encrypts your data. An attacker spoofs the AP’s or a client’s MAC address and sends forged “you are disconnected” frames, knocking devices off the network. It needs no password and no association.

The disconnect is rarely the end goal. It forces clients to reconnect, which an attacker uses to capture a WPA2 handshake for offline cracking, or to push them onto an evil-twin AP. That is why deauth detection is early warning for a larger attack.

What does a deauth attack look like, and what defends against it?

The throughline: PMF is the prevention, a WIDS is the detection, and you need both because PMF has known limits and not every client supports it.

How to detect WiFi deauthentication attacks

Detection needs a sensor that sees 802.11 management frames — a wireless IDS/WIPS (Kismet, nzyme, or vendor WIPS). Feed its events to the SIEM and threshold the flood.

index=wids sourcetype=kismet:alert (frame_type=deauth OR frame_type=disassoc)
| bin _time span=1m
| stats count AS frames, dc(dest_mac) AS clients by _time, bssid
| where frames >= 50
| sort - frames

A spike of 50+ deauth/disassoc frames a minute targeting one BSSID — especially hitting many clients — is an attack, not normal roaming. Tune the threshold to your environment’s baseline. Even on a PMF-protected network, the attempt is hostile reconnaissance worth alerting on.

A second, proactive query confirms your networks actually negotiate PMF, by reading the RSN information element your sensor records from beacons:

index=wids sourcetype=kismet:device type=AP
| eval pmf = if(match(rsn_capabilities,"MFPR|MFPC"),"enabled","disabled")
| search pmf="disabled"
| stats values(channel) by bssid, ssid

How to test your deauth detection

In a lab you own, on your own AP and an RF-isolated channel where possible:

1. Generate deauth frames against your own test client and confirm the WIDS flood rule fires.
2. Enable 802.11w (PMF) and confirm the test client stays connected during the flood — the control validating itself.
3. Read the RSN IE from your AP’s beacon and confirm PMF shows required/optional as intended; confirm the “PMF disabled” query is empty for production SSIDs.
4. Confirm a deauth attempt still alerts even when PMF prevents the disconnect.

How to harden against deauthentication attacks

• Verify the RSN IE, do not assume — confirm PMF is actually negotiated.
• Segment and monitor guest/IoT networks, which often lag on PMF support.
• Treat deauth alerts as evil-twin/handshake-capture precursors, and pivot to WPA2 PMKID detection on alert.

Common deauth-detection mistakes

• No 802.11 sensor. Standard network IDS (IP-based, like Suricata) never sees management frames; you need a WIDS/WIPS.
• Assuming PMF = done. Known bypasses and unsupported clients mean monitoring still matters.
• Not verifying the RSN IE. A network you believe is PMF-protected may not be.
• Treating it as “just DoS.” It is usually the opening move of a bigger attack.

WiFi deauthentication detection checklist

1. Deploy a wireless IDS/WIPS (Kismet, nzyme, or vendor) that captures 802.11 mgmt frames.
2. Forward WIDS events to the SIEM; threshold deauth/disassoc floods per BSSID.
3. Enable WPA3-only with MFPR=1 where supported; WPA2 + PMF optional for legacy.
4. Query the RSN IE to confirm PMF is negotiated; alert on PMF-disabled SSIDs.
5. Patch clients and APs for PMF-implementation flaws (e.g., CVE-2023-21061).
6. Alert on deauth attempts even when PMF blocks them (hostile recon).
7. Treat deauth alerts as evil-twin / handshake-capture precursors and pivot.
8. Test detection and PMF in an authorized lab.

Why does this attack still work in 2026?

Deauthentication is one of the oldest wireless attacks and remains effective in most environments, which is worth explaining because it determines whether detection or hardening is the better investment.

The original frames were unauthenticated by design. Management frames in the classic standard carry no integrity protection, so anything that can transmit on the channel can forge one. There is no vulnerability to patch — the protocol behaved as specified.

The fix exists but requires both ends. Protected Management Frames close this, and they only apply when the access point and the client both support and enable them. A single legacy device — a printer, a scanner, a badge reader, an old handset — is usually enough for an operator to leave the protection optional across the estate, at which point the attack works against everything.

Downgrade remains available. Where protection is optional rather than required, an attacker can frequently arrange for the unprotected path to be used.

The practical consequence: check whether management-frame protection is set to optional or required, because those are very different postures and most estates are on the former without anyone having decided it. Where required is achievable, the attack disappears rather than being detected. Where it is not, detection is the whole control and it should be resourced accordingly.

What is the attacker usually doing next?

Deauthentication is almost never the objective. It is a means, and knowing which means tells you what else to look for once the alert fires — which is the difference between noting an event and running an investigation.

Three common purposes:

Forcing a reconnection to capture the handshake. The client reconnects, the exchange is observed, and an offline attack on the passphrase follows. Here the deauth is a precursor to something that leaves no further trace on your network at all — so the deauth event may be the only evidence you ever get.

Forcing a client onto a rogue access point. Knock the client off the legitimate network and offer a more attractive one. The follow-on signal is a known client associating with an unexpected BSSID, which is a much stronger detection than the deauth itself.

Denial of service. Sometimes the disruption is the goal — a targeted outage of wireless cameras, badge readers, or point-of-sale terminals, occasionally as cover for something physical.

That third case is why deauth alerts deserve correlation with physical security rather than being handled purely as a network event. A wireless outage confined to the cameras covering one entrance is a different incident from a general disruption, and only the targeting pattern distinguishes them.

What should you actually collect, and where from?

Detection here depends entirely on having visibility into management frames, and that is a collection problem before it is an analysis problem. Ordinary network telemetry cannot see this at all — the frames never reach a switch.

Three viable sources, in decreasing order of practicality:

The wireless infrastructure itself. Enterprise access points and controllers generally expose client-disconnect reason codes and, where a wireless intrusion detection feature exists, explicit deauthentication alerts. This is the source to exhaust first because you already own it, it covers the whole estate, and it needs no new hardware.

Dedicated sensors. Purpose-placed radios monitoring the channel continuously. Higher fidelity, more cost, and worth it for sites where wireless carries something that must not drop — a production floor, a clinical environment, physical security devices.

Client-side telemetry. Endpoint agents can report unexpected disconnects. Noisy on its own and genuinely useful as corroboration, because it tells you which specific clients were affected, which is what separates a targeted attack from ambient interference.

The field that carries most of the signal is the reason code on the disconnect. Normal roaming, idle timeout, and a forged deauthentication produce different codes, and a rule that ignores them will alarm on ordinary client behaviour all day. The detection is not “disconnects happened”; it is a burst of a specific reason code, affecting multiple clients, in a short window, on one BSSID.

How do you separate an attack from bad RF?

The most common outcome of a first deauth-detection deployment is a stream of alerts caused by physics rather than adversaries. Wireless is a shared, unlicensed medium and disconnects are ordinary.

Four discriminators, in the order they resolve alerts fastest:

• Volume against baseline. Every environment has a normal disconnect rate that varies by hour. A rate anomaly relative to that hour’s baseline is far more meaningful than a fixed threshold, which will be wrong at both ends of the day.
• Reason code distribution. Interference and congestion produce a broad mix. A forged attack produces a narrow one. A sudden collapse in code diversity is a strong signal.
• Spatial concentration. Interference from a microwave or a neighbouring network affects a channel and an area diffusely. An attack targeting specific clients or one access point is tightly bounded, and that boundary is the tell.
• What happened next. A disconnect followed by immediate successful reconnection to the same access point is normal. Followed by association to a different BSSID, it is the rogue-AP scenario, and that follow-on event is a much stronger detection than the deauth that preceded it.

The practical rule: alert on the sequence, not the event. A single deauthentication is noise in every environment. A burst with narrow reason codes, spatially concentrated, followed by clients landing somewhere new, is an incident — and specifying it that way is what makes the detection survivable on a real network.

What is the realistic response when it fires?

Wireless attacks sit awkwardly in incident response because the attacker is physically near and the usual containment actions do not apply — you cannot block an IP that never existed or isolate a host that was never on your network.

A response that works, in order:

Confirm it is not RF. Run the discriminators above before escalating. The majority of first alerts are environmental, and treating them as attacks burns credibility quickly.

Establish scope and location. Which access points, which clients, which physical area. Wireless telemetry is inherently spatial, and that is its advantage: unlike a network alert, this one tells you roughly where the attacker is standing.

Check what the clients did next. Reconnection to the same access point suggests disruption or handshake capture. Association elsewhere suggests a rogue access point and changes this from a nuisance to a credential-exposure incident.

Correlate with physical security. Badge logs and camera footage for the affected area and window. This is the step most teams skip and the one most likely to identify the source, because the attacker had to be within radio range.

Consider what the disruption covered. Targeted outages of cameras, badge readers, or point-of-sale devices deserve treatment as a possible diversion rather than as an isolated network event.

Two things not to do. Do not attempt to jam back or transmit countermeasures — that is illegal in most jurisdictions and it degrades your own network. And do not treat a single alert as an incident; the sequence, not the event, is what warrants a response, which is why the detection is specified that way in the first place.

How do you test the detection without disrupting anyone?

A detection nobody has fired is a hypothesis, and here the obvious test — running the attack — disrupts real users and is unlawful against networks you do not own. The validation has to be designed around that.

Use an isolated lab SSID. A dedicated access point, a test client, and no production traffic. This is the only setting where generating the frames is appropriate, and it is sufficient to prove the pipeline works end to end: frame generated, sensor observes, reason code recorded, rule fires, alert routes to a human.

Validate the plumbing separately from the technique. Most failures are not detection logic — they are a sensor that stopped reporting, a log source whose format changed, or an alert routing to a queue nobody watches. Those are testable by injecting a synthetic event into the pipeline, with no radio involved at all.

Schedule it, because wireless detection decays quietly. Firmware updates change log formats, sensors are relocated during office moves, and controller upgrades reset settings. A quarterly lab test catches all three classes.

Record the expected baseline while you are there. The normal disconnect rate and reason code distribution are what every threshold above depends on, and they drift as the client population changes.

What to avoid: testing against your own production wireless during business hours because it seems harmless. It is not — you will disconnect real users from real work, and if anything depends on that network for safety or physical security, the test becomes the incident.

What belongs in the runbook for this alert?

Because wireless incidents are location-bound rather than host-bound, the usual runbook shape does not transfer. What a responder needs here is different.

A floor plan with access-point locations. The single most useful artefact, and almost never present. An alert names a BSSID; without a map, that is a string rather than a place.

The normal disconnect baseline for that hour, so “is this elevated” is answerable in seconds rather than by scrolling a graph and guessing.

A named contact in physical security, plus what to ask for: camera coverage of the affected area for the alert window, and badge events for the same window.

The explicit instruction not to transmit countermeasures. Jamming is unlawful in most jurisdictions and degrades your own network; it needs to be written down precisely because it is the instinctive response.

A decision line for when wireless matters more than usual. If cameras, badge readers, or payment terminals ride the affected SSID, the incident is a possible diversion and escalates differently. That dependency list belongs in the runbook, not in someone’s memory.

The test for whether this runbook works: hand it to someone who has never investigated a wireless alert and see whether they can determine, unaided, if the alert is real and roughly where it came from. If not, the missing piece is almost always the floor plan.

Keep the plan itself one page. Wireless alerts are infrequent enough that whoever picks one up will be reading it for the first time, and a document that assumes familiarity will not be finished before the window to act has closed.

Store it beside the network runbooks rather than in the security wiki. The person who reaches this alert first is usually on the network side, and a document filed where they do not look is a document that does not exist.

Review it after the first real alert, whatever the outcome. The gap between what the runbook assumed and what the responder actually needed is only visible once, and it closes cheaply if you capture it while the session is fresh rather than reconstructing it weeks later from memory.

The takeaway

WiFi deauthentication detection is a WIDS counting forged management frames, backed by 802.11w/WPA3 to make the forgery ineffective and patching to cover PMF’s limits. Alert on the attempt, verify PMF is really on, and treat every deauth spike as the opening move of a larger wireless attack — often a rogue AP, covered in evil twin access points: defensive controls. Continue with WPA2 PMKID capture detection and HackRF defensive RF awareness, or browse the full Hardware Security pillar.