--- title: "The Handshake Was Captured. The Network Was Not." description: "A Wi-Fi assessment methodology that separates radio visibility, network identity, authentication, client trust, and post-association access before calling a wireless test successful." date: 2026-08-13 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/posts/wifi-handshake-evidence-chain/ --- ## Wi-Fi evidence in 60 seconds Wireless assessments are unusually vulnerable to impressive but weak conclusions. A scanner lists dozens of SSIDs. A capture file contains a four-way handshake. A test access point advertises the same name as a corporate network. A client sends a probe request. Each observation is useful. None, by itself, proves that an unauthorized user can enter the network or reach anything valuable. The reason is structural: Wi-Fi places several independent security decisions between a radio frame and a business system. An assessment becomes credible only when it states which decision was tested, what changed, and where the evidence stops. This note presents a field methodology for authorized Wi-Fi testing. It deliberately avoids a target or reusable attack recipe. Examples use controlled identities and reserved names. Any test that can disconnect users, solicit credentials, imitate production infrastructure, or transmit outside the agreed area requires explicit written permission, a maintenance window, and a tested stop condition. ## A wireless connection is six different claims “The network is vulnerable” compresses too much. Replace it with six smaller questions: 1. **Radio presence:** Can the assessor observe or transmit on the relevant channel from the approved location? 2. **Network identity:** Does the observed BSSID, SSID, security advertisement, and controller record belong to the scoped WLAN? 3. **Association:** Will a client and access point agree on capabilities and establish a link? 4. **Authentication:** Can the client prove possession of the expected password, certificate, or enterprise identity? 5. **Client trust:** Does the client verify that it is speaking to the expected network and authentication server? 6. **Authorization:** After connection, which VLAN, peers, services, and application actions can that identity actually reach?

A handshake belongs near the middle of the chain. It is not evidence that the credential was recovered, a client trusted a rogue service, or an internal route became reachable.

Each step needs its own evidence. A beacon proves an access point advertised parameters. A successful association proves negotiated link state. An EAP success proves an authentication conversation completed for a particular identity. A DHCP lease proves address assignment. None of those automatically proves access to another wireless client, a management interface, or an internal application. ## Start with identity, not the SSID name An SSID is a label, not a cryptographic identity. Multiple access points legitimately advertise the same name. A neighboring organization can choose the same name. A test access point can copy it. Hidden SSIDs do not change this property; clients and access points still exchange enough information to operate the network. Before active testing, build an authorized WLAN identity record: | Signal | Why it matters | | --- | --- | | SSID and BSSID set | Separates a service name from the radios that implement it | | Band, channel, width | Prevents testing a similarly named neighbor on an overlapping channel | | RSN/AKM/cipher advertisement | Shows which authentication and encryption modes the AP offers | | PMF capability and requirement | Distinguishes management-frame support from enforced negotiation | | Controller/AP inventory | Correlates over-the-air observations with owned infrastructure | | Physical test zone | Defines where transmission is permitted and where leakage is measured | | Expected VLAN or role | Gives post-association testing a known policy outcome | The controller inventory is a control-plane view; the capture is a client-side view. Differences between them deserve investigation. They can reveal stale radios, transition modes, misapplied WLAN profiles, or a device that does not belong to the deployment. The mismatch is a candidate until the asset owner confirms identity. ## Read the authentication family before choosing a test The same SSID name can represent materially different security models. ### Personal networks WPA2-Personal uses a shared secret. Risk depends on the passphrase policy, who knows it, how it is rotated, whether per-device credentials exist, and what access is granted after connection. Capturing a valid exchange can create material for an authorized password-strength test, but capture success is not password recovery. WPA3-Personal replaces the WPA2 pre-shared-key exchange with SAE. Treat WPA2/WPA3 transition mode as a separate configuration, not as “WPA3 enough.” Record what a specific client actually negotiated; the strongest mode advertised by the AP is not necessarily the mode used by every client. A senior assessment asks whether the organization can retire shared secrets, isolate legacy devices, use per-device identities, and detect downgrade or compatibility exceptions. It does not celebrate the existence of a capture file. ### Enterprise networks WPA2/WPA3-Enterprise delegates authentication through 802.1X and EAP, commonly to a RADIUS service. The client must authenticate the server before it releases a reusable password or completes mutual certificate authentication. A trusted certificate chain alone is insufficient if the client accepts any server name under that chain; expected RADIUS server names are part of the decision. EAP-TLS changes the credential model because the client proves possession of a private key rather than sending a password-derived response. That does not make every deployment safe automatically. Certificate issuance, identity mapping, revocation, device ownership, fallback EAP methods, and the post-authentication role still require validation. ### Open and guest networks An open SSID can be intentional. The useful question is what compensating controls exist: captive portal behavior, encrypted application traffic, client isolation, guest-to-corporate separation, session expiry, abuse controls, and monitoring. Encryption on the radio and authorization to internal systems are separate properties. ## What a handshake proves “Handshake” is often used as if it named one security outcome. It is better to identify the exact conversation: - an authentication or association exchange; - a WPA2 four-way handshake; - an SAE exchange; - an EAP identity exchange; - an EAP method negotiation; - a TLS server certificate and tunnel establishment; - an EAP success followed by key establishment. For every capture, record the endpoints, timestamp, channel, negotiated security suite, and the specific frames that make it complete for the intended analysis. A file that merely contains traffic near the right SSID is not a validated artifact. Then write the conclusion narrowly: ```text Observed: a complete WPA2 key-establishment exchange for the authorized lab client Supports: an offline strength assessment against the approved canary credential Does not support: credential recovery, network admission, or internal access ``` This phrasing prevents the tool output from outrunning the evidence. ## Four high-value test families ### 1. Credential resilience without credential spillage For a Personal network, use a canary passphrase provisioned specifically for the assessment or an isolated replica of the production policy. Agree on the allowed candidate set, compute budget, stop time, and evidence retention before testing. Report the tested policy and time-to-result, not the secret itself. The strongest negative control is a second canary that complies with the intended policy and remains unrecovered under the same bounded test. That comparison demonstrates the difference between a weak credential and a merely captured handshake. Production credentials should not be copied into reports, terminal history, screenshots, or shared archives. If the objective can be met with a canary, there is no reason to expose a real secret. ### 2. Enterprise server identity validation In Enterprise Wi-Fi, a rogue authentication service is useful only if a client is willing to trust it. The test should therefore target the client's decision, not users. Use an isolated lab SSID and an assessor-controlled test identity. Present a RADIUS certificate that fails one intended property at a time: unexpected name, untrusted issuer, expired validity, or missing server-authentication purpose. The client should fail before releasing reusable credentials or completing authentication. Never ask production users to accept a surprise certificate prompt.

The test is strongest when only one certificate property changes. A managed client should reject unexpected server identity without transferring the decision to an untrained user.

Windows documents separate checks for certificate signature, validity, trusted root, server name, and Server Authentication purpose. Apple deployment guidance similarly allows administrators to anchor trust to specific certificates or expected RADIUS hostnames. Android 12 requires enterprise server certificate validation, while Android 13 adds a Trust on First Use path for networks without a preinstalled authenticated key. These platform differences belong in the test matrix. ### 3. Management-frame resilience without uncontrolled disruption Protected Management Frames (PMF) protect selected management exchanges and are required by WPA3. Do not infer enforcement from an AP configuration label. Inspect the advertised capability and the actual client association: capable and required are different states, and transition deployments can produce different results across clients. Active resilience testing can disconnect users and affect adjacent networks sharing airtime. It needs its own authorization line, bounded channel and transmit settings, a dedicated client, a brief window, and a stop trigger. The objective is not “send as many frames as possible.” It is to answer a precise question such as whether a negotiated PMF-capable client rejects an unprotected management action and whether monitoring records the attempt. Evidence should include the negotiated PMF state, the single approved stimulus, client continuity, AP/controller telemetry, and a negative control against a lab profile where protection is intentionally different. Availability impact is not acceptable collateral evidence. ### 4. Client trust and controlled look-alike networks An access point can advertise a copied SSID. That only proves that names are copyable. A meaningful client-trust test asks whether a managed client automatically associates, whether it validates the Enterprise authentication server, and which information it releases before rejecting the connection. Use a dedicated test device and a purpose-built lab profile. Do not clone a production SSID in a place where uninvolved devices or people may connect. Do not collect real user credentials. If a client should be managed, test the deployed profile—not whether a person can be persuaded to ignore a warning. The safe outcomes are explicit: - the client does not auto-join an untrusted profile; - an Enterprise client rejects the unexpected RADIUS identity; - no reusable credential leaves the client; - the wireless monitoring stack creates a correlated alert; - the test AP and profile are removed after validation. ## Association is the start of the network assessment Once an approved test identity connects, the work changes from radio testing to access-control testing. Record the assigned address, DNS, gateway, VLAN or role, and the policy the controller says it applied. Then compare intended and observed reachability.

Validate each destination class independently. Guest isolation, infrastructure protection, internal application access, and internet egress are different policies.

For guest and BYOD services, include client-to-client isolation. A guest that cannot reach a corporate subnet may still attack another guest on the same broadcast domain. Conversely, a blocked peer probe does not prove the internal ACL is correct. A minimum reachability matrix should include: | Source identity | Destination class | Expected | Evidence | | --- | --- | --- | --- | | Guest canary | Other guest canary | Deny | Both directions tested; isolation telemetry retained | | Guest canary | AP/controller management | Deny | Explicit management-plane targets only | | Guest canary | Corporate test service | Deny | Known live service provides a valid negative control | | Corporate device canary | Approved internal test service | Allow | Confirms test path and policy are functioning | | Quarantined device | Remediation service | Allow only | Role assignment and limited route verified | | Any wireless role | Unapproved DNS/egress | Per policy | Resolver and egress identities recorded | Use known live canary services for denials. A timeout against a nonexistent host proves nothing about the firewall. ## A field workflow that survives tool changes ### Phase 0 — write the RF rules of engagement Wireless scope needs more than an SSID list. Record: - authorized SSIDs, BSSIDs, bands, channels, sites, and physical test boundaries; - allowed test adapters, MAC addresses, test clients, and canary identities; - passive-only versus active phases; - whether look-alike AP, association, authentication, management-frame, and segmentation tests are allowed; - maximum transmit power, time windows, and forbidden neighboring networks; - emergency contact, stop conditions, evidence retention, and cleanup ownership. An SSID name without BSSID ownership and location context is not sufficient authorization to transmit. ### Phase 1 — establish a passive baseline Observe before transmitting. Correlate beacons and probe responses with the controller inventory. Capture security suites, PMF flags, channel use, expected AP density, and obvious outliers. Repeat from agreed perimeter locations to measure exposure without implying that signal presence is a vulnerability. The output is an inventory with confidence levels, not a list of “rogue APs.” ### Phase 2 — model client populations Group clients by security behavior rather than brand: - managed Enterprise clients with pinned trust; - Enterprise clients that rely on user prompts or TOFU; - WPA2-Personal legacy clients; - WPA3-SAE clients; - transition-mode clients; - guest/BYOD devices; - IoT or operational devices with limited supplicant controls. One successful modern client does not validate the oldest supported population. Select representative canaries and record OS, driver/firmware, profile source, and negotiated mode. ### Phase 3 — change one security property For each active test, hold the client, location, identity, and radio conditions stable. Change one property: certificate name, trusted issuer, advertised AKM, PMF requirement, credential policy, or assigned role. This makes the cause defensible and the remediation precise. ### Phase 4 — validate both control planes Preserve the client-side and infrastructure-side views: - over-the-air negotiation; - client decision and user-visible behavior; - AP/controller association record; - RADIUS authentication result and policy attributes; - DHCP/DNS assignment; - firewall or segmentation decision; - wireless monitoring alert. If those views disagree, do not average them into a conclusion. The disagreement is the investigation. ### Phase 5 — repeat and clean up Repeat the expected success and expected denial. Remove test profiles and certificates, stop test APs, revoke canary identities if appropriate, delete transient network objects, restore modified policy, and confirm that monitoring no longer sees the assessor infrastructure. ## Evidence quality and finding thresholds | Observation | Classification before impact validation | | --- | --- | | SSID visible outside the building | Exposure measurement | | Unknown BSSID advertises a corporate SSID | Rogue-AP candidate | | WPA2 handshake captured | Analysis artifact | | Weak canary recovered under approved limits | Credential-policy weakness demonstrated | | Client prompts for an unexpected RADIUS certificate | Trust configuration weakness; credential release still unproven | | Managed client releases a reusable response to an untrusted lab RADIUS service | Client-trust impact demonstrated | | Test identity receives the wrong VLAN or role | Authorization-policy failure | | Guest canary reaches a live corporate canary service | Segmentation impact demonstrated | | Unprotected management stimulus disconnects a PMF-required canary | Resilience failure on the tested combination | Do not assign severity from the tool name or attack category. Tie it to the strongest controlled effect: recoverable production-equivalent credential policy, credential disclosure, unintended network role, cross-client access, internal service reachability, or bounded availability failure. ## Common conclusions that do not survive review **“We captured a handshake, so the Wi-Fi password is crackable.”** Capture completeness and password strength are separate. Use a bounded canary comparison. **“The SSID can be cloned, so evil twin is confirmed.”** SSID names are expected to be copyable. Show the managed client's unsafe trust decision and what it releases. **“WPA3 is enabled, so deauthentication is solved.”** Verify the mode negotiated by each client and whether PMF is required, not merely capable or advertised. **“The guest network is isolated because RFC1918 probes timed out.”** Test known live canaries, peer isolation, management surfaces, DNS, IPv6, and policy telemetry. **“RADIUS used a valid certificate, so server validation is correct.”** Confirm the intended issuer, server name, purpose, validity, and client prompt behavior. ## Remediation priorities The most durable improvements reduce shared assumptions: 1. Maintain an owned BSSID/AP inventory and continuously compare it with over-the-air observations. 2. Prefer WPA3 where the supported client population permits it; isolate legacy transition requirements. 3. Replace broad shared secrets with per-device or per-user identities where operationally feasible. 4. For Enterprise Wi-Fi, deploy managed profiles that validate an expected CA and RADIUS server name, and prevent users from overriding failed validation. 5. Prefer EAP-TLS for managed populations when certificate lifecycle and identity mapping are mature. 6. Require PMF where compatibility allows and verify actual client negotiation. 7. Apply role-based segmentation after authentication; protect management planes and test client isolation. 8. Correlate wireless monitoring with controller, RADIUS, DHCP, and firewall telemetry. 9. Remove stale SSIDs, unused EAP methods, transition exceptions, and orphaned device credentials. 10. Retest with representative legacy and modern clients instead of validating only the AP configuration. ## Evidence matrix | Signal | What it proves | What it does not prove | Independent check | | --- | --- | --- | --- | | Beacon advertises WPA3 and PMF | The AP offers those capabilities in that frame | A client negotiated them or policy requires them | Inspect association state and controller record | | Complete WPA2 handshake | Required exchange material was observed for the endpoints | Secret recovery or network admission | Use an approved canary and bounded strength test | | Enterprise client rejects wrong server name | Name validation worked in the tested profile | Other issuers, clients, or EAP methods are safe | Change one certificate property per test | | RADIUS Access-Accept exists | Authentication service accepted the canary identity | Correct VLAN, ACL, or reachable services | Correlate returned attributes and observed role | | DHCP lease assigned | The client received network configuration | Peer isolation or internal segmentation | Test known live destinations and policy logs | | Guest cannot reach peer canary | Isolation held in the tested direction and state | Corporate routes and IPv6 are blocked | Complete the destination matrix both ways | | Wireless monitor alerts on lab AP | Detection observed the approved simulation | Response, containment, or coverage at other sites | Correlate timestamps and run a documented negative control | ## Research outcome The useful unit of Wi-Fi research is not the packet capture. It is the disagreement between what the access point advertises, what the client verifies, what the authentication service accepts, and what the network authorizes afterward. A captured handshake may be the beginning of that investigation. It is never permission to skip the remaining decisions. By separating radio evidence, identity, authentication, client trust, and post-association access, an assessment becomes reproducible, safer to operate, and much harder to overstate. ## Primary references - [NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks](https://www.nist.gov/publications/guidelines-securing-wireless-local-area-networks-wlans-0) - [Android Open Source Project: Enterprise Wi-Fi Trust on First Use](https://source.android.com/docs/core/connect/wifi-tofu) - [Microsoft: EAP for network access and server certificate validation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/network-access) - [Apple: Connect Apple devices to 802.1X networks](https://support.apple.com/en-ca/guide/deployment/depabc994b84/web) - [HPE Aruba: WPA3-Enterprise modes](https://arubanetworking.hpe.com/techdocs/aos/wifi-design-deploy/security/modes/wpa3-enterprise/) - [Cisco: WPA3 and Protected Management Frames](https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-17/config-guide/b_wl_17_17_cg/m_wpa3.html) - [Cisco Meraki: Wireless Client Isolation](https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Wireless_Client_Isolation)