r2.4 Detect wireless access points and validate wireless configurations
Where wireless environments connect to the CDE or transmit account data, apply secure configurations and change vendor defaults. In a pure AWS environment there is no customer wireless infrastructure, but scope must be documented.
AWS services
AWS Config 
AWS Security Hub Requirement 2
Apply Secure Configurations to All System Components
PCI sub-requirements covered
- 2.3 Wireless environments are configured and managed securely
How to implement on AWS
For workloads that do not rely on wireless in AWS, formally document non-applicability. Where customer-managed hybrid wireless components exist, change default keys/credentials and apply strong encryption; centralize configuration evidence in AWS Config/Security Hub and in the scope documentation.
Practical implementation
How this control is implemented in each reference architecture:
A pure AWS single-account deployment usually has no customer-managed wireless, so the tactical work is documenting non-applicability, or hardening any hybrid wireless that reaches the account.
- Confirm there is no customer-managed wireless in scope for this account and record the non-applicability, with rationale, in your PCI scope document.
- If a hybrid/on-premises wireless segment connects to this account, change all vendor defaults (SNMP community strings, admin passwords, keys) and apply strong encryption on those devices.
- Keep the evidence (config exports or attestations) with the account's compliance artifacts.Account logging / evidence store
Amazon S3
How to validate: The scope document states wireless applicability with rationale; where wireless exists, device configs show no vendor defaults.
Avoid: Silently ignoring the requirement because 'AWS has no wireless'. Document the non-applicability explicitly, an assessor needs the rationale on record.
Handle wireless once at the org level: document non-applicability centrally, and where hybrid wireless connects, manage and evidence it from the central network account.
- Document wireless applicability/non-applicability once at the organization level so every CDE account inherits a consistent position.
- Where hybrid wireless connects to CDE accounts, manage those network devices from the central network account (defaults changed, strong encryption).Network/inspection account
Transit Gateway - Record configuration evidence centrally in the log-archive account.Log archive account Amazon S3
How to validate: The org-level scope document addresses wireless, and any connected wireless devices show changed defaults with evidence retained centrally.
Avoid: Documenting wireless applicability separately (and inconsistently) per account. Decide it once at the org level and keep evidence central.
PCI validation
Testing procedures
- Examine policies/procedures and interview personnel to verify that processes are defined for wireless vendor defaults to be changed or confirmed secure on installation (2.3.1.a).
- Examine vendor documentation and observe login to wireless devices to verify SNMP and default passwords are not used, and other wireless vendor defaults are changed (2.3.1.b, 2.3.1.c).
- Interview personnel and examine key-management documentation to verify wireless encryption keys are changed as required (2.3.2). Where wireless does not apply on AWS, document the non-applicability.
Evidence in AWS
- PCI scope document indicating applicability or non-applicability of wireless environments.
- Where applicable: evidence of changing default credentials/keys on the wireless components.
Customized approach
Requires a targeted risk analysis (Req 12.3.2).
Customized Approach Objective
- 2.3 — Wireless networks cannot be accessed using vendor default passwords or default configurations.
Learning resources
References
- PCI DSS v4.0.1 Requirement 2.3