Neighboring networks and rogue access points
Any network you do not control that shares or overlaps your channel spends airtime your control traffic needed, and you can only manage what you have detected.
On this page5 sections
Is this your problem? It presents like this
- Retries and utilization rise on some channels with no change in your own traffic.
- Problems cluster near walls shared with neighbors, near docks, or where someone installed their own access point.
- Unknown SSIDs or BSSIDs appear in scans, some on your channels.
- The problem started with no change on your side, or soon after a neighbor, tenant, or contractor moved in.
- Stationary and mobile devices are both affected.
- Family
- External RF
- Bands
- 2.4 GHz5 GHz
Why it happens
Wi-Fi shares the medium with every transmitter in range on the same channel, whether it belongs to you or not. A vendor design guide for EtherNet/IP over wireless tells you to count traffic from neighboring WLANs sharing the same channel when you size a channel, and to give control traffic a dedicated channel rather than share it with applications under someone else’s control. One carmaker’s service bulletin makes the same point from the other side: when wireless phone projection drops in crowded areas, only the traffic on the channel matters, not the signal strength.
Not every foreign network is benign. Vendor documentation separates rogues, neighbors, and honeypots. A rogue sits on your wired network without authorization, a neighbor only shares your airspace, and a honeypot advertises your SSID to capture clients. NIST calls identifying and eliminating rogue access points a key concern for industrial wireless and points to intrusion detection and prevention.
Containment has limits. The FCC has warned that intentionally blocking or disrupting personal Wi-Fi hot spots on commercial premises is illegal. You handle neighbors by channel planning and negotiation, and rogues by removing them from your network. Detection comes first, because you cannot plan around a network you have not seen.
How to confirm it
- Export the neighbor and rogue lists from your WLAN system, or a survey tool, for the affected area.
- Filter for networks on or overlapping the channels your affected access points use, and note their signal levels and channel widths.
- Check whether any unknown access point is connected to your wired network. That is a security event as well as an RF one.
- Measure how much airtime the foreign networks use on your channel, not only how strong they are.
- Track the foreign networks over several days and correlate their activity with your drops.
The fix
- Re-plan channels in that area to avoid the strongest foreign networks.
- Remove rogue access points from your network, and find out who installed them and why.
- Talk to the neighbor or contractor and agree on channels, widths, and power.
- Reduce your own transmit power where it spills beyond the area you need to cover.
- Do not deauthenticate or jam networks you do not own.
Prevent it at design time
- Reserve channels for control traffic and keep other applications off them.
- Run continuous wireless intrusion detection in production areas and alert on new networks on control channels.
- Write a spectrum policy that forbids unapproved access points, and make contractors sign it.
- Coordinate channel plans with neighbors who share walls or yards.
About this page
Built from 5 sources: 1 standards body or lab, 2 regulators and government sources and 2 vendor documents. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made
- First published
- Last updated
Change history (1)
- First published
Cite this page
Plain
Ben Rutter. "Neighboring networks and rogue access points." OT Wireless, published October 5, 2026. https://otwireless.com/causes/neighboring-networks-and-rogue-aps/
APA 7
Rutter, B. (2026, October 5). Neighboring networks and rogue access points. OT Wireless. https://otwireless.com/causes/neighboring-networks-and-rogue-aps/
BibTeX
@misc{rutter2026neighboringnetworksandrogueaps,
author = {Rutter, Ben},
title = {{Neighboring networks and rogue access points}},
year = {2026},
howpublished = {\url{https://otwireless.com/causes/neighboring-networks-and-rogue-aps/}},
organization = {OT Wireless},
}