PCI DSS 11.2.1: Authorized and unauthorized wireless access points
PCI DSS v4.0.1 control 11.2.1: the requirement in full, the 4 testing procedures an assessor uses to verify it, and the related controls in section 11.2.
Requirement 11: Test Security of Systems and Networks Regularly › Section 11.2
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.
- If automated monitoring is used, personnel are notified via generated alerts.
Summary
Test for wireless access points every three months, identify which are yours and which are not, and alert someone if you automate it.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 11.2.1.a | Examine policies and procedures to verify processes are defined for managing both authorized and unauthorized wireless access points with all elements specified in this requirement. |
| 11.2.1.b | Examine the methodology(ies) in use and the resulting documentation, and interview personnel to verify processes are defined to detect and identify both authorized and unauthorized wireless access points in accordance with all elements specified in this requirement. |
| 11.2.1.c | Examine wireless assessment results and interview personnel to verify that wireless assessments were conducted in accordance with all elements specified in this requirement. |
| 11.2.1.d | If automated monitoring is used, examine configuration settings to verify the configuration will generate alerts to notify personnel. |
This control applies whether or not you use wireless. Its purpose is finding access points you did not authorise, so an entity with no sanctioned wireless has the same obligation and arguably a clearer signal: any access point found is unauthorised. That reading catches out entities that mark it not applicable because they run no Wi-Fi. Four elements, and the fourth is conditional: if automated monitoring is used, personnel are notified via generated alerts, which 11.2.1.d tests separately, so a wireless intrusion detection system deployed without alerting satisfies less than a quarterly walk with a laptop. The three-month cycle is a floor, and the results feed the wireless bullet in the incident response plan under 12.10.5.
What to prepare
- The documented process, covering all four elements.
- The methodology in use: physical survey, wireless scanning, or automated monitoring.
- Assessment results for each of the last four quarters, with dates.
- If automated, the alerting configuration, which is examined directly.
How to implement it
1. Do it even with no wireless. The control is about detection, and an entity with no authorised access points should find nothing, which is a clean and cheap result to produce.
2. Cover every facility in scope, not the head office. Retail sites, warehouses and branch offices are where an unsanctioned access point is most likely to appear and least likely to be looked for.
3. Turn on the alerting if you automate. The fourth element is separately tested and is the usual reason an automated deployment scores worse than a manual one.
4. Reconcile findings against 11.2.2. Identifying an access point as unauthorised requires the inventory of authorised ones, so the two controls are one exercise.
Where this commonly fails
- Marked not applicable because the entity runs no wireless, which is the case the control is written for.
- Automated monitoring deployed with alerting off, failing the fourth element.
- Only the primary site surveyed, leaving branches and stores untested.
- Quarterly in policy and twice a year in practice, visible from the dates on the results.
Related controls
Others in section 11.2:
| Control | What it requires |
|---|---|
| 11.2.2 | An inventory of authorized wireless access points is maintained… |
← 11.1.2 · All controls · 11.2.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.