Wireless Access Point Detection

PCI DSS 4.0.1 Requirement 11.2.1 expects you to actively test for the presence of Wi‑Fi access points in and around your cardholder data environment (CDE), detect and identify both authorized and unauthorized access points, run that detection on a defined recurring cadence (at least quarterly), and generate alerts if you use automated monitoring. ¹

Key takeaways:

• You need a repeatable process to find any Wi‑Fi access point, not just the ones you installed. ¹
• Your control must produce evidence that detection and identification occurred on schedule and that exceptions were handled. ¹
• If you deploy automated monitoring, configure alerting and prove who receives and responds to alerts. ¹

Wireless access point detection is one of those PCI requirements assessors test quickly because it is easy to misunderstand and easy to fail on evidence. The requirement is not “we don’t have Wi‑Fi in the CDE.” It is “we can prove we regularly test for Wi‑Fi access points, and we can detect and identify any that exist, whether authorized or rogue.” ¹

Operationally, this control sits at the intersection of security engineering (radio scanning and network discovery), IT operations (authorized access point inventory and change control), and governance (documented cadence, assigned ownership, and remediation tracking). You will also run into scoping complexity: you may have “no wireless” in the CDE, while offices nearby still have Wi‑Fi, personal hotspots, or third-party managed access points. The requirement still expects you to test for their presence and be able to explain what you found and what you did about it. ¹

This page translates Requirement 11.2.1 into an operator-ready implementation plan: who owns it, how to run it, what evidence to retain, and what assessors typically ask for.

Wireless access point detection requirement (PCI DSS 11.2.1) in plain English

You must run a repeatable activity that:

1. tests for the presence of wireless (Wi‑Fi) access points,
2. detects and identifies all wireless access points found (authorized and unauthorized),
3. performs the testing/detection/identification on a regular schedule (at least quarterly), and
4. if you use automated monitoring, generates alerts that notify personnel. ¹

“Detect and identify” is the operational hinge. Detection means you can find a signal/device; identification means you can tie what you found to something actionable (for example: a known AP from your inventory, a neighbor’s SSID bleeding into your space, an employee hotspot, or a rogue device on your wired network).

Regulatory text

PCI DSS v4.0.1 Requirement 11.2.1 states:

“Authorized and unauthorized wireless access points are managed as follows: the presence of wireless (Wi-Fi) access points is tested for, all authorized and unauthorized wireless access points are detected and identified, testing detection and identification occurs at least once every three months, and if automated monitoring is used it is configured to generate alerts to notify personnel.” ¹

What the operator must do: implement a control that produces provable results showing you looked for Wi‑Fi APs, recorded what you found, classified them as authorized or unauthorized, acted on unauthorized findings, and repeated the activity on schedule. If you rely on a tool that continuously scans, you must show alerting is configured and routed to a real response path. ¹

Who it applies to

Entity types

• Merchants and service providers that store, process, or transmit account data.
• Service providers whose people, processes, or systems can affect the security of the CDE. ¹

Operational contexts where this becomes “real”

• Corporate offices adjacent to a CDE network segment (even if the CDE is “wired only”).
• Retail and hospitality locations where consumer Wi‑Fi exists near payment systems.
• Warehouses and clinics where operational Wi‑Fi (scanners, tablets) is present near payment devices.
• Colocation and shared facilities where neighboring tenants’ Wi‑Fi may be detectable.
• Third-party managed sites (franchisees, MSP-managed branches) where you still need evidence that testing happened.

What you actually need to do (step-by-step)

Step 1: Set ownership, scope boundaries, and success criteria

• Assign an owner (usually Network Security or IT Security) and a backup owner for coverage during absences.
• Define the physical scope: buildings, floors, rooms, and adjacent spaces where Wi‑Fi could create a path into the CDE or where an AP could be plugged into CDE-adjacent wiring closets.
• Define the technical scope: CDE subnets, adjacent subnets, and switch closets where an unauthorized AP could be connected.
• Define “authorized”: what makes an AP approved (ticket, standard configuration, asset tag, management controller enrollment, approved SSIDs, approved security settings).
• Define “unauthorized”: everything else, including personal hotspots and third-party devices that are not approved for the environment.

Deliverable: a one-page “Wireless AP Detection Standard” that states scope, cadence, tooling approach (manual surveys vs automated), and required evidence. ¹

Step 2: Build and maintain an inventory of authorized access points

You cannot reliably identify “unauthorized” if you do not have a clean list of what is authorized.

• Maintain an inventory with: make/model, serial/MAC/BSSID, location, responsible team, SSIDs, management plane, and change ticket reference.
• Tie inventory updates to your change process: any AP install/move/decommission must update the inventory.

Artifact: “Authorized Wireless Access Point Inventory” with change history.

Step 3: Choose your detection method (and document why)

You have two common implementation patterns:

A) Quarterly (or more frequent) active testing

• Perform a site survey walk-through with a scanning tool to detect SSIDs/BSSIDs and signal strength around in-scope areas.
• Perform a wired-side check to detect APs connected to switchports (for example, ports with known AP OUIs/MAC patterns, or ports providing PoE to an AP).
• Record findings and validate each detected AP against the authorized inventory.

B) Automated/continuous wireless monitoring

• Use a wireless intrusion detection/prevention or monitoring capability that continuously detects APs and flags rogue/unknown devices.
• Configure alerting to notify personnel when unknown/unauthorized APs appear. ¹

Decision rule for operators: if you operate many distributed sites or frequently changing office layouts, automated monitoring reduces missed detections but increases the need to prove alert triage and response.

Step 4: Execute detection and identification runs on a fixed cadence

Run the detection activity on the required cadence, and keep it consistent so evidence is easy to defend. For each run:

1. Prepare: export current authorized AP inventory; pull recent network changes; note any site construction events.
2. Scan: collect wireless scan outputs (SSIDs, BSSIDs, channels, encryption type if available) and wired-side indicators (switchport connections that look like APs).
3. Identify: match each finding to the authorized inventory or classify it as unknown.
4. Investigate unknowns:
   • Determine whether it is a neighbor’s AP (detectable but not connected to your network) vs a device physically present and connected.
   • Check switchport, NAC, DHCP logs, or physical inspection when needed.
5. Disposition:
   • Authorized: document match to inventory record.
   • Unauthorized: open an incident/ticket, remove/disable, and document root cause (for example, shadow IT, contractor install, mis-scoped AP).
6. Close out: produce a final report signed/approved by the control owner.

Requirement mapping: this run is where you prove “presence tested,” “detected and identified,” and “performed on schedule.” ¹

Step 5: If you use automated monitoring, prove alerting and response

If you claim automation:

• Configure alerts for unknown/rogue AP detection and routing to an on-call group or ticketing queue.
• Define SLAs as internal targets (avoid publishing numbers you cannot evidence).
• Test alerting by introducing a benign test AP (or a simulated event) and capture the alert, ticket creation, and closure notes.
• Retain evidence of who was notified and what action was taken. ¹

Step 6: Manage exceptions explicitly

Legitimate exceptions happen (shared buildings, temporary construction Wi‑Fi, lab environments).

• Create an exception record with: business justification, compensating measures, scope boundary, approval, and expiration date.
• Revalidate exceptions on the same cadence as your detection run so they do not become permanent blind spots.

Required evidence and artifacts to retain

Assessors usually fail teams on “we do it” without durable artifacts. Keep:

• Wireless AP Detection Standard / procedure (scope, method, cadence, roles). ¹
• Authorized AP inventory with identifiers and locations.
• Detection run package for each period:
  • scan outputs (exports, screenshots, logs),
  • reconciliation spreadsheet or system report mapping detected APs to inventory,
  • list of unknown/unauthorized findings and investigation notes,
  • remediation tickets and closure evidence.
• Automated monitoring configuration evidence (alert rules, recipients, sample alerts) if used. ¹
• Training/operational handoff evidence for staff who execute scans and triage alerts.
• Exception register and approvals.

If you manage evidence in Daydream, structure it as a recurring control with an evidence checklist per run (scan output, reconciliation, ticket IDs, approval). That reduces scramble risk during a QSA request and keeps cadence visible to GRC.

Common exam/audit questions and hangups

Expect these:

• “Show me the last detection run and the one before it.” They will test cadence and consistency. ¹
• “How do you know this access point is authorized?” Have inventory linkage and change ticket references.
• “What happens when you find an unknown AP?” Show tickets, time-stamped actions, and removal/containment.
• “If you use automated monitoring, who gets the alert and how do they respond?” Provide alert routing evidence. ¹
• “Does this cover all locations in scope?” Be ready with a site list and sampling logic if you have many sites.

Frequent implementation mistakes (and how to avoid them)

1. Inventory drift: you scan, find APs, but the inventory is stale so you cannot “identify.”

   • Fix: tie AP inventory updates to change control and require location + identifier fields.

2. Scanning only the corporate SSID: teams validate their managed Wi‑Fi controller but never scan the airspace for non-corporate signals.

   • Fix: record raw scan results that include all detected SSIDs/BSSIDs.

3. Ignoring wired rogue APs: a small AP can be plugged into a wall jack in a closet; airspace-only surveys may miss it depending on placement.

   • Fix: pair wireless surveys with switchport checks in wiring closets.

4. Automation without alert operations: the tool “can alert,” but nobody can show it is configured, routed, and tested.

   • Fix: run an alert test and retain the resulting ticket trail. ¹

5. Poor scoping story: “No wireless in CDE” becomes a rationale to do nothing.

   • Fix: document the physical and logical boundary and show you tested for presence anyway. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so treat the risk as assessment-driven rather than headline-driven. The practical risk is straightforward: an unauthorized AP can create an unmonitored ingress path to networks near or inside the CDE, and a weak evidence trail can trigger PCI findings that expand remediation scope and retesting effort. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Name the control owner and define the in-scope site list.
• Publish the Wireless AP Detection Standard (scope, method, cadence, roles). ¹
• Build the initial authorized AP inventory and reconcile with network team records.
• Decide detection method (manual testing vs automated monitoring) and document the rationale.

Day 31–60 (run it once end-to-end)

• Execute a full detection run across the defined scope.
• Reconcile detections to inventory; open tickets for unknown APs; close or document disposition.
• If using automated monitoring, configure alerting and run an alert test; capture evidence. ¹
• Stand up an evidence repository (GRC system or controlled folder) with a standard “run package” template.

Day 61–90 (make it repeatable and audit-ready)

• Run a second cycle (or a targeted spot check) to prove repeatability and improve the runbook.
• Add KPIs for internal management (for example, number of unknown findings by site) without publishing unsupported external benchmarks.
• Train backup personnel and formalize escalation paths (facilities, IT, security incident response).
• If you use Daydream, implement automated reminders, evidence requests, and exception expirations so the cadence is visible and defensible during QSA work.

Frequently Asked Questions

Do we still need wireless access point detection if we prohibit Wi‑Fi in the CDE?

Yes. The requirement is to test for the presence of wireless access points and detect/identify authorized and unauthorized devices; “no Wi‑Fi” is not evidence by itself. ¹

What counts as “identification” of an access point?

Identification means you can tie each detected AP to a specific authorized inventory entry or document it as unauthorized/unknown with enough detail to investigate and resolve (for example, BSSID/MAC and location). ¹

Can we meet the requirement with quarterly walk-through scans, or do we need continuous monitoring?

Quarterly testing is acceptable as long as you can show testing, detection, and identification occurred on the required cadence and you handled unauthorized findings. Continuous monitoring is optional, but if you use it you must enable alerting. ¹

What evidence do assessors usually ask for first?

They typically ask for the last one or two detection runs, the authorized AP inventory, and proof that any automated monitoring generates alerts to personnel when enabled. ¹

How do we handle neighboring businesses’ Wi‑Fi that we can detect but don’t control?

Record it as a detected AP, document that it is not connected to your network, and show what checks you performed to confirm it is external. Keep an exception note if it is a recurring detection near sensitive areas.

How should third-party managed locations handle this control?

Require the third party to provide the same run package you would produce internally: scan outputs, reconciliation to an authorized list, and tickets for unauthorized findings. Keep those artifacts with your PCI evidence set. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. PCI DSS v4.0.1 Requirement 11.2.1

2. Just Published: PCI DSS v4.0.1