August 2026
Wi‑Fi is no longer only a connectivity layer. It is becoming a sensing layer. That statement would have sounded like a research-lab curiosity a decade ago, but in 2026 it is increasingly practical: IEEE 802.11bf‑2025 has been published, commercial Wi‑Fi sensing platforms and acquisitions show that the market is moving, and recent research continues to show that ordinary Wi‑Fi signals can reveal presence, motion, occupancy, position, and — in carefully tested conditions — individual identity signatures.
For wireless engineers, this is both exciting and uncomfortable. Wi‑Fi sensing promises new capabilities without cameras: occupancy analytics, smart buildings, security monitoring, elder-care wellness, device presence, power management, and environment-aware automation. But it also turns the WLAN into a spatial data system. That creates new engineering questions (airtime overhead, measurement scheduling, reliability, calibration, false positives) and new governance questions (privacy, consent, security, retention, and whether the feature should even be enabled).
This August 2026 post looks at Wi‑Fi sensing as a real operational topic, not a novelty. We’ll explain what 802.11bf standardizes, how Channel State Information (CSI) and Beamforming Feedback Information (BFI) are used for sensing, why sensing can affect data performance, how recent privacy research should change enterprise governance, and how Wi‑Fi 7/8 reliability thinking should shape sensing deployments. The central idea is simple: Wi‑Fi sensing can be valuable, but it must be treated as a controlled capability — not as a hidden by-product of connectivity.
What you’ll take away
A modern WLAN already has multiple roles:
The fourth role is the new one. Traditional Wi‑Fi “location” usually means estimating where a client device is, using signal strength, RTT, triangulation, or vendor-specific methods. Wi‑Fi sensing is different: it can infer environmental change even when the person or object being sensed does not carry a device. The signal itself becomes the sensor.
That matters because Wi‑Fi is already everywhere. The same APs, extenders, laptops, phones, and IoT devices that carry data can also produce measurements that describe the RF channel. As people move, sit, breathe, open doors, or walk through corridors, they slightly change multipath reflections and attenuation. With enough measurement quality and signal processing, those changes can be classified.
This is why Wi‑Fi sensing is attractive for smart buildings: you can detect occupancy without installing a camera in every room. It is also why the topic is sensitive: a system that sees motion without a camera can still be a monitoring system. The ethical and operational burden does not disappear just because the sensor is radio-based.
IEEE 802.11bf‑2025 is the WLAN sensing amendment. The IEEE standards page describes it as defining modifications to the 802.11 MAC, to PHY service interfaces for HE/EHT PHYs, and to DMG/EDMG PHYs to enhance WLAN sensing operations in license-exempt bands between 1 GHz and 7.125 GHz and above 45 GHz. That means sensing is not limited to one band. It includes familiar sub‑7 GHz Wi‑Fi as well as directional/high-frequency sensing possibilities above 45 GHz.
The most important engineering point is that 802.11bf does not mean every AP suddenly becomes a privacy-invasive radar by default. It means the 802.11 ecosystem now has standardized mechanisms to support sensing operations more consistently. Before standardization, vendors and researchers often relied on proprietary methods, driver hacks, CSI extraction from specific chipsets, or application-specific workarounds. Standardization should improve interoperability and give the ecosystem common language and procedures.
A useful way to understand 802.11bf:
NIST’s earlier summary of 802.11bf use cases is still a good framing: presence detection, environment monitoring in smart buildings, and remote wellness monitoring are central examples. The real-world scope is broader — but the point is the same. Wi‑Fi is being formalized as a sensing medium.
It is important not to overstate the standard. 802.11bf provides a standards-based framework for WLAN sensing procedures, but it does not automatically answer the hardest deployment questions: whether a sensing model is accurate in a particular building, whether the measurement overhead is acceptable under peak load, whether privacy expectations are satisfied, or whether derived events are safe to feed into automation. Those remain implementation and governance responsibilities.
In practice, a production sensing project needs three layers of validation:
Two technical terms appear constantly in Wi‑Fi sensing discussions: Channel State Information (CSI) and Beamforming Feedback Information (BFI). They are related, but they are not the same operationally.
CSI describes how the wireless channel behaves across subcarriers, antennas, and time. It captures how the environment affects amplitude and phase. For sensing, CSI is valuable because movement and presence alter the channel in measurable ways. Researchers have used CSI for presence detection, activity recognition, localization, gesture detection, and breathing/health-related experiments.
The catch: raw CSI extraction on commodity devices has historically been inconsistent. Many research systems relied on particular chipsets, modified drivers, or lab-specific capture methods. That limits deployability and makes standardization important.
Beamforming Feedback Information exists because modern Wi‑Fi systems use feedback from clients to help transmitters steer energy more effectively. BFI is not raw CSI, but it can act as a compressed representation of channel behaviour. Because BFI is closer to normal Wi‑Fi operation and can be captured from standard-compliant frames in some circumstances, researchers increasingly treat it as a practical data source for sensing.
That practicality is why BFI matters. A 2023 research tool called Wi‑BFI demonstrated extraction of beamforming feedback angles and reconstructed BFI from commercial Wi‑Fi devices. More recent research continues to use BFI-like data for positioning, anomaly detection, and passive sensing. In 2026, Karlsruhe Institute of Technology publicized research showing that beamforming feedback could be used to infer individual identity signatures from ordinary Wi‑Fi communication in a study with 197 participants.
The lesson for engineers is not “panic.” The lesson is that radio measurement data is sensitive data. If a WLAN exposes detailed spatial signatures, the organization must treat that data with privacy and security controls, even if the primary intent is building automation or performance optimization.
Practical distinction: CSI/BFI data is not “just Wi‑Fi diagnostics.” In sensing-aware systems, it can become environmental data, occupancy data, and potentially biometric-adjacent inference data.
The strongest Wi‑Fi sensing use cases are those where cameras are too intrusive, PIR sensors are too limited, and installing a dedicated sensor network is too expensive or operationally heavy. Before choosing a product or architecture, distinguish between two sensing styles:
Most real deployments will blend these concepts, but the distinction helps clarify risk: active sensing is easier to disclose and bound; passive sensing can be easier to hide and harder for users to understand.
Buildings already need occupancy signals for HVAC, lighting, desk utilization, meeting room analytics, energy management, and cleaning operations. Wi‑Fi sensing can potentially provide room- or zone-level occupancy without requiring every person to carry a device and without deploying cameras. For commercial real estate and smart offices, that is a compelling proposition.
Residential and small-business systems have already marketed Wi‑Fi motion detection as a camera-free security layer. In enterprise settings, the same idea could apply to after-hours motion in restricted areas, movement in storage rooms, or presence in spaces where cameras are not acceptable. The caveat is false positives and operational trust. If the model cannot distinguish people, pets, doors, HVAC movement, and equipment vibration reliably enough, it becomes alert noise.
Wi‑Fi sensing is often discussed for elder care, wellness, and non-contact monitoring. The attraction is obvious: passive presence and motion signals can support fall-risk patterns or daily activity changes without requiring cameras or wearable compliance. But the governance threshold is higher because the context is health-adjacent. Any deployment must treat consent, data retention, model accuracy, and explainability as first-order design criteria.
A 2026 research example demonstrated human presence detection using Wi‑Fi sensing on commodity laptops, aiming at intelligent power management and security features without external sensors. That type of application is important because it moves sensing from “building infrastructure” toward endpoint features. If devices can use their own Wi‑Fi hardware for presence awareness, then sensing becomes a client-platform capability, not only an AP feature.
Sensing is not free. Even if the sensing computation happens off the RF path, measurements and coordination can consume airtime, processing, memory, and management-plane attention. NIST research has explicitly examined 802.11bf sensing performance and its impact on data communication, highlighting that sensing procedures can introduce overhead and that the interaction between sensing and communications needs careful study.
In practical networks, the reliability question becomes:
A poorly implemented sensing feature could become the wireless equivalent of noisy telemetry: useful in theory, harmful under load. A well implemented sensing feature should be scheduled, bounded, observable, and subordinate to critical communications.
Reliability rule: sensing must never be allowed to silently degrade the tail. If 95th/99th percentile latency worsens when sensing is enabled, the feature is not production-ready for that zone.
A practical acceptance test is straightforward: run the same collaboration, voice, roaming, and bulk-traffic test with sensing disabled and then enabled. Compare 95th/99th percentile latency, retry rate, airtime utilization, and roam stall frequency. If the sensing feature is useful but increases jitter during critical periods, schedule it more conservatively, narrow its zone, or disable it for production hours.
The privacy risk is not theoretical. Researchers at Karlsruhe Institute of Technology reported that identity inference could be performed using Wi‑Fi beamforming feedback, with the attack operating from ordinary Wi‑Fi communication and not requiring the person being identified to carry a device. Their public summary emphasizes that BFI is transmitted unencrypted and can be recorded by anyone in range.
That does not mean every Wi‑Fi sensing system can identify people in every environment, and it does not mean every enterprise deployment is automatically exposed in the same way. Research conditions, training data, device placement, movement patterns, device support, and model assumptions matter. But the finding is enough to change governance. If a signal can support identity-like inference, the data must be treated as sensitive even when the product UI calls it “motion,” “presence,” or “occupancy.”
Enterprises should adopt five guardrails:
This is not just a legal/privacy issue. It is an engineering quality issue. If you cannot explain what data is collected, where it is processed, and who can access it, you are not ready to deploy sensing in production.
Wi‑Fi sensing can be architected in several ways. Each has different privacy and reliability implications.
The AP or local controller produces simple events: motion/no motion, occupied/not occupied, presence confidence. This minimizes data movement and can be privacy-friendly if raw measurements are not retained. The trade-off is less model complexity and less cross-site learning.
Measurements are processed on an on-site appliance, gateway, or controller. This supports stronger models, local storage controls, and integration with building systems while avoiding continuous cloud transfer of raw sensing data. For enterprise and healthcare-adjacent deployments, this may be the most balanced architecture.
Cloud processing can improve model training, fleet management, and cross-site analytics, but it increases privacy and data-sovereignty complexity. If cloud analytics is used, organizations need clear contractual and technical controls: retention, encryption, access, model training use, tenant separation, and data export/deletion processes.
A practical architecture is hybrid: local processing for real-time events and privacy-sensitive zones, cloud aggregation for anonymized trends and fleet health. This maps well to enterprise operations because it preserves responsiveness while giving central teams visibility.
Wi‑Fi sensing depends on changes in the RF channel. That means sensing quality is affected by the same things that affect connectivity: multipath, interference, channel width, antenna placement, device movement, and transmit power. A network that is a retry factory is not a good sensing platform.
Wi‑Fi 7 gives sensing-aware networks several useful ingredients:
But the same warnings apply as in every serious Wi‑Fi 7 design: do not over-wide channels, do not rely on patchy 6 GHz, and do not assume MLO makes poor RF good. For sensing, the penalty can be twofold: the connectivity experience degrades, and the sensing model becomes noisy or less reliable.
Wi‑Fi 8 (802.11bn) is being defined around Ultra‑High Reliability, with multi‑AP coordination as a central mechanism in public research and vendor education. That direction is directly relevant to Wi‑Fi sensing. Sensing is inherently a multi-device, multi-perspective problem: more APs and clients create richer environmental views, but also more opportunities for measurement overhead and interference.
A sensing-aware WLAN needs coordination across:
This is why Wi‑Fi 8 thinking matters now, even before Wi‑Fi 8 is widely deployed. If future WLANs are more coordinated, sensing can become safer and more predictable. But if sensing is bolted onto uncoordinated, high-contention WLANs, it risks becoming yet another background workload that hurts the tail.
If you are evaluating Wi‑Fi sensing in 2026, use a deployment checklist that treats it as both a technical and governance project.
Sensing is likely to arrive through familiar platforms: AP firmware, cloud dashboards, smart home gateways, building-management integrations, and security products. Before enabling it, ask vendors hard questions:
The right answer is not always “do not deploy sensing.” The right answer is “deploy it like a sensitive system.” Wi‑Fi sensing is too powerful to be treated as a harmless checkbox.
The WLAN contract used to be simple: provide connectivity, enforce access policy, and keep performance stable. Wi‑Fi sensing changes that contract. The WLAN may now observe physical space, infer occupancy, and feed automation or analytics systems. That is a different operational responsibility.
Engineers should not reject Wi‑Fi sensing simply because it is sensitive. There are legitimate, valuable, privacy-preserving use cases. But the bar must be higher than “the vendor dashboard has a new feature.” A production-ready sensing deployment needs:
If you do that, Wi‑Fi sensing can become a useful part of the AI-aware building and enterprise WLAN. If you don’t, it becomes an invisible surveillance and reliability risk hiding inside your connectivity platform. In 2026, the engineering challenge is not whether Wi‑Fi can sense. It is whether we can operate sensing responsibly.
Want more deep‑dive Wi‑Fi engineering posts?
Follow the blog: wifiblog.eawtech.net
Connect on LinkedIn: Eduardo Wnorowski
Eduardo Wnorowski is a Technologist and Director.
With over 30 years of experience in IT and consulting, he helps organizations design and operate stable, secure, and high‑performance networks through disciplined architecture, measurement, and continuous optimization.
LinkedIn Profile