2.3 Wireless environment configuration: requirements and evidence

What PCI DSS 2.3 asks for and why wireless keys and defaults get tested

Requirement 2.3 applies only if a wireless network is connected to the cardholder data environment (CDE) or transmits account data. If it is, PCI DSS expects two things: wireless vendor defaults are changed or confirmed secure before the access points go live (2.3.1), and wireless encryption keys are changed when people who knew them leave or when a key is suspected or known to be compromised (2.3.2). The requirement exists because a Wi-Fi network is a door that opens from the parking lot. A default administrator password, a default SNMP community string or a widely known shared key lets an unauthorized device join a network that may route traffic toward payment systems, and a former employee who still knows the key can do the same.

Start with the wireless inventory, because the requirement only reaches networks you know about. Walk the sites, pull controller and access point lists, and record which SSIDs are connected to the CDE or carry account data, including guest, point-of-sale and handheld networks that share infrastructure with payment traffic. For each access point and controller, confirm whether vendor defaults such as default encryption keys, administrative passwords and SNMP settings were changed at installation, or whether someone documented why a default was acceptable. Keep that record with your configuration standards so an assessor can trace it to a device.

Key changes are harder than they look because a shared pre-shared key often serves dozens of devices, and changing it means reconfiguring every client. Ask who holds the key today: staff, contractors, a former managed service provider, or a vendor support account. Decide in advance how you will rotate it, who approves the change, and where the trigger events are logged, such as offboarding tickets or incident records. If a managed provider runs the access points, your written responsibility matrix should say who changes defaults and keys, and you should confirm that the provider's evidence can be shown to your assessor. Your qualified security assessor will check the configuration and the records, so confirm the scope with them early.

Which wireless networks fall under 2.3

Requirement 2.3 applies only to wireless environments that connect to the cardholder data environment or transmit account data. Whether a given network qualifies depends on how it is wired, segmented and used, so the decision is made per network, not per building or per vendor.

Corporate and guest Wi-Fi on shared infrastructure

If corporate and guest SSIDs share access points, controllers or VLAN trunks with a segment that reaches the CDE, the wireless environment is usually in scope even when guests never touch payment systems. Check whether the access points and controller sit on a path to the CDE, and whether any firewall rule between the wireless segment and the CDE is in place and reviewed. Confirm this against the network diagram before deciding that guest access is out of scope.

Point-of-sale handhelds and mobile terminals

Wireless handhelds that accept or process card data, or that connect to a payment application, are clearly in scope for 2.3. Confirm which SSID each device joins, which encryption keys it uses, and who holds those keys. Staff turnover often reaches these devices first, so the list of key holders should match the device inventory.

Wireless printers and payment terminals

A wireless printer that prints receipts or reports containing account data, or a Wi-Fi payment terminal that transmits cardholder data, transmits account data and therefore falls under 2.3. A wireless printer that only prints unrelated documents on the same network may still touch the CDE through shared services. Inspect each device's network path and its vendor default settings before scoping it out.

Third-party managed access points

When a vendor or landlord manages access points that carry traffic toward your CDE, the wireless environment can still be in scope for your assessment. Contracts should state who changes vendor defaults, who rotates encryption keys after personnel changes, and who provides evidence. Ask the provider for its configuration and key-change records, and confirm responsibilities in writing before the assessment.

Scope confirmation against the inventory

Scope should be confirmed by comparing the network diagram with a current wireless inventory listing every access point, controller, SSID and connected device. Any wireless segment that appears on the diagram but not in the inventory, or the reverse, is a finding to resolve before the assessor arrives. Record the decision and its reasoning for each network so an assessor can trace it.

How an assessor tests 2.3 at the wireless layer

This table sets out how an assessor scopes wireless networks under 2.3.1 and 2.3.2, what evidence they ask for, and where organizations typically fail. Read each row as a test step paired with the artifact that proves it, so you can prepare the evidence before the assessment starts.

Assessment step	What the assessor does	Evidence requested	Common finding
Scope wireless networks	Confirms which wireless networks connect to the CDE or transmit account data, including guest, staff and maintenance networks that share infrastructure	Wireless network inventory, network diagrams, SSID and VLAN mapping, and the scoping rationale	A guest or contractor SSID left out of scope that bridges to a segment containing account data
Confirm 2.3.1 vendor defaults at install	Checks that default encryption keys, access point passwords, SNMP strings and other security-related defaults were changed or confirmed secure before go-live	Build or installation records, configuration exports, and the vendor default list used for the check	Access point admin credentials or SNMP community strings still set to vendor values on newly added units
Review SNMP and management defaults	Inspects wireless controller and access point management settings, including SNMP versions and community strings	Configuration files or screenshots showing changed strings, and documented justification for any retained defaults	No written record of which SNMP strings were changed, or a default string that is undocumented
Verify key change after personnel exit	Compares HR or access termination dates with the dates wireless keys were changed for roles that knew the keys	Leaver records, key change tickets, and the list of people who held wireless key knowledge	Keys not rotated after staff turnover because no one linked offboarding to wireless credentials
Review key change after suspected compromise	Asks how suspected or known key exposure is detected, reported and handled, then checks a sample of incidents	Incident tickets, change records with timestamps, and the incident response procedure referencing wireless keys	Keys that were reported exposed but never changed, or changes made without a record
Test configuration in practice	May review live settings or a representative sample of access points to confirm the documented state matches the device	Exported configurations, controller reports, and change logs for the sampled devices	Documentation says keys were changed, but the controller still shows the previous key on some access points
Check ownership and procedure	Confirms named roles own wireless configuration and that the steps for key change are written and followed	Procedures, role assignments and training or handover records for administrators	Key changes depend on one administrator, with no backup procedure when that person leaves

How to implement 2.3 in sequence

This sequence turns Requirement 2.3 into a scoped wireless inventory, a recorded default-change baseline, and a written key rotation procedure that your team can show an assessor. Each step produces a record that proves the wireless environment was configured and is maintained.

Inventory every wireless access point and controller
Start by listing every wireless access point, wireless controller, bridge and management interface that is connected to the cardholder data environment or transmits account data. Your network team owns the list, and a network engineer should confirm it against switch port records and controller tables, not against the floor plan alone. The output is a dated inventory with model, firmware version, location, network segment and the CDE connection each device supports. Confirm with your QSA or assessor where the boundary sits, because Requirement 2.3 applies only to wireless environments connected to the CDE or transmitting account data.
Confirm the wireless scope boundary
Map which wireless segments reach the CDE, which carry only guest or corporate traffic, and whether any wireless path could carry account data. Document the segmentation controls that separate these networks, and record who approved the boundary. The output is a short scope statement tied to the inventory, which shows that out-of-scope networks were considered and excluded on purpose. Review this statement whenever a new access point or network segment is added.
Identify vendor defaults on each device
For each device in the inventory, list its security-related defaults: default encryption keys, administrator and access point passwords, SNMP community strings and other factory settings. Pull this list from the vendor documentation and from a configuration export of each device, not from memory. The output is a default-settings worksheet per device that names each default and its current state. Your vendor's installation guide is the starting point, and you should confirm the defaults for your exact model and firmware.
Change or confirm each vendor default
Change every security-related default to a unique value that meets your password and key standards, or document why a default is already secure. Store new credentials in your approved secrets vault and remove or disable unused SNMP versions and community strings. Engineers make these changes during installation or during the hardening window, and a second person should verify each change against the device configuration. The output is a default-change record listing device, setting, prior state, new state, date, person who made the change and person who verified it.
Write the wireless key rotation procedure
Document when wireless encryption keys must be changed and who does it. The two required triggers are departure of personnel who know the key, including role changes, and any suspected or confirmed key compromise. Tie the first trigger to your HR offboarding checklist, so that a departing employee or contractor with knowledge of the key creates a rotation task. Tie the second trigger to your incident response plan, so that a suspected compromise starts a key change. The output is a written procedure with named owners, the steps to change keys on each device type, and a record template.
Test the triggers and rotate keys
Run a tabletop test of both triggers, one HR offboarding case and one suspected compromise case, and follow the procedure from start to finish. Rotate the wireless keys on each in-scope device and confirm that clients reconnect with the new key. The output is a test record showing the trigger, the timestamps, the devices changed and any gaps found. Fix any gaps in the procedure and retest the step that failed.
Record confirmations for the assessor
Collect the inventory, scope statement, default-change record, rotation procedure and test record into one evidence folder with version dates and approvals. Schedule a recurring review so that the inventory and default settings are checked when devices change and when personnel with key knowledge leave. The output is an evidence pack that your assessor can trace from each device to its configuration and its change history. Ask your QSA which format they prefer before you finalize the pack.

What meeting 2.3 costs in money and effort

The first effort is establishing what Requirement 2.3 applies to. You need an inventory of every wireless network connected to the cardholder data environment or carrying account data, then a record of the vendor defaults on each access point, controller and management console. Hardening and default changes are then carried out and documented, and the wireless encryption key procedure is written down so that staff know what triggers a change.

Scope inventory: Identify each wireless network, its SSIDs, and whether it touches the CDE or transmits account data.
Default review: Record encryption keys, administrator passwords, SNMP strings and other security-related defaults on each device, then change or confirm them.
Procedure drafting: Write the steps for key changes on departure of key holders and on suspected compromise, with named owners.
Evidence setup: Decide where configuration exports, change tickets and the procedure will be stored so an assessor can sample them.

Ask a provider to price each of these steps separately so you can see which part is your own staff time and which is external work.

Evidence that passes a 2.3 test and how to keep it current

An assessor testing Requirement 2.3 wants to see that the wireless environment is known, that vendor defaults were changed or confirmed secure, and that keys changed when they should have. The cards below cover the artifacts that prove each point and the routines that keep them accurate between assessments.

Wireless environment inventory

The inventory lists every wireless access point, controller and bridge that is connected to the CDE or transmits account data, with location, SSID purpose, owner and the network segment each one joins. Assessors start here because it defines the population for 2.3. Confirm that the inventory includes guest and staff networks if either can reach the CDE, and that it records the date of its last review. A missing access point in this list is the most common gap that undermines the rest of the evidence.

Configuration exports showing changed defaults

For 2.3.1, keep dated exports from each access point or controller showing that the default administrator password, default SNMP community strings, default encryption keys and other security-related defaults were changed at installation or confirmed secure. A screenshot without a date or hostname is weak evidence. Export configurations after each change, store them under version control, and check that the hostnames match the inventory entries.

Key change tickets linked to departures

For 2.3.2, every wireless key change should have a ticket that names the trigger: a person with knowledge of the key leaving the company or role, or a key suspected or known to be compromised. Link each ticket to the HR offboarding record or the incident record that prompted it. Assessors often sample departures from HR records and then look for a matching key change, so the two systems must share identifiers.

The documented wireless procedure

The procedure states how defaults are changed on new hardware, who approves exceptions, how keys are rotated, and which systems record each step. It should name the roles that perform each task and the trigger events that require a rotation. Review it at least once a year and after any change to the wireless architecture. Confirm that staff who perform the work follow this document and that its version history is retained.

Reconciliation against the network diagram

Compare the wireless inventory with the current network and data-flow diagrams at a fixed interval. Every access point that appears on the diagram should be in the inventory, and every wireless segment connected to the CDE should be shown with its boundary controls. Discrepancies become tickets. This reconciliation is what keeps the 2.3 scope accurate after new sites open, access points move or a segment is added to a controller.

Monitoring for unauthorized wireless devices

Scheduled wireless scans or a wireless intrusion detection tool show whether rogue access points or unexpected clients appear near the CDE. Keep the scan reports, the dates they ran, and the tickets raised for any unknown device. Note that these records support Requirement 11 testing as well as 2.3, so store them where both assessments can find them. Confirm the scan frequency and the person who reviews each report.

How self-hosted open-source tools support 2.3 evidence

Wireless access points and controllers are usually vendor-managed appliances or cloud services, so most of the evidence for Requirement 2.3 (vendor defaults changed at installation, and wireless encryption keys changed when people with knowledge leave or a key is suspected or known to be compromised) will come from the wireless platform itself and from your change and key-management records. Open-source tools rarely replace that evidence. They support the adjacent evidence an assessor will ask about: that wireless networks are kept away from the cardholder data environment, and that the endpoints administering or joining those networks are configured correctly. Plan for that split before you pick tools.

OPNsense rule and log evidence is the most direct support. If wireless segments terminate on a firewall, the rule set should show that traffic from wireless to the CDE is blocked or tightly limited by source, destination, port and protocol, using aliases for the wireless and CDE address groups. Enable logging on the rules that matter so the live log view can show matches over time. Wazuh Security Configuration Assessment can check the configuration of endpoints such as a management workstation or a RADIUS or controller host, using YAML policies that are mostly based on CIS benchmarks and can be extended with custom checks for files, registry keys and running processes. Fleet policies, written as yes or no osquery questions, can show which managed devices pass or fail a check, such as whether a laptop used to administer wireless is in an approved state.

Licensing is straightforward: OPNsense is BSD-2-Clause, Wazuh is GPL-2.0-only, and Fleet is MIT. Before you rely on any of them, confirm that the tool can actually see the wireless controller. Ask whether the controller exposes logs or configuration through a syslog feed, SNMP, API or agent that the tool can read, and test whether a change to a default setting or key is visible in the evidence. If it is not, the evidence must come from the controller's own records. Ask your QSA which combination of system output and screenshots they will accept before you build the evidence pack.

Who does what for 2.3: your team, a partner and the QSA

Your organization owns requirement 2.3 in full. Scope applies only to wireless environments connected to the cardholder data environment or that transmit account data, so your team must first decide which access points, controllers and wireless segments meet that test. Once scope is fixed, your staff apply the vendor default changes, set the wireless encryption keys, and decide when a rotation is triggered. The assessor will ask who holds the authority to make these decisions and whether they act on them.

Scope decisions: Record which wireless networks touch the CDE or carry account data, and which do not, with the reasoning.
Default changes: Change or confirm vendor defaults such as encryption keys, administrator passwords and SNMP strings at installation.
Key rotation triggers: Define who must tell the team when someone with key knowledge leaves the company or changes role, and when a key is suspected or known to be compromised.
Operational records: Keep dated change records showing when keys were changed and why.
Ownership: Name the accountable role for each step so the assessor can trace each control to a person.

Check that your team can show the rotation trigger and at least one executed change record before the assessment begins.

Where organizations usually fall short on 2.3

Requirement 2.3 is small on paper but fails in practice for predictable reasons: keys nobody rotates, guest traffic that reaches the cardholder data environment, and access points that appear outside the change process. The cards below cover the gaps assessors most often find and the closing action for each.

Shared keys never rotated after staff leave

Wireless encryption keys and pre-shared passphrases often sit with help desk staff, contractors and former employees long after their roles end. Requirement 2.3.2 treats departure from the company or role as a trigger for key change, so a key that outlives the people who knew it is a direct gap. Check the date of the last key change against your leaver list and confirm that each network has a named owner for rotation.

Guest networks bridged to the CDE

Guest and visitor wireless often shares hardware, controller or VLAN configuration with corporate segments. If a bridge, trunk or misapplied VLAN tag lets guest devices reach systems in or connected to the CDE, the wireless environment falls into scope for 2.3. Test from a guest client that no route exists to payment segments, and review the access point configuration for trunked VLANs that should not carry guest traffic.

Unmanaged access points added by facilities

Facilities, retail operations or contractors sometimes install access points or extenders to fix coverage problems without involving the security team. These devices may still use vendor default passwords, SNMP defaults or old keys, and they may connect to the CDE network without anyone recording them. Compare wireless discovery results with the asset inventory, and ask facilities to route all installations through the same change process as other network equipment.

Vendor defaults left on new equipment

Requirement 2.3.1 expects vendor wireless defaults, including encryption keys, access point passwords and SNMP community strings, to be changed at installation or confirmed as secure. Teams often apply a configuration template and move on, or assume a managed service has handled it. Check each access point's build record for a signed-off default review, and confirm that the provider's configuration is documented if someone else manages the controller.

No trigger linking HR and incidents to keys

Key changes depend on events that happen in other departments. When HR offboarding, role changes or incident response do not notify the network team, the key rotation step never happens, even when the procedure exists on paper. Map the leaver checklist, the change of role process and the incident response playbook to a named wireless task, and test the chain with one sample departure to confirm that a key change record results.

Questions buyers ask about 2.3 cost, effort and outside help

Can we meet requirement 2.3 in-house without an outside partner?

Yes, in principle. Requirement 2.3 is narrow, and the organization owns its controls, so an internal team can change wireless vendor defaults and manage encryption keys without a partner. The question is capacity and records. Your team needs to know which wireless environments connect to the cardholder data environment or transmit account data, because 2.3 applies only to those. It also needs a way to show, on demand, that defaults were changed or confirmed secure at installation and that keys were rotated after staff departures or suspected compromise. If the people who hold that knowledge are few, or the wireless estate is spread across many sites, an outside partner can help with the work, but the organization still makes the decisions and keeps the evidence.

What actually drives the effort for wireless configuration work?

The main drivers are the number of wireless environments in scope, the number of access points and wireless controllers, and how many people hold knowledge of the encryption keys. Each access point or controller must have its vendor defaults reviewed, including default encryption keys, administrative passwords and SNMP settings, then either changed or documented as secure. Key management effort rises with staff turnover, because each departure or change in role that touches key knowledge triggers a key change under the requirement. Effort also rises when wireless networks are not documented, since the assessor will expect you to show which networks are connected to the CDE. Ask any provider to break its estimate down by site, controller and key-holder group.

How long does requirement 2.3 work take to complete?

The duration depends on the number of sites, wireless controllers and access points in scope, and on whether defaults and key records already exist. No duration figure is supplied for this requirement, so treat any number you hear as unverified. A small, single-site environment with a documented inventory will move faster than a multi-site estate with undocumented controllers. Plan around the work that cannot be shortened: inventorying wireless networks, confirming which ones touch the CDE, changing or verifying each vendor default, and setting a procedure that triggers key changes. Ask your team or a provider to show a written plan with milestones tied to sites and controllers, and confirm timing with your assessor before committing to a date.

What does the team need to provide for requirement 2.3?

The team needs four things: an accurate inventory of wireless networks and the systems they connect to, administrative access to each controller and access point, a named owner for key rotation, and a record of who knows the current keys. Network staff must be able to change or verify vendor defaults on each device and document the result. HR or the people managing role changes must notify the key owner when someone with key knowledge leaves or changes role, so a key change can be scheduled. Security staff should set the procedure for suspected or known compromise. Document each of these as it happens, because the evidence has to show the process ran, not only that it exists.

Can an implementation partner prepare the evidence for requirement 2.3?

A partner can prepare systems and evidence, but it cannot validate compliance. Under DeployOpen's model, the organization owns its controls, a partner prepares the configuration changes, inventories, key-change procedures and records, and only an independent assessor issues the report or attestation. For requirement 2.3, a partner could document the default-setting review for each controller, set up a repeatable key-change procedure and produce the wireless inventory your assessor will request. Agree in writing which records the partner produces, who signs them off, and where they are stored. Keep the assessor's role separate from the implementer's role throughout the engagement.

Will a QSA accept records that our own team prepared?

Yes, provided the records are accurate, dated and show that the process was followed. The Self-Assessment Questionnaire D for Service Providers asks whether vendor defaults for wireless environments were changed at installation or confirmed secure, and whether keys are changed when people with knowledge leave or a key is suspected or known to be compromised. Those questions are answered from evidence, so your records should show the specific changes, the dates, the people involved and the approvals. Whether a particular assessor accepts a particular record format is a matter for that assessor, so confirm the expected format before you build the records. Remember that a certificate or a letter from a consultant is not a validation of compliance.

What risks come with doing requirement 2.3 ourselves?

The main risks are missed devices, undocumented key changes and gaps in the link between staff departures and key rotation. A wireless controller that nobody inventoried can keep a default password for years without anyone noticing. Key changes that depend on one person remembering to act are easy to miss when that person is absent. Mitigate these by keeping a current wireless inventory tied to CDE connectivity, adding key rotation to your offboarding and role-change checklists, and reviewing the list each time the network changes. If your team cannot keep these running, consider a fixed-scope engagement with a written deliverable list, and keep control of the final evidence in your own hands.

Which open-source tools can help with wireless configuration evidence?

Open-source tools can help with the surrounding configuration evidence, but none of them replaces the wireless controls themselves. Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation, which helps with ongoing configuration checks on hosts that manage wireless. Fleet policies ask yes or no questions of devices as osquery queries and show which devices pass or fail, which helps verify baseline settings on managed endpoints. Confirm with each vendor whether a specific wireless controller or access point can be monitored by these tools before relying on them. Keep the tool output as part of your evidence, alongside the inventory and key-change records.

What DeployOpen does and does not do for 2.3

DeployOpen prepares the wireless environment and its evidence, but it does not validate it. Under a fixed-scope written agreement, DeployOpen can help you define which wireless networks are connected to the cardholder data environment or transmit account data, then harden the self-hosted controller, access points and management plane to the vendor-default changes that 2.3.1 expects. The same work produces the records an assessor will ask for: the wireless inventory, the configuration baseline, the record of each default changed or confirmed secure, and the log of when wireless encryption keys were rotated and why. Scope, deliverables and timelines are agreed before work starts, so you know in advance which items are in and which remain with your team.

The 2.3.2 key-change obligation is an operating process, not a one-time project. DeployOpen can design the trigger procedure, document who must be told when a person with key knowledge leaves a role, and set up the change steps so that rotation is repeatable. What it cannot do is decide that your keys are safe to keep, sign off on a compromise assessment, or act as the owner of the control. Those decisions stay with your security leadership, and the rotation history must be produced from your own systems.

DeployOpen does not issue Reports on Compliance, Attestations of Compliance or certificates. Only a Qualified Security Assessor completing a ROC, or a Self-Assessment Questionnaire with its Attestation of Compliance where that route applies, provides validation, and the payment brands decide which entities must validate. Ask your QSA early whether they will accept the wireless evidence in the form you plan to produce it, and confirm the current SAQ or ROC template against the PCI SSC standard page before finalizing your evidence set.

How DeployOpen scopes and prepares 2.3 evidence

DeployOpen works on 2.3 Wireless environment configuration as part of a self-hosted platform build inside your own infrastructure. We first confirm which wireless networks touch the cardholder data environment or carry account data, then prepare the vendor-default and key-change evidence your assessor will ask to see. Your organization keeps ownership of the control and of the assessment decision.

How we scope

Confirm which wireless networks connect to the CDE or transmit account data, and document those that do not
List every access point, controller and wireless management interface in the written scope
Agree in writing which vendor defaults must change at installation and which will be confirmed secure
Define who owns key rotation triggers, such as staff departures and suspected compromise

How we build

Replace wireless vendor defaults, including encryption keys, administrator passwords and SNMP community strings, on in-scope devices
Configure wireless segmentation so in-scope networks reach the CDE only through the firewall rules set under Requirement 1
Set up a documented procedure for rotating wireless encryption keys and test it on a non-production network first
Enable configuration assessment checks on wireless controllers so drift from the hardened baseline is visible

How we hand over

Provide a dated inventory of in-scope wireless devices with the configuration state recorded for each
Deliver a key-change runbook with trigger conditions, responsible roles and a log template for each rotation
Document test results showing that default credentials were changed and that the new keys work across the network
Hand over the evidence set to your internal team and your independent QSA, who decides whether it meets the requirement

How we support

Fixed-scope engagements define deliverables and timelines in writing before any configuration work starts
Ongoing support is available as a retainer for key rotations, configuration reviews and upgrades to wireless firmware
Your team can request re-testing after staff changes or a suspected compromise to refresh the evidence
A quote follows from the written scope, so ask for the wireless device list and network diagram before requesting one