Wi-Fi Sensing Explained: IEEE 802.11bf, CSI, Motion Detection, Privacy

Wi-Fi sensing is the use of ordinary Wi-Fi transmissions to detect what is happening in a space: whether someone is moving, which room they are in, and in research settings even gestures or breathing. It works by measuring how a person's body changes the radio channel between two Wi-Fi devices, a measurement called channel state information (CSI). IEEE 802.11bf-2025, approved by the IEEE SA Standards Board on 28 May 2025 and published on 26 September 2025, standardises how Wi-Fi devices set up and exchange those measurements.

The privacy problem is simple. No camera is involved, so people assume nothing is watching, yet the output can reveal when a home is empty and where someone is. This post covers how it works, what the standard says, what research has inferred, which laws may apply, and how to limit it.

Key takeaways

• Wi-Fi sensing reads the physical channel, not your traffic. Encryption such as WPA3 protects the data in a frame; it does not hide the fact that a body moving through a room changes how that frame propagates.
• IEEE 802.11bf-2025 is an active amendment to IEEE 802.11. It covers license exempt bands between 1 GHz and 7.125 GHz and bands above 45 GHz, and defines how stations advertise sensing capability, set up measurements and exchange feedback.
• Research since 2013 has shown gesture recognition from Wi-Fi signals (94 percent average accuracy across nine gestures in one study), through-wall motion tracking, and passive room level tracking of people from outside a building using a single smartphone that sniffs existing traffic.
• Consumer motion features already exist in some internet provider gateways and mesh systems. At least one large provider's documentation describes its feature as opt in, says it uses the gateway plus up to five stationary connected devices, and states that information it generates may be disclosed in response to a subpoena or warrant.
• Sensing output that is linked to a person can fall under privacy law. California's definition of biometric information includes gait patterns and sleep or health data that contain identifying information, and Washington's My Health My Data Act covers vital signs and health data inferred by algorithms or machine learning.
• The practical defence is mostly configuration: know whether the feature is on, who can see the history, how long it is kept, and whether a firmware update changed any of that.

What Wi-Fi sensing is

The IEEE 802.11 task group that wrote the standard defines WLAN sensing as "the use of PHY and MAC features of IEEE 802.11 stations to obtain measurements that may be useful to estimate features of objects in an area of interest." Its own status page lists the features as range, velocity, angle and motion, the objects as humans and animals, and the areas of interest as homes, enterprises and vehicles. The physical idea is old. A Wi-Fi signal does not travel in a single straight line from transmitter to receiver. It reflects off walls, furniture and people, and the receiver sees the sum of all those paths. This is called multipath. When a person moves, the lengths of some of those paths change, so the combined signal changes too. A receiver that measures the channel carefully, many times per second, can spot those changes and, with enough modelling or machine learning, guess what caused them.

Channel state information in plain terms

Modern Wi-Fi uses OFDM, which splits a channel into many narrow subcarriers. To decode data, the receiver has to estimate how each subcarrier was distorted on the way, using known training fields at the start of each frame. That estimate is the channel state information. For each subcarrier, and for each pair of transmit and receive antennas, CSI is a complex number: an amplitude (how much the signal was weakened) and a phase (how much it was delayed).

Two published tools make the shape of the data concrete:

• The Linux 802.11n CSI Tool, released by Daniel Halperin, Wenjun Hu, Anmol Sheth and David Wetherall and described in a January 2011 ACM SIGCOMM Computer Communication Review paper, reports channel matrices for 30 subcarrier groups. Each matrix entry is a complex number with signed 8 bit resolution for the real and imaginary parts, and each entry describes the gain and phase of the path between one transmit antenna and one receive antenna.
• A widely used microcontroller SDK documents CSI as the channel frequency responses of subcarriers, estimated when packets are received from a transmitter. Each subcarrier's response is stored as two signed bytes, imaginary part first, and a single received packet can carry up to three fields depending on which training fields (legacy, HT, or STBC HT) were present.

So a single received frame yields a vector of tens to hundreds of complex numbers. A stream of frames yields a matrix that changes over time. Sensing is the job of reading meaning into those changes.

If you want the signal processing background, our posts on the Fourier transform and Wi-Fi OFDM and the Doppler effect cover the two ideas sensing relies on most.

How research tools made CSI available

For most of Wi-Fi's history, CSI lived inside the radio chip. The firmware computed it, used it to equalise the signal, and threw it away. Three kinds of tool changed that:

1. Modified laptop firmware (2011). The Linux 802.11n CSI Tool ran on one specific 802.11n network card with custom modified firmware and open source Linux drivers. Its maintainers say they once kept a list of more than 1,000 published papers using the tool and its data before giving up and pointing to search engines instead.
2. Firmware patching frameworks. An open source CSI extractor from a university lab patches the firmware of several Wi-Fi chips found in phones, a single board computer and a consumer router. Its README tells users to "be careful", and documents that the extracted CSI is emitted as UDP packets, one per configured core and spatial stream for each matching frame, with 64, 128 or 256 values per packet for 20, 40 or 80 MHz channels.
3. Documented SDK APIs. Some low cost Wi-Fi microcontrollers now expose CSI through an ordinary, documented API with a build option, a receive callback and a configuration call. No firmware modification is needed.

Each step lowered the cost and skill needed to collect CSI. Standardisation in 802.11bf is the next step: a common way for devices to request and share measurements.

What IEEE 802.11bf-2025 standardises

Status and dates

According to the IEEE SA page for the standard, IEEE 802.11bf-2025 is an active standard titled "Amendment 4: Enhancements for Wireless LAN Sensing." The page lists:

The two PAR dates are not a contradiction. The task group page records the original PAR in September 2020 and a PAR extension motion in May 2024; the standard page shows the PAR approval date of the version the standard was finally approved under. The IEEE SA page also notes that the PDF is available at no cost through the IEEE GET program. For the project's early goals, Francesco Restuccia's 2021 paper "IEEE 802.11bf: Toward Ubiquitous Wi-Fi Sensing" (arXiv 2103.14918) reported the task group's initial work on presence detection, activity recognition and object tracking.

Scope in the standard's own words

The IEEE SA abstract says the amendment "defines modifications to the IEEE 802.11 medium access control (MAC); the physical layer (PHY) service interface of High Efficiency (HE) and Extremely High Throughput (EHT) PHYs; and to the Directional Multi Gigabit (DMG) and enhanced DMG (EDMG) PHYs." In consumer terms, HE is Wi-Fi 6 and 6E and EHT is Wi-Fi 7 (see our Wi-Fi generations post for the mapping). DMG and EDMG are the 60 GHz PHYs.

The task group's status page lists what the amendment enables:

• Stations can inform other stations of their WLAN sensing capabilities.
• Stations can request and set up transmissions that allow sensing measurements.
• Stations can exchange WLAN sensing feedback and information.

Notice what is not on that list. The standard does not define what a "person in the kitchen" looks like in CSI, how to detect a fall or how to estimate breathing. Interpretation stays with the device maker's software. 802.11bf standardises the plumbing: who asks for a measurement, who transmits, who measures, and how results are reported.

Roles: initiator, responder, transmitter, receiver

An overview paper written by task group participants (Du et al., "An Overview on IEEE 802.11bf: WLAN Sensing", arXiv 2207.04859) describes the framework the group was building. Note that it was written during drafting; it describes the procedures as they stood in 2022, and the published amendment is the authority on final details.

It separates two pairs of roles:

• A sensing initiator starts a sensing procedure. A sensing responder takes part in a procedure someone else started. Either can be an access point or a client.
• A sensing transmitter sends the frames used for measurement. A sensing receiver receives them and performs the measurement.

The two pairs are independent. An initiator can be the transmitter, the receiver, both, or neither. In the last case, the responder measures by other means and feeds results back. That flexibility is useful for engineers and is exactly what a privacy reviewer should watch: a device that never transmits a sensing frame can still end up holding sensing results.

The five phases of a sensing procedure

The overview paper lists five phases:

Trigger based and non trigger based measurement

For sub 7 GHz operation, the overview describes two variants of the measurement instance. In the trigger based (TB) variant the access point is the initiator and one or more clients are responders. It may include:

• A polling phase, in which the access point checks which clients are available to take part.
• An NDPA sounding phase, in which the access point transmits a null data packet (a frame with a preamble and no payload) so clients can measure the downlink channel.
• A trigger frame sounding phase, in which the access point asks clients to transmit null data packets so it can measure the uplink channel.
• A reporting phase, in which measurements are sent back.

The non trigger based variant covers a client acting as initiator with an access point as responder.

Sensing by proxy

The overview describes a sensing by proxy (SBP) procedure: a client asks an access point to run sensing on its behalf. The access point runs the procedure with one or more other clients and reports the results back to the client that asked. Privacy wise, this means a phone or hub that never touches most of the devices in a home could still receive measurements of the channels between the access point and those devices.

60 GHz sensing

For DMG and EDMG, the overview describes monostatic sensing (one device transmits and receives its own reflections, like radar) and bistatic sensing (one device transmits, another receives), each with or without coordination between devices.

What the standard says about security and privacy

The overview paper's security section is candid. It splits the risks into two categories:

1. Sensing report overhearing. An eavesdropper collects the measurement reports themselves. Proposed fixes include encrypting the feedback and physical layer techniques that degrade what unintended receivers get.
2. Sensing signal overhearing. An eavesdropper measures the channel from the sensing frames it overhears, then runs its own inference. One idea, borrowed from the 802.11az positioning amendment, is a protected training sequence: if legitimate stations pre exchange a secret sequence, an eavesdropper using the standard one gets the wrong channel estimate.

At the time of writing, the paper said the task group was "still discussing which solution to add." Whatever made it into the final text, the second category is a physics problem more than a protocol one. A standard can protect its own frames and reports. It cannot stop a passive receiver from measuring ordinary data frames that every Wi-Fi network already sends, which is what the attack research below did.

Where Wi-Fi sensing is shipping

Consumer Wi-Fi motion detection exists today as a category of features in internet provider gateways, mesh Wi-Fi systems and some smart home hubs. These products usually present it as a "motion" or "awareness" toggle in the companion app, with notifications and an activity feed. We do not rank products or name vendors here; instead, here is what one large US cable provider's own support article says about its implementation, because it shows the shape of the category:

• It is opt in, and activating it requires agreeing to the provider's residential services agreement and privacy policy.
• It uses the provider's gateway, its Wi-Fi extenders and the customer's own Wi-Fi connected devices, which should be stationary and usually powered on. The setup flow asks you to choose up to five such devices.
• It "does not use cameras, capture images or video, or record audio."
• It is "not a home security service and is not professionally monitored."
• Detection only works where there are strong Wi-Fi signals between the gateway and the chosen devices, and the article says home size, layout and building materials affect it.
• Users see live activity and an activity feed in the app.
• The provider "may be required to disclose information generated by WiFi Motion in response to a valid subpoena, court order, search warrant or other lawful legal process."

That last point is the one most buyers miss. If motion history is computed or stored in a provider's cloud, it is a record held by a third party, and the provider's privacy policy and legal process decide who else can see it. Check your own provider's documentation; implementations differ, and features described here may not match yours.

What can be inferred, and how accurately

Results vary enormously with hardware, placement, number of people and how much the system was trained on the specific room. The figures below come from the original papers and project pages, under their test conditions. They are not guarantees about any consumer product.

Presence and motion

This is the easy case and the one commercial products target. A moving body disturbs multipath in a way that is hard to miss, especially near the line between two devices. The consumer documentation above is clear that it depends on strong links between devices, so coverage is uneven: rooms with no sensing device nearby may be blind spots.

Gestures

WiSee, from the University of Washington (ACM MobiCom 2013, best paper), recognised a set of nine whole body gestures with an average accuracy of 94 percent in an office and a two bedroom apartment, including non line of sight and through the wall cases. It used software defined radios rather than consumer hardware. The paper explains the core idea with a number: a hand gesture at 0.5 m/s produces about a 17 Hz Doppler shift at 5 GHz.

That figure is easy to check, and it shows why sensing is subtle:

• Wavelength at 5 GHz is the speed of light divided by frequency: 300,000,000 m/s divided by 5,000,000,000 Hz, which is 0.06 m or 6 cm.
• For a reflection, the path length changes at up to twice the hand's speed, so the maximum Doppler shift is 2 times 0.5 m/s divided by 0.06 m, which is about 16.7 Hz.
• A Wi-Fi channel is 20 MHz wide or more. A 17 Hz shift is roughly a millionth of the channel width, which is why gesture work needs long observation windows and careful processing.

A second worked example: at 2.4 GHz the wavelength is 300,000,000 divided by 2,400,000,000, or 0.125 m. The same 0.5 m/s hand gives 2 times 0.5 divided by 0.125, or 8 Hz. Lower bands see smaller Doppler shifts for the same motion but travel further through walls.

Through-wall tracking

Wi-Vi, from MIT (ACM SIGCOMM 2013), tracked moving people through walls and behind closed doors using reflections of its own transmitted Wi-Fi signals, without access to any device on the other side. The same group's WiTrack (USENIX NSDI 2014) used a custom radio rather than Wi-Fi, transmitting at about a hundredth of Wi-Fi's power. Its project page reports locating a person's body centre to within 10 to 13 cm horizontally and 21 cm vertically, the direction of a pointing hand with a median error of 11.2 degrees, and fall detection at 96.9 percent accuracy, even through walls. The group also published work on monitoring breathing and heart rate from radio reflections (CHI 2015). WiTrack is not Wi-Fi sensing, but it shows what dedicated radio sensing can do and where Wi-Fi sensing research aims.

Dense body pose

"DensePose From WiFi" (Geng, Huang and De la Torre, arXiv 2301.00250, December 2022) trained a deep network to map the phase and amplitude of Wi-Fi signals to body surface coordinates across 24 human body regions. The authors report performance comparable to image based approaches for multiple subjects, with Wi-Fi signals as the only input, and present it as privacy preserving compared with cameras. Yet a body outline is exactly what people assume radio cannot give.

Passive sensing by an outsider

The most important paper for defenders is "Et Tu Alexa? When Commodity WiFi Devices Turn into Adversarial Motion Sensors" (Zhu et al., NDSS 2020). The authors showed that an attacker outside a building, "just by sniffing existing WiFi signals," can detect and track movement of people inside, "without compromising any WiFi network, data packets, or devices." They built the attacker on a single commodity smartphone and tested it in 11 real offices and residential apartments.

The mechanism, at a conceptual level: Wi-Fi devices inside the home (cameras, speakers, hubs) transmit regularly. When someone moves near one of them, the variance of the signal seen outside rises. If the attacker can roughly locate the transmitting devices, they can infer which room the motion is in. No packet needs to be decrypted, because the attack reads the radio channel, not the content.

The paper's defence findings are just as useful:

• Four "immediate" defences, namely geo fencing, rate limiting, MAC address randomisation and transmit power randomisation, were found to be either impractical or ineffective.
• Their proposed defence has the access point inject customised cover signals on behalf of its devices. It reduced the attacker's human detection rate to 47 percent while raising false positives to 50 percent, which the authors say renders the attack useless in practice.

A second line of defence research, IRShield (Staat et al., arXiv 2112.01967, revised April 2022), uses an intelligent reflecting surface, a panel of programmable reflecting elements, to randomise the wireless channel. In a state of the art motion detection attack using off the shelf Wi-Fi devices, IRShield lowered detection rates to 5 percent or less.

Summary of what is realistic

Who controls the data, and what about people who never agreed

Wi-Fi sensing creates three parties' worth of questions.

The account holder. The person who turned the feature on agreed to the provider's terms. They usually control notifications and may control history retention, depending on the product.

Everyone else in range. Guests, housemates, children, carers, cleaners and neighbours never agreed to anything. Radio does not stop at the property line, and the NDSS 2020 work shows the reverse is also true: signals from inside leak outside. A motion feed in a shared house can show when a housemate comes home. In a flat, a sensing link that crosses a party wall can register a neighbour.

The provider. If inference or storage happens in the cloud, the provider holds the record. As quoted above, at least one provider tells customers it may disclose that information under legal process. Any cloud record can also be exposed in a breach.

There is also a quieter control question: who decides which devices act as sensing points? In the documented consumer flow, the account holder picks up to five stationary devices. Under 802.11bf, any capable station can advertise sensing capability, and sensing by proxy lets a client request results from the access point. Device roles become a policy decision for whoever manages the network.

For how Wi-Fi leaks presence even without sensing, see Wi-Fi probe requests and MAC randomisation. Other home devices that map your space, such as the robot vacuum and the smart speaker, raise the same point: what matters is the inference, not the raw signal.

Is sensing output personal data? GDPR and US state laws

This section is general information, not legal advice. How a law applies depends on the facts, and you should talk to counsel for a real product decision.

GDPR

The GDPR defines personal data in Article 4(1) as any information relating to an identified or identifiable natural person. A raw CSI capture in a lab may not identify anyone. A motion timeline tied to a household account usually does, because the account holder is identified and the timeline describes when people in their home are present. Article 4(14) defines biometric data as personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a person that allow or confirm unique identification. Article 9 places biometric data processed to uniquely identify someone, and data concerning health, in special categories with stricter conditions.

For a product team, three GDPR principles do most of the work: data minimisation (Article 5(1)(c)), storage limitation (Article 5(1)(e)) and data protection by design and by default (Article 25). For a home user, Article 2(2)(c) keeps processing "in the course of a purely personal or household activity" outside the regulation. Recital 18 adds that the regulation still applies to controllers or processors that provide the means for such household processing, which covers a provider running the sensing service.

California

California's privacy law defines biometric information in Civil Code section 1798.140(c). The definition covers physiological, biological or behavioural characteristics used or intended to be used to establish identity, and it explicitly includes "gait patterns or rhythms, and sleep, health, or exercise data that contain identifying information." A sensing product that estimates sleep or that learns to tell household members apart by how they walk sits close to this text.

Washington

Washington's My Health My Data Act (RCW 19.373.010) is broader than most people expect:

• Biometric data includes "keystroke patterns or rhythms and gait patterns or rhythms that contain identifying information."
• Consumer health data includes "bodily functions, vital signs, symptoms, or measurements" of health information.
• It also includes health information "derived or extrapolated from nonhealth information (such as proxy, derivative, inferred, or emergent data by any means, including algorithms or machine learning)."
• Consent means a clear affirmative, opt in act, and cannot be obtained by acceptance of general or broad terms of use.

Breathing or sleep estimates inferred from Wi-Fi signals look like the inferred data the Washington definition describes. If you build or sell such a feature, treat it as health data until counsel tells you otherwise.

What to take from this

How Wi-Fi sensing compares with other presence sensors

The "visible to the people sensed" row is the one that changes behaviour. People adjust what they do in front of a camera. They have no cue to adjust for a router.

Step by step: check and limit Wi-Fi sensing on your network

Step 1: Find out whether any device has a motion feature

Open each app that manages your Wi-Fi: the internet provider's app, the mesh system's app and any smart home hub app. Look in home, security, awareness or labs sections for anything called motion, sensing, presence or activity. Check the product's support pages for "motion" too; features are sometimes off by default but promoted in a banner or added by an update.

Step 2: List what talks to your access point

The documented consumer flow uses stationary, usually powered on devices as sensing points, so knowing what is connected tells you where sensing links could exist. On a Linux machine acting as or attached to your access point, the standard iw tool lists associated stations:

# List wireless interfaces on this machine
iw dev

# Show stations associated to an access point interface (replace wlan0)
iw dev wlan0 station dump | grep -E "^Station|connected time|signal:"

On a typical laptop, nmcli dev wifi list shows nearby networks and signal strength, which helps you see how far your own network reaches.

# Show nearby networks, channels and signal strength
nmcli dev wifi list

Otherwise, use the router app's connected devices page.

Step 3: Decide whether you want the feature at all

Ask whether everyone who lives in or visits the home would agree to motion monitoring. If unclear, leave it off. If you keep it for an empty home alert, turn it off when people are home.

Step 4: Limit history and sharing

In the app, look for activity history, retention or privacy settings. Reduce history to the shortest option, turn off sharing with other household accounts that do not need it, and delete existing history if the app allows it. Read the privacy policy section on legal disclosure so you know what the provider says it can hand over.

Step 5: Choose the sensing devices deliberately

If the product lets you pick which devices act as sensing points, choose devices in common areas and avoid bedrooms and bathrooms. Remember that the sensed area is the space between devices, not just the room each device is in.

Step 6: Recheck after firmware updates

Router and mesh firmware updates can add features and change defaults. After each major update, repeat step 1 and look at the release notes for sensing or motion changes. Keep updates on, because the same firmware also carries security fixes. Our posts on how a home router is made and Wi-Fi mesh and EasyMesh explain where that firmware comes from and how mesh nodes are managed.

Step 7: Secure the network itself

Strong Wi-Fi security does not stop passive channel sensing, but it does stop outsiders joining your network, or reading sensing reports sent over it. Use WPA3 where your devices support it, a strong passphrase and separate networks for guests and smart home devices, as described in how to secure a wireless network with WPA3.

For builders: run CSI capture only in a lab, with consent

If you are researching sensing or building a product, the ethical baseline is the same as any human subjects work:

1. Own the hardware and the space. Capture only from devices you own, on a network you control, in a room you control. Use a dedicated SSID that is not your home network.
2. Get written informed consent from every person who will be in range, including colleagues who walk through. Post a notice on the door while capture is running.
3. Minimise. Capture only the fields you need and only for the session. Do not tie captures to names; use session IDs.
4. Set a retention date before you start, and delete raw captures when it passes.
5. Keep it off the internet. Store captures on an encrypted disk. Do not upload them to shared drives or public datasets without ethics review.
6. Check the law for your jurisdiction, especially if you estimate breathing, sleep or identity.

As an example of how documented SDKs expose CSI, one microcontroller SDK requires a build option before any CSI can be collected, and then three API calls to set a receive callback, configure which training fields to report and enable collection. The build option looks like this in the project configuration:

# sdkconfig: CSI collection is compiled out unless this is set
CONFIG_ESP_WIFI_CSI_ENABLED=y

The SDK documentation also warns that the CSI callback runs in the Wi-Fi task, so heavy work should be queued to a lower priority task. If you review firmware for a product that should not sense, check that this option and its equivalents are off and that no CSI callback is registered. That is a simple, auditable control.

Common mistakes

• Assuming no camera means no surveillance. The consumer documentation itself makes the point that the feature uses no camera and records no audio. That is true and still says nothing about what a motion timeline reveals.
• Leaving cloud history on by default. Motion history held by a provider is a third party record that can be disclosed under legal process or exposed in a breach. Shorten or delete it.
• Ignoring firmware updates that enable or change sensing. Updates are essential for security, so keep them on, but recheck features and defaults afterwards.
• Forgetting the people who did not consent. Guests, carers, housemates and neighbours are sensed too. Tell them, or switch the feature off when they are there.
• Treating WPA3 as protection against sensing. Encryption protects frame contents. Passive channel sensing reads how frames propagate, not what they contain, as NDSS 2020 showed.
• Treating breathing or sleep estimates as ordinary analytics. Under Washington law, health data inferred by machine learning is consumer health data, with opt in consent rules.
• Relying on MAC randomisation or power changes as a defence. The NDSS 2020 authors found these either impractical or ineffective against passive sensing.

FAQ

Can my Wi-Fi router see me?

Not as an image. A router with a sensing feature can detect that someone is moving, and with enough devices and modelling it may estimate which room. Research systems have gone further, recognising gestures and estimating body pose, but those needed special hardware or heavy training in controlled settings.

What is IEEE 802.11bf?

It is an amendment to the IEEE 802.11 Wi-Fi standard, titled "Enhancements for Wireless LAN Sensing." It defines how Wi-Fi devices advertise sensing capability, set up sensing sessions and measurements, and exchange sensing feedback, in bands between 1 GHz and 7.125 GHz and above 45 GHz. The IEEE SA Standards Board approved it on 28 May 2025 and it was published on 26 September 2025.

What is channel state information in Wi-Fi?

CSI is the receiver's estimate of how the radio channel changed each subcarrier's amplitude and phase between each transmit and receive antenna. Receivers compute it to decode data. Sensing systems read how it changes over time to infer movement.

Does WPA3 stop Wi-Fi sensing?

No. WPA3 protects the content of frames and who can join your network. Sensing reads the physical effect of a body on the radio channel, which an outsider can measure from frames they cannot decrypt. WPA3 is still worth using because it protects sensing reports and network access.

Can Wi-Fi detect breathing?

Research has shown breathing and heart rate monitoring from radio reflections; the published work cited here used a dedicated radio, not consumer Wi-Fi. If a product offers sleep or breathing estimates, treat the output as health data.

Can my neighbour use my Wi-Fi to see when I am home?

Research published at NDSS 2020 showed that an attacker outside a building, using one smartphone that sniffed existing Wi-Fi signals, could detect and roughly locate movement inside, without joining the network. It is a demonstrated technique, not an everyday threat, but it is why access point side defences such as cover signals were studied.

Is Wi-Fi motion data personal data under GDPR?

When it relates to an identified or identifiable person, such as a motion timeline tied to a household account, it generally is personal data under Article 4(1). Health related estimates can be special category data under Article 9. This is general information, not legal advice.

How do I turn off Wi-Fi motion sensing?

Open the app that manages your gateway, mesh system or smart home hub, find the motion, sensing or awareness setting and switch it off. Then check whether past activity history is kept and delete it if you can. Recheck after firmware updates.

Where Safeguard fits

Safeguard does not detect Wi-Fi sensing, analyse router firmware, scan radio hardware or manage devices. The fit is with the software your team builds around sensing: a smart home hub's app and cloud service, a research pipeline in Python that parses CSI captures, a mobile companion app, or a container that runs inference. Those are ordinary codebases with open source dependencies. Safeguard scans repositories, container images and SBOMs (safeguard scan --dir ., --image <name>, --sbom <file>), lists the components and versions inside them, matches them against vulnerability databases and ranks findings by reachability, so a team shipping a sensing feature can see which of its services carry a vulnerable library and fix it.

Sensing features concentrate sensitive data in a few services: the one that receives measurements, the one that turns them into events and the one that stores history. A vulnerable parser or web framework in any of those exposes exactly the data this post warns about. Supply chain hygiene still applies here, even though the radio side is outside Safeguard's scope, because the companion apps, cloud services and pipelines that handle sensing data are built from open source components that need patching like any other software.

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and it reads the finding and advisory, asks before any command that changes something, moves lodash to 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow fits a dependency bump in the web service behind a sensing companion app, where you want a person to review each change before it touches data about people's homes.

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 scans from the terminal. For a research group, that means a CSI analysis pipeline and its dependencies can be scanned on a lab workstation, without the captures themselves leaving the room.

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 Safeguard tools Claude can use. A product team can then ask in plain language which of its services contain a given version of a parsing or messaging library used in the sensing data path.

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

To try it on your own services, download Safeguard and read the CLI documentation.

Quick check

Sources

• IEEE SA: IEEE 802.11bf-2025, Amendment 4: Enhancements for Wireless LAN Sensing
• IEEE P802.11 Task Group BF (WLAN Sensing): status and meeting updates
• Du et al., An Overview on IEEE 802.11bf: WLAN Sensing (arXiv 2207.04859)
• Restuccia, IEEE 802.11bf: Toward Ubiquitous Wi-Fi Sensing (arXiv 2103.14918)
• Linux 802.11n CSI Tool project page
• Nexmon CSI extractor README
• Microcontroller SDK documentation: Wi-Fi channel state information
• WiSee: Whole-Home Gesture Recognition Using Wireless Signals (project page)
• WiSee paper (MobiCom 2013)
• Wi-Vi: See Through Walls with Wi-Fi (project page)
• WiTrack: Through-Wall 3D Tracking Using Body Radio Reflections (project page)
• Geng, Huang and De la Torre, DensePose From WiFi (arXiv 2301.00250)
• Zhu et al., Et Tu Alexa? When Commodity WiFi Devices Turn into Adversarial Motion Sensors (NDSS 2020)
• Et Tu Alexa? full paper (PDF)
• Staat et al., IRShield: A Countermeasure Against Adversarial Physical-Layer Wireless Sensing (arXiv 2112.01967)
• Internet provider support article on Wi-Fi motion sensing
• Regulation (EU) 2016/679 (GDPR), Official Journal L 119, Publications Office of the EU
• California Consumer Privacy Act text, California Privacy Protection Agency (PDF)
• Washington RCW 19.373.010, My Health My Data Act definitions

Last reviewed: 25 October 2026. Wi-Fi sensing features and their defaults change with firmware updates, and privacy law in this area is moving; check your device maker's documentation, your provider's privacy policy and current law before relying on anything described here. This post is general information, not legal advice.