Why wireless security testing matters when Wi-Fi is already inside your perimeter
If a compliance framework, a customer security review, a product launch or an insurer has asked you to show that Wi-Fi cannot be used to reach internal or cardholder systems, the answer has to come from testing the wireless network itself. Wireless access is an entry point into your network, so it must be tested as one. Network segmentation and firewall rules on paper do not prove that a device joined to a guest SSID, a rogue access point or a misconfigured corporate SSID cannot reach a file server, a payment application or a cardholder data environment. The risk falls into a few categories: weak encryption and authentication modes, such as a WPA2-only network where WPA3 or 802.1X was intended; rogue and lookalike access points that impersonate a corporate SSID; guest bridging, where guest traffic shares a VLAN or gateway with staff traffic; and wireless-to-internal paths that exist because of routing, DNS or controller settings.
Wireless is also a physical attack surface. Signals reach past the walls of an office, a store or a warehouse, so the tester must work on site, from locations an outside attacker could realistically occupy, and must find access points that were installed without approval. NIST SP 800-115, the *Technical Guide to Information Security Testing and Assessment*, lists wireless scanning as a target identification and analysis technique, which means it is the discovery step that tells you what radio coverage actually exists before any validation begins. Ask the provider how it will inventory radios across every site and floor, and how it will record the locations it visited and the signal range it measured.
Before commissioning the work, confirm three things in writing: which SSIDs, controllers and VLANs are in scope, whether the test may join guest and corporate networks with test devices, and which systems count as the boundary you need to prove. Those answers determine whether the result can serve an auditor or customer as evidence. Also confirm who in your organization approves on-site access and who receives the findings, because wireless testing often touches facilities, guest operations and network teams at once.
What can be in scope for a wireless test
Wireless scope is set by where radio coverage reaches, which networks are broadcast, and what those networks can talk to once a device joins. Each decision below changes the test plan, the access the tester needs and the evidence the client receives. Agree them in writing, along with the rules of engagement, before any on-site work begins.
Physical sites and boundaries
Scope starts with the buildings, floors, car parks, warehouses and outdoor areas where radio signal can be received. Walls, neighboring tenants and public spaces all shape what a tester can reach, so the written scope should list each site, its address or floor plan, and the areas where signal leaks beyond the property line. Ask whether a test covers only company premises or also the surrounding public area, and who authorizes testing in shared or leased space.
SSIDs, VLANs and network mapping
Each broadcast network name, or SSID, should be mapped to the VLAN, subnet and firewall policy behind it. This mapping shows whether a corporate SSID, a guest SSID and an IoT SSID are truly separate, or whether they share a segment. Ask the client for the current wireless design document and a list of every SSID, including retired or hidden ones, so the test checks what is actually deployed rather than what the design says.
Corporate, guest and IoT networks
Corporate, guest and IoT networks carry different trust levels and usually need separate test cases. Guest isolation is checked against internal subnets, management interfaces and other client networks. IoT networks, including printers, sensors, badge readers and building controls, often use weaker authentication and are tested for reach into business systems. Confirm which of these networks are in scope and whether each one needs its own pass/fail criteria.
Authentication back ends
Enterprise SSIDs using 802.1X hand authentication to a RADIUS server, which in turn may check an identity provider or directory. The RADIUS servers, their certificate trust settings, and the identity source behind them are all part of the wireless attack surface. Confirm which RADIUS servers, certificate authorities and identity sources are in scope, and whether the test includes the directory or identity provider itself or only the wireless interaction with it.
Wireless controllers and management
Wireless controllers, cloud management consoles and access point management interfaces decide how every access point is configured and updated. Scope should name each controller, its software version, the management network it sits on, and the administrative accounts that reach it. Ask whether the test includes configuration review of the controller and whether it is limited to observing wireless behavior from the air and from connected clients.
Cardholder environment segments
If any wireless network reaches a cardholder data environment, the test must cover the path from wireless into that segment. PCI DSS requirement 11.4.1 treats testing from inside the network, including into the CDE from untrusted internal networks, as part of penetration testing, and segmentation testing under requirement 11.4.5 confirms that isolation holds. Confirm in writing whether wireless is inside or outside the CDE boundary, and whether a segmentation test is included in this engagement.
How a wireless engagement runs from planning to retest
The sequence moves from agreed rules and scope through on-site discovery and validation to a report that shows which wireless paths reach internal or cardholder systems, and a retest that confirms the fixes. It follows the four phases NIST SP 800-115 describes, with target identification and vulnerability validation kept distinct.
Agree rules of engagement and written approval
The tester and client document the sites, buildings, SSIDs, wireless networks in scope, testing windows, permitted techniques and emergency contacts before any radio work starts. NIST SP 800-115 treats this planning phase as the point where rules are identified and management approval is documented, and its Appendix B provides a rules of engagement template to adapt. Ask whether the test is overt (IT staff aware) or covert (staff unaware, management approved), since that choice changes what the results show. The step is done when the signed rules of engagement name every network and the people authorized to approve changes to them.
Inventory wireless networks and access points on site
The tester walks the premises with passive and active wireless scanning to identify every SSID, BSSID, channel, band and visible access point that broadcasts into the environment. This is target identification under NIST SP 800-115's review and analysis techniques, and it produces a map of what the organization actually broadcasts, which often differs from its asset register. Results are compared with the client's list of approved access points so unknown devices are flagged early. The step closes when the inventory is reconciled with the client, and each unexplained device is either assigned an owner or queued for rogue checks.
Review encryption and authentication configuration
For each in-scope network, the tester records the security mode and checks it against the Wi-Fi Alliance's published WPA3 requirements, including SAE for WPA3-Personal, the 192-bit security mode for WPA3-Enterprise, and Protected Management Frames. For 802.1X networks, the review covers the authentication server, certificate validation on client devices, the EAP method and how guest or legacy modes coexist with the enterprise SSID. Where the client supplies controller or RADIUS configuration, the tester checks it directly; otherwise findings are marked as observed from the air. The step closes with a per-SSID table of mode, observed weaknesses and the evidence used.
Check for rogue and lookalike access points
The tester looks for unauthorized access points, including devices plugged into the wired network, and for lookalike SSIDs that imitate corporate or guest networks to pull in staff devices. This is vulnerability validation of the wireless perimeter, and it confirms whether clients would auto-connect to an impostor network. Findings are recorded with signal evidence, location and the device types that responded. The step is complete when each rogue or lookalike candidate is confirmed, cleared or handed to the client for removal, with no live interference left unrecorded.
Test guest isolation and reachability into internal networks
The tester joins from a guest or lowest-trust wireless network and attempts to reach internal hosts, management interfaces, file shares, printers and, where in scope, cardholder data environment systems, using only the access that a visitor would have. Results show whether client isolation, VLAN separation and firewall rules hold in practice, not only in the design. Under PCI DSS requirement 11.4.5, segmentation controls must be tested at least every 12 months and after changes, so this step can feed that evidence where wireless is in the cardholder data environment's boundary. The step closes with a reachability matrix listing each source network, destination segment and the observed result.
Validate impact on internal and cardholder systems
For reachability that succeeds, the tester confirms the impact in a controlled way, such as whether the reachable system exposes authentication services, sensitive data or administrative access, and records how far the path extends. NIST SP 800-115 describes this validation stage as separate from discovery, so findings are confirmed rather than assumed from a scan result. The tester avoids disruption to production systems and stops when the proof is sufficient for the client to act. The step closes when each validated path has a severity rating, reproduction notes and the systems affected.
Report findings and agree remediation
The report sets out scope, methods, the rules of engagement as executed, a wireless inventory, each finding with evidence, affected SSIDs or segments, and prioritized remediation steps. It states which segmentation and access results bear on PCI DSS requirements 11.4.1 and 11.4.5 where those apply, and which findings the client should confirm with its qualified assessor. The readout covers what was not tested, such as areas that were out of hours or excluded. The step is done when the client has accepted the report and assigned owners to each remediation item.
Retest fixes and close findings
After the client changes its configuration, the tester repeats the checks that produced each finding and records whether the condition is resolved, partly resolved or still present. Retest scope is agreed in advance, and it is usually narrower than the original test, so the client should confirm in writing which findings and networks are included. The output is a retest addendum that references the original finding IDs and shows the new evidence. The step closes when every finding has a documented status that the client can give to its auditor or customer.
Which wireless weaknesses testers look for and why they matter
This table lists the wireless weakness categories testers examine on site, what each one looks like in the target environment, and the business risk it creates. Read each row as a question to put to your own wireless estate: if the answer is unclear, the category belongs in the test scope.
| Weakness category | What it looks like in the target | Business risk |
|---|---|---|
| Mixed WPA2 and WPA3 transition mode | An SSID accepts both older and newer security modes so that legacy clients can still join, often left enabled after a refresh | Clients may fall back to weaker negotiation, and the network inherits the weakest configured option |
| WPA3-Personal without SAE | A network labeled WPA3 that does not actually use Simultaneous Authentication of Equals for its key exchange | The security label overstates protection, and staff may assume controls that are not in place |
| WPA3-Enterprise and 192-bit mode gaps | An enterprise network that does not use the 192-bit security mode where the design calls for it, or mixes it with weaker profiles | Weaker encryption for traffic on sensitive segments, and a mismatch with the design the security team approved |
| Protected Management Frames not enforced | Management frame protection is disabled or optional on a WPA3 network, or not enabled on a WPA2 network that carries sensitive traffic | Forged management traffic can disrupt sessions, which affects availability and makes other attacks easier to stage |
| 802.1X certificate validation gaps | Supplicants are set to accept any server certificate or do not pin the expected authority, so clients trust an unknown RADIUS server | Credentials can be captured by a rogue authentication server, exposing user and domain accounts |
| 802.1X weak inner methods or shared credentials | Legacy inner authentication methods are still allowed, or many devices share one account or one certificate | Captured authentication exchanges are easier to abuse, and shared accounts remove individual accountability |
| Rogue and evil-twin exposure | Clients auto-connect to networks that copy a corporate SSID, or no process detects unknown access points in the building | Users may send credentials or traffic to an attacker-controlled network without noticing |
| Guest VLAN bridging | Guest SSIDs share a bridge, route, or firewall rule set with internal VLANs, or allow access to management addresses | A guest device becomes a foothold on internal networks, which undermines the purpose of the guest network |
| Weak pre-shared keys | Short, reused, or widely shared passphrases on personal or branch networks, sometimes printed on devices or shared in email | Anyone who learns the key can join the network, and rotation becomes difficult once many devices use it |
| Wireless paths into internal or CDE networks | Wireless VLANs route into corporate or cardholder data environment segments without documented, tested controls | A wireless client may reach systems in scope for PCI DSS, which widens the audit scope and the breach impact |
How wireless testing differs across office, retail, campus and cardholder sites
Corporate offices usually run WPA3-Enterprise or WPA2-Enterprise with 802.1X, so testing starts with how clients authenticate and what a successful login grants. Testers review the path from the access point to the authentication server, check whether client devices validate the server certificate, and confirm that VLAN assignment follows directory group membership. Time on site goes mostly to floor walks and comparing broadcast networks with the approved inventory.
- Authentication path: confirm the EAP methods in use and whether supplicants reject an untrusted server certificate.
- Directory-backed access: check that group membership maps to the intended VLANs and that disabled or departed accounts lose access.
- Rogue and lookalike SSIDs: compare what is broadcast on each floor against the approved list and investigate near-identical names.
- Protected management frames: where WPA3 is deployed, confirm that the network enforces Protected Management Frames as the Wi-Fi Alliance requires for WPA3.
Check that corporate wireless reaches only the server networks its directory groups justify, and that a compromised laptop cannot move laterally through the wireless segment.
Guest and visitor networks carry untrusted devices by design, so the test question is whether the isolation promised to the business holds in practice. Testers confirm that the guest network has no route to corporate, server or management address space, and that the captive portal, pre-shared key or voucher process cannot be bypassed to reach internal services. These checks usually take less time on site than corporate testing, but they need a clear list of what counts as internal.
- Client isolation: confirm that guest clients cannot reach each other or the wired network through the controller or gateway.
- Management exposure: check that access point and controller management interfaces are unreachable from the guest VLAN.
- Shared credentials: review how guest keys are issued, rotated and revoked, and whether a single shared key is still in use.
- Captive portal logic: test whether portal sessions and redirects can be abused to reach internal resources or sensitive pages.
- Infrastructure services: verify which DNS and DHCP services guest clients can query and whether they can see internal hostnames.
Check the guest network from both a wireless client and the wired network it shares infrastructure with, because isolation failures often sit in the gateway rather than the radio.
At retail sites, wireless often carries point-of-sale traffic, handheld payment devices or back-office links that sit inside the cardholder data environment. Testing therefore becomes a PCI DSS question as well as a wireless question. Internal testing covers the CDE from inside the network and from trusted and untrusted internal networks, and segmentation tests must confirm that the CDE is isolated from every out-of-scope system. Service providers face a six-month cycle for segmentation testing under requirement 11.4.6, while other organizations test segmentation at least every 12 months under 11.4.5, and both repeat after relevant changes.
- CDE scope: establish which wireless networks, devices and store links are in scope before any test begins.
- Payment terminal separation: confirm that wireless payment devices cannot reach other store networks or corporate systems.
- Guest and staff networks: verify that customer Wi-Fi and staff devices cannot route into the payment VLAN.
- Unauthorized access points: run wireless scans in each store to detect rogue devices plugged into the store network.
- Store-to-headquarters paths: check the links that carry payment data upstream and whether they are filtered as segmentation requires.
Check that segmentation evidence is refreshed after each store refit or network change, because a sample taken before a rollout does not show the current boundary.
Campus and multi-site estates raise the question of coverage. A single controller may manage many buildings, or each site may run its own configuration, and the test plan must match that structure. Planning under NIST SP 800-115 requires documenting rules of engagement and management approval, which for a multi-site estate should name every location, controller and shared link in scope. The main decision is whether to test every site or a representative sample, and that choice should be written into the scope before work begins.
- Site and controller inventory: build a verified list of sites, controllers and access points, including ones added informally.
- Configuration baseline: compare settings across sites to find drift, such as a weaker authentication mode at one branch.
- Sample selection: agree in writing how sites are chosen, the criteria used and how findings at one site affect others.
- Shared buildings and tenants: identify networks that serve partners, landlords or neighboring tenants and decide whether they are in scope.
- Inter-site links: check whether wireless traffic that crosses site-to-site links is protected and filtered at each end.
Check that the sampling method is documented in the rules of engagement, so the final report explains exactly which sites the findings represent.
Warehouses, distribution centers and industrial plants depend on handheld scanners, sensors, automated guided vehicles and wireless gateways for equipment that often cannot run standard endpoint controls. The wireless test therefore centers on device inventory, the security of the network those devices join and the boundary between enterprise and operational networks. Test windows must respect shift patterns and production schedules, and any active scanning should be agreed with the operations team in advance, since some devices are sensitive to unexpected traffic.
- Device inventory: identify which devices join the wireless network, who owns them and whether they appear in any asset list.
- Legacy authentication: check whether older devices still use pre-shared keys or weaker modes, and how keys are distributed to them.
- Default and shared configuration: review whether devices or gateways ship with factory settings or shared administrative accounts still in place.
- Operational boundary: confirm that the warehouse network cannot reach industrial control segments or the corporate network without a controlled path.
- Firmware and updates: ask how wireless gateways and handheld devices receive patches, and who approves them.
Check that OT and IoT devices are in a separate scope with its own rules of engagement, because the controls and safety considerations differ from those of office or retail networks.
What drives the cost and duration of a wireless test
This table compares the components of a wireless test, who performs each one, whether it is paid once or repeated, and what pushes effort up. Read it as a checklist for a quote: each row names a scope decision you can make, and the fewer unknowns in the written scope, the easier it is to compare proposals on equal terms.
| Cost component | Who does the work | Driver and what to ask for |
|---|---|---|
| Planning and rules of engagement | Tester lead with your security owner | Agreeing sites, SSIDs, authorized test windows and rules of engagement in writing. Ask what planning hours are included. |
| Sites and physical locations | Tester on site | Each building or floor adds travel and walk-through time. Ask whether the quote covers a fixed number of sites or a per-site rate. |
| SSIDs and authentication back ends | Tester analysis | Every network name and its authentication path (PSK, 802.1X, captive portal) is tested separately. Ask for a list of SSIDs in scope. |
| Controllers and access points | Tester on site and analyst | Controller count and access point density affect survey and rogue detection time. Ask how access points are sampled. |
| 802.1X and certificate infrastructure review | Tester analyst, sometimes with your PKI or RADIUS team | Reviewing RADIUS configuration, certificate validation and EAP methods adds analysis effort. Confirm whether this is in scope. |
| CDE reachability testing | Tester on site and internal testing team | Testing whether wireless clients can reach cardholder systems adds test cases and coordination with segmentation owners. Confirm whether PCI DSS segmentation testing is included. |
| Guest network isolation checks | Tester on site | Verifying that guest clients cannot reach internal ranges is a bounded task per network. Ask whether it is counted per SSID. |
| Travel and on-site days | Tester and engagement manager | Travel costs and on-site days are usually billed separately from analysis. Ask for the expected number of on-site days and any travel cap. |
| Analysis and reporting | Tester analyst and lead reviewer | Findings, evidence and remediation guidance scale with the number of networks and issues. Ask what the report format includes. |
| Retest | Tester analyst | A retest of confirmed findings is usually a separate, smaller piece of work. Ask whether one retest round is included and how long the retest window is. |
| One-time versus recurring | Your organization | Most wireless tests are one-time engagements. Repeat tests are needed after significant wireless or segmentation changes, so ask for a repeat quote tied to a defined scope. |
What you receive and whether it satisfies an auditor or customer
A wireless test produces a set of documents, and each one answers a different question for a different reader. The cards below describe what a well-formed package contains and how to check it against the expectations of your assessor or customer. Auditors decide whether evidence is sufficient, so confirm the framework's own requirements before you sign off on any report.
Scope and rules of engagement
The report should open with the agreed scope: which sites, buildings, SSIDs, controllers and client devices were in scope, and which were excluded. It should also restate the rules of engagement, including permitted test windows, whether guest or production networks were tested live, and who at the client approved the work. NIST SP 800-115 treats this planning record as a required part of a penetration test, so check that it matches the signed statement of work before accepting the report.
Per-SSID encryption and authentication evidence
Each SSID should have its own finding block showing the security mode in use, whether WPA3-Personal or WPA3-Enterprise with 802.1X is enforced, whether transition modes allow older protocols, and whether Protected Management Frames are required. Ask for the captured configuration or controller output that supports each statement, not only the tester's summary. Evidence that is tied to a specific SSID and site is what an assessor can trace back to the network.
Rogue and lookalike access point results
The report should list the access points observed during the survey, classify each as authorized, unknown or lookalike, and state the method used to tell them apart. For every unknown or spoofed network, it should record location, channel, signal strength and the response the team recommends. A clean result should still state the area covered and the time of the survey, since a rogue device placed later is outside the earlier test.
Guest isolation and reachability results
This section should show, with test sources and destinations, whether guest clients could reach internal subnets, management interfaces, file shares, printers or cardholder data environment addresses. Each path tested should be listed with its result, including the paths that were blocked. For networks in PCI DSS scope, the reachability record is the evidence that a wireless segment is or is not connected to the cardholder data environment, so confirm it covers every path the assessor will ask about.
Severity, remediation and retest report
Each finding should carry a severity rating with the rationale, a remediation step the network team can act on, and an owner field. After fixes are applied, a separate retest report should record the status of each original finding, the evidence that the fix works, and any findings still open. Keep the original report and the retest together as one record, since an assessor will expect to see both.
Letter describing the work
A short letter from the testing provider should state the dates, the method at a summary level, the testers' qualifications for the work and the scope limits. It is useful for a customer security review or an insurer, which often asks for confirmation that testing took place rather than the full technical detail. The letter does not replace the technical report, and it should not state any compliance outcome, since the assessor makes that determination.
What your team prepares before the wireless test starts
The most useful preparation for a wireless test is a written asset list that the testers can work from on day one. List every access point model and its location, the wireless LAN controllers or cloud management consoles that manage them, and every SSID with its purpose, security mode and VLAN or network segment. Include the guest and any IoT or point-of-sale SSIDs explicitly, because those are where isolation questions usually surface. Ask the team to flag which SSIDs are believed to reach internal or cardholder systems, since the test plan will prioritize those paths. Also confirm site access in writing: building access windows, escort requirements for each floor or site, badge or visitor arrangements, and who on your side will meet the testers and hold the keys to any wiring closets or comms rooms.
The second block is identity and certificate documentation. For any SSID using 802.1X, identify the RADIUS servers or network policy services, the directory they authenticate against, the certificate authority that issued the server certificate, and the full certificate chain that clients are expected to trust. Note which EAP methods are enabled and whether clients validate the server certificate, because these settings decide whether an evil twin access point can capture credentials. For WPA3-Personal, state whether the network is in transition mode alongside WPA2, and who holds the pre-shared key and how often it rotates. Name a contact on the network team, a contact on the identity team and an escalation owner with authority to act during the test. Agree a change freeze on the wireless and identity infrastructure for the test window, so that findings reflect a stable environment.
Plan for a rogue or unexpected access point before the testers arrive. Agree in writing what counts as a rogue, which is typically any access point broadcasting your SSIDs or an unknown device connected to the internal network, and who decides whether the tester may connect to it, isolate it or only report it. Keep the rules of engagement and the decision on any live exploitation or client attack consistent with the planning phase described in NIST SP 800-115, which provides a rules of engagement template in Appendix B. The test should avoid disrupting production wireless. Ask for deauthentication and jamming-style activity to be limited or excluded, and agree a window and a stop condition with your network operations team, so that testing does not knock out clinical, retail, warehouse or executive users.
What to check when choosing a wireless testing provider
A wireless test touches physical premises, live networks and sometimes cardholder environments, so the contract matters as much as the testing method. The cards below list what to verify and get in writing before signing. Confirm each claim in the statement of work, not only in a sales conversation.
Written scope and rules of engagement
Ask for a written scope that names every site, SSID, building and network segment in play, plus the rules of engagement covering permitted techniques, testing windows, stop conditions and emergency contacts. NIST SP 800-115 treats planning, with rules identified and management approval documented, as the first phase, and its Appendix B offers a rules of engagement template. Confirm that the rules name what the provider must not do before any signal is transmitted.
Named testers with on-site wireless experience
Ask for the names and relevant experience of the people who will be on site, not only the firm's general credentials. Wireless work involves RF surveys, rogue device hunts and walking the premises, which differs from remote network testing. Confirm that the named testers will perform the work and that any substitution requires your written approval.
Handling of captured data
Wireless testing can capture traffic, probe requests and client identifiers from neighboring tenants, staff and members of the public. Ask how captured data is stored, encrypted, who can access it, how long it is retained and how it is destroyed at close. Require that captures are limited to what proves a finding and that the handling terms appear in the contract.
Insurance and liability terms
Ask for current proof of professional indemnity and general liability insurance, with coverage limits stated in the contract. Check who is liable if a test disrupts a live network, a building system or a neighboring tenant's service. Confirm the indemnity clause, the dispute process and how the provider handles accidental access to data outside scope.
Method alignment with NIST SP 800-115
Ask the provider to map its wireless method to the planning, discovery, attack and reporting phases of NIST SP 800-115, and to state whether the test is overt or covert. Covert testing examines what an adversary could do, while overt testing is usually less expensive and carries less risk. Confirm which approach you are buying and whether the report explains the methods used.
Reachability testing into internal and CDE networks
Ask how the provider will test whether a wireless foothold reaches internal hosts, management interfaces, guest-to-corporate boundaries and any cardholder data environment. Request that each reachable path be tested from the wireless side and reported with evidence, including segments the test could not reach. Confirm that the approach supports PCI DSS segmentation testing if a cardholder environment sits behind the wireless network.
Retest terms and remediation support
Ask whether the quote includes a retest after fixes, how many retest rounds are covered, and the window for requesting one. Confirm whether the provider validates fixes such as WPA3 or 802.1X migration, rogue device removal and guest isolation changes, or only reviews them on paper. Get the retest terms in the statement of work so they are not an extra negotiation after the report.
Common questions before commissioning a wireless test
How much does a wireless penetration test cost?
DeployOpen does not publish a price list, and the quote follows from the written scope. The main cost drivers are the number of sites, the floor area to survey, the number of SSIDs and authentication modes in use, and whether the work includes hunting for rogue access points across the premises. Scope also changes cost when guest, corporate and cardholder segments must each be verified from the wired side, and when testing has to happen outside business hours. The test itself is a one-time fee, while a retest after fixes is a separate item. When you request a quote, ask for pricing itemized by site, a list of SSIDs in scope, the reporting deliverables, and any travel or site access charges. The cost drivers section below explains each component in more detail.
How long does a wireless security test take?
Duration depends mostly on how many sites, buildings and floors the test covers, how many wireless networks and authentication modes need checking, and how quickly the client can provide access. Access is often the bottleneck. Testers need escorts, approved test windows, and access to controller or access point management consoles to confirm configuration against what they observe on air. Time is also spent coordinating with facilities and operations teams when test devices or temporary monitoring are placed on premises. Planning and rules of engagement agreement happen before any on-site work, as NIST SP 800-115 describes for penetration testing in general. Ask for the timeline in the written scope, with separate lines for planning, on-site work, analysis and reporting, so you can see which dependencies sit on your side.
What does the client need to provide for a wireless test?
The client provides the authorization, the information needed to test accurately, and the people who make decisions during the work. A signed authorization from management and a rules of engagement document should come first, because NIST SP 800-115 treats planning, including documented management approval, as a required phase. Expect to supply an inventory of access points and wireless controllers, the SSID list, the design of the authentication path (such as RADIUS servers, certificate authorities and any guest portal), and network diagrams showing where wireless segments meet wired networks and the cardholder data environment. You should also name escorts, approved test windows, and a contact who can halt testing. Confirm in advance whether any access point sits in a shared building or a neighboring tenant's space, since that affects what can be tested.
Can our internal team run a wireless security test themselves?
Sometimes, but the answer depends on skills, tooling and independence. PCI DSS allows internal penetration testing by a qualified internal resource with organizational independence, so an internal team can satisfy that requirement if the testers are independent of the team that operates the wireless estate. Several checks should be made before deciding:
- Do the testers have current wireless assessment skills and tooling, including site survey and authentication analysis?
- Are they independent of the people who configured and manage the access points and controllers?
- Will the output, including method, scope and evidence, be accepted by your auditor or assessor?
If any answer is no, an external provider adds value. Ask whether the scope of an internal test would reach the same findings as an external engagement would produce, and document the reasoning either way.
Do WPA3 and 802.1X both need to be tested?
Yes, if both are deployed, because they protect different parts of the connection. The Wi-Fi Alliance states that WPA3 is mandatory for Wi-Fi CERTIFIED devices, and it describes WPA3-Personal using Simultaneous Authentication of Equals, WPA3-Enterprise offering a 192-bit security mode, and WPA3 networks requiring Protected Management Frames. A test confirms that those settings are enforced and that transition modes do not allow a fallback to weaker protocols. 802.1X is the authentication framework that checks each device or user against a RADIUS service, so testing focuses on certificate validation on client devices, the EAP methods in use, and whether VLAN assignment keeps corporate, guest and cardholder traffic apart. Testing one without the other leaves the path between them unverified. The Wi-Fi Alliance security overview is a useful starting point for the standards involved.
Does a wireless test count as the PCI DSS internal test?
It can, but only if the scope meets what requirement 11.4.1 defines for internal testing. That requirement covers testing from inside the network, both inside the cardholder data environment and into it from trusted and untrusted internal networks. If a wireless network can reach cardholder systems, or can reach a segment that connects to them, that path belongs in the internal test scope. Where wireless is used as a bridge between segments, segmentation testing under requirement 11.4.5 also applies, and it must run at least every 12 months and after changes. Requirements 11.4.2 and 11.4.3 allow a qualified internal resource or a qualified external third party with organizational independence, who need not be a QSA or ASV. Confirm the scope and the tester's qualifications with your QSA or acquirer before the test starts.
What happens to rogue access points found during a wireless test?
The rogue access point is recorded, classified and reported, and removing it is a decision the client makes or pre-authorizes in the rules of engagement. During a site survey, a tester may find access points that are unauthorized, unknown, or misconfigured and bridged to the wired network. The report should show each device's location, SSID, channel, approximate reach, and whether it connects to internal networks. The rules of engagement should define who is notified and how quickly for a critical finding, and whether testers may disconnect a device. Testers should not interact with networks that belong to neighbors or third parties, and any finding that may involve another organization should go through legal and management before further action. Ask the provider how it handles discovered devices, and what evidence it keeps so the finding can be traced later.
How does retesting work after wireless findings are fixed?
Retesting confirms that the fixes work, and its scope is agreed in writing like the original test. Typically it covers the findings that were remediated, along with the configuration and access controls those fixes touched, such as authentication settings, guest isolation, and segmentation between wireless and cardholder networks. Evidence from the client, such as configuration exports or change records, often shortens the work, but the tester should still observe the result on air or from the relevant network position. Retesting cost depends on how many findings are retested, how many sites are affected, and whether a fresh site survey is needed. PCI DSS also requires penetration testing after significant changes, so a change to wireless infrastructure may trigger another test. Confirm retest terms, included evidence and timing in the quote.
How DeployOpen scopes, tests, reports and retests wireless
DeployOpen agrees a written, fixed scope for each wireless engagement before any on-site work starts, covering which networks, sites and systems are in play. Testing is carried out on site, documented against the agreed rules of engagement, and followed by a retest once remediation is complete.
How we scope
- Written scope lists each SSID, site, floor and building included in the wireless assessment.
- Scope states which authentication modes, including WPA3-Personal, WPA3-Enterprise and 802.1X, are reviewed.
- Rules of engagement confirm whether guest, corporate and cardholder-adjacent networks are in or out of bounds.
How we build
- Planning records management approval and the rules of engagement before any radio activity begins on site.
- Testers survey access points, rogue and lookalike SSIDs, and whether Protected Management Frames are enforced.
- Guest isolation and any path from wireless segments to internal or cardholder systems are tested and validated.
How we hand over
- The report maps each finding to the affected SSID, access point location and the wireless control involved.
- Evidence records what was observed, the conditions under which it was reached, and the recommended fix.
- Findings are written so your auditor or customer security reviewer can trace each one to the scoped test.
How we support
- Remediation guidance is provided for configuration changes, such as authentication mode, RADIUS policy and segmentation.
- A retest verifies that agreed fixes are in place for the wireless scope originally tested.
- Ongoing support and continuous testing for wireless and related infrastructure are available as a retainer.
