Which wireless approach to choose first, and when to combine them
Start with wireless access point scanning if you do not yet have a reliable inventory of your wireless estate, and start with wireless penetration testing if you already know every access point and need to know whether its controls hold under attack. Scanning proves what is on the air and whether anything unauthorized is present. Penetration testing proves whether the authentication, encryption and segmentation controls resist an attacker. If you are in PCI DSS scope with wireless networks, the first purchase depends on which of those questions your assessor and your records cannot yet answer.
Scanning is usually the right first purchase when the authorized access point inventory is incomplete, when no one has checked for rogue devices or unauthorized SSIDs in the last quarter, or when the wireless network sits near a cardholder data environment and its boundaries are undocumented. PCI DSS requirement 11.2.1 asks for methods that detect both authorized and unauthorized devices, and requirement 11.2.2 asks for an inventory of authorized access points with business justification. Confirm with your assessor whether they expect passive monitoring, active scanning or both, and whether alerts must reach personnel. Penetration testing is the better first purchase when the inventory is current and the open question is whether the configured settings, such as WPA3 modes, management frame protection, guest isolation and firewall rules between wireless and cardholder segments, can be defeated. Confirm the encryption and authentication settings your access points actually use before scoping that test.
Most organizations combine the two. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and the same logic applies here: scanning finds the access points and devices that the penetration test must include, while the test shows whether those devices can be abused. A practical sequence is to complete an inventory and rogue scan, reconcile the results against the access point list, then scope the penetration test against the validated list and the segmentation boundary. Ask the provider to state in writing which devices are in scope, which tests touch live clients, and how any rogue device found during testing will be handled.
Side-by-side: scope, method, access and evidence
This table compares what a wireless access point scan and a wireless penetration test each set out to do, from goal and method to access, transmitted traffic and deliverable. Read it as two different questions: is there an unauthorized device in the air, and can an attacker get past the wireless controls that protect the network.
| Dimension | Wireless access point scanning | Wireless penetration test |
|---|---|---|
| Primary goal | Detect and identify authorized and unauthorized access points, including rogue devices attached to authorized ones (PCI DSS 11.2.1) | Determine whether authentication, encryption and segmentation can be defeated and what an attacker reaches from the wireless side |
| Method | Passive monitoring, or scanning that listens to the radio environment without attaching to discovered devices | Active attachment to discovered devices to test authentication, encryption and administration access settings |
| Transmits to target devices | Nothing, per NIST SP 800-115 wording on passive wireless scanning | Traffic and test payloads directed at the target access points and clients |
| Access required | Physical proximity within radio range; no credentials or network accounts | Radio range plus authorized test credentials or client access where the scope requires them |
| Question it answers | Is every access point and SSID on the air one the organization knows about? | Can an attacker bypass the wireless security controls and reach internal systems? |
| Typical scope | Whole site or facility footprint, including areas near the perimeter where unexpected signals may appear | Named SSIDs, access point groups and the segments they connect to, agreed in the rules of engagement |
| Output a buyer receives | Inventory of observed devices, unexpected MAC address vendors or SSIDs, and alerts routed to personnel | Validated findings on authentication, encryption and segmentation, with evidence and remediation steps |
What access point scanning proves under PCI DSS 11.2.1
Access point scanning answers one question: does the organization know every wireless device in scope, and would it notice one it did not expect? PCI DSS requirement 11.2.1 asks for methods that detect and identify both authorized and unauthorized wireless access points, including an unauthorized device attached to an authorized one, and requires alerts to personnel when automated monitoring is used. Requirement 11.2.2 is the paired record: an inventory of authorized access points, with a business justification for each. Read together, the two requirements expect you to hold a current list, to detect anything that is not on it, and to be able to say why each approved device exists. Confirm with your assessor which tools and frequency they will accept for the detection method, and whether they expect a documented alert path for automated monitoring.
Passive scanning is the usual first method because it transmits no data. NIST SP 800-115 describes it as listening to wireless traffic, which means the scanner does not attach to or probe the devices it sees. It is run regularly and supplements wireless intrusion detection. Its typical findings are practical: a device whose MAC address vendor does not match the hardware you bought, or a broadcast SSID that nobody on your change list recognizes. A passive scan can show that a device exists and is broadcasting. It cannot show how that device is configured, so a rogue device found this way still needs to be located, identified and removed through your own procedures.
A scan does not test how the approved access points are secured. It does not check whether the authentication method is weak, whether the encryption configuration is acceptable, or whether a guest network can reach the cardholder data environment. Those questions belong to a wireless penetration test, which attaches to devices and tries to break them. If your environment uses WPA3, the Wi-Fi Alliance's security overview describes the properties your configuration should show, which a scan cannot verify. Ask your team to document, for each access point, which findings a scan covers and which a penetration test must cover.
What each approach finds and what it misses
Wireless access point scanning and wireless penetration testing answer different questions about the same airspace. The cards below show where each one stops, so a team can see which gaps the other method must cover.
Rogue and unlisted devices
Passive and active scans find access points and SSIDs that are not in the authorized inventory, including devices plugged into the wired side of an authorized network. NIST SP 800-115 describes passive scans that flag rogue devices from unexpected MAC address vendors or unauthorized SSIDs. Check that alerts reach personnel and that every finding is matched against the inventory required by PCI DSS 11.2.2, with business justification for each authorized access point.
Weak WPA configuration
A scan usually reports which security mode an access point advertises, but not whether the configuration can withstand an attack. Active testing attaches to discovered devices and checks authentication and encryption settings directly. Ask the tester to confirm the WPA mode in use, whether WPA3-Personal is enforced where supported, and whether Protected Management Frames are required. Wi-Fi Alliance guidance on WPA3 is a useful reference for these checks.
Administration access exposure
Active wireless testing also checks how access points are managed, including administrative interfaces reachable over the wireless network, default credentials and management protocols. Passive scanning cannot see these settings because it transmits nothing to the device. Ask for a list of management interfaces that were tested and whether any were reachable from a guest or low-trust SSID.
Segmentation gaps
A penetration test can show whether a wireless client on a guest or corporate SSID reaches systems it should not, such as the cardholder data environment. A scan can identify the SSID but cannot prove what traffic is permitted beyond it. PCI DSS 11.4.5 requires segmentation controls to be penetration tested at least every 12 months, so confirm the wireless segments are inside that test's scope.
Devices outside the test window
A penetration test is a point-in-time exercise against the scoped access points. A device placed in a lobby, a rogue hotspot brought in by staff, or an access point added after the test window will not appear in its results. Only regular passive monitoring covers that gap, which is why NIST SP 800-115 pairs passive scanning with periodic active testing. Ask how often scans run and who receives their alerts.
Combining both methods
Scanning keeps the inventory current and catches new or unexpected devices between tests. Penetration testing confirms that authentication, encryption, administration and segmentation hold up against an attacker. Use the scan to decide what the penetration test must include, and use test findings to tune the scan's detection rules. Ask the provider to show how each method's results map back to PCI DSS 11.2.1 and 11.4.5.
How a wireless penetration test moves from discovery to attack
The sequence turns an agreed scope into evidence on whether discovered access points can be abused, starting from passive observation and ending with a report that separates inventory findings from proven attack paths.
Agree scope and rules of engagement
The client and the tester agree which sites, SSIDs, access points, controllers and wired segments are in scope, which techniques are allowed, when testing happens, and who to call if something breaks. NIST SP 800-115 provides a rules of engagement template in Appendix B that teams commonly adapt for this. The step is complete when the signed document names the permitted active tests, the exclusions, and the emergency contacts.
Run passive discovery of access points and clients
The tester listens to wireless traffic from within the defined locations and records access points, SSIDs, channels, client devices and the MAC address vendors seen. Passive scanning transmits no data, so it can run alongside normal operations. Unexpected vendors and unauthorized SSIDs are flagged as candidate rogue devices. The step closes with a raw inventory that the client reconciles against its approved access point list.
Attach to discovered devices in scope
Only the devices named in the rules of engagement are approached actively. The tester connects or interacts with them to read configuration details that passive capture cannot show, such as the security modes offered and whether administration interfaces respond. Candidates outside scope are reported but not touched. The step closes when each in-scope device has a recorded configuration profile.
Validate authentication and encryption
The tester checks which authentication methods each network accepts, whether weaker legacy modes are still offered, whether management frames are protected, and how resistant pre-shared keys and enterprise credentials are to guessing or capture-based attacks within the agreed limits. Findings are tied to the specific SSID and device. The step closes with a pass or fail note per control, backed by captured evidence.
Test segmentation from the wireless side
From a wireless foothold, the tester attempts to reach systems that should sit behind the wireless boundary, such as cardholder data environments or management networks, and checks whether guest and corporate networks are isolated. This tests whether segmentation controls hold under attack, which PCI DSS requirement 11.4.5 expects to be penetration tested at least every 12 months where segmentation is relied upon. The step closes with a list of reachable and blocked paths.
Report inventory gaps and proven attack paths separately
The report separates findings from the passive inventory, such as unknown devices, from findings proven by active testing, such as a weak mode that allowed access. Each finding records the evidence, affected devices, the scope it was tested under, and the remediation owner. The step is complete when the client can match each unauthorized device to an action and each proven weakness to a fix or retest.
What to verify on WPA3 and protected management frames
A wireless penetration test does not stop at finding access points. It checks whether the authentication and frame protection on each network hold up under attack. The cards below cover the settings a tester verifies on WPA3 networks, and each one should be confirmed against your own controller configuration rather than assumed from the product name.
Confirm WPA3-Personal is in use
Start by recording which security mode each SSID actually advertises, including guest and IoT networks that are often configured separately from corporate ones. The Wi-Fi Alliance states that WPA3 is mandatory for Wi-Fi CERTIFIED devices, but that certification describes what a device can support, not how your network is set. Check the mode on every controller profile and on the access point overrides, since a single site can differ from the template.
Verify SAE as the authentication method
WPA3-Personal uses Simultaneous Authentication of Equals (SAE) in place of the pre-shared key exchange used by WPA2. A tester checks that SAE is the only personal authentication method offered, because a transition mode that also accepts WPA2 keeps the older exposure open. Ask the team to confirm the exact setting on each controller, since the label used in the management interface varies by vendor.
Require Protected Management Frames
Protected Management Frames (PMF) protect management traffic such as deauthentication and disassociation from forgery. The Wi-Fi Alliance states that WPA3 networks must use PMF, so a WPA3 network with PMF disabled is a configuration problem to report. During an active test, the tester attempts to disrupt clients on the network, and the result shows whether PMF is enforced or only optional.
Disable legacy and fallback modes
Transition modes that allow WPA2 clients to join a WPA3 SSID can be useful during migration, but they also let an attacker push clients toward the weaker option. Check that open networks, WEP, WPA and mixed WPA2 or WPA3 modes are removed from production SSIDs, or that they are isolated and documented. Confirm the result with the controller export rather than the wireless setup wizard, which may enable fallbacks by default.
Check the management and segmentation path
A correct cipher setting does not protect a network that is bridged into the wrong VLAN or that accepts management access from client subnets. Test whether the wireless controller admin interface is reachable from user networks and whether guest SSIDs can reach internal ranges. These findings belong to a penetration test rather than a passive scan, because they require sending traffic across the boundary. Confirm the segmentation design with your network team before testing.
What you receive from each approach
This table compares the records each approach hands back, from a device inventory and alert log to a validated attack-path report. Read it to confirm which artifacts your assessor and your security team will actually receive, since the exact formats depend on the statement of work.
| Deliverable | Wireless access point scanning | Wireless penetration test |
|---|---|---|
| Core output | Device inventory reconciled against the authorized access point list | Scoped report of validated findings and the wireless attack paths that worked |
| Unauthorized devices | Rogue device alerts, including devices attached to authorized ones, with the detection method noted | Only the rogue devices the tester encountered or was asked to hunt, reported as scope evidence |
| Alert handling | Evidence that alerts reached personnel and how each one was triaged and closed | Not a primary output; alert response may be observed and recorded during the test |
| Technical evidence | Scan logs, device records with vendor and SSID data, and timestamps for each run | Captured evidence of authentication, encryption and administration tests, with reproduction steps |
| Remediation guidance | Usually limited to removing or authorizing a device and updating the inventory | Specific fixes for weak authentication, encryption, management access and segmentation, with retest plans |
| Rules of engagement | Scan window, permitted scope and contact list, often short-form | Signed rules of engagement record covering targets, permitted techniques, time windows and stop conditions |
| Confirm before signing | Report format, retention period for scan data, and whether alert records are included | Report template, retest terms, and whether attack-path narratives and raw captures are delivered |
What drives cost and effort for each approach
Both approaches are priced on the same few variables: how much physical estate is covered, how often it is checked, and how much testing the client allows. The cards below show who is paid for what, which costs are one-time and which recur, and what to put in writing before asking for a quote.
Number of sites and access points
Passive scanning costs grow with the number of locations, because sensors or survey time must cover each floor, building and radio environment. A penetration test scales with the number of networks and wireless segments that are actually attacked, so a large estate does not automatically mean a large test. Ask the provider how many sites, access points and SSIDs each price assumes, and whether a sample of sites is proposed for active work.
Continuous or periodic monitoring
Continuous passive monitoring is a recurring cost for sensors, licenses and staff who review alerts, and it is usually bought from a platform or managed service. Periodic scanning is a recurring engagement that the client schedules and the provider runs on a set cadence. NIST SP 800-115 recommends passive scans regularly to supplement wireless intrusion detection, so the choice is about who reviews the output and how fast alerts must be handled.
SSIDs and segments in scope
Each SSID, VLAN and wireless-to-wired boundary adds test cases for authentication, encryption, guest isolation and segmentation. Testing a flat guest network is a short exercise, while a corporate network that bridges into cardholder data needs the segmentation path tested as well. Ask which SSIDs and segments are in scope, which ones are excluded with a reason, and whether the segmentation test is priced separately from the wireless test.
Active testing in production
Active testing connects to discovered devices, checks authentication and administration settings, and can disrupt users or clients if it is run during trading hours. Providers often charge more for production windows, out-of-hours staffing and rollback planning, and the client may need to pay for a staging copy of the network. Confirm in writing whether active tests may run on production radios, which hours are allowed, and who stops the test if clients are affected.
Reconciliation against an authorized inventory
PCI DSS requirement 11.2.2 expects an inventory of authorized access points with a business justification, and requirement 11.2.1 expects unauthorized devices to be detected and alerted. Reconciling scan results against that inventory is internal work for the client's network and security teams, and it recurs each quarter as devices change. An inventory that is incomplete at the start turns the first scan into a large one-time cleanup, so ask who builds the baseline and who owns updates.
Questions buyers ask about wireless testing and scanning
Which one does an assessor ask for under PCI DSS 11.2.1 and 11.4.5?
Requirement 11.2.1 asks for a method that detects and identifies authorized and unauthorized wireless devices, so assessors expect wireless access point scanning on a recurring basis. Requirement 11.4.5 is different: it requires segmentation controls to be penetration tested at least every 12 months, which is a separate test of whether the segmentation holds under attack. Most assessors therefore look for both, and they will ask you to show the scan results and the penetration test report as distinct evidence. Confirm the exact evidence format with your assessor or qualified security assessor before the assessment.
Does automated wireless scanning alone satisfy the penetration testing requirement?
No. The PCI SSC's Penetration Testing Guidance, version 1.1 from September 2017, describes penetration testing as essentially a manual process and states that simply running an automated tool does not satisfy the penetration testing requirement. A scan can show that an access point exists and whether it is authorized, but it does not show whether an attacker can break the WPA3 or WPA2 authentication, reach the cardholder data environment through the wireless segment, or abuse administration access. Scanning answers the detection question. A penetration test answers the exploitation question, and the two are not interchangeable.
How often should each one run?
Passive scanning should run regularly and supplement wireless intrusion detection, according to NIST SP 800-115, and PCI DSS 11.2.1 is the basis for the recurring rogue device check in a cardholder environment. Active penetration testing against segmentation is required at least every 12 months under requirement 11.4.5. Many teams also re-test after significant changes to the wireless or segmentation design, a practice that is good engineering but not a fixed PCI DSS interval. Confirm the scan cadence your assessor expects for your environment before you set a calendar.
What does the work need from our team?
Both methods need an accurate inventory of your wireless estate, the authorized access point list required by requirement 11.2.2, and a named contact who can approve active testing windows. A penetration test also needs defined rules of engagement covering which SSIDs, controllers and client networks are in scope, what authentication attacks are allowed, and how a tester should stop if a production service degrades. Your team should expect to review findings, confirm which devices are authorized, and remediate misconfigurations. Ask the provider which artifacts they need from you before work starts.
Can our in-house team run the scanning ourselves?
Often yes for passive detection, provided the team has wireless monitoring tools, a current authorized inventory, and a process to investigate and act on alerts. PCI DSS 11.2.1 requires alerts to personnel when automated monitoring is used, so the people receiving those alerts must be named and trained. Active testing is harder to bring in-house, because it touches devices and needs a tester who can attack authentication, encryption and administrative access without disrupting service. Confirm your team's skills against the wireless test scope before deciding, and note that an independent test is commonly expected for the penetration testing requirement.
What drives the cost of each engagement?
Cost depends on the number of sites, access points, controllers, SSIDs and client networks in scope, the number of locations that need physical walkthroughs, and whether the work includes active attacks on authentication and segmentation. Scanning is usually a recurring operational cost, whether run by your staff or a provider, plus the tooling and alert handling. A penetration test is a scoped, usually one-time engagement that recurs on your compliance cycle, and its price rises with the depth of segmentation testing and the amount of retesting. DeployOpen does not publish prices. A quote follows from the written scope.
What should we ask for in a quote?
Ask for a written scope that names the sites, wireless networks, controllers and segmentation boundaries in and out of scope, along with the methods used, passive, active or both. The quote should list deliverables, including the device inventory, the list of rogue or unauthorized devices, the attack paths tested against WPA3 or WPA2 authentication and encryption, and a report that separates scan findings from penetration test results. Ask how active testing windows, rules of engagement and emergency stop procedures are agreed, who performs the work, and what retesting is included. Also ask how evidence will be packaged for your assessor. DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
What does WPA3 change for what a penetration test checks?
WPA3 changes the authentication and management protections a tester should verify. The Wi-Fi Alliance states that WPA3 is mandatory for Wi-Fi CERTIFIED devices, that WPA3-Personal uses Simultaneous Authentication of Equals, and that WPA3 networks must use Protected Management Frames. A tester should confirm these protections are enabled and that legacy modes are not still accepted on the same SSID, because a transition mode can keep older weaknesses reachable. Passive scanning cannot confirm this on its own, so the active portion of a test is where this is verified. Check the current Wi-Fi Alliance guidance and your vendor's configuration documentation for the exact settings.
Which one an assessor asks for and why
An assessor asks for both, because they answer different PCI DSS questions. Requirement 11.2.1 asks whether you can detect and identify authorized and unauthorized wireless devices, including rogue devices attached to authorized ones, and requirement 11.2.2 asks for an inventory of authorized access points with business justification. Access point scanning, passive or active, is the method that produces that evidence: a scan log, the inventory it is checked against, and the alert records if automated monitoring is in place. Wireless penetration testing is a different exercise. Under PCI SSC guidance, wireless networks sit within network-layer penetration testing, and segmentation controls must be penetration tested at least every 12 months under requirement 11.4.5. A scan that shows an access point exists does not show whether its authentication or encryption can be broken, or whether a wireless segment can reach the cardholder data environment.
Assessors check evidence against each requirement separately, so a sample report from one exercise will not satisfy the other. For the scanning side, ask your qualified assessor which scan outputs, inventory records and alert samples they will sample, and whether passive monitoring results are accepted as the detection method. For the penetration side, ask how they expect the test to treat wireless as a network layer, which scope and rules of engagement they need, and whether the segmentation test under 11.4.5 must include wireless paths from guest or unmanaged networks. Confirm these expectations in writing before purchase, since the required depth and format depend on your environment and the assessor's own methodology, not on this page.
Plan the two exercises as complements. Passive scanning can run continuously and should feed your wireless intrusion detection, while active testing against authentication, encryption and administration settings is a scheduled, scoped engagement with a named tester. If your budget covers only one exercise this year, the gap is usually visible in your evidence: no inventory with justification points to 11.2.2 work, and no segmentation test covering wireless points to 11.4.5 work. Check which of those gaps your assessor has already flagged before deciding.
How DeployOpen scopes and delivers wireless security testing
DeployOpen plans and runs wireless security work inside the client's own sites and networks, with the scope written down before any testing starts. Teams that need both an access point inventory and an attack-based test can agree one written scope that covers both, so the findings line up with what the assessor will ask to see.
How we scope
- The written scope names the sites, SSIDs, controllers and wireless segments in play before any testing starts.
- Rules of engagement cover permitted active techniques, testing windows, and who on the client side is notified during active work.
- The scope states whether the work is a passive rogue access point scan, an active penetration test, or both, and why.
- Fixed-scope engagements agree deliverables and timelines in writing, and any ongoing support is offered as a retainer.
How we build
- Passive survey of the airspace records authorized and unexpected access points, with MAC address vendors and SSIDs logged for review.
- Active testing checks authentication, encryption, management access and whether wireless segments reach the cardholder data environment.
- Each test step maps to the agreed scope, so every finding traces back to a defined target and technique.
- Test traffic and any device changes are logged so the client can match them against its own monitoring alerts.
How we hand over
- The report separates the authorized access point inventory from unauthorized or unexpected devices found during the survey.
- Each finding records the technique used, the affected asset, the evidence captured and the steps needed to reproduce it.
- Remediation guidance covers configuration changes, detection rules and segmentation fixes, with owners named for each item.
- A handover session walks the client's security and network teams through the results and the open questions for the assessor.
How we support
- Ask for a written record of which access point inventory and which penetration test evidence the assessor will request.
- Retesting after fixes can be scoped as a follow-up, with the same method and rules of engagement as the original work.
- Ongoing support, upgrades and continuous testing are available as retainers for teams that repeat wireless checks.
- Confirm with your assessor which evidence format they accept before work begins, since requirements differ by assessor.
