PCI DSS v4.0.1 Requirement 11.2.1 requires that the presence of wireless access points is tested for, that all authorised and unauthorised access points are detected and identified, and that this happens at least once every three months. It applies even when policy prohibits wireless entirely (PCI Security Standards Council). NIST's SP 800-153, Guidelines for Securing Wireless Local Area Networks recommends a technical WLAN security assessment at least annually, plus periodic assessments at least quarterly unless continuous monitoring already collects the attack and vulnerability information those assessments would produce.
Both speak to detection cadence. Neither tells you whether someone in your loading bay can reach a file server from your guest SSID, or whether your warehouse scanner fleet will hand corporate credentials to a laptop parked outside. That is what a Wi-Fi penetration test answers. This guide is for the person deciding whether to buy one this quarter: a new office or distribution centre, a guest network nobody has reviewed since it was stood up, an audit finding about rogue access points, or a merger that added a wireless estate you have never seen. By the end you should be able to draft your own scope document.
Survey, audit and penetration test are three different purchases
Many disappointing wireless engagements are the wrong product bought under the right name. Three distinct services get sold as "wireless assessment", with different practitioners, outputs and price points.
Wireless site survey | Wireless security audit | Wi-Fi penetration test | |
|---|---|---|---|
Question answered | Is coverage and roaming adequate? | Does config match a secure baseline? | Can someone get in, and how far? |
Who performs it | RF and network engineers | Security consultants, often remote | Offensive security testers, on site |
Inputs | Floor plans, AP placement, spectrum data | Controller export, SSID and EAP settings, RADIUS policy, MDM profiles | Live RF environment, client devices, guest and corporate access |
Output | Heat maps, channel plan | Gap list against a baseline | Proven access paths, evidence, risk-rated findings |
Proves exploitability | No | No | Yes, within agreed rules |
Remote delivery | Partly | Yes | No, a tester must be in radio range |
A fourth thing gets confused with all three: a recurring rogue access point sweep, whether via a wireless intrusion detection system or a walk-through. That is a compliance control on a quarterly cadence, not a test of your defences. Buy it separately and do not let it stand in for the penetration test. If the network is the real worry and Wi-Fi is one input, start from the broader network security service line, because guest-to-corporate findings only matter when someone follows the path onto the internal network.
What belongs in scope, and what does not
A wireless scope document is mostly a list of radios and addresses. "Test our Wi-Fi" produces a vague report. Write it down at this granularity.
Scope area | What to name in the document |
|---|---|
Corporate WPA2/WPA3-Enterprise SSIDs | Each SSID, EAP method, RADIUS platform, identity source |
Corporate WPA2/WPA3-Personal SSIDs | Each SSID, who holds the key, when it was last rotated |
Guest networks | SSID, captive portal type, intended egress, whether client isolation is expected |
BYOD and onboarding SSIDs | Provisioning SSID, certificate enrolment flow, MDM profile |
IoT, OT and legacy device SSIDs | Printers, badge readers, cameras, HVAC and building management, barcode scanners, forklift terminals |
Wireless client devices | Which device classes are testable, and whether staff laptops and phones are included |
Rogue and shadow access points | Whether the tester sweeps for and physically locates unknown transmitters |
Wireless management plane | Controllers, AP management interfaces, RADIUS servers, cloud management portals |
Physical sites | Full addresses, floors, buildings, outdoor yards and car parks |
Normally out of scope unless bought separately: sub-GHz industrial telemetry, Bluetooth and BLE, Zigbee and Z-Wave, cellular and private 5G, and RFID badge systems. Physical entry attempts belong in a physical security assessment. State the exclusions either way, so nobody assumes coverage that was never bought.
Two exclusions are non-negotiable. Neighbouring tenant and passer-by networks are recorded as observed in the RF environment and never touched. And your authorisation letter must name the physical addresses, because in a shared building the tester stands in space you may not fully control. In a multi-tenant tower, tell building management before test week.
The finding classes that actually come back
Wireless reports have a stable finding distribution. Below is what a competent test surfaces, at the level a defender needs to act on. Every one is fixable with a configuration change, a key rotation or a firmware upgrade.
Finding class | What it is and why it matters |
|---|---|
Weak or stale pre-shared key | A WPA2-Personal passphrase that is short, guessable, or never rotated after staff leave. One key grants access to everyone in earshot with no per-user accountability, and WPA2-Personal permits offline password guessing from captured material. WPA3-Personal's SAE handshake resists that class |
EAP misconfiguration and missing server certificate validation | Enterprise clients set to accept any RADIUS certificate, or to trust a CA without pinning the expected server name. This turns a rogue access point into a credential harvest and enables relay of those credentials against other services. It is a client setting, so it must be enforced by MDM or group policy on every device |
WPA3 transition mode exposure | Mixed WPA2/WPA3 so older clients can associate. Necessary during migration, but it keeps the WPA2 surface alive. The test shows which SSIDs can now be locked to WPA3 only |
Guest-to-corporate bridging | A guest SSID that lands on a VLAN with a route into internal address space, resolves internal DNS, or reaches management interfaces. The most common high-severity wireless finding, and the one that turns a lobby chair into an internal foothold |
Missing client isolation on guest | Guest devices able to reach one another, which makes your guest network a hostile LAN for visitors, contractors and staff personal devices |
Rogue and shadow access points | Unknown transmitters inside your footprint: a consumer router someone plugged in, a personal hotspot, a vendor appliance with an undocumented radio. These bypass your entire wired security stack |
Evil twin exposure | How readily a device imitating your SSID attracts your clients. Measures the practical value of your client hardening and your wireless intrusion detection coverage |
Client probe leakage | Laptops and phones broadcasting the networks they remember, exposing your corporate SSID alongside hotel and home networks. Useful targeting data for an outsider, and the reason saved-network hygiene and MAC randomisation belong in the scope |
Missing management frame protection | 802.11w Protected Management Frames not enforced, so forged disconnect frames can knock clients off the network. That is an availability issue and the setup for client redirection. The Wi-Fi Alliance notes PMF is required for WPA3 and Enhanced Open and lets devices ignore forged disconnect frames (Wi-Fi Alliance) |
WPS enabled | Wi-Fi Protected Setup left on, typically on consumer-grade gear in branches or vendor-installed equipment. A legacy convenience feature with a long history of weakening otherwise sound key material |
Legacy and orphaned SSIDs | An old open or WEP-era SSID still beaconing for a scanner fleet, a printer, or a system decommissioned years ago. Free access with no authentication, invisible in the dashboard nobody reviews |
Wireless management plane weakness | Default or shared credentials on controllers and APs, management interfaces reachable from a client VLAN, weak RADIUS shared secrets. Compromise here is estate-wide rather than site-local |
Signal bleed beyond the perimeter | Usable corporate signal in the street, car park, adjacent unit or the floor below. Determines whether an attacker needs to enter your building at all |
Two of these drive most of the remediation budget. Guest-to-corporate bridging is a segmentation problem, so the fix sits with the network team. Missing server certificate validation is a fleet configuration problem, so the fix touches every managed device and is a project rather than a change ticket.
Client behaviour is the half of the estate that walks out of the building
Access points sit still. Clients do not, and an assessment that only looks at your APs has tested half the problem.
Client-side scope covers what your devices do away from your APs and what they agree to when they return. Testers examine probe behaviour, meaning how much your laptops and phones broadcast about remembered networks, because a preferred network list naming your corporate SSID plus a set of hotel and home networks is a targeting aid. They check whether MAC address randomisation is actually in effect. They review the Wi-Fi profiles your MDM pushes, because the certificate validation setting above lives there. And, where authorised, they test whether staff devices will associate with an imitation of your SSID and what they disclose when they do.
This is the scope switch that most changes the engagement, because it involves employees' working devices and so needs an explicit decision on notification. Testing without notice gives the honest answer about default device behaviour. Testing with notice is gentler and still validates configuration. Either is defensible; not deciding is not. Where this touches the human layer rather than the device layer, it overlaps with social engineering work and should be scoped alongside it.
Why a wireless test needs someone on site, and what that does to your calendar
Radio has range. A tester must be physically within range of the network being tested, because the medium under assessment is the RF environment itself. There is no remote equivalent of standing in your warehouse and listening. That has direct scheduling consequences:
Travel is part of the engagement. Multi-site estates mean multi-city trips. Sequence sites to minimise travel days and expect travel as a line item.
Testing windows are physical, not logical. A tester covers the ground they can walk. Warehouses and campuses take longer per square metre than an office floor, and racking, cold storage and mezzanines slow coverage further.
After-hours work cuts both ways. Out-of-hours testing reduces disruption but removes the client devices that make client-side testing meaningful. A split schedule usually works best.
Escorts constrain the day. In secure or operational areas the engagement moves at the escort's pace, so confirm availability for the whole window.
Some testing can be shipped. Stingrai's Wi-Fi security assessment can deploy a purpose-built wireless testing appliance to a site, reporting back to a controlled analysis environment. That cuts travel for multi-site estates and periodic re-testing, and covers branches that do not justify a full visit. It does not replace a tester on site where physical positioning, escorted areas or client-side work are involved.
One point of clarity on delivery. Snipe, Stingrai's autonomous agent, is scoped to web application penetration testing only. Wireless, network, Active Directory, physical and social engineering engagements are delivered by senior human testers holding OSCE3, OSCP, OSWE, OSED, OSEP, CREST CRT, CISSP and CRTO certifications. Stingrai is a CREST-accredited penetration testing service provider at firm level, which is a separate accreditation from the individual CREST CRT certifications testers hold.
What you receive: a deliverable that survives an auditor and a network engineer
A wireless report has two audiences. The auditor wants inventory and evidence of a repeatable process. The network engineer wants to know which BSSID on which floor, and what to change. Ask for both.
Executive summary in business terms: what an outsider could reach, from where, and what it would cost you.
Observed SSID and BSSID inventory, reconciled against your authorised AP list. This feeds PCI DSS Requirement 11.2.2, which asks you to maintain an inventory of authorised access points with documented business justification.
Rogue and unknown transmitter list, each with a location estimate and a call on whether it is yours, a neighbour's, or worth investigating physically.
Coverage and rogue-AP map per site and per floor, showing where usable corporate signal extends past your property line. This is the visual that gets remediation approved.
Per-finding technical detail: affected SSIDs and BSSIDs, evidence, a risk rating with its reasoning, and remediation specific to your controller platform.
Segmentation test results: what was reachable from guest and BYOD networks, as attempted paths and outcomes rather than a firewall rule review.
Client-side findings by device class, so each fix can be assigned to whoever owns that fleet.
Detection timeline: what your wireless intrusion detection and your SOC saw. If nothing fired, that is a finding.
Prioritised remediation plan plus a retest and attestation letter once fixes land, which is what your auditor or a customer questionnaire will ask for.
What drives duration and cost
Wireless pricing follows physical geography far more than device count. One office with forty access points is a shorter engagement than three branches with six each.
Driver | What to tell your vendor |
|---|---|
Number of physical sites | Full address list with a rough size for each. This is the largest single driver |
Floor area, floor count and layout | Square footage, floors, and whether warehouses, yards or car parks are included |
Number of SSIDs and auth types | SSID list with encryption and EAP method, since each is a separate test path |
Client-side testing in or out | Whether staff devices are in scope, and which fleets |
Segmentation depth | Whether you want the internal path proven or only the boundary probed |
Detection validation | Whether you want the purple team treatment or a silent test |
Out-of-hours or split scheduling | Acceptable testing windows per site |
Operational constraints | Any site needing safety induction, PPE, escorts or restricted-zone access |
Retest inclusion | Whether a retest visit or shipped-appliance re-check is bundled at the outset |
For a single office, plan on a small number of on-site days plus reporting. Multi-site retail, logistics and manufacturing estates are usually scoped as a sampled programme, testing a representative subset of sites per cycle rather than every site every year. That is how most organisations keep wireless coverage sustainable.
On price: Stingrai's published figures on the pricing page are scoped to web application testing. Wireless, network, Active Directory, physical and social engineering engagements are quoted individually, because the number depends on the site list rather than a tier. Send the address list and SSID inventory with your request and you will get a firm number quickly.
What to prepare before test week
Preparation separates a productive on-site week from a tester waiting in reception. Have these ready before kickoff, not during it.
Item | Why it matters |
|---|---|
Written authorisation naming every address | The tester operates in physical space, and shared buildings make this essential |
Landlord or building management notification | Stops facilities escalating an unfamiliar person with unfamiliar equipment |
Badges and named escorts for the full window | The most common cause of lost testing hours |
Safety induction and PPE confirmed early | Warehouses and plants often bar floor access without it |
Authorised access point and SSID inventory | Without it, every unknown radio is an investigation rather than a finding |
Controller platform, model and firmware versions | Makes remediation advice specific rather than generic |
Floor plans, even rough ones | Materially improves the coverage and rogue-AP map |
Agreed testing windows per site | Needed wherever availability-sensitive testing is in scope |
Deconfliction contact reachable during testing | So a genuine incident is separated from the test within minutes |
Decision on staff notification | Drives realism versus disruption for client-side testing |
Guest and corporate test credentials | Removes a day of black-box effort where you already know the answer |
MDM Wi-Fi profile export | The fastest route to confirming certificate validation across fleets |
Change freeze during the window | Firmware upgrades mid-test invalidate findings |
How to tell a real engagement from a scan with a report template
Wireless is easy to fake, because a tool export superficially resembles a report. Put these questions to any proposal.
Does it name physical addresses and per-site hours? A quote produced before the vendor knows your site count and floor area is a guess.
Does it distinguish observed from owned? A credible report separates networks present in the RF environment from networks in your estate. One that lists your neighbour's SSIDs as findings was not read by a human.
Is segmentation actually tested? Ask whether the tester will attempt to reach a named internal target from the guest network, and what evidence you get. A firewall rule review is not a segmentation test.
Is client-side testing explicitly in or out? If the proposal is silent, it is out, and you will discover that at the report stage.
Does the deliverable include a reconciled inventory and a coverage map? Both require site work, so their absence signals a remote or automated engagement.
Is there a detection timeline? If the report does not say what your monitoring saw, nobody was watching.
Who is on site, and what do they hold? Ask for the named tester and their certifications, not the firm's logo wall.
Does the vendor say what wireless will not answer? A proposal claiming wireless covers Bluetooth, badge systems and physical entry is selling something it will not deliver.
Stingrai has run offensive security engagements since 2021 from Toronto and London, holds 18 published CVEs, and carries a 5.0 out of 5.0 rating across 19 Clutch reviews. Wireless sits inside the wider network security practice, and the Wi-Fi security assessment page is where to start with a site list. Penetration testing supports your PCI DSS, ISO 27001 and SOC 2 programmes by producing the technical evidence they ask for. Worth knowing which actually require testing: PCI DSS v4.0.1 mandates penetration testing across a general population and CMMC requires it at Level 3, while ISO 27001, SOC 2 and NIST SP 800-171 do not mandate it and set no frequency of their own.
Frequently Asked Questions
What is Wi-Fi penetration testing?
Wi-Fi penetration testing is an authorised, adversarial assessment of wireless networks, performed by a tester within radio range of the sites in scope. Rather than only checking configuration against a baseline, it attempts to gain unauthorised access, cross from guest to corporate space, or capture credentials from wireless clients within agreed rules. The output is proven access paths with evidence, a reconciled inventory of the wireless estate, and a prioritised remediation plan.
How much does a Wi-Fi penetration test cost?
Wireless engagements are priced from the site list rather than a published tier, because the dominant cost drivers are location count, floor area, travel and whether client-side testing is in scope. Stingrai's published pricing covers web application testing, so wireless, network, Active Directory, physical and social engineering work is quoted individually. Send the addresses, approximate size per site, SSID list and whether staff devices are in scope to get a firm number.
How long does a wireless security assessment take?
A single office is typically a small number of on-site days plus reporting and quality assurance time. Multi-site estates scale with travel rather than access point count, so three small branches usually take longer than one large headquarters. Warehouses and campuses take longer per square metre because coverage is a walking exercise that racking, cold storage and mezzanines all slow down.
Does a Wi-Fi penetration test have to be done on site?
Largely yes, because the thing being tested is the radio environment and a tester has to be within range to observe it. Parts of a programme can be covered by deploying a purpose-built wireless testing appliance that reports back to a controlled analysis environment, which reduces travel for branch locations and periodic re-testing. On-site presence is still required for physical positioning, escorted areas, coverage mapping and client-side testing against staff devices.
What is the difference between a wireless site survey and a Wi-Fi penetration test?
A wireless site survey is an RF engineering exercise answering whether coverage, capacity, channel planning and roaming are adequate, and its output is heat maps and design recommendations. A Wi-Fi penetration test answers whether someone can get in and how far they can go, and its output is proven access paths with evidence and remediation. They are performed by different specialists, so buying one does not give you the other.
Does PCI DSS require wireless penetration testing?
PCI DSS v4.0.1 Requirement 11.2.1 requires that the presence of wireless access points is tested for and that authorised and unauthorised access points are detected and identified at least once every three months, and it applies even where policy prohibits wireless. That is rogue access point detection, a narrower and more frequent control than a penetration test. PCI DSS separately mandates penetration testing, so organisations in scope usually run a recurring rogue-AP process alongside a periodic wireless penetration test rather than substituting one for the other.
Will a Wi-Fi penetration test disrupt our network?
A properly run engagement is scoped so availability-affecting techniques are either excluded or confined to agreed windows, and the rules of engagement should say which applies at each site. Passive discovery, coverage mapping, configuration review and most client-side work carry no meaningful disruption risk. Agree the windows up front, provide a deconfliction contact reachable during testing hours, and avoid firmware upgrades during the test so findings stay valid.
What do we need to prepare before a Wi-Fi penetration test?
Written authorisation naming every physical address, site access with badges and named escorts for the whole window, and any safety induction or PPE requirements confirmed in advance. Technically, provide your authorised access point and SSID inventory, controller platform and firmware versions, floor plans even if rough, an MDM export of your Wi-Fi profiles, and test credentials if authenticated testing is in scope. Finally, decide whether staff will be notified, because that shapes how realistic the client-side portion can be.
