Wi-Fi Security Audit for Business: What a Wireless Assessment Must Measure in 2026

Most Wi-Fi assessments answer the wrong question. They answer "is the network encrypted", which it almost always is, and the answer has been yes since 2003. The question that decides whether an unauthorised device got onto your network last quarter is narrower and much harder: who can associate to which service set, from how far away, with what credential, and what can they reach once they are on. Every one of those clauses is a measurement, and none of them is a setting you can read off a controller dashboard.

That gap matters more than it used to, because the perimeter moved. In Verizon's 2026 Data Breach Investigations Report - 22,000 confirmed breaches across 145 countries, published in May 2026 - exploitation of vulnerabilities became the most common initial access vector for the first time, at 31 per cent, up 55 per cent year on year, while credential abuse fell to 13 per cent. The report also reclassified remote access devices into a dedicated network asset category, which rose from 1.5 to 5 per cent of breaches. Wireless sits at the intersection of both findings: an access point is remote access infrastructure with no cable, and the credential that opens it is a shared secret that walks out of the building in a thousand pockets.

So this is not another page about choosing WPA3 over WPA2. It is about what a wireless assessment should measure, in what order, with what arithmetic behind the findings, what the test cannot prove at all, what the standards actually require when they say "quarterly", and how to read a report and a price. If you are buying an assessment, the sections on enterprise certificate validation, on segmentation as a test rather than a VLAN, on scope and cost, and on the report worth paying for are the ones to read first.

The radio perimeter ends where the signal ends, not where the wall is

Every other security perimeter on your estate is defined by an interface you can enumerate: a firewall rule set, a VPN concentrator, a set of public IP addresses. The wireless perimeter is defined by physics, and physics does not respect a lease boundary. This is the single fact that makes wireless assessment different from network assessment, and it is the one most often skipped in the report.

The arithmetic is not exotic. In free space, received signal falls by about 6 dB every time you double the distance, and a wall costs somewhere between 3 and 5 dB if it is plasterboard and 10 to 20 dB if it is concrete, brick or a lift shaft. A cell designed for a -67 dBm edge at the far corner of an open-plan floor is therefore still delivering roughly -73 to -77 dBm thirty metres outside the building, through two walls, which is comfortably inside the sensitivity of a laptop card with an external antenna. A directional antenna bought for forty pounds adds 9 to 12 dBi in one direction, which is another doubling-and-a-half of range. The practical consequence: the car park, the pavement, the floor above and the neighbouring unit are all inside your radio perimeter whether or not they are inside your building.

Channel plan matters for the same reason, in the opposite direction. The 2.4 GHz band offers three non-overlapping 20 MHz channels in North America and most of Europe, which is why a dense deployment puts every third access point on the same channel and why co-channel interference makes "the Wi-Fi is slow" the most common complaint that turns out to be a security finding: an access point transmitting at full power to beat interference is an access point transmitting into the street. The 5 GHz band offers around 25 non-overlapping channels depending on regulatory domain, and 6 GHz offers up to 59 twenty-megahertz channels in the United States, which is 1,200 MHz of spectrum. More channels means smaller cells and more access points, and more access points means a larger inventory of radios that someone has to account for.

The inventory is where the assessment starts, because a reconciliation needs a denominator. An office with 120 staff and a controller claiming 28 access points routinely turns out to have 34 radios transmitting under its name: the 28 managed ones, two standalone units left from an old fitting in a meeting room, a printer broadcasting its own setup network, a facilities building-management bridge, and a couple of ranges belonging to the unit next door that happen to broadcast a similar SSID. The scan finds all of them. Only an authorised list tells you which are yours.

One number to make the point concrete: beacons are transmitted every 100 milliseconds by default, so a single radio advertising three SSIDs produces about 30 beacon frames a second, and a thirty-second passive scan at one location hears roughly 290 beacons per radio in range. A walk-round of three floors produces thousands of observations that collapse to a few hundred distinct BSSIDs. Anyone who presents that list without saying which entries matched your authorised inventory has given you a signal survey, not a security assessment.

Four questions the engagement should answer, in this order

Wireless findings that arrive as a list of techniques - WPS enabled, PMF optional, WPA2 in use - are impossible to prioritise because they are not stated in terms of what an attacker gains. The same set of observations becomes actionable when it is organised around four questions, each of which produces a different kind of evidence.

• Who can associate? Which SSIDs exist, what each one accepts as a credential, how strong that credential is in practice, and whether any of them can be joined without a credential at all. This is the authentication question, and its evidence is a per-SSID record of the authentication method actually negotiated by each client type, not the method configured on the controller.
• What can they reach once associated? This is the segmentation question, and it is answered with a matrix rather than an adjective. From each SSID, which internal hosts and ports are reachable, which are not, and what path exists between guest, corporate, IoT and management networks. "Guest network is isolated" is a claim; "guest to corporate: 0 of 14 tested internal targets reachable, guest to printer subnet: 3 of 3 reachable" is a finding.
• What else is transmitting? Rogue and shadow access points, evil twins, and client devices that will associate with anything broadcasting a remembered name. The evidence is an observation list reconciled against the authorised inventory, plus a per-device-class record of automatic join behaviour.
• Is anyone checking? The process question, and increasingly the one that matters for compliance. If the organisation must test quarterly, the assessment should report whether the internal record exists, what it contains, and whether unauthorised devices found in previous sweeps were actually removed rather than documented.

Ordering matters because each answer constrains the next. A network where the corporate SSID uses a 12-character random PSK has a different segmentation problem from one where it uses the company name: the first needs a reachability test to find the paths an attacker would use after joining legitimately, the second needs the credential treated as already public.

Pre-shared keys, and the arithmetic that decides whether yours survives

A pre-shared key is not a password in the ordinary sense. It is the input to a key derivation that produces a pairwise master key, and in WPA2-Personal the material needed to attack that derivation travels on the air every time a device joins. Two capture methods are relevant. The classic four-way handshake capture needs a client to associate while the tester is listening, which is why testers used to send deauthentication frames to force a reconnection - a technique that knocks real devices off a production floor and is one of the reasons active testing needs a change window. Since 2018 the PMKID method has been cheaper: a single frame in the association exchange carries enough material to attempt the derivation offline, with no client and no deauthentication at all.

What follows is not a cracking exercise but a keyspace calculation, and it is the number that belongs in the report. WPA2-Personal runs the passphrase through 4,096 iterations of PBKDF2-HMAC-SHA1 before the first guess, which is why a graphics card manages hundreds of thousands of guesses per second rather than billions. At 500,000 guesses per second - a realistic figure for one modern GPU on this workload - the search times for a full keyspace sweep are:

• Eight lowercase letters - 2.1 x 10^11 candidates, about 4.8 days.
• Eight characters from lowercase and digits - 2.8 x 10^12 candidates, about 65 days.
• Ten characters from lowercase and digits - 3.7 x 10^15 candidates, about 232 years.
• Twelve lowercase letters - 9.5 x 10^16 candidates, roughly 6,000 years.

The honest reading of that table: a modern assessment does not crack a random twelve-character key, so any report claiming to have "recovered the PSK" is telling you the key was guessable - a dictionary word, a pattern, the company name plus a year - and that is the finding worth reporting. The other finding is the one that needs no arithmetic at all: one key is one credential for every device and every person who has ever joined, including the ones who left two years ago. Measure the time since the last rotation, the number of people who know the key, whether it is on a card in the kitchen drawer, and whether it is the same key as the guest network. That last one is not a hygiene point; it is the enabling condition for the SSID confusion attack described further down.

WPA3-Personal changes the arithmetic rather than eliminating the problem. Simultaneous Authentication of Equals replaces the pre-shared-key handshake with an exchange that cannot be attacked offline from a passive capture, and it provides forward secrecy so that a key recovered later does not decrypt earlier traffic. What it does not do is make a weak passphrase safe against an attacker who can interact with the access point repeatedly - SAE limits guesses per session rather than making guesses expensive - and it does not protect clients that still negotiate WPA2 because the network runs in transition mode. WPA3 also drops support for the older TKIP cipher, which is one reason legacy devices are exactly the population that keeps a WPA2 SSID alive.

Wi-Fi Protected Setup is worth a sentence because it survives in more estates than anyone expects, usually enabled by a vendor default on a printer, a camera or a domestic-grade access point bought by a department. The eight-digit PIN is split for validation into two halves of four and three digits, which reduces the effective search from a hundred million combinations to 11,000 attempts, and on chipsets vulnerable to the offline variant known as Pixie Dust the PIN falls out of a single exchange without any guessing at all. If WPS is enabled anywhere in the estate, the PSK is effectively public regardless of how long it is.

Enterprise authentication: what 802.1X proves, and the setting that voids it

An 802.1X deployment has three parts: a supplicant on the device, an authenticator (the access point or controller), and a RADIUS server that makes the decision. The security property people believe they have bought is per-device credentials with no shared secret. The property they actually get depends on one client-side configuration choice and on how the inner authentication method works, and both are routinely wrong.

The strong configuration is EAP-TLS with mutual certificate authentication: the device presents a certificate, the server presents a certificate, and both validate. There is no password to phish and no shared secret to rotate. The weak but extremely common configuration is PEAP with MSCHAPv2 inside it: the server proves itself with a certificate, the client proves itself with a username and password inside the TLS tunnel. That is sound in principle and catastrophic in one specific case, because PEAP allows the client to skip validating the server's certificate, and many device defaults, provisioning scripts and help-desk instructions do exactly that.

When the client does not validate the server certificate, or validates any certificate signed by any CA without checking the expected server name, an attacker broadcasting your SSID from a car park becomes a credential collection point. The client connects, the inner MSCHAPv2 exchange happens against the attacker's server, and the attacker captures a challenge-response pair that can be attacked offline to recover the account password - which, on a domain-joined laptop, is frequently the same password that opens email, the VPN and the file share. Corporate wireless credentials are not a wireless problem; they are a domain credential problem with a radio delivery mechanism.

The test is therefore per device class rather than per SSID, because each operating system's supplicant has its own defaults and its own prompts: Windows, macOS, iOS, Android, and the long tail of handheld scanners, label printers, medical carts and building-management panels that support 802.1X badly if at all. For each class the assessment should record whether server certificate validation is on, which CA is trusted, whether the expected server name is configured, and whether a user can override the warning. The remediation is a managed configuration profile pushed by MDM or group policy - not a memo - and it has to be verified by observation on the device, because a profile that failed to apply looks identical, from the controller, to one that applied.

Two more enterprise details belong in the same section. First, RADIUS logging: the server knows which device authenticated, when, and from which access point, and that record is the only reliable way to answer "was this device on the network in March". An 802.1X deployment whose authentication logs are kept for seven days and read by nobody is a compliance artefact rather than a control. Second, the management plane: modern wireless is a cloud service, and the controller account is now an internet-facing administrative login with the ability to push a configuration to every access point in the estate. Phishing that account is a faster route to a rogue SSID than any radio technique, so its multi-factor status and its named-user count belong in the scope even though they are not wireless findings in the traditional sense.

Transition mode, downgrade, and the SSID that is not authenticated

WPA3 has been required for Wi-Fi Alliance certification of new devices since 1 July 2020 and is mandatory in the 6 GHz band, so it is reasonable to assume the access points support it. It is not reasonable to assume clients use it. WPA3 includes a transition mode that lets WPA3 and WPA2 devices share one SSID, and transition mode is the standard way to migrate an estate without a flag day. It is also a downgrade surface: an attacker who broadcasts a WPA2-only beacon with the same SSID and a matching credential can cause a client to negotiate the weaker handshake, and the resulting capture is crackable with the arithmetic above. This is the mechanism behind the transition-mode downgrade in the Dragonblood work published by Mathy Vanhoef and Eyal Ronen in 2019, alongside timing and cache side channels in the SAE password-to-curve derivation tracked as CVE-2019-9494 and CVE-2019-9495.

A separate and more recent design issue is worth understanding because it survives good passwords. The IEEE 802.11 standard does not always bind the network name into the key derivation, and the four-way handshake does not include a protected exchange of the SSID. In the SSID Confusion attack, published in 2024 and tracked as CVE-2023-52424, a client that intends to join a trusted network can be tricked into joining a different network that uses the same credentials, while its user interface continues to display the trusted name. Every tested device was vulnerable. The attack requires the attacker to be in range and to control a network whose credentials match, which makes credential reuse across SSIDs - one passphrase for corporate and guest, one RADIUS server name presented by several networks - the enabling condition rather than a detail.

The practical check is short and belongs in every enterprise report. Which SSIDs still run WPA2-Personal, and when was that key last changed? Does any SSID use the same passphrase as another? Are 6 GHz SSIDs WPA3-only, and do the 2.4 and 5 GHz SSIDs run transition mode? Do the RADIUS server certificates present distinct common names per network, as the researchers recommend, or is one name reused everywhere? Are WPA3-only profiles pushed to managed devices, so that the client cannot fall back even when an attacker invites it to?

Protected Management Frames deserve their own line because the setting has three states and only one of them helps. PMF, defined in 802.11w, protects deauthentication and disassociation frames, which are otherwise unauthenticated and trivially forged. Forgeable deauthentication is the enabler for both denial of service and evil-twin coercion: knock every client off the real access point and they reconnect to whatever is loudest. WPA3 requires PMF, and it is mandatory for newly certified devices, but an estate upgraded in place can be left at "optional" - and optional provides almost no protection, because an attacker targets the client population that does not support it. The assessment should report the negotiated state per SSID per device class, not the configured state, since a client without PMF support negotiates it away even when the access point requires it.

Rogue access points, shadow IT and evil twins are three different problems

These three phrases are used interchangeably in vendor marketing and they describe unrelated risks with unrelated fixes. Conflating them produces a report that recommends buying a wireless intrusion prevention system for a problem that is actually a procurement decision about meeting-room coverage.

A rogue access point in the strict sense is an unauthorised transmitter connected to your wired network. That connection is what makes it serious: it bypasses the firewall, the NAC posture check and the logging that everything else on the estate passes through, and it typically presents an open or weakly protected SSID inside your building. It is found by correlating what the radio hears with what the wire knows - switch MAC address tables, Power over Ethernet draw per port, DHCP fingerprints, port authentication logs. A radio sweep alone can see the transmitter but cannot tell you whether it is plugged into your switch or into the flat upstairs, and that distinction is the entire finding.

Shadow IT is the same object with a different cause: a legitimate need served badly. The £40 travel router in the annex exists because the guest network does not reach the annex. The printer's own access point exists because the vendor's setup workflow enables it by default. The building-management bridge exists because the HVAC contractor needed remote access and nobody asked. Shadow access points are found by inventory reconciliation, and they are fixed by removing the need rather than by blocking the device - a distinction that matters because the block is what gets reverted two weeks later.

An evil twin is an attacker's access point impersonating your SSID, usually with a stronger signal and often with a captive portal that harvests credentials. It is not connected to your network at all, and no amount of wired-side correlation will find it. What finds it is client behaviour testing: does a managed device automatically join a network that presents the remembered SSID with a different BSSID, a different security configuration, or a different certificate? The answer is frequently yes, and it is the single most useful thing a wireless assessment can demonstrate to a non-technical audience, because the demonstration takes thirty seconds and the fix is a managed profile.

• Rogue: radio observation plus wired correlation, disposition "plugged into port 14 on floor 2, PoE draw 12 W, unknown OUI".
• Shadow: inventory reconciliation against the authorised list, disposition "sanctioned device never added to the register" or "business need, remediate coverage".
• Evil twin: client auto-join behaviour per device class, disposition "profile requires manual join" or "no certificate pinning, credential exposure".

The reason this taxonomy matters commercially: an estate with 34 radios and an authorised list of 28 has six findings, and every one of them needs a different owner. Reporting them as "six rogue access points" guarantees that none of them gets fixed.

Guest, BYOD and IoT: segmentation is a test, not a VLAN

Almost every organisation can state its segmentation design. Very few can state what is actually reachable across it, which is why the assessment tests reachability rather than reading the configuration. Three mechanisms are routinely confused: layer-2 client isolation, which stops wireless clients talking to each other on the same SSID; layer-3 access control, which stops traffic between subnets; and egress filtering, which stops a device reaching the internet except where it needs to. A guest network with the first two and no egress filtering still lets a compromised guest laptop reach a command-and-control server, and a guest network with all three can still leak through the printer.

The leakage paths worth testing are specific. Broadcast and multicast traffic crossing from guest to corporate is common, because mDNS and SSDP are discovery protocols that printers, casting devices, smart speakers and some VoIP handsets answer cheerfully across a VLAN boundary if the reflector is enabled. Captive portal bypass is common, because portals frequently cache authorisation by MAC address, allow an over-broad walled garden, or can be stepped around with a DNS tunnel. Device-to-device reachability within a guest SSID is common, because client isolation is a per-SSID checkbox that nobody re-verifies after a firmware update.

The test produces a matrix: rows are source SSIDs, columns are destination classes - corporate hosts, management interfaces, printer subnet, IoT subnet, internet - and the cells contain the number of targets reachable out of the number attempted. Fourteen internal targets from guest is a defensible sample for a 120-person office; the number that matters is not the count but the ratio, and the specific hosts that answered. A single reachable management interface on a switch or a hypervisor console outweighs thirteen correctly blocked file shares.

IoT segmentation deserves separate treatment because the devices cannot participate in the security model. Cameras, sensors, door controllers, TVs and building systems frequently have no 802.1X supplicant, no certificate store, no patch path and a cloud dependency that requires outbound access to a vendor domain you cannot audit. Putting them on a separate SSID is the beginning, not the end: the SSID needs its own credential (never a reused passphrase), its own VLAN, an egress allowlist limited to the vendor endpoints the device actually needs, and no route to anything internal except the specific management host that administers it. The assessment should test the egress rule by attempting outbound connections to a set of destinations outside the allowlist, because a "restricted" IoT VLAN that permits all outbound traffic is a separation in name only.

BYOD sits awkwardly between the two. Personal devices on a corporate SSID inherit the corporate trust model with none of the corporate control, and personal devices on the guest SSID are fine until someone needs email on a phone. The defensible pattern is a third SSID for employee-owned devices with 802.1X user credentials, no access to internal file shares, and an MDM conditional access check for anything that touches mail or the intranet. Whether that exists is a finding; whether it is enforced is a second finding, and the second one is the one that requires looking at a device rather than at a policy document.

Passive monitoring versus active testing, and where the legal edge sits

Wireless work splits into two modes that prove different things, and a report that does not label which mode produced each finding is hard to act on. Passive work listens without transmitting: it collects beacons, probe requests, association frames and the security configuration each radio advertises. It is safe on a live production floor, it can be done continuously, and it is the only mode that reliably answers "what else is transmitting in this building". What it cannot do is test authentication or reachability, because both require joining.

Active work transmits: association attempts, credential tests, portal bypass, deauthentication to test PMF, reachability probes from a client that is genuinely associated. It produces the findings that matter most and it carries real risk. Deauthentication testing on a warehouse floor stops handheld scanners mid-shift. A rogue access point test that accidentally bridges to the production VLAN is an outage authored by the tester. Credential testing against live accounts can lock out real staff if the domain policy counts wireless authentications toward lockout thresholds. This is why active testing needs a written change window, a named person who can stop the test, and a fallback plan for each technique that is run.

The legal edge is narrower than most internal stakeholders assume and wider than most testers state. Three points are worth putting in writing. First, radio monitoring is regulated differently across jurisdictions: receiving is generally permitted, but transmitting on frequencies you are not licensed for is not, and the rules on interception of communications apply to wireless frames exactly as they apply to a wiretap. Second, interference with networks you do not own is generally prohibited - the deliberate transmission of deauthentication or jamming frames against a third party's network is not a security test, whatever the motive, and it is the single most common way an enthusiastic internal team creates a legal problem for the organisation. Third, in a shared building or a serviced office, the neighbouring SSIDs your scan records are other tenants' networks; recording their BSSIDs and signal strength as part of a coverage map is ordinarily fine, capturing their client traffic is not.

Data handling belongs in the same paragraph because a wireless assessment generates unusually sensitive artefacts. Packet captures contain credentials, session tokens, internal hostnames, and occasionally personal data from staff devices. The defensible pattern is to hash and retain only what supports a finding, to state retention in the engagement letter, to encrypt the evidence at rest, and to delete captures on a schedule rather than keeping them "in case". MAC addresses are widely treated as personal data when they can be linked to a person, so a client-observation log is a personal data processing activity with the obligations that follow from it.

Five things a wireless test cannot tell you

Scope discipline is what separates a security assessment from a sales document. These five exclusions should be stated in the report rather than discovered by the client after the invoice.

• Whether the physical space is controlled. A test can show that an access point is reachable in a riser cupboard; it cannot tell you whether that cupboard is locked, who holds the key, or whether the cleaner props it open. Physical control is a separate assessment.
• Whether a client device is already compromised. A laptop with malware associates legitimately and behaves perfectly on the radio. Wireless testing observes the network, not the endpoint.
• Whether an insider is exfiltrating with legitimate access. Someone with a valid credential on an authorised SSID is indistinguishable, at layer 2, from a diligent employee. That is a detection and data-loss question.
• Whether the wireless management plane is secure. The controller account, the cloud tenant, the API keys and the firmware supply chain are adjacent systems. They are frequently the weakest link and they need their own scope.
• Whether the wired network behind the access points is well configured. A wireless assessment stops at the first switch port. VLAN hopping, spanning tree, ARP behaviour and switch management interfaces belong to the internal network test.

Stating these exclusions is not an admission of weakness. It prevents the most common failure mode of wireless work, which is a client who reads "no critical findings" as "the network is secure" when what the report actually says is "the radio layer is configured sensibly and nobody looked at anything behind it".

The obligations that make this recurring rather than a one-off

The reason wireless testing is quarterly in regulated environments rather than annual is that a network changes every time someone buys a device. The requirements are specific enough to quote, and each one implies an evidence trail rather than a good intention.

PCI DSS v4.0.1, requirement 11.2.1 is the clearest. It requires the organisation to test for the presence of wireless access points and detect and identify all authorised and unauthorised wireless access points on a quarterly basis, and - where automated monitoring is not in place - to perform the scan every quarter and document the results, with procedures that include incident response for unauthorised devices. Two details are routinely missed. The requirement applies even where wireless is prohibited, in which case the test is looking for the access point someone brought in anyway. And the scenario changes from "scan quarterly" to "monitoring is in place and alerts" only if the monitoring is genuinely continuous and generates an alert, which means a WIPS nobody configured to email anyone does not discharge it.

ISO/IEC 27001:2022 carries it less prescriptively through control A.8.20 on network security, which expects networks to be segmented, secured and managed, and A.8.1 on inventory of assets, which is the control that fails first in practice: an estate that cannot produce an authoritative access point list cannot claim either. GDPR Article 32 requires appropriate technical measures, and a shared pre-shared key with no rotation is a weak candidate; where staff device monitoring is part of the assessment, the personal-data obligations attach to the observation data as described above. Sector rules add deadlines rather than requirements - NIS2 and the financial-sector operational resilience regimes both expect network segmentation to be demonstrable, and cyber-insurance questionnaires have converged on asking for evidence of wireless segmentation and rogue access point detection specifically, usually without accepting a policy document as evidence.

The practical consequence is a two-tier routine. A quarterly internal sweep, documented, meets the recurring obligation cheaply and produces the evidence trail. An annual external assessment tests the things an internal sweep cannot - credential strength, downgrade behaviour, per-device-class certificate validation, segmentation reachability - and resets the baseline. Organisations that buy only the annual test usually discover, at audit time, that they cannot evidence the quarters in between.

What it costs, and the four variables that move the number

Published pricing for wireless assessment is broad because the unit of work is not obvious. Rates are quoted per site or per day, and the number that matters is always a product: sites multiplied by SSIDs multiplied by authentication paths multiplied by device classes. A single-site office with one SSID and a pre-shared key is a fundamentally different job from a six-site estate with corporate, guest, IoT and BYOD SSIDs, three of which use 802.1X from different RADIUS realms.

• Single site, 1 to 5 access points, one or two SSIDs: commonly quoted at around £3,000 to £4,000 for one to two tester days, roughly $4,100 to $5,500 at prevailing rates.
• Multi-floor office, 6 to 20 access points, enterprise authentication plus guest isolation: around £4,000 to £8,000, roughly $5,500 to $10,900.
• Campus, multi-building, IoT and operational technology in scope: £8,000 to £20,000 and upwards, roughly $11,000 to $27,000 and beyond.
• Travel and out-of-hours work add £1,000 to £5,000 on multi-site engagements, and out-of-hours testing is often necessary rather than optional on production floors.

The four variables that move a quote most, in order of impact. Site count, because each additional site costs a day of travel and a day of testing before any analysis. Authentication paths, because each distinct combination of SSID, EAP method and device class is a separate test; four device classes against two enterprise SSIDs is eight certificates to inspect, not one. Segmentation depth, because reachability matrices scale with the number of source networks and target classes, and the target list has to be agreed in advance or the test has no denominator. Testing window, because a warehouse that runs 24 hours forces the work into a narrow window at premium rates, and a hospital forces a great deal of coordination.

What should not move the price: the number of employees. A 400-person office with 20 access points is not four times the work of a 100-person office with the same 20. Quotes that scale with headcount are pricing on the wrong variable, and quotes that omit a retest line are pricing the first half of the job - the retest is what converts a finding into a closed finding, and it should be in the scope from the start rather than sold afterwards.

What a report worth paying for contains

A wireless report is judged by whether someone who was not in the room can act on it. Five elements separate a usable report from a document that reads well and changes nothing.

A coverage denominator. Which sites were visited, which floors and which rooms, which channels and bands were scanned, which SSIDs were in scope, what was walked and explicitly what was not. A report that says "a wireless survey was performed" without a coverage statement cannot be relied on during an audit, because there is no way to distinguish a thorough test from a partial one.

Evidence per observation. Each finding should carry the BSSID, the SSID, the band and channel, the signal strength, the timestamp, and the location to a level of precision that lets a facilities team find the device. The inventory reconciliation should show the authorised list, the observed list and the difference between them as three separate columns, because the difference is the finding.

Severity expressed as reachability. Not "high" as a bare label, but what an attacker with this finding gains: physical proximity required, a credential required, a victim device required, and what the next hop is from there. A weak PSK on a guest network that reaches nothing internal is a different matter from the same PSK on a corporate SSID with file-share access, and a severity scale that cannot express that difference is decoration.

A configuration change, not a product. "Enable PMF as required on all SSIDs and disable WPS" is actionable. "Deploy a next-generation wireless security platform" is not, and it is usually the line that tells you the report was written by someone with a licence to sell. Where a product genuinely is the answer - continuous rogue detection at scale, for instance - the report should say what it must be configured to do and how that configuration will be verified.

Retest criteria agreed in advance. Each finding should state the specific observation that will close it. That single practice eliminates most arguments about whether remediation is complete, because both sides agreed the test before the fix was attempted.

The tell-tale signs of a report not worth filing: recommendations that name a standard rather than a setting, no inventory reconciliation, no evidence that segmentation was actually tested, a severity scale with no reachability dimension, and an executive summary that describes the tooling used instead of what an attacker could reach.

The remediation order that reduces risk fastest

Findings arrive in severity order, but fixes should not be attempted in severity order, because several of them are the same configuration push and two of them are procurement projects. The sequence below closes reachable paths first and defers the expensive items until the cheap ones have removed the obvious ways in.

1. Rotate the pre-shared key and split the guest network. Hours of work, closes the largest single exposure: a credential held by everyone who has ever joined. The new guest SSID gets its own key, client isolation and a bandwidth cap. Do not accept "we will rotate at the next maintenance window"; this is a controller change.
2. Set PMF to required and disable WPS everywhere. Hours. Removes forged deauthentication as an enabler and removes the 11,000-attempt PIN path entirely. Verify by observation on a client, not by reading the configuration page.
3. Push managed profiles with certificate validation and WPA3-only where supported. Days to weeks, because it needs MDM coverage of every device class. This is the fix for the credential-harvesting exposure described earlier, and it is the one item where a partial rollout leaves the whole population exposed.
4. Segment IoT onto an egress-filtered SSID and remove shadow access points. Days. Removing shadow access points means fixing the coverage or access need that created them, or they return.
5. Build the inventory and the detection capability. Weeks. An authoritative access point register, a documented sweep procedure, and either continuous monitoring configured to alert or a quarterly manual sweep with wired-side correlation.
6. Retire WPA2-only SSIDs and TKIP. A quarter, because it requires replacing or isolating legacy devices. This is the item that is always deferred and always still open at the next assessment.

The order is deliberately not the same as the severity order in the report. A critical finding on a legacy device that nobody can replace for two quarters should not block the two hours of controller work that removes the shared-key exposure in the meantime, and a report that presents them as equals invites the organisation to do nothing until the harder one is solved.

A five-day assessment, worked through

Abstract scope documents hide the shape of the work. Here is a realistic five-day engagement: three sites, 34 access points, six SSIDs across corporate, guest, IoT and BYOD, 140 staff, two enterprise SSIDs using 802.1X from different RADIUS realms, four device classes.

Day one is authorisation and inventory. Kickoff with the named stop authority present, the signed authorisation confirming sites, SSIDs, channels and testing windows, and the authorised BSSID export from the controller. The rest of the day is a passive walk of each floor with a laptop in monitor mode, producing a per-floor observation set, followed by the first reconciliation: 41 distinct BSSIDs observed against 34 authorised, plus a coverage map annotated with where signal leaks past the building line.

Day two is authentication. Per SSID, per device class: negotiate and record the actual method, test PMF by sending a deauthentication and observing whether the client is protected, attempt the WPA3 transition-mode downgrade against a test client, capture a PMKID where a pre-shared key is in use, and assess the key against a policy-derived wordlist rather than a general one. Two of the six SSIDs turn out to reuse the same passphrase, which is the enabling condition for SSID confusion and is written up as such.

Day three is enterprise and the management plane. For each device class, inspect server certificate validation, trusted CA and expected server name on the supplicant. Read the RADIUS logs to establish whether authentication history exists and for how long, review the controller account list and its multi-factor status, and test whether a deauthentication storm on one floor causes clients to reconnect to a rogue access point with a matching SSID.

Day four is segmentation and the rogue hunt. From guest, IoT and BYOD, attempt the agreed target matrix; attempt portal bypass and check whether authorisation is cached by MAC; test IoT egress against the allowlist. Then correlate the three unexplained BSSIDs from day one against switch MAC tables and PoE draw to establish which are plugged into the estate and which belong to the neighbours.

Day five is retest and debrief. Anything fixed during the week is retested and evidenced; the reachability matrix is finalised; the evidence pack is hashed and handed over with a retention statement. The deliverable is deliberately counted rather than described: 41 observed BSSIDs against 34 authorised, 11 distinct authentication paths tested, 4 device classes inspected, 60 segmentation assertions across 4 source SSIDs and 15 targets, 3 findings closed in-week, 9 open with named owners.

Two things about that schedule are worth noting. The first is that only two of the five days involve transmitting anything, which is why the change window can be narrow. The second is that the analysis is not a separate phase appended at the end - the reconciliation, the matrix and the retest are produced as the week proceeds, which is what makes the report land within days rather than weeks.

The quarterly routine you can run yourself

The recurring obligation does not require an external team every quarter; it requires a documented, repeatable procedure with a record. A defensible internal sweep for a small estate takes about an hour per site and produces artefacts an assessor will accept.

1. Export the authorised list. BSSIDs from the controller, with their locations, dated. If this export does not exist, creating it is the first quarter's work.
2. Walk the site with the scanner. Floors, stairwells, meeting rooms, comms cupboards, and the perimeter - including outside the building line, because that is where an attacker sits. Record band, channel, signal strength and location per observation.
3. Reconcile three ways. Observed but not authorised is a candidate rogue. Authorised but not observed is a dead entry or a powered-down device. Authorised and observed with an unexpected security configuration is a change-detection finding.
4. Investigate the unknowns against the wire. Switch MAC table, PoE draw per port, DHCP fingerprint, and the known vendor OUIs. "It is the shop next door" is a legitimate disposition, but it needs the evidence that established it.
5. Disposition and ticket every candidate. Removed, sanctioned and added to the register, or investigated and closed as external. An unclosed candidate is an open finding, and reviewers ask for the closure rate.
6. Sign and file. Date, tester, coverage, observations, dispositions, and the ticket references. That single document is the quarterly evidence.

What the routine does not replace is the annual external test, because a sweep answers "what is transmitting" and not "what can an attacker with a credential reach". That distinction is worth stating plainly to whoever owns the compliance calendar, since the two activities are frequently conflated into one line item and then only the cheaper one is funded.

Where 6 GHz and Wi-Fi 7 change the picture

Two technology shifts are relevant in 2026, and both change what an assessment should check rather than making the assessment unnecessary.

The 6 GHz band is the more consequential. It is WPA3-only and requires Protected Management Frames, so the newest spectrum cannot be run in legacy mode at all, and it also prohibits the older TKIP cipher. Physically, higher frequencies attenuate faster, which means 6 GHz cells are smaller and leak less far past the building line - a genuine security benefit that arrives with a cost: more access points for the same coverage, and therefore a larger inventory to reconcile. A 6 GHz deployment also creates a blind spot worth testing: 6 GHz-only clients cannot see 2.4 GHz rogue access points, so a rogue hunt conducted only from a 6 GHz-capable laptop misses exactly the cheap, legacy devices an attacker would deploy.

Wi-Fi 7 certification has tightened the baseline further. Devices certified under it must support WPA3 with the SAE hash-to-element derivation, Protected Management Frames, and beacon protection, and open networks must use Enhanced Open rather than sitting unencrypted. Beacon protection is the interesting one, because it finally gives clients a mechanism to verify that a beacon actually came from the network it claims - the direction of travel for the SSID confusion problem described earlier, though client support and controller support have to line up before it delivers that property in practice.

The practical implication for an assessment scoped in 2026 is that "we run WPA3" is now a statement about three different things that need to be checked separately: 6 GHz SSIDs, which are WPA3-only by rule; 5 GHz and 2.4 GHz SSIDs, which are frequently in transition mode; and client profiles, which may still be configured to accept a WPA2 fallback. A network can be WPA3-certified at the access point, in transition mode on the air, and negotiating WPA2 on the client, all at the same time. Only the last of those three is a security property, and it is the one that requires a device in hand to observe.

Scoping the work, and the boundary we will not cross

Every engagement starts with written authorisation that names the sites, the SSIDs, the bands, the testing windows and the named person who can stop the test at any point. That is not paperwork; it is the difference between an assessment and an incident, and it is the document an organisation needs when a neighbouring tenant complains about packets on their network.

Three boundaries are fixed, and they apply to internal teams as much as to external testers. We test only networks the client owns or has documented authority over - in a shared building, that means the client's SSIDs and infrastructure, and nothing belonging to other tenants. We do not jam, flood or deauthenticate networks we are not authorised to test, and we treat interference with third-party wireless as out of scope regardless of intent. And we do not build capability for covert surveillance of people: the radio work here is about the network, the evidence is about configuration and reachability, and client-observation data is minimised, retained on a stated schedule and deleted.

Within those boundaries the deliverable is a specific set of artefacts: the authorised inventory, the reconciled observation list with dispositions, the per-device-class authentication record, the segmentation reachability matrix, the rogue and evil-twin analysis with wired-side correlation, a severity model expressed as reachability, a remediation order with owners, and retest evidence for everything closed. If any of those is missing, the engagement is not finished, whatever the invoice says.

If you are planning a wireless assessment for a regulated environment, or you need to evidence a quarterly sweep you have not been running, the sensible first step is a scoping call that produces two things: an authorised BSSID export, and an agreed target list for the segmentation matrix. Those two documents determine most of the cost and nearly all of the value.