WIRELESS NETWORK PENETRATION TESTING
Your wireless network is the one part of your perimeter that literally leaves the building. A firewall stops an attacker at the edge of your wired network, but radio does not stop at the wall — it spills into the car park, the lobby, the floor above, and the street outside. An attacker sitting in a parked car is, for the purposes of your wireless network, already on site. They do not need to get past reception, tailgate through a door, or plug into a switch; they only need to be in range. A wireless penetration test assesses exactly that exposure: what someone within radio range can see, capture, and reach, and whether the encryption, authentication, and segmentation between your networks actually hold up under a determined attack rather than just looking correct in the controller's configuration screen.
We assess wireless across three areas, and the distinction between them matters because each one defends against a different kind of attacker.
What we test
Our methodology covers three areas, and a full engagement works through all of them against the SSIDs and sites in scope.
- Infrastructure — the wireless implementation itself. We look at the encryption in use (modern WPA2/WPA3 versus legacy protocols that should have been retired long ago), the authentication design (a shared PSK versus enterprise authentication backed by RADIUS and EAP), and the network segmentation between guest, corporate, and production SSIDs — because a guest network that can reach internal systems is a flat network wearing a disguise. This is also where we hunt for rogue or unauthorised access points: devices broadcasting your network name, or unsanctioned APs plugged in by staff, that quietly extend your attack surface beyond anything IT approved.
- Protocol — weaknesses in the wireless protocols and how they are configured. On a network using a pre-shared key, we capture the authentication handshake and attempt to crack a weak PSK offline, where an attacker has unlimited time and computing power and your users never notice. We test for downgrade attacks that push clients onto weaker protocols, and we examine enterprise authentication for misconfiguration — for example, clients that fail to validate the RADIUS server's certificate and will therefore hand their credentials to any server that asks.
- Client-side attack — the devices that connect, not the network they connect to. A laptop or phone that has ever joined your Wi-Fi remembers the network and will look for it again. We test whether an evil twin or rogue AP — an attacker-controlled access point impersonating your legitimate SSID — can lure those clients into connecting and harvest credentials in the process. We use deauthentication to see how clients behave when knocked off the real network, and we measure how easily a user can be steered onto a network the attacker controls. Client-side attacks matter because they route around the infrastructure entirely: even a well-configured network cannot help you if the endpoint willingly connects to an impostor.
Scope — the number of SSIDs, the number of sites, and whether we cover guest, corporate, and production networks — is agreed with you up front, and the depth of testing adapts to your environment rather than being forced through a fixed checklist.
How we work
Every engagement runs through the same phases, so you always know where the project stands and what arrives next.
- Scope SSIDs & sites — We agree which networks and which physical locations are in scope, which SSIDs are guest versus corporate versus production, and what "in range" means for your buildings. Untested surface is agreed here, not discovered at the end.
- Survey & recon — On site, we map the radio environment: which access points and SSIDs are actually broadcasting, their encryption and authentication settings, signal reach beyond your walls, and anything present that should not be — the first place a rogue AP shows up.
- Infrastructure & protocol testing — We assess the encryption and authentication design, capture handshakes to test PSK strength offline, probe segmentation between networks, and examine enterprise/RADIUS/EAP configuration for the misconfigurations that let an attacker bypass it.
- Client-side testing — We stand up controlled evil-twin and rogue-AP scenarios and use deauthentication to test whether client devices can be lured onto an attacker-controlled network and made to disclose credentials, always within the rules of engagement agreed during scoping.
- Reporting — Findings are written up with impact, rated by Risk Level, and given a clear reproduction path so your team can see exactly what we did.
- Retest — After your team remediates, we retest to confirm each issue is genuinely closed and update the report to reflect it.
What you get
Every report contains, at minimum:
- Executive summary — a business-level risk picture, suitable for management and auditors.
- Findings by Risk Level — each issue rated Critical, High, Medium, or Low so remediation can be prioritised objectively.
- Reproduction / POC for every finding — the exact steps, captures, and conditions that reproduce the issue; your engineers should never have to guess how we did it.
- Remediation guidance — practical fixes tied to your environment, not scanner boilerplate.
- Retest verification — findings are re-checked after your fixes and the report is updated to reflect closed items.
Team credentials
Testing is performed by our in-house team holding industry certifications including OSCP, OSCE, CREST CRT, CREST CPSA, and GIAC GREM — credentials earned through rigorous, hands-on examination. See the full list of certifications the team holds.
Standards
If your organisation handles payment-card data, wireless testing is not optional. PCI DSS Requirement 11 calls for detecting both authorised and unauthorised (rogue) wireless access points on a quarterly basis, precisely because a single rogue AP can undo an otherwise segmented cardholder-data environment. This test covers that requirement directly and feeds into your wider PCI DSS penetration test scope.
Wireless testing also complements our infrastructure penetration test: the wireless assessment covers the perimeter that travels through the air, while the infrastructure test covers the wired network and internal systems an attacker reaches once they are through it. Tested together, they close the gap between what an attacker can touch from the car park and what they can reach once inside.
Last reviewed: 11 Jul 2026
Book a scoping callFrequently asked questions
Why does wireless need its own penetration test?
Your wireless network is the one part of your perimeter that literally leaves the building. A firewall stops an attacker at the edge of your wired network, but radio spills into the car park, the lobby, and the street outside. An attacker in a parked car is already on site — they only need to be in range. A wireless test assesses what someone within radio range can see, capture, and reach.
What does a wireless penetration test cover?
Three areas: infrastructure (encryption in use, WPA2/WPA3 versus legacy, PSK versus enterprise RADIUS/EAP, segmentation between guest/corporate/production SSIDs, and rogue access points), protocol (capturing the handshake to crack a weak PSK offline, downgrade attacks, and RADIUS certificate-validation misconfigurations), and client-side attacks (evil-twin and rogue-AP scenarios that lure devices into connecting).
What is an evil twin or rogue access point attack?
An evil twin is an attacker-controlled access point impersonating your legitimate SSID. A device that has ever joined your Wi-Fi remembers the network and looks for it again, so an evil twin can lure it into connecting and harvest credentials. We use deauthentication to see how clients behave when knocked off the real network, and measure how easily a user can be steered onto a network the attacker controls.
Does this satisfy PCI DSS wireless requirements?
Yes — when run on the quarterly cadence the standard requires. PCI DSS Requirement 11 calls for detecting both authorised and unauthorised (rogue) wireless access points on a quarterly basis, precisely because a single rogue AP can undo an otherwise segmented cardholder-data environment. This test covers that requirement directly and feeds into your wider PCI DSS penetration test scope.

