38 Wi-Fi Security and Provisioning

In 60 Seconds

Wi-Fi security evolved from WEP (broken RC4 encryption, never use) through WPA (deprecated TKIP) to WPA2-PSK (AES-CCMP, minimum standard) and WPA3-SAE (Dragonfly handshake with forward secrecy, best available). WPA2-PSK shares one password across all devices – one stolen sensor exposes the entire network; WPA2-Enterprise (802.1X/RADIUS) provides per-device credentials with revocation capability. WPA3-SAE eliminates WPA2’s offline dictionary attack vulnerability through commit-confirm exchange and requires Protected Management Frames against deauth attacks. Network segmentation via VLANs isolates IoT devices from the main network – compromised sensors cannot pivot to laptops. Provisioning headless devices uses BLE (most secure, recommended), SoftAP (good UX), or SmartConfig (fast setup) – never WPS (PIN attack vulnerability) or hardcoded credentials (firmware dumps expose passwords). Defense in depth combines WPA2/3 encryption, 16+ character passwords, VLAN isolation, disabled WPS, and regular firmware updates.

Sensor Squad: Keeping Wi-Fi Safe and Secure

“Wi-Fi security is like protecting a clubhouse!” said Lila the LED. “WEP was a lock that anyone could pick. WPA was better but still old. WPA2 is a strong deadbolt, and WPA3 is a smart lock with a fingerprint scanner!”

“The biggest mistake is sharing ONE password with ALL devices,” warned Max the Microcontroller. “If someone steals one sensor and reads the password from its memory, they can access your ENTIRE network! WPA2-Enterprise gives each device its own unique key, so you can just revoke the stolen one.”

“But how do sensors WITHOUT screens get the Wi-Fi password?” asked Sammy the Sensor. “We cannot type it in!”

“Provisioning!” explained Bella the Battery. “The safest way is BLE – your phone sends the password over Bluetooth. You can also use SoftAP mode, where the sensor creates a temporary hotspot and you configure it through a web page. NEVER use WPS (it has a PIN attack) and NEVER put the password in your source code (anyone who downloads your code gets the password)!”

“And always put IoT devices on their OWN network,” added Lila. “That way, even if a sensor is hacked, the attacker cannot reach your laptop or phone!”

38.1 Learning Objectives

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

Compare Wi-Fi Security Protocols: Evaluate WEP, WPA, WPA2, and WPA3 for IoT deployments
Implement Secure Provisioning: Configure Wi-Fi credentials securely on headless IoT devices
Evaluate WPA3 Enhancements: Assess how SAE (Dragonfly), forward secrecy, and protected management frames improve IoT security over WPA2
Analyze Enterprise vs Personal Security: Select appropriate authentication modes for different IoT scales
Design Secure Wi-Fi Networks: Apply network segmentation, VLANs, and guest isolation for IoT
Troubleshoot Wi-Fi Security Issues: Diagnose authentication failures and security misconfigurations

38.2 Prerequisites

Before diving into this chapter, you should be familiar with:

Wi-Fi Fundamentals and Standards: Understanding basic Wi-Fi operation, 802.11 standards, and how Wi-Fi networks function is essential for comprehending security mechanisms
Networking Basics: Knowledge of network fundamentals including IP addressing, subnets, VLANs, and network segmentation concepts used in secure IoT deployments
Security Fundamentals: Basic cryptography concepts (encryption, hashing, public/private keys) are needed to understand WPA2/WPA3 security protocols

Ethics and Safety

This chapter discusses vulnerabilities and defensive controls. Only perform Wi-Fi security testing on networks you own or where you have explicit permission. When possible, use provided captures/simulations for analysis instead of capturing traffic on real networks.

Related Chapters

Deep Dives:

Wi-Fi Fundamentals and Standards - Wi-Fi protocol basics
Wi-Fi Architecture and Mesh - Mesh network security considerations
Wi-Fi Comprehensive Review - Security review and assessment

Comparisons:

Bluetooth Security - BLE vs Wi-Fi security approaches
Cellular IoT Security - Mobile network security
LoRaWAN Security - LPWAN security trade-offs

Security Context:

Security and Privacy Overview - Broader IoT security principles
Encryption Architecture and Levels - Understanding WPA2/WPA3 encryption
Device Security - Hardware-level IoT security
Network Design and Simulation - Secure network architecture

Learning Resources:

Quizzes Hub - Test Wi-Fi security knowledge
Videos Hub - WPA2/WPA3 explained visually

For Beginners: Wi-Fi Security Explained Simply

Wi-Fi security is like protecting your home. Just as you lock your doors and only give keys to trusted people, Wi-Fi security ensures only authorized devices can connect and that data is kept private.

The Four Security Generations:

Protocol	Analogy	Security Level
WEP	Broken lock (easy to pick)	Never use
WPA	Old lock (better but dated)	Avoid
WPA2	Modern deadbolt	Good for most IoT
WPA3	Smart lock with fingerprint	Best available

Two Key Concepts:

Authentication: Proving you’re allowed to connect (like showing your ID)
- PSK (Pre-Shared Key): Same password for everyone (home Wi-Fi)
- Enterprise: Each device has unique credentials (corporate Wi-Fi)
Encryption: Scrambling data so eavesdroppers can’t read it
- Without encryption: Anyone nearby can see your data
- With encryption: Data is scrambled and unreadable to others

Provisioning is how you get the Wi-Fi password onto a device. For smart home devices without screens (like sensors), this is tricky:

WPS: Press buttons on device and router (convenient but has security flaws)
Soft AP: Device creates its own Wi-Fi network; you connect and configure
Bluetooth: Use phone app to send Wi-Fi credentials via Bluetooth
QR Code: Scan a code to auto-configure

Simple Rule: Always use WPA2 or WPA3. Put IoT devices on a separate network from your main devices.

38.3 Wi-Fi Security for IoT

⏱️ ~12 min | ⭐⭐ Intermediate | 📋 P08.C37.U01

38.3.1 Security Protocols

Wi-Fi security protocol evolution showing legacy WEP and WPA as deprecated, WPA2 PSK and Enterprise as current minimum standard, and WPA3 SAE and Enterprise as modern best practice, with an upgrade path from older to newer standards — Figure 38.1: Wi-Fi Security Protocol Evolution

Alternative View: Wi-Fi Security Selection Decision Tree

This decision tree helps select the appropriate Wi-Fi security protocol for IoT deployments.

38.3.2 Security Protocol Comparison

Protocol	Encryption	Key Management	IoT Recommendation
WEP	RC4 (weak)	Static keys	❌ Never use
WPA	TKIP	PSK/Enterprise	❌ Deprecated
WPA2-PSK	AES-CCMP	Pre-shared key	✅ Minimum standard
WPA2-Enterprise	AES-CCMP	802.1X (RADIUS)	✅ Corporate IoT
WPA3-Personal (SAE)	AES-CCMP (128-bit)	SAE (Dragonfly)	🌟 Best for new devices
WPA3-Enterprise	AES-CCMP / GCMP (optional 192-bit suite)	802.1X (EAP/RADIUS)	🌟 High-security IoT

Cross-Hub Connections

Want to explore Wi-Fi security further?

Quizzes Hub - Test your understanding of WPA2/WPA3 protocols, authentication modes, and network segmentation with interactive quizzes
Videos Hub - Watch visual explanations of WPA2 4-way handshake, WPA3 SAE (Dragonfly) protocol, and enterprise authentication flows
Simulations Hub - Interactive Wi-Fi provisioning simulator showing SoftAP, BLE, and SmartConfig methods for headless IoT devices
Knowledge Gaps Hub - Common Wi-Fi security misconceptions (WPS security, MAC filtering effectiveness, PSK vs Enterprise trade-offs)

Hands-on labs:

Configure WPA2-Enterprise on ESP32 using certificates
Implement BLE provisioning for headless sensors
Set up VLAN isolation for IoT network segmentation
Analyze a WPA2 4-way handshake capture (provided PCAP) with Wireshark

Common Misconception: “MAC Filtering Provides Strong Security”

The Misconception: Many IoT deployments rely on MAC address filtering as primary security, believing only devices with whitelisted MAC addresses can connect to the network.

The Reality: MAC filtering provides minimal security and is easily bypassed:

Example (why this fails):

A building deploys sensors on an open Wi-Fi network and relies only on a MAC whitelist
MAC addresses are visible on the local network, so an attacker nearby can observe an authorized device’s MAC address
Many systems allow changing a network interface MAC address in software, enabling impersonation of whitelisted devices
Result: unauthorized access despite the whitelist

Why MAC Filtering Fails:

Trivially Spoofed: MAC addresses are Layer 2, transmitted in plaintext, easily changed in software
No Encryption: Even with MAC filtering, traffic is visible without WPA2/WPA3
Maintenance Burden: Every new device requires manual whitelist entry
False Sense of Security: Teams neglect real security (WPA2, segmentation) relying on MAC filtering

Proper Security Architecture:

Primary: WPA2/WPA3 encryption (not optional)
Segmentation: IoT VLAN isolated from main network
Optional Addition: MAC filtering as defense-in-depth (not primary control)
Monitoring: Intrusion detection to identify spoofed MACs

Key Takeaway: Never use MAC filtering as primary security. Always use WPA2-PSK minimum (16+ char password) or WPA3-SAE. MAC filtering can supplement but never replace encryption.

IoT Security Best Practices

Always use WPA2 or WPA3 - Never WEP or open networks
Strong passwords - Minimum 16 characters, random
Separate IoT network - VLAN or guest network isolation
Disable WPS - Known vulnerabilities in PIN method
Enable MAC filtering (optional) - Additional layer, not primary security
Regular firmware updates - Both AP and IoT devices
Monitor connected devices - Detect unauthorized access
Use VPN for remote access - Don’t expose IoT devices to internet

Never Use Open Wi-Fi for IoT Devices

Deploying IoT devices on open (no password) Wi-Fi networks is a critical security mistake:

Anyone within range can connect and intercept all traffic
No encryption means sensor data, commands, and credentials sent in plain text
Easy man-in-the-middle attacks - attacker can modify commands or inject malicious data
Device impersonation - attacker can pretend to be your sensor or controller

Even for “non-critical” sensors like temperature monitors, open Wi-Fi allows attackers to map your network, learn patterns (when you’re home/away), and pivot to attack other devices. Always use WPA2-PSK minimum, WPA3-SAE for modern deployments.

Hardcoded Wi-Fi Credentials: A Deployment Nightmare

Embedding Wi-Fi credentials directly in firmware causes severe problems:

Security risks:

Password visible in source code (GitHub, shared repos)
Firmware dumps expose credentials to anyone with physical access
One compromised device reveals network password

Operational issues:

Cannot deploy same firmware to multiple locations
Password change requires reflashing all devices
No way to provision devices in the field

Solution: Implement Wi-Fi provisioning via BLE, SoftAP, or SmartConfig. Store credentials in NVS (Non-Volatile Storage) and protect them at rest with flash/NVS encryption where supported—never in source code. For mass deployments, use WPA2-Enterprise with unique credentials (e.g., EAP-TLS certificates) per device.

38.4 Wi-Fi Security for IoT Deployments

38.4.1 Network Segmentation

Wi-Fi network segmentation architecture showing a router and firewall separating a main VLAN containing laptops and phones from an IoT VLAN containing cameras and sensors, with firewall rules that block IoT-to-main access while allowing internet connectivity — Figure 38.2: Network Segmentation Architecture for IoT Security

Security Architecture:

Separate IoT VLAN - Isolate IoT devices from main network
Firewall rules - IoT devices can’t access main network
IoT can access internet - For cloud connectivity
Main network can access IoT - For control/monitoring

38.4.2 WPA3 SAE (Dragonfly) Handshake

WPA3 introduces SAE (Simultaneous Authentication of Equals), also known as Dragonfly, which replaces WPA2-Personal’s PSK-based password authentication. SAE provides forward secrecy and makes offline dictionary attacks against captured handshakes impractical.

Sequence diagram of WPA3 SAE Dragonfly handshake showing commit and confirm exchanges between device and access point, ephemeral key derivation providing forward secrecy, and transition to encrypted communication, highlighting resistance to offline dictionary attacks — Figure 38.3: WPA3 SAE (Dragonfly) Handshake Protocol

WPA3 Security Improvements:

SAE (Dragonfly) authentication: Replaces WPA2‑PSK’s password→PMK derivation; captured handshakes don’t enable offline dictionary attacks (the 4‑way handshake still runs to derive session keys)
Forward secrecy: Session keys are derived from ephemeral exchanges, reducing the impact of password compromise on past sessions
Protected Management Frames (PMF): Required in WPA3, reducing deauthentication/disassociation spoofing attacks
Enterprise 192‑bit suite (optional): Stronger cipher suites for high-security deployments

WPA2 vs WPA3 Vulnerability:

WPA2-PSK: A captured 4-way handshake can enable offline password guessing if the passphrase is weak
WPA3-SAE: Eliminates the offline guessing vector; attackers must interact online with the AP (rate limited)

38.4.3 Implementing Device Authentication

// ESP32 WPA2-Enterprise (802.1X) Authentication
#include <Wi-Fi.h>
#include "esp_wpa2.h"

const char* ssid = "Enterprise-Wi-Fi";
const char* identity = "device_id_001";
const char* username = "iot_device";
const char* password = "device_password";

void setup() {
  Serial.begin(115200);

  Wi-Fi.disconnect(true);
  Wi-Fi.mode(WIFI_STA);

  // Configure WPA2-Enterprise
  esp_wifi_sta_wpa2_ent_set_identity((uint8_t *)identity, strlen(identity));
  esp_wifi_sta_wpa2_ent_set_username((uint8_t *)username, strlen(username));
  esp_wifi_sta_wpa2_ent_set_password((uint8_t *)password, strlen(password));
  esp_wifi_sta_wpa2_ent_enable();

  Wi-Fi.begin(ssid);

  while (Wi-Fi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("\nConnected to Enterprise Wi-Fi");
  Serial.println("IP: " + Wi-Fi.localIP().toString());
}

void loop() {
  // Your application code
}

For production WPA2-Enterprise deployments, prefer certificate-based EAP-TLS when possible and validate the RADIUS server certificate (CA pinning) to avoid credential theft via rogue access points. Also avoid hardcoding secrets—provision credentials securely and store them in NVS protected by flash/NVS encryption where supported.

38.4.4 Wi-Fi Provisioning Methods

Provisioning is the process of securely configuring Wi-Fi credentials on headless IoT devices (devices without screens or keyboards). Different methods offer trade-offs between security, user experience, and implementation complexity.

Comparison of Wi-Fi provisioning methods for headless IoT devices including WPS, SoftAP, Bluetooth, and SmartConfig, showing the setup flow between phone, device, and router with relative security ratings and user experience trade-offs — Figure 38.4: Wi-Fi Provisioning Methods for Headless IoT Devices

Provisioning Method Comparison:

Method	Security	User Experience	Implementation	Use Case
WPS	❌ Low (PIN attack)	Simple (button press)	Easy	❌ Avoid
SoftAP	⚠️ Medium	Good (web interface)	Medium	Consumer IoT
BLE	✅ High	Excellent (app-based)	Medium-Hard	Recommended
SmartConfig	⚠️ Medium	Very fast	Easy-Medium	Quick setup
QR Code	✅ High	Very easy	Easy	Simple devices
NFC	✅ High	Tap-to-configure	Medium	Phones available

Best Practices:

BLE provisioning for production IoT devices (most secure out-of-band method)
SoftAP for consumer devices where BLE not available (good UX)
Never use WPS in production (known PIN attack vulnerabilities)
Always encrypt credentials during provisioning (TLS, AES)
Factory reset option if provisioning fails or credentials need changing
Store credentials in NVS and protect them at rest (flash/NVS encryption + secure boot where supported), never in plaintext or hardcoded

Interactive: WPA2/WPA3 4-Way Handshake Animation

38.5 Worked Example: Smart Office — Wi-Fi Security Architecture for 3,200 IoT Devices

Scenario: SecureWork Ltd provisions a 12-floor corporate headquarters with 3,200 IoT devices. The CISO requires: (1) no single compromised sensor can reach corporate laptops, (2) credential revocation within 1 hour for any stolen device, and (3) zero-touch provisioning for maintenance staff without IT skills.

Device inventory and risk classification:

Device Type	Count	Risk Level	Data Sensitivity	Network Access Needed
Environmental sensors (temp, CO2)	2,000	Low	Non-sensitive	Cloud API only
IP cameras	400	High	Video streams	NVR + cloud backup
Smart locks	200	Critical	Access tokens	Door controller + cloud
Conference room displays	400	Medium	Calendar data	Microsoft 365 API
Occupancy counters	200	Low	Non-sensitive	Cloud API only

Security architecture — VLAN segmentation:

VLAN 10: Corporate (laptops, phones)    — WPA3-Enterprise, 802.1X with certificates
VLAN 20: IoT-Sensors (2,200 devices)    — WPA2-Enterprise, 802.1X with EAP-TLS
VLAN 30: IoT-Cameras (400 devices)      — WPA2-Enterprise, 802.1X with EAP-TLS
VLAN 40: IoT-Critical (200 smart locks) — WPA3-Enterprise, 802.1X with EAP-TLS + MACSec
VLAN 50: IoT-Displays (400 devices)     — WPA2-Enterprise, 802.1X with EAP-PEAP

Inter-VLAN firewall rules:
  VLAN 20 → Internet (HTTPS 443 only): ALLOW
  VLAN 20 → VLAN 10: DENY ALL
  VLAN 20 → VLAN 30: DENY ALL
  VLAN 30 → NVR (VLAN 30, port 554 RTSP): ALLOW
  VLAN 30 → Internet (HTTPS 443): ALLOW
  VLAN 30 → VLAN 10: DENY ALL
  VLAN 40 → Door controller (VLAN 40, port 8883 MQTTS): ALLOW
  VLAN 40 → VLAN 10/20/30: DENY ALL

Why WPA2-Enterprise, not WPA2-PSK?

PSK scenario: one shared password “SecureWork-IoT-2026!” for 3,200 devices
If 1 sensor is stolen and firmware dumped, attacker extracts PSK → full network access
Credential rotation: changing 1 PSK requires re-provisioning all 3,200 devices (estimated 160 person-hours)
Enterprise scenario: each device has a unique X.509 certificate issued by internal CA
If 1 sensor is stolen: revoke its certificate in RADIUS (< 5 minutes), all other devices unaffected
Cost of Enterprise: RADIUS server (FreeRADIUS on existing VM, EUR 0) + certificate management (step-ca, open source, EUR 0) + initial provisioning time (see below)

Provisioning method evaluation:

Method	Setup Time/Device	Security	Maintenance Staff Skill	Chosen For
BLE provisioning app	45 seconds	High (encrypted BLE channel)	Tap phone, scan QR	Sensors, counters
SoftAP + web portal	90 seconds	Medium (temporary open AP)	Connect Wi-Fi, open browser	Cameras, displays
QR code + mobile MDM	30 seconds	High (pre-enrolled cert)	Scan QR code	Smart locks
WPS push-button	15 seconds	Low (PIN brute-force in 4-11 hours)	Press button	NOT USED
Hardcoded credentials	0 seconds	None (firmware dump = game over)	None	NOT USED

Provisioning time and cost for initial deployment:

2,200 sensors + counters via BLE app: 2,200 x 45 s = 27.5 hours
400 cameras via SoftAP: 400 x 90 s = 10.0 hours
200 smart locks via QR/MDM: 200 x 30 s = 1.7 hours
400 displays via SoftAP: 400 x 90 s = 10.0 hours

Total provisioning: 49.2 hours
At 2 technicians: 24.6 hours = ~3.1 working days
Labour cost: 49.2 h x EUR 45/h = EUR 2,214

Credential revocation test results:

Stolen sensor detected at 14:32
Certificate revoked in RADIUS at 14:37 (5 minutes)
OCSP stapling pushes revocation to all APs within 15 minutes
Stolen sensor disconnected at 14:52 (20 minutes total)
All other 3,199 devices: unaffected, zero downtime

Cost comparison — PSK vs Enterprise:

Factor	WPA2-PSK	WPA2/3-Enterprise
Initial setup	EUR 0	EUR 2,214 (provisioning)
Annual certificate renewal	EUR 0	EUR 1,800 (automated, 40h/yr)
Per-incident response (stolen device)	EUR 7,200 (re-key 3,200 devices)	EUR 45 (revoke 1 cert, 1 hour)
Risk of lateral movement	High (shared key)	None (VLAN + per-device auth)
Compliance (ISO 27001, GDPR)	Fails audit	Passes audit

At just 1 security incident per year, Enterprise saves EUR 7,200 - EUR 1,800 = EUR 5,400 net. The initial EUR 2,214 provisioning cost pays for itself in the first incident.

Worked Example: Calculating WPA2-PSK Offline Attack Time

Scenario: Your company deploys 150 IoT cameras with WPA2-PSK using the password “SmartCam2024!”. An attacker parks outside, captures the WPA2 4-way handshake in 30 seconds, and attempts an offline brute-force attack using a consumer GPU.

Attack Hardware: NVIDIA RTX 3090 @ ~600,000 WPA2 guesses/second (realistic hashcat benchmark)

Putting Numbers to It

Brute-force attack time follows: $\text{Time (seconds)} = \frac{\text{Keyspace (combinations)}}{\text{Guess Rate (guesses/second)}}$. For a 13-character password with 63-character set (a-z, A-Z, 0-9, symbols): Keyspace = $63^{13} \approx 1.9 \times 10^{23}$ combinations. Worked example: At 600,000 guesses/second, brute-forcing takes $\frac{1.9 \times 10^{23}}{600,000} = 3.2 \times 10^{17}$ seconds = ~10 billion years. But dictionary attacks reduce the keyspace dramatically: testing “SmartCam” (14M words) x years (11) x symbols (3) = 462M combinations takes only $\frac{462,000,000}{600,000} = 770$ seconds (13 minutes).

Step 1 – Calculate password keyspace:

Your password “SmartCam2024!” has: - 13 characters - Uppercase (26), lowercase (26), digits (10), symbol (1) = 63 character set - Keyspace: 63^13 ≈ 1.9 × 10^23 combinations

Step 2 – Brute force time (worst case):

Time = Keyspace / Guess rate
     = 1.9 × 10^23 / 600,000 guesses/sec
     = 3.2 × 10^17 seconds
     ≈ 10 billion years

Looks secure, right? WRONG!

Step 3 – Dictionary + rule-based attack (reality):

Attackers don’t try every combination. They use: - Common password patterns: [Word][Year][Symbol] - “SmartCam” is in the RockYou dictionary (leaked password list) - Years 2020-2030 are common - Symbols ! @ # are common endings

Optimized attack:

Dictionary words: 14 million
Years: 11 (2020-2030)
Symbols: 3 (!, @, #)

Keyspace: 14,000,000 × 11 × 3 = 462 million combinations
Time: 462,000,000 / 600,000 = 770 seconds = 12.8 minutes

Your password is cracked in 13 minutes!

What makes a strong WPA2-PSK password:

Password	Pattern	Crack time (RTX 3090)
“password123”	Pure dictionary	<1 second
“SmartCam2024!”	Dictionary + year + symbol	13 minutes
“Correct-Horse-Battery-Staple”	4 random words	2.7 years
“xK9$mP2#vL8@qR5&”	16 truly random chars	>10 trillion years

Best Practices:

Minimum 16 random characters from full charset (a-z, A-Z, 0-9, symbols)
Use password generator, not patterns humans invent
Or 4+ random words (XKCD method) - easier to remember, hard to crack
Never use: company name, product name, year, common symbols at end
Better: Upgrade to WPA3-SAE to eliminate offline attacks entirely

Common Mistake: Relying on MAC Filtering for IoT Security

Scenario: A retail chain deploys 800 digital price tags on Wi-Fi with open authentication + MAC filtering, believing “only whitelisted tags can connect.”

Attack: A researcher with a laptop and $25 Wi-Fi adapter defeats the security in 3 steps:

Step 1 - Observe a legitimate tag’s MAC (passive sniffing):

# No authentication needed - MAC addresses are visible in beacons
airodump-ng wlan0mon --essid "Store-PriceTags"

# Output shows:
# Station MAC: A4:5E:60:E8:7C:3D (legitimate price tag)

Step 2 - Clone the MAC address (takes 5 seconds):

ifconfig wlan0 down
macchanger -m A4:5E:60:E8:7C:3D wlan0
ifconfig wlan0 up

Step 3 - Connect using the cloned MAC:

iw dev wlan0 connect "Store-PriceTags"
# CONNECTED - now on the same network as price tags AND the store's POS system

Total time to break “security”: 2 minutes

Why MAC filtering fails:

Security Property	MAC Filtering	WPA2-PSK	WPA3-SAE
Prevents eavesdropping	❌ No (traffic visible)	✅ Yes (AES encryption)	✅ Yes (AES encryption)
Prevents impersonation	❌ No (MAC easily cloned)	✅ Yes (password required)	✅ Yes (password required)
Defends against offline attacks	N/A	❌ No (capture handshake)	✅ Yes (Dragonfly)
Management overhead	High (whitelist updates)	Low (password change)	Low (password change)

What the retail chain SHOULD have done:

Architecture:
- VLAN 10: Store-PriceTags (isolated)
- VLAN 20: Store-Corporate (POS, backoffice)
- Firewall rules: VLAN 10 → Internet (HTTPS to pricing server only)
                  VLAN 10 → VLAN 20 (DENY ALL)

Security:
- WPA2-Enterprise (802.1X) with per-device certificates
- Or WPA3-SAE with a strong 20+ character random PSK
- MAC filtering as supplementary defense-in-depth ONLY

Monitoring:
- Alert on any new MAC address
- Alert on multiple devices with same MAC (indicates cloning)
- Regular audit of connected devices

Cost of the breach: The attacker modified 50 price tags to show incorrect prices, resulting in $18,000 in unintended discounts before discovery.

Key Lesson: MAC filtering is not encryption. It provides no confidentiality and minimal access control. Always use WPA2/WPA3 as primary security, with MAC filtering as optional supplementary control.

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

38.6 Concept Relationships

Understanding how Wi-Fi security and provisioning concepts relate:

Concept	Depends On	Enables	Trade-off
WPA3-SAE	Dragonfly handshake	Forward secrecy	Device compatibility vs security
802.1X Enterprise	RADIUS server	Per-device credentials	Infrastructure cost vs scalability
Network Segmentation	VLAN support	Breach containment	Configuration complexity vs security
BLE Provisioning	BLE on device	Secure out-of-band setup	Hardware cost vs security
Flash Encryption	Secure boot support	Credential protection	Performance overhead vs protection

Common Pitfalls

1. Shipping Devices With Default or Hardcoded Credentials

Using default Wi-Fi credentials (e.g., “admin”/“password”) or hardcoding SSID/password in firmware allows anyone with firmware access to extract credentials. All production devices must use unique per-device credentials provisioned during manufacturing or user-configured during setup.

2. Using WPS PIN Mode for IoT Provisioning

WPS PIN mode has a well-documented vulnerability allowing brute-force attack in under 4 hours (Reaver tool). While convenient for provisioning, it creates a permanent security weakness. Use AP mode with HTTPS configuration portal or BLE-based provisioning instead.

3. Not Implementing Provisioning Timeout

An IoT device in provisioning mode (AP mode or BLE pairing mode) that stays in provisioning indefinitely creates a persistent attack surface. Implement a provisioning timeout (e.g., 5-10 minutes) after which the device returns to normal operation. Require a physical button press to re-enter provisioning mode.

4. Using HTTP Instead of HTTPS for the Provisioning Portal

Configuration portals that deliver Wi-Fi credentials over plain HTTP expose credentials to anyone monitoring the provisioning network. The provisioning AP (even with no internet access) can be monitored by an attacker nearby. Always use HTTPS with a self-signed certificate for configuration portals.

🏷️ Label the Diagram

💻 Code Challenge

38.7 Summary

This chapter covered Wi-Fi security and provisioning for IoT deployments:

Security Protocol Evolution: WEP (obsolete, crackable), WPA (deprecated TKIP), WPA2-PSK (minimum standard with AES-CCMP), and WPA3-SAE (modern with Dragonfly handshake, forward secrecy) provide progressively stronger protection against attacks
WPA2-PSK Risk: If an attacker captures a WPA2 4-way handshake, weak passphrases may be guessed offline; use long random passphrases (or WPA3-SAE) to make guessing impractical
WPA2-Enterprise for Scale: 802.1X with RADIUS provides per-device credentials (certificates or username/password) instead of shared PSK, enabling secure credential revocation when devices are stolen without affecting entire network
Network Segmentation: IoT VLAN/subnet isolation with firewall rules prevents compromised sensors from attacking the main network, allows IoT→Internet where needed, and blocks unnecessary east‑west access
Hardcoded Credential Risks: Passwords in source code expose credentials via GitHub/firmware dumps; use secure provisioning (BLE/SoftAP/SmartConfig) and store credentials in NVS protected by flash/NVS encryption where supported
Wi-Fi Provisioning Methods: SmartConfig (UDP broadcast), SoftAP (temporary AP mode), BLE (out-of-band), and QR code scanning allow headless devices to receive Wi-Fi credentials without hardcoding or physical configuration interface
Defense in Depth: Combine WPA2/3 encryption, strong passwords (16+ chars), network segmentation, disabled WPS, MAC filtering (additional layer), regular firmware updates, and VPN for remote access to create comprehensive IoT security
WPA3 SAE Protocol: Dragonfly handshake eliminates WPA2’s offline brute-force vulnerability through commit-confirm exchange, provides forward secrecy (unique PMK per session), and mandates Protected Management Frames preventing deauthentication attacks
Provisioning Security: BLE provisioning (recommended for production) uses out-of-band secure channel, SoftAP creates temporary AP for web configuration, SmartConfig broadcasts encrypted credentials, while WPS should be avoided due to PIN attack vulnerability

38.8 See Also

For deeper exploration of related topics:

Wi-Fi Implementation: ESP32 Basics - SmartConfig and SoftAP provisioning code examples
IoT Security Threats - Common attack vectors and defenses
Authentication and Access Control - 802.1X and certificate management
Network Segmentation - VLAN design for IoT isolation

38.9 What’s Next

Chapter	Focus
Wi-Fi Implementation: ESP32 Basics	SmartConfig and SoftAP provisioning code examples for ESP32
Wi-Fi Architecture and Mesh	Mesh network security considerations and enterprise AP design
Wi-Fi Comprehensive Review	Full security review and assessment across Wi-Fi standards