A wireless and IoT pentest checklist covers six areas: wireless discovery and RF mapping, Wi-Fi encryption and authentication (WPA2-PSK, WPA2-Enterprise, WPA3), rogue and evil-twin access points, segmentation between guest, IoT and corporate networks, device-level testing (hardware, firmware, Bluetooth, Zigbee), and the IoT cloud and app backend. Every item should end in evidence an auditor can accept.
Wi-Fi and connected devices reach past your firewall. An attacker in the parking lot, a badge reader with default credentials or a sensor talking to an unauthenticated MQTT broker can each open a path to the internal network. Annual network pentests often leave these out of scope.
This checklist is for CISOs, IT directors and security and compliance leads who are scoping a wireless or IoT test, comparing vendor proposals, or getting ready for PCI DSS, SOC 2 or ISO 27001. It follows public guidance from NIST SP 800-153 (wireless LAN security), NIST SP 800-115 (security testing) and the OWASP IoT Security Testing Guide.
What does a wireless and IoT pentest checklist cover?
| Area | What the test answers | Main reference |
|---|---|---|
| Discovery and RF mapping | What is broadcasting, where, and how far the signal reaches | NIST SP 800-153 |
| Wi-Fi encryption and authentication | Can an outsider join or decrypt your networks? | NIST SP 800-153, Wi-Fi Alliance WPA3 spec |
| Rogue and evil-twin access points | Can a fake or unauthorized AP capture users or bridge into the LAN, and does anyone notice? | PCI DSS 4.0 Req. 11.2 |
| Segmentation | Can a guest, IoT or compromised device reach systems it shouldn’t? | PCI DSS 4.0 Req. 11.4.5, ISO 27001 A.8.22 |
| IoT devices (hardware, firmware, radio) | Can a device be opened, read, cloned or controlled? | OWASP IoT Security Testing Guide, NISTIR 8259 |
| IoT cloud, apps and APIs | Can one device or user reach another’s data or commands? | OWASP ISTG, OWASP API Top 10 |
Work through it in order. Each layer often supplies the foothold for the next.
What should a wireless penetration test check? (Wi-Fi checklist)
A wireless penetration test checks whether someone within radio range, with no credentials, can join, decrypt, impersonate or pivot from your Wi-Fi. Use these items to scope the test and to judge whether a proposal is complete.
1. Discovery and RF mapping
- Inventory every SSID, BSSID, band (2.4, 5 and 6 GHz) and channel at each site, including hidden SSIDs
- Compare what’s broadcasting against your approved access point list
- Walk-test signal leakage past the building edge: parking lots, lobbies, shared floors and neighbouring tenants
- Flag legacy networks still running WEP, WPA (TKIP) or open authentication
- Record which networks bridge to which VLANs, so later findings can be tied to business impact
2. Encryption and authentication
WPA2-Personal (pre-shared key)
- Test whether the passphrase can be recovered offline from a captured handshake or PMKID
- Check how widely the key is shared, and whether it was rotated after staff or vendor departures
- Confirm WPS is disabled
WPA2/WPA3-Enterprise (802.1X with RADIUS)
- Confirm clients validate the RADIUS server certificate and are pinned to the right server name. Without this, an evil-twin AP can harvest credentials
- Identify the EAP methods in use, and flag PEAP-MSCHAPv2 or EAP-TTLS/PAP configured without strict certificate validation
- Check that device and user certificates are issued, revoked and expired properly
- Verify that wireless accounts can’t reach more of the network than their role needs
WPA3-Personal (SAE)
- Check whether WPA3 runs in transition mode alongside WPA2. Transition mode lets a fake AP push clients down to WPA2
- Confirm Protected Management Frames (802.11w) are required, not optional
- Confirm access point and controller firmware is patched for published SAE weaknesses, such as the 2019 Dragonblood issues
3. Rogue and evil-twin access points
- Look for unauthorized APs, personal hotspots and consumer routers plugged into corporate ports
- Stand up a controlled evil-twin AP that copies a corporate SSID, then see which clients connect and what they send
- Test whether your wireless intrusion detection or prevention system (WIDS/WIPS) raises an alert, and how long it takes
- Confirm someone actually receives and acts on that alert, not just the console
4. Guest network and segmentation
- Confirm guest Wi-Fi can’t reach internal subnets, management interfaces or IoT VLANs
- Test client isolation, so guests can’t reach each other
- Check captive portal bypasses, such as MAC address spoofing of an already-authenticated device
- From each wireless network, try to reach the cardholder data environment and other sensitive zones (required as segmentation evidence under PCI DSS)
5. Clients and infrastructure
- Check whether corporate laptops and phones auto-join open or look-alike networks
- Review controller and AP management interfaces for default credentials, exposed admin pages and outdated firmware
- Confirm SNMP, Telnet and other management protocols aren’t reachable from wireless client networks
What should an IoT penetration test include? (IoT checklist)
An IoT penetration test should cover the whole device ecosystem, not just the device. That means the device, the radio protocols it uses, the network it sits on, and the cloud, mobile app and APIs behind it. The OWASP IoT Security Testing Guide and NISTIR 8259 organize the work around these same layers.
6. Device inventory and ownership
- Keep a current inventory of every connected device: cameras and recorders, badge readers, smart locks, building controllers, printers, sensors, scanners and gateways
- Record an owner, a location, a firmware version and a vendor support end date for each one
- Find devices nobody owns. These are often the ones with default settings and no patching
7. Scope the device layers explicitly
Ask the vendor to state in writing which of these layers are in scope for each device model:
- Network services and exposed management interfaces
- Credential and account handling, including default and shared credentials
- Firmware and software update process, including how updates are verified
- Radio protocols in use, such as Bluetooth Low Energy, Zigbee, Z-Wave or LoRaWAN
- Physical access to the device, if it sits in a public or shared space
A proposal that says “IoT testing” without listing layers per device is hard to compare and hard to hold to account.
8. Segmentation and pivot risk
- Confirm IoT devices sit on their own network segment, separate from corporate users and sensitive systems
- Test whether a compromised device on that segment could reach the corporate network, the cardholder data environment or other critical zones
- Check that device-to-cloud traffic is restricted to the destinations each device actually needs
9. IoT cloud, mobile app and APIs
- Confirm each device has its own identity and credentials, not a key shared across the fleet
- Check that one user or device can’t read or control another’s data or devices
- Verify that traffic between devices, gateways, apps and cloud is encrypted and that certificates are validated
- Include the companion mobile app and its APIs in scope, since they often hold the most direct path to device control
10. Operational technology and building systems
In factories, warehouses, hospitals and smart buildings, some devices can’t tolerate active testing. Agree up front which systems get passive observation only, which can be tested in a maintenance window, and who on your side can halt testing immediately.
How do you run a wireless pentest without disrupting operations?
You avoid disruption by agreeing on rules of engagement before testing starts. Put these in writing:
- Sites, buildings, floors and SSIDs in scope, plus anything explicitly out of scope, such as neighbouring tenants’ networks
- Which tests could interrupt service, whether they are allowed, and during which hours
- Testing windows for sensitive environments. Hospitals, production floors and retail sites often need after-hours work
- A named contact on each side who can pause testing immediately
- How captured credentials and traffic are handled, stored and destroyed
- Whether your security team will be told in advance, or whether detection and response are part of what’s being tested
What should a wireless and IoT pentest report include?
A good report lets leadership see the risk and lets engineers fix it. Ask for:
- An executive summary in business terms, with overall risk by site
- A findings list rated by severity (CVSS or equivalent), each with evidence, affected sites or devices, and clear remediation steps
- A map of which networks and devices could reach which sensitive systems
- Rogue AP and wireless inventory results, which you can keep as PCI DSS evidence
- A methodology section naming the standards followed, such as NIST SP 800-115 and the OWASP IoT Security Testing Guide
- Test dates, tester names and scope, so auditors can match the report to the period under review
Which compliance frameworks ask for wireless and IoT testing?
| Framework | What it asks for | How the checklist helps |
|---|---|---|
| PCI DSS 4.0 | Req. 11.2.1: test for unauthorized wireless access points at least every three months. Req. 11.4.5: test segmentation controls | Rogue AP sweep (item 3) and segmentation tests (items 4 and 8) |
| SOC 2 | No wireless test is mandated, but pentest results are common evidence for the monitoring and risk-assessment criteria | A dated report with scope and remediation tracking |
| ISO 27001:2022 | Annex A 8.20 (networks security), 8.22 (segregation of networks), 8.8 (technical vulnerabilities) | Wi-Fi checks (items 1 to 5) and segmentation tests (item 8) |
| HIPAA Security Rule | Risk analysis and technical safeguards for systems handling ePHI | Testing of clinical Wi-Fi and connected medical or building devices |
What should you ask a wireless pentest vendor before signing?
- Which standards does your methodology follow?
- Do you test on site, remotely with a drop device, or both? How many sites can you cover?
- How do you test WPA2/WPA3-Enterprise and rogue AP detection without disrupting users?
- Which IoT layers and radio protocols are in scope for each device model?
- Will the report include segmentation evidence our auditor will accept?
- Who does the testing, and what wireless and IoT experience do they have?
- How do you handle and destroy credentials and data captured during the test?
Wireless and IoT pentest FAQ
What’s the difference between a wireless pentest and a wireless vulnerability scan?
A scan lists access points, configurations and known weaknesses. A pentest tries to use those weaknesses to join networks, capture credentials or reach internal systems, and shows what an attacker could actually do. Many teams use scans between annual pentests.
How often should we test wireless networks?
PCI DSS requires a rogue access point check at least every three months. A full wireless pentest is usually done once a year, and again after major changes such as a new site, new controllers or a move to WPA3.
Is WPA3 enough on its own?
No. WPA3 makes offline password cracking harder, but transition mode, optional management frame protection, weak client settings and poor segmentation can still leave networks exposed.
Can wireless and IoT be tested in one engagement?
Yes, and it’s often more useful. The most realistic attack paths cross both, such as a weak IoT device on a poorly segmented wireless network.
How are wireless and IoT pentests priced?
Pricing depends on scope: the number of sites, SSIDs, device models and radio protocols, and whether testing must happen after hours. Ask vendors to price against a written scope so proposals can be compared fairly.
What’s the difference between a wireless pentest and a wireless red team exercise?
A pentest aims to find as many weaknesses as possible in the agreed scope. A red team exercise pursues a specific objective covertly, and also tests whether your team detects and responds.
Get an outside view of your wireless and IoT risk
If you want an independent team to work through this checklist across your sites and devices, talk to Canary Trap about a wireless security assessment.
