PCI DSS 2.3.1: For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited
PCI DSS v4.0.1 control 2.3.1: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 2.3.
Requirement 2: Apply Secure Configurations to All System Components › Section 2.3
For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to:
- Default wireless encryption keys.
- Passwords on wireless access points.
- SNMP defaults.
- Any other security-related wireless vendor defaults.
Summary
Change every wireless default before the network carries anything: keys, admin passwords, SNMP strings, firmware.
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 | |
|---|---|
| 2.3.1.a | Examine policies and procedures and interview responsible personnel to verify that processes are defined for wireless vendor defaults to either change them upon installation or to confirm them to be secure in accordance with all elements of this requirement. |
| 2.3.1.b | Examine vendor documentation and observe a system administrator logging into wireless devices to verify: • SNMP defaults are not used. • Default passwords/passphrases on wireless access points are not used. |
| 2.3.1.c | Examine vendor documentation and wireless configuration settings to verify other security-related wireless vendor defaults were changed, if applicable. |
The wireless case of 2.2.2, and it exists separately because wireless defaults are both well known and remotely reachable: an attacker does not need to be on your network to try them, only near your building. The scope is anything connected to the CDE or transmitting account data, which includes a guest network sharing infrastructure with a CDE-connected controller. Note the wording "changed at installation or confirmed to be secure": inheriting a vendor-configured deployment is acceptable if you verified it, which most entities have not.
What to prepare
- An inventory of wireless access points, controllers and their firmware versions.
- Evidence that default keys, passwords and SNMP community strings were changed or verified.
- The relationship between guest wireless and any CDE-connected infrastructure.
How to implement it
1. Include SNMP. Default community strings are the forgotten one, they are readable from the air, and they frequently expose enough configuration to plan an attack.
2. Check the controller, not just the access points. The controller holds the credentials for the whole estate, and it is administered rarely enough that its own defaults survive.
3. Treat vendor-installed as unverified. An installer who set it up is not evidence you confirmed it; the requirement offers verification as an alternative to changing, not as an assumption.
4. Map guest to CDE deliberately. A guest SSID on the same hardware as a CDE-connected network is in scope for this control however separate the VLANs are.
Where this commonly fails
- Wireless keys changed and SNMP community strings left at public/private.
- Access points hardened while the controller keeps its default administrative password.
- Guest wireless excluded because it "is not the payment network", though it shares the infrastructure.
- A vendor deployment accepted without the confirmation the requirement permits it on.
Related controls
Others in section 2.3:
| Control | What it requires |
|---|---|
| 2.3.2 | For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed… |
← 2.2.7 · All controls · 2.3.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.