Rogue Access Points

A rogue access point is any unauthorized wireless access point operating in your environment. The term covers three very different situations, and collapsing them into one word is the reason most rogue AP programs either drown in false alarms or miss the case that actually matters: a device physically connected to your wired network, bridging traffic around every control you have at the perimeter.

This is not a solved problem, and it is not a legacy one. In 2024 Volexity documented a Russian state actor compromising an organization across the street from its real target, then using that foothold to reach the target’s enterprise Wi-Fi from a neighboring building. The target’s internet-facing systems all required multi-factor authentication. The wireless path was chosen precisely because it was the route with the fewest controls.

Quick Facts

• Three categories, one word: on-wire rogue, evil twin, and neighboring third-party AP. Only the first two justify a response.
• The dangerous case: an unauthorized AP plugged into your network is an unauthenticated bridge past the firewall, regardless of how well your applications encrypt traffic.
• Compliance floor: PCI DSS v4.0 Requirement 11.2.1 requires testing for the presence of wireless access points at least once every three months, even where wireless is prohibited.
• Containment is regulated: the FCC fined Marriott $600,000 in 2014 under Section 333 of the Communications Act for using containment against guests’ personal hotspots.
• The recent case that matters: the Nearest Neighbor attack, disclosed by Volexity in 2024, in which an APT reached a target’s Wi-Fi from a compromised organization nearby.
• What decides response time: location accuracy. Building-level detection produces a ticket. Desk-level or rack-level detection produces a recovery.

What Counts as a Rogue Access Point?

“Rogue” is the most overloaded term in wireless security, and the ambiguity has an operational cost. Most wireless consoles flag every unknown BSSID within earshot, so a mid-size office sees hundreds of rogues that are simply the businesses next door. Teams then either drown in the noise or turn the alerting off. Three categories are worth separating:

Category	Definition	Primary risk
Rogue AP (on-wire)	An unauthorized wireless device physically connected to your wired network	Bypasses the firewall entirely; an unauthenticated bridge into the internal LAN
Evil twin or honeypot	An attacker-controlled AP impersonating a trusted SSID, not connected to your network	Client-side: credential harvesting, interception, session theft
Neighboring external AP	A legitimate third-party AP that happens to be within RF range	Usually none; interference at most

Devices move between categories. An employee’s personal hotspot on a desk is a policy matter. The same hotspot bridged to an Ethernet port is an on-wire rogue and a network security incident. Classification, not detection, is what most programs actually get wrong. The client-side half of this topic is covered in our Wi-Fi Pineapple research.

Why an On-Wire Rogue Is the Serious Case

An access point connected to your network extends that network into the air with whatever security the person who installed it happened to configure, which is frequently none. Everything the organization spent on perimeter control sits in front of a path that no longer runs through the perimeter.

• It is an access problem, not an eavesdropping problem. TLS protects the contents of application traffic. It does nothing about an unauthenticated bridge onto an internal segment.
• Intent is often benign. A department that could not get wireless coverage buys a consumer router. The security consequence is identical to a malicious install.
• Dwell time is the damage mechanism. A rogue can operate for months before anyone notices, and the gap between installation and discovery is where the loss happens.
• The economics favor the attacker. Hardware capable of providing covert entry costs less than thirty dollars.

Is This Still a Real Threat?

The skeptical version of this question is fair: the canonical examples are old. TJX in 2005 and Target in 2013 both predate ubiquitous TLS, and citing them as the lead evidence invites the response that this is a solved retail problem.

The current anchor case is better. In November 2024 Volexity disclosed what it called the Nearest Neighbor attack, tracing activity to a Russian state actor. Rather than attacking the target directly, the actor compromised organizations in physical proximity, then used a dual-homed system at a neighboring organization to connect to the target’s enterprise Wi-Fi from across the street. The target’s internet-facing resources required multi-factor authentication; the wireless path did not have equivalent controls, which is why it was chosen.

Two conclusions follow. Proximity-based wireless access is demonstrated nation-state tradecraft against MFA-protected environments, not a legacy problem. And blanket advice to ignore neighboring access points aged badly, because in that case a neighbor’s network was the attack path.

Does 802.1X, NAC, or WPA3 Already Cover This?

Partially, which is exactly why the assumption is so durable. It is worth being precise about where the coverage ends rather than dismissing controls that genuinely help.

What 802.1X genuinely does: port-based authentication enforces policy at the edge, so a consumer router plugged into a wall jack cannot pass traffic until it authenticates. Certificate-based 802.1X also blocks evil twin connections, because the client validates the network’s identity before connecting. For the naive case, this works.

Where it stops working:

• Supplicant-capable rogues. An access point configured as an 802.1X supplicant can authenticate the port itself.
• Devices placed downstream of an authenticated endpoint. Hardware bridged between a switch and an already-authenticated workstation inherits that authenticated path, and purpose-built bypass tooling automates exactly this.
• MAC Authentication Bypass devices. Anything authenticated by MAC address alone, such as printers, cameras, and VoIP handsets, is trivially impersonated. Standard guidance is to segment those devices into their own VLAN with minimal reachable resources.
• Anything never on the wire. A cellular hotspot, an LTE-connected management interface, or a soft AP running on a laptop never touches an 802.1X-controlled port. Neither 802.1X nor NAC observes it at all.

WPA3 belongs in a different column. It improves the client-side story meaningfully, transition-mode deployments remain exposed to downgrade behavior, and none of it applies to an on-wire rogue, which is not an encryption problem in the first place.

The honest summary: 802.1X controls the deterministic part of the problem, which is the wire. The rogue AP threat lives at the edge of that control, particularly where insider-installed and cellular-connected devices are concerned.

How Do I Confirm a Rogue Is on My Network?

This is the highest-volume technical question in wireless forums, and the tooling has documented limits that teams tend to discover during an incident rather than before one.

Rogue Location Discovery Protocol, the canonical on-wire test in Cisco environments, carries constraints stated plainly in the vendor’s own documentation: it works only against open rogue APs that broadcast their SSID, the managed AP has to obtain a DHCP address from the rogue network, it does not work on 5 GHz DFS channels unless the AP is in monitor mode, an ACL anywhere in the path blocks it, running it on a local-mode AP takes that radio out of client service, and a failed attempt in a noisy RF environment is not automatically retried.

Switch port tracing requires every switch to be onboarded with SNMP credentials and CDP or LLDP data to be available. Read-only credentials identify the port; read-write credentials are needed to shut it.

MAC correlation, matching a radio MAC to a wired-side MAC, breaks when the rogue performs NAT, which most consumer routers do out of the box.

Practical fallbacks worth checking: switch ports showing more than one MAC address, unexpected CDP or LLDP neighbors, and DHCP lease anomalies. The structural point is that RF-only detection cannot answer the on-wire question, wired-only detection cannot see a device that has not been plugged in or never will be, and correlation across both is what actually resolves it.

The False Positive Problem

“I have four hundred rogues in my dashboard, which ones matter?” is the question behind most rogue AP tooling decisions, and it deserves a direct answer rather than a longer capability list.

Detection literature has flagged this since the mid-2000s: simplified detection approaches produce both false negatives, because attack forms vary, and false positives, because an access point missing from a database is not necessarily connected to the network of concern. It may be a neighboring business within range of a sensor. Both failure modes leave real intrusions undiscovered.

The practical failure mode is alert fatigue. Unreliable classification produces frequent false alarms, administrators stop reading the alerts or disable them, and the organization is unprotected while believing it is covered. When evaluating any rogue detection capability, the useful questions are how many alerts a small team will triage per week, what gets automatically classified versus escalated, and how confident the classification is. Client MAC randomization has made client attribution harder in recent years, though access point identifiers remain comparatively stable.

Can I Legally Shut It Down?

Carefully, and rarely over the air. This is the most legally consequential question in the topic.

In 2014 the FCC fined Marriott $600,000 over Wi-Fi blocking at a Gaylord property, where a monitoring system’s containment feature was used against guests’ personal hotspots. The action was brought under Section 333 of the Communications Act, which addresses willful interference. The consent decree was scoped to that conduct and did not declare deauthentication categorically illegal, but the enforcement advisory that followed made the FCC’s position on Wi-Fi blocking clear.

• Containment on your own wire is the first move. Shutting the switch port removes the risk without transmitting anything and avoids the regulatory question entirely.
• Target matters more than technique. Containing a device on your network, or one maliciously impersonating your SSID, is broadly defensible. Containing a device merely visible in your airspace is not.
• Automatic, indiscriminate containment is the hazard. Vendor best-practice guidance advises evaluating auto-containment very carefully or avoiding it, given the liabilities of leaving it running unattended. One documented case saw a company’s containment spill over and deny service across much of an adjacent public park.
• Broadcast versus selective. Broadcast deauthentication risks catching a neighbor’s newly installed AP; selective containment is less disruptive but is defeated by MAC spoofing and channel roaming.
• Over-the-air containment is becoming technically obsolete. 802.11w Management Frame Protection, now widely deployed, protects the very frames containment depends on. Running MFP as mandatory is also how you keep a neighbor’s controller from containing your access points.

The defensible posture is to classify aggressively, locate physically, contain on the wire, and treat over-the-air containment as a narrow last resort with an audit log recording exactly what was targeted and why.

How Often Do I Have to Scan?

PCI DSS v4.0 Requirement 11.2.1 requires testing for the presence of wireless access points, identifying all authorized and unauthorized access points, at least once every three months. Two points are consistently misread:

• Prohibiting wireless does not exempt you. The requirement applies even when wireless is not used in the cardholder data environment and policy forbids it, precisely because an access point is easy to attach and hard to notice. You verify compliance rather than assume it.
• Quarterly is a floor, not a goal. Anchoring on the quarterly language leaves a window of up to three months in which a rogue operates undetected, and an intermittently powered device may never be present during a scheduled walkthrough at all.

PCI guidance itself scales with the environment: physical inspection may suffice for a single tamper-evident kiosk, while multi-node environments such as retail estates, call centers, and data centers should combine physical inspection with wireless analysis. Card production standards go further, requiring WIDS-based random scans at least monthly in high-security areas, and NIST SP 800-153 recommends continuous WIDS and WIPS monitoring. Other regimes, including HIPAA and GDPR, create exposure through the breach rather than through an explicit scanning mandate. The artifact an assessor wants is an authorized-AP inventory with documented business justification, plus dated scan results and remediation records.

Finding and Handling a Rogue Access Point

CISA’s Wi-Fi guidance is candid that identifying and mitigating rogue access points is challenging and labor-intensive, specifically because the devices get moved and are not always powered on. A device that beacons for twenty minutes during a contractor’s visit will never appear in a quarterly walkthrough.

Location accuracy is what determines whether an alert is actionable. Building-level accuracy in a large facility is close to useless, floor-level narrows the search, and desk-level or rack-level turns a two-day hunt into a five-minute walk. Once located, the sequence that works:

1. Isolate first. Disable the switch port or block at the controller before completing the investigation.
2. Verify it is actually unauthorized. Check asset inventory. A legitimate device that was never logged needs an inventory fix, not an incident response.
3. Preserve evidence. Photograph the device in place, record MAC, SSID, and switch port, and capture traffic logs before disconnecting if forensic review is warranted.
4. Close the loop. A department that installed a consumer router had an unmet need. Meeting it with a managed access point prevents recurrence far better than confiscation does.

What About Everything That Is Not Wi-Fi?

Coverage boundaries are usually assumed rather than verified. Infrastructure-bundled wireless intrusion prevention is scoped to the radios your access points contain, which is a design fact rather than a defect, and it leaves specific gaps:

• 6 GHz. Wi-Fi 6E added 1200 MHz of contiguous spectrum. Whether your scanning radios cover it depends entirely on hardware generation, and mixed-age fleets have inconsistent visibility.
• Cellular hotspots and embedded modems. Phone tethering, LTE-connected management interfaces, and IoT gateways with cellular backhaul operate on spectrum a Wi-Fi scanning radio never tunes to. Neither the firewall nor the WIPS observes that path.
• Soft APs. Laptop and phone hotspot modes frequently appear only intermittently.
• Bluetooth, BLE, and proprietary IoT protocols. Outside 802.11 monitoring by definition, and increasingly common in the same spaces.

The buyer-facing question is simple: which bands does your current tooling actually tune to, and did you verify that or assume it?

How Bastille Detects Rogue Access Points

Bastille monitors the RF spectrum passively from 100 MHz to 7.125 GHz using a network of software-defined radios, which means detection does not depend on a device joining your network, appearing in an inventory, or being present during a scheduled walkthrough.

Two honest boundaries. RF monitoring establishes that a device exists and where it is; determining whether it is bridged to your network still requires correlation with wired-side data, and that correlation is the answer to the on-wire question rather than either source alone. And detection does not decide the containment question for you, which remains a policy and legal decision. Further reading: rogue wireless access point detection and mitigation and wireless intrusion detection systems.

Frequently Asked Questions

What is a rogue access point?

A rogue access point is an unauthorized wireless access point operating in your environment. The consequential case is one physically connected to your wired network, because it creates an unauthenticated wireless path into internal systems that bypasses the perimeter.

Is a rogue access point the same as an evil twin?

No. An evil twin impersonates a trusted network name to capture clients and is usually not connected to your network at all. A rogue access point is any unauthorized AP in your space, and the serious variant is one attached to your wire. They call for different responses.

Is my neighbor’s access point a rogue?

Almost always no. A third-party AP within RF range is a neighbor, not a threat, and treating every unknown BSSID as a rogue is the main source of alert fatigue. The exception worth noting is that a compromised neighboring network was the actual attack path in the 2024 Nearest Neighbor case.

Does 802.1X stop rogue access points?

It stops the naive case of an unauthenticated device plugged into a port. It does not stop an AP acting as its own supplicant, a device bridged behind an already-authenticated endpoint, impersonation of a MAC-authenticated printer or camera, or any device with a cellular uplink that never touches a controlled port.

How do I tell whether a rogue AP is on my network?

By correlating wireless detection with wired-side evidence: switch port tracing via SNMP with CDP or LLDP data, ports showing multiple MAC addresses, unexpected neighbors, and DHCP lease anomalies. Automated on-wire tests have real limits, including working only against open networks and failing when the rogue performs NAT.

How often does PCI DSS require wireless scanning?

At least once every three months under Requirement 11.2.1, including in environments where wireless is prohibited by policy. Continuous monitoring is what closes the window between scheduled scans, which is where an intermittently powered device hides.

Is it legal to deauthenticate a rogue access point?

It depends on the target. The FCC fined Marriott $600,000 in 2014 under Section 333 for containing guests’ personal hotspots. Containment against a device on your own network or maliciously impersonating your SSID is broadly defensible; containment against a device merely visible in your airspace is not. Shutting the switch port avoids the question entirely.

Should I enable automatic containment?

Not indiscriminately. Vendor best practice advises evaluating auto-containment carefully or avoiding it because of the liability of unattended operation. A defensible middle position is to classify automatically, contain automatically only on devices confirmed to be on your wire, and prefer wired-side containment.

Why does my dashboard show hundreds of rogues?

Because most consoles classify every unknown BSSID in range as a rogue, and in any dense area that includes every neighboring business. The fix is classification confidence and risk scoring, not more detection, since unreliable alerts get ignored or switched off.

What should I do when I find a rogue access point?

Isolate it by disabling the switch port, verify against asset inventory that it is genuinely unauthorized, preserve evidence including photographs, MAC, SSID, and port details, and then address the need that led someone to install it.

Are rogue access points still used in real attacks?

Yes. The 2024 Nearest Neighbor attack documented a Russian state actor compromising a nearby organization and using it to reach the target’s enterprise Wi-Fi, specifically because the wireless path lacked the multi-factor authentication protecting internet-facing systems.

Does encryption make this less serious?

No. TLS protects the contents of traffic. An on-wire rogue access point is a network access problem, and encryption does nothing about an unauthenticated bridge onto an internal segment.

What Can I Do to Defend Against This Threat?

• Maintain an authorized AP inventory with documented business justification, because you cannot classify what you have not defined.
• Deploy 802.1X and segment MAB devices into their own VLAN with minimal reachable resources, closing the deterministic wired case.
• Monitor the spectrum continuously rather than scanning quarterly, so intermittently powered and cellular-connected devices are visible.
• Correlate RF detections with wired-side data to answer the on-wire question, which neither source resolves alone.
• Write the containment policy before you need it: who authorizes it, what evidence justifies it, and why wired-side containment comes first.
• Enable Management Frame Protection as mandatory, which also prevents a neighboring organization’s system from containing your access points.
• Treat recurrence as a service gap: when someone installs their own AP, provide managed coverage instead of only removing the device.

Rogue access points persist because they occupy the space between network controls and physical security, where neither is looking, and because the window between installation and discovery is usually measured in months. See a demo to understand what continuous RF visibility looks like in your environment, or explore more Bastille wireless security research.