15 Wi-Fi Security: Access and Segmentation Controls

iot

wi-fi

security-review

15.1 Start With the Decision

One shared Wi-Fi key can turn a lost sensor into a fleet-wide breach. Access, identity, and network segments must limit that blast radius.

15.2 Route Overview

This is part 1 of 2. Continue with Wi-Fi Security: Provisioning and Recovery Evidence.

15.3 Part Objectives

Compare Wi-Fi access controls for device fleets.
Design segmentation rules that isolate device services.

15.4 Chapter Roadmap

Start With the Wireless Story
In 60 Seconds
Quick Check: Wi-Fi Security
Security Provisioning Review Flow
Security Provisioning Record
Authentication Mode Review
Provisioning Path Review
Credential Handling
Segmentation And Service Rules

15.5 Start With the Wireless Story

Make First Join Safe and Repeatable

Picture a new room sensor that must join the right building network. A nearby stranger should not be able to claim it. A support worker should not need one shared secret for every device.

An access point is the local radio device that joins Wi-Fi devices to a network. Provisioning is the setup path that gives a device the right network details and its own trust record. Start with a clear proof of ownership, such as a physical action, a short code, or a managed claim.

Give each device its own identity. Check the network identity before sending secrets. Protect setup data while it moves. End the setup window quickly. Record who enrolled the device, when it happened, and which rule set it received.

Then test the full life. Replace a lost secret. Move the device. Change the network name. Remove an old owner. Reset and enrol again. A safe path must recover without falling back to a common password or an open setup mode.

Use Practitioner for enrolment and recovery records. Use Under the Hood for key exchange, protected frames, enterprise trust, and attack limits.

Picture a new sensor joining a shared Wi-Fi network. The join must prove who the device is, who may set it up, and what it can reach.

First, name the owner, join path, secret, and service rule. Then record how access is changed or removed when the device or staff role changes.

A shared secret is easy to start, but one leak can affect many devices. A unique identity is safer to revoke, yet it needs more care and support.

That is the simple story, but it cannot prove a safe join or full site plan. The later records and checks test each part of that claim.

Use the Practitioner sections to review setup, access, and recovery. Use the Under the Hood sections to study key steps, attack paths, and trust limits in more depth.

Plain check

Name the device owner. Name the network owner. Name the setup user. Name the service need.
Pick the join path. Limit who can start it. Set a short join time. Record the result.
Give each device identity. Keep each secret safe. Limit where it lives. Plan safe removal.
Check the first join. Check a repeat join. Check a wrong user. Check a wrong network.
Test a weak secret. Test a lost device. Test a copied setup code. Test a failed update.
Limit network reach. Limit service reach. Block unused paths. Log each denied path.
Keep setup traffic local. Keep admin steps clear. Keep recovery safe. Give each step an owner.
Plan staff change. Plan device sale. Plan device loss. Plan final removal.
Save the device build. Save the join mode. Save the access rules. Save the test date.
Recheck after code change. Recheck after router change. Recheck after owner change. Keep proof current.
Use Practitioner to review. Use deeper key checks. Test one attack path. State each bound.
Review the whole life. Remove stale access. Fix weak recovery. Repeat the join test.

Wi-Fi security starts before the first normal packet. The story runs from onboarding and credentials through WPA mode, identity proof, key rotation, fleet recovery, and deprovisioning, because a device that is easy to join must also be safe to operate.

15.6 In 60 Seconds

A Wi-Fi security and provisioning review checks whether an IoT device can be joined, authenticated, isolated, recovered, updated, and removed without exposing credentials or creating a flat network risk.

The review should not approve a design because it uses a familiar Wi-Fi password, a newer security label, or a convenient onboarding flow. It should record the device role, authentication mode, credential owner, provisioning path, storage behavior, recovery path, segmentation boundary, update path, monitoring signal, and retest triggers.

Only perform Wi-Fi security testing on networks and devices you own or are explicitly authorized to review. This chapter focuses on defensive design review, not attack instructions.

15.7 Learning Objectives

By the end of this chapter, you will be able to:

review Wi-Fi authentication and provisioning decisions for IoT devices
distinguish shared-password, per-device, certificate, and managed onboarding models
identify credential exposure, reset, revocation, update, and recovery risks
check whether network segmentation and service rules limit device compromise impact
write a bounded security and provisioning decision with owner and retest triggers

Quick Check: Wi-Fi Security

15.8 Security Provisioning Review Flow

Use Figure 15.1 to keep security and onboarding decisions connected.

Before approving a provisioning design, inspect Figure 15.1 to follow security from the device threat model through its operational lifecycle.

Wi-Fi security provisioning flow showing threat model, authentication mode, provisioning path, credential lifecycle, segmentation, maintenance, and bounded decision record. — Figure 15.1: Wi-Fi security provisioning flow from threat model through authentication, onboarding, credentials, segmentation, maintenance, and bounded decision.

Read Figure 15.1 in sequence: define risk, select authentication, onboard the device, protect credentials, constrain network access, and maintain recovery. The final decision therefore includes reset, update, and support rather than ending when the device first joins.

The flow asks:

What device role and threat model are being reviewed?
Which authentication mode is used, and who owns credentials?
How does a headless device receive network credentials?
Where are secrets stored, rotated, revoked, and recovered?
What network boundary limits device compromise impact?
What update, reset, monitoring, and support path keeps the design maintainable?

15.9 Security Provisioning Record

Use Figure 15.2 to make the approval traceable.

Before signing off onboarding, inspect Figure 15.2 to make the security decision traceable across the device lifecycle. Authentication strength alone does not cover secret storage, recovery, segmentation, updates, or support.

Wi-Fi security and provisioning evidence record covering device class, credential owner, provisioning path, storage, segmentation, recovery, updates, monitoring, decision, and retest trigger. — Figure 15.2: Wi-Fi security and provisioning evidence record

Read Figure 15.2, move from device risk and credential ownership through provisioning and secret management, then inspect network boundaries, maintenance, monitoring, and reset paths. The accepted limits and retest trigger connect initial setup to the operational controls needed after ownership or network conditions change.

A useful record contains:

device class, location, power source, data sensitivity, command risk, and owner
selected Wi-Fi authentication mode and fallback modes that are allowed or blocked
provisioning path, pairing proof, timeout behavior, reset behavior, and user/support workflow
credential storage, rotation, revocation, factory reset, and lost-device handling
network segment, allowed services, blocked lateral paths, and monitoring signals
update path, certificate or password renewal path, firmware recovery, and support handoff
accepted decision, rejected alternatives, limits, owner, and retest trigger

15.10 Authentication Mode Review

Wi-Fi authentication is not one thing. Review the actual protocol, because each one fails differently.

15.10.1 WEP — never accept it

WEP encrypts traffic with the RC4 stream cipher using short, reused initialization vectors. The key can be recovered from ordinary captured traffic in minutes. WEP is broken for every use — if a device supports only WEP, treat that as a hardware end-of-life signal, not a setting to tune.

15.10.1.1 Why WEP Fails Mechanically

WEP forms RC4’s per-packet seed by concatenating a public 24-bit initialization vector with a shared 40-bit or 104-bit secret:

K_{\text{RC4}}=IV_{24}\,\|\,K_{\text{shared}}.

RC4 expands that seed into keystream $Z$ , and encryption is the stream-cipher operation $C=P\oplus Z$ . The IV must travel in the frame so the receiver can regenerate $Z$ . It is therefore observable, not a nonce protected by encryption. When an IV repeats under the same shared secret, the same keystream repeats and an observer obtains

C_1\oplus C_2=(P_1\oplus Z)\oplus(P_2\oplus Z)=P_1\oplus P_2.

A 24-bit space has only $2^{24}$ values. By the birthday effect, collisions become likely after roughly $\sqrt{2^{24}}=2^{12}=4096$ frames, far earlier than exhausting all IVs. Worse, weak-IV and RC4 key-scheduling relationships leak statistical information about shared-key bytes across a large capture. Merely avoiding one immediately repeated IV does not repair the construction.

WEP appends CRC-32 as an integrity check before encryption. CRC detects accidental transmission errors, but it is linear and unkeyed. An attacker who flips a chosen delta $\Delta$ in ciphertext can compute the corresponding CRC delta, so the receiver can accept a predictably modified plaintext without the attacker knowing the secret key. Confidentiality and integrity therefore fail for different but reinforcing reasons.

Known traffic accelerates capture. ARP frames have short, predictable fields. An attacker can replay a captured ARP request so the network emits many related ARP responses, rapidly collecting IVs and RC4 samples instead of waiting for ordinary use. The failure sequence is: observe a valid frame, stimulate repeatable traffic, collect public IV/ciphertext pairs, recover the shared key statistically, then decrypt or inject traffic.

WPA with TKIP was an emergency compatibility bridge. It retained RC4 but mixed the temporal key, transmitter address, and packet sequence into a per-packet key; expanded the sequence space; added replay checks and rekeying; and introduced the 64-bit Michael message-integrity code. Those changes made simple WEP-style reuse harder, but Michael was deliberately lightweight and weak. TKIP countermeasures react to repeated MIC failures, yet forgery and packet-injection techniques remained possible under constrained conditions. TKIP is now legacy, not a safe fallback: require AES-CCMP or an approved modern WPA2/WPA3 suite and remove WEP/TKIP rates and modes from acceptance tests.

15.10.2 WPA2-Personal (PSK) — the shared-password model

Every device shares one passphrase. From that passphrase plus the network name (SSID), each device derives a Pairwise Master Key (PMK); a 4-way handshake then derives the per-session keys that actually encrypt traffic. Two consequences matter for IoT:

An attacker who captures the 4-way handshake can run an offline dictionary attack against the passphrase with no further network access — a weak passphrase falls quickly.
Because the secret is shared, one extracted device credential compromises the entire fleet, and rotating it means reprovisioning every device.

Accept WPA2-Personal only for small, low-sensitivity fleets with a strong passphrase and a realistic rotation/reprovisioning plan.

15.10.3 WPA3-Personal (SAE) — a stronger shared-password model

WPA3-Personal replaces the PSK handshake with SAE (Simultaneous Authentication of Equals), built on the Dragonfly key exchange. SAE resists the offline dictionary attack (a captured exchange cannot be replayed against a wordlist) and adds forward secrecy, so a later passphrase leak does not decrypt previously captured traffic. Prefer it whenever both AP and device support it — but it is still a shared secret, so segmentation and rotation planning remain.

15.10.4 WPA2/WPA3-Enterprise (802.1X + EAP) — per-device identity

Enterprise mode removes the shared secret entirely. Each device authenticates through 802.1X, carrying an EAP exchange to a RADIUS server. With EAP-TLS, the device presents its own client certificate and validates the server’s — mutual authentication with no passphrase to leak. For IoT fleets this means:

a single device can be revoked individually (revoke its certificate) without touching the rest of the fleet
there is no shared credential to extract and reuse

The cost is operational: a certificate authority, per-device enrollment, renewal, revocation, and time sync. Choose Enterprise/EAP-TLS when the fleet is large or high-value and operations can run the identity lifecycle; it is usually too heavy for a handful of unmanaged consumer devices.

15.11 Provisioning Path Review

Provisioning is often the weakest part of a Wi-Fi IoT design.

For headless devices, review:

how the device enters setup mode
how the user or installer proves physical possession
whether setup mode times out and closes cleanly
how credentials are transferred and protected
how failed setup is retried without exposing secrets
how the device is reset, transferred, decommissioned, or reissued
how support can diagnose setup without asking users to reveal passwords

Common provisioning paths, by name:

SoftAP setup: the device hosts a temporary access point; a phone joins it and pushes the Wi-Fi credentials. Widely used, but the credentials cross that setup link, so it must close cleanly after onboarding.
BLE-assisted provisioning: a companion app sends the credentials over a short-range Bluetooth Low Energy link, keeping them off any open Wi-Fi.
WPS (Wi-Fi Protected Setup): PIN- or push-button onboarding. The PIN method is brute-forceable and should not be used — treat WPS support as something to disable.
Wi-Fi Easy Connect (DPP, Device Provisioning Protocol): the modern standard — scanning a QR code bootstraps a public-key exchange, so no plaintext passphrase is ever transferred. Prefer it when supported.
Zero-touch / managed enrollment: per-device certificates are pre-loaded at manufacture, so the device joins an Enterprise (EAP-TLS) network with no field secret entry at all.

None is automatically safe. Match the path to the device role, installer skill, support model, and recovery requirement.

15.12 Credential Handling

Do not accept a provisioning design until credential handling is clear.

Review questions:

Are credentials ever stored in source code, logs, screenshots, build artifacts, or support tickets?
Does the device store secrets in a protected device store where available?
Can a credential be rotated without replacing the device?
Can one lost or compromised device be revoked without disrupting the full fleet?
Is the reset path bounded, observable, and resistant to accidental exposure?
Is there a documented owner for credential renewal and retirement?

The decision should identify which secrets exist, where they live, who can change them, how they are removed, and what event forces a retest.

15.13 Segmentation And Service Rules

Wi-Fi authentication controls who joins. Segmentation controls what a joined device can reach.

Review segmentation evidence:

device segment name and purpose
allowed service destinations and protocols
blocked lateral movement to user, admin, and unrelated device areas
management path for updates and support
monitoring signal for unexpected destinations, retries, or join attempts
exception owner and expiry date for temporary access

Segmentation should be tested with the real service path. A device that can join securely but can reach every internal system is still a weak design.

15.14 Continue to the Next Part

Carry this evidence into Wi-Fi Security: Provisioning and Recovery Evidence, which begins with Recovery, Updates, And Removal.