Chapter 8: Wireless Security: WiFi, Bluetooth, and the Invisible Attack Surface

"On a wired network, an attacker has to get into the building. On a wireless one, the building comes to them." — a saying among wireless security engineers

Overview

A contractor sat in the parking lot of a Meridian branch in a rented sedan, laptop open on the passenger seat, and did nothing that looked like hacking. He did not pick a lock or tailgate through a door. He broadcast a wireless network named Meridian-Staff — the same name the branch's real network used — from a small battery-powered access point on his dashboard, turned up its radio so it was louder than the genuine one, and waited. Within twenty minutes, three bank-issued tablets and a teller's phone, configured months earlier to "automatically connect to Meridian-Staff," did exactly that. They connected to his access point. Every web request those devices made now flowed through his laptop before it reached the internet, and he sat there, in a parking space, reading it.

This is the problem with wireless, stated as plainly as it can be stated: the network leaves the building. Every other layer of defense in this book so far has assumed a comfortable physical fact — that to touch the wire, you have to be inside, past the doors and the cameras and the badge readers. Radio erases that assumption. A WiFi signal does not stop at the wall; it spills into the parking lot, the street, the office above, the coffee shop next door. An attacker never has to be authorized to be near you, and "near" now means anywhere a sensitive antenna can reach, which is much farther than most people imagine. The attack surface of a wireless network is, quite literally, invisible — you cannot see where your signal goes, and you cannot see who is listening.

That is the bad news. The good news, and the spine of this chapter, is that the wireless world has spent twenty-five years learning this lesson the hard way and building defenses that work. We have gone from an encryption scheme that a laptop can break over lunch (WEP) to one that resists offline attack even when you use a weak password (WPA3). We have a way to give every employee their own wireless identity instead of one shared passphrase taped under a keyboard (enterprise authentication with 802.1X). We have systems that watch the airwaves and shout when a rogue access point appears (wireless intrusion detection). And we have the single most important wireless control, which is not a wireless technology at all but the segmentation you met in Chapter 6: the principle that even a fully compromised wireless network should reach nothing that matters.

By the end of this chapter you will be able to look at a wireless deployment and a configuration file and say what is wrong with it, what an attacker would do about it, and exactly how you would detect and prevent that. You will harden Meridian's branch and guest WiFi, and you will add wifiaudit.py to your bluekit toolkit — a function that grades a wireless configuration the way an auditor would.

In this chapter, you will learn to:

• Explain why wireless is a categorically different defensive problem from wired networking, and stop treating "we have a WiFi password" as security.
• Trace the evolution from WEP to WPA3 and name the precise flaw that killed each generation, so you can recognize a dangerous configuration on sight.
• Design enterprise wireless with 802.1X and EAP, giving each user a revocable identity instead of a shared secret.
• Recognize, detect, and prevent rogue access points, evil twins, and the deauthentication attacks that make them work.
• Assess Bluetooth and NFC exposure proportionately — taking real risks seriously without inventing imaginary ones.
• Segment guest and branch WiFi so that wireless compromise stays contained, and audit a wireless configuration in code.

Learning Paths

Wireless security sits at the intersection of network engineering and certification knowledge, with detection content for analysts. Weight your reading accordingly:

🏗️ Security Engineer: This is your chapter. Sections 8.2 (protocol selection), 8.3 (enterprise 802.1X/EAP), and 8.6 (designing Meridian's segmented WiFi) are core to anything you will build. The Project Checkpoint is a configuration you could deploy. 🛡️ SOC Analyst: Focus on §8.4 (detecting rogue APs and evil twins — these generate the wireless alerts you will triage) and the WIDS material. Know what a deauthentication flood looks like in telemetry. 📋 GRC: Skim §8.2 for the protocol-compliance baseline (PCI-DSS forbids WEP and requires strong wireless authentication) and §8.6 for the policy artifact. The wireless policy is your deliverable here. 📜 Certification Prep: All of WEP→WPA3, PSK vs. Enterprise, EAP methods, evil twin, and rogue AP are heavily tested on Security+ and appear on CISSP. The key-takeaways.md file maps each to its exam domain.

8.1 Why wireless is special

Begin with the fact that reorganizes everything else: a wired network has a physical access control that a wireless network does not. To send a packet onto Meridian's branch LAN over a cable, you must plug into a port, and to reach a port you must be inside the branch, past the locked door and the camera and the receptionist who notices a stranger crawling under a desk. Physical security is a layer of network security on the wire. The cable is, in a real sense, the first firewall.

Radio removes that layer entirely. A wireless access point is a port that anyone within radio range can reach, and radio range is not the polite thirty feet the marketing box promised. With a directional antenna — a legal, inexpensive device sold for extending home networks — a patient person can reach a WiFi network from hundreds of meters, sometimes far more, through walls and across streets. The attacker does not appear on any camera. They do not trip any door alarm. They do not need a single credential to be present on the medium and listening to everything that is not encrypted. This is the whole of why wireless is special, and it has three concrete consequences that the rest of the chapter is built to address.

First, eavesdropping is the default, not the exception. On a switched wired network, traffic is delivered only to the port it is destined for; an attacker who wants to sniff must work for it (we covered ARP spoofing and man-in-the-middle attacks in Chapter 6). On wireless, every frame is broadcast into the air, and every radio in range receives every frame. The only thing standing between an attacker and your data is encryption. If the encryption is weak (WEP) or absent (an open network), the attacker simply listens. This is why the entire history of WiFi security, which we trace in §8.2, is really a history of encryption that holds up against an attacker who already has every packet.

Second, the attacker can talk, not just listen. Radio is not a one-way medium. An attacker in range can transmit — inject frames, impersonate an access point, and send management frames that legitimate devices obey. This is what makes the parking-lot evil twin in our cold open possible, and what makes the deauthentication attack of §8.4 so effective: the attacker sends a frame that tells your device "you've been disconnected," and your device, trusting it, disconnects — and then reconnects, perhaps to the attacker's stronger signal.

Third, the boundary is invisible and uncontrollable. You can survey where your signal reaches today, but you cannot fence it. You cannot put a guard on the parking lot of the building next door. The defensive posture this forces is the one this whole book has been building toward: assume the medium is hostile and compromised, and design so that compromise of the wireless layer is survivable. That is not pessimism; it is the only honest model. A wireless network is a public space you happen to broadcast into.

🚪 Threshold Concept: On a wired network, the cable is a control — being on the medium implies you got past physical security. On a wireless network, being on the medium is free. Internalize this and the design rules follow automatically: encrypt everything because everyone is listening; authenticate strongly because anyone can be present; segment ruthlessly because the medium itself can never be trusted. Wireless security is the art of building a trustworthy network on top of an untrustworthy medium.

One piece of vocabulary before we go further, because it appears in every configuration and every attack in this chapter. An SSID (Service Set Identifier) is the human-readable name of a wireless network — Meridian-Staff, Meridian-Guest, the CoffeeShop_Free_WiFi your phone remembers from last week. It is broadcast in the clear by default, in management frames that are not encrypted even on a fully secured WPA3 network, so an attacker always knows the names of the networks around them and the names your devices are looking for. The SSID is not a secret and was never designed to be one; hiding it (disabling the broadcast) is a frequently recommended "control" that provides almost no security and creates real problems, as we will see. Hold onto the SSID concept — the evil-twin attack is, at bottom, an attacker broadcasting your SSID more loudly than you do.

Here is the wireless threat model in one diagram. Keep it in mind for the rest of the chapter; almost every attack and control is a move on this picture.

                         ((( radio spills outside )))
   ┌──────────────────────────────────────────────────────────┐
   │  BRANCH BUILDING                                          │
   │                                                          ((( ))) ── parking lot
   │   [Real AP]  SSID="Meridian-Staff"                        │        │
   │      │  encrypted if WPA2/3                               │   [Attacker laptop]
   │      ▼                                                    │    - listens (sniff)
   │   [Teller workstations] ── wired ── [Switch] ── [Core]    │    - transmits:
   │                                                           │       * evil twin AP
   │   [Guest devices] ····· should be ISOLATED ·············  │         (same SSID,
   │                                                           │          louder signal)
   └───────────────────────────────────────────────────────── │       * deauth frames
        ▲                                                      │         (kick clients off)
        └──── signal reaches here ─────────────────────────────┘
   The attacker never enters the building. Radio brought the network to them.

Figure 8.1 — The wireless threat model. The attacker operates entirely outside the physical perimeter. Defenses must therefore assume the medium is observed and writable by an adversary, and contain the blast radius if the wireless segment is compromised.

🔄 Check Your Understanding: 1. Name the single physical-security property that a wired network has and a wireless network lacks, and state the most important design consequence of losing it. 2. Is the SSID a secret? What does that imply about "hiding" your network by disabling SSID broadcast?

Answers

1. On a wired network, reaching the medium requires physical presence inside the controlled space, so being on the wire implies passing physical security; wireless removes this, so you must assume an unauthenticated, unseen attacker is always present on the medium — which means encrypt everything, authenticate strongly, and segment so wireless compromise is survivable. 2. No — the SSID is broadcast in cleartext management frames and is trivially observed even on WPA3; disabling its broadcast hides it from casual users but not from any attacker with a wireless sniffer, while breaking some client behavior, so it is at best a very weak measure, not a real control.

8.2 The evolution from WEP to WPA3

The history of WiFi encryption is unusually useful to a defender because each generation died of a specific, nameable flaw, and recognizing those flaws in a live configuration is a core skill. We will walk the four generations in order. The practical payoff is a single rule you can apply on sight — WPA3 if you can, WPA2 if you must, never anything older — and the understanding to defend that rule when someone asks why the old equipment has to go.

WEP: broken by design, and broken in practice

WEP (Wired Equivalent Privacy) was the original WiFi encryption standard, introduced in 1997 with the explicit goal stated in its name: to make wireless as private as a wire. It failed completely, and the failure is instructive. WEP encrypted traffic with the RC4 stream cipher using a key built from a static secret combined with a 24-bit initialization vector (IV) — a value meant to be different for each packet so that identical plaintext would not produce identical ciphertext. The fatal problem was that 24 bits is tiny. On a busy network, IVs repeat within hours, and when two packets reuse the same IV with the same key, the encryption leaks exploitable structure. By 2001, researchers had published practical attacks; within a few years, tools could recover a WEP key passively from captured traffic in minutes, regardless of how long or complex the passphrase was. The length of your WEP key never mattered, because the attack was on the protocol, not the password.

The defender's takeaway is blunt: WEP provides no meaningful protection and its presence is itself a critical finding. If you discover WEP anywhere in Meridian's environment — on a forgotten branch access point, an old wireless barcode scanner, an ATM maintenance link — treat it as equivalent to an open network carrying sensitive data, because that is what it is. PCI-DSS has prohibited WEP for cardholder-data environments for over a decade. Finding WEP is not a "schedule a fix" item; it is a "why is this still here" item.

⚠️ Common Pitfall: Assuming a long, complex WEP passphrase is "good enough for now." The WEP attacks do not brute-force the passphrase — they exploit the IV reuse in the protocol itself, recovering the key from observed traffic. A 63-character WEP key falls exactly as fast as a 5-character one. Passphrase strength is a meaningful control for WPA2/WPA3 personal mode (next), but it does nothing for WEP. The only fix for WEP is to stop using WEP.

WPA: the emergency patch

WPA (Wi-Fi Protected Access) arrived in 2003 as a deliberately temporary fix — a way to improve security on hardware that already existed, before the stronger WPA2 standard was finalized. Its main innovation was TKIP (Temporal Key Integrity Protocol), which wrapped the same RC4 cipher in per-packet key mixing and a sequence counter to defeat the IV-reuse and replay attacks that killed WEP. WPA was a genuine improvement and bought the industry time, but it was always a stopgap built on a compromised cipher. TKIP was later found to have its own weaknesses, and it is now deprecated. You should treat WPA (TKIP) as nearly as obsolete as WEP: better than nothing, acceptable nowhere in 2020s, and a finding wherever it appears. Its historical role is the lesson — WPA is what an industry does when it needs to improve security on deployed hardware right now, a situation you will face yourself with IoT and operational technology later (Chapters 14 and 33).

WPA2: the workhorse, and its one famous crack

WPA2, standardized in 2004, was the right answer and remained the dominant standard for fifteen years. It replaced the RC4-based scheme with AES-CCMP — encryption built on the AES block cipher you met in Chapter 4 — which has no practical cryptographic break to this day. For most of its life, "use WPA2 with AES and a strong passphrase" was simply correct advice, and a great deal of the world still runs on it.

WPA2 has two modes you must distinguish, because the distinction is the heart of §8.3:

• WPA2-Personal (PSK): everyone shares one passphrase — a pre-shared key — that the access point and every device use to derive their encryption keys. This is what a home router and a small branch use.
• WPA2-Enterprise: every user authenticates individually against a central server (we build this in §8.3). No shared passphrase exists.

WPA2-Personal's weakness is not in AES; it is in the four-way handshake, the exchange that happens when a device joins the network and proves it knows the passphrase. An attacker in range can capture this handshake passively (or force it by sending a deauthentication frame to make a device reconnect — note how the attacks compose) and then take it home and guess the passphrase offline, trying billions of candidates per second against the captured handshake with no further contact with the network. This is the central WPA2-Personal risk and it has a precise shape: the security of WPA2-Personal reduces almost entirely to the strength and secrecy of the passphrase. A passphrase of password123 or the company name falls in seconds. A long, random passphrase resists this attack for a practical eternity. This is the offline-guessing problem, and it is exactly the problem WPA3 was designed to eliminate.

WPA2 also suffered a famous protocol-level attack in 2017 called KRACK (Key Reinstallation Attack), which abused the four-way handshake to force reinstallation of an already-used key, enabling decryption of some traffic. KRACK mattered, made headlines, and was fixed by software patches on both clients and access points. The defender's lesson from KRACK is not "WPA2 is broken" — it isn't, when patched — but the recurring one: even sound protocols have implementation bugs, so patching wireless infrastructure and client supplicants is part of wireless security, not separate from it.

🛡️ Defender's Lens: The offline-guessing attack on WPA2-Personal is why a shared passphrase is a weak foundation for any network that matters. From the blue-team seat, you cannot detect an attacker capturing a handshake — it is passive, just listening, and produces no log on your equipment. You cannot detect them guessing the passphrase — that happens offline on their own hardware. Your only defenses are preventive: make the passphrase long and random so guessing is infeasible, change it whenever someone who knew it leaves, and — far better — stop using a shared passphrase at all and move to Enterprise authentication (§8.3), where there is nothing shared to capture and crack. When you cannot detect, you must prevent.

WPA3: closing the offline-guessing door

WPA3, introduced in 2018, is the current standard, and its headline improvement directly attacks the WPA2-Personal weakness above. WPA3-Personal replaces the four-way handshake's pre-shared-key exchange with a protocol called SAE (Simultaneous Authentication of Equals, also marketed as "WPA3 Personal" or by the codename Dragonfly). The crucial property of SAE is that it is resistant to offline dictionary attacks: even if an attacker captures the handshake, they cannot take it home and guess passphrases against it, because SAE does not hand them the material to do so. Each guess requires a fresh, live interaction with the access point, which is slow, rate-limited, and detectable. SAE also provides forward secrecy (a concept from Chapter 5): capturing today's traffic and learning the passphrase later does not let an attacker decrypt the recordings.

WPA3 adds two more things worth naming. Enhanced Open (Opportunistic Wireless Encryption, OWE) encrypts traffic on networks that have no password at all — like a guest or coffee-shop network — so that even an "open" network is no longer a wide-open eavesdropping target; it protects against passive sniffing without requiring a shared secret. And WPA3-Enterprise defines a stronger 192-bit security mode for high-security environments. WPA3 is not magic — it still relies on correct implementation, it has had its own implementation bugs (a set of issues nicknamed Dragonblood in 2019, since patched), and it does not remove the need for segmentation — but it meaningfully raises the floor, especially for the personal/PSK mode that small sites actually deploy.

The whole evolution collapses into a comparison table you should be able to reconstruct, because it is the single most testable artifact in this chapter and the most useful one in practice:

The decision rule that falls out of this table is the one to memorize: prefer WPA3; use WPA2-AES with a long random passphrase where WPA3 is unsupported; treat WPA(TKIP) and WEP as findings to remove. And the deeper rule, which carries into the next section: a shared passphrase, even a strong one, is a liability at organizational scale — because you cannot revoke it for one person, you cannot tell who used it, and it tends to end up written on a sticky note. The answer to that problem is to give every user their own identity.

🔄 Check Your Understanding: 1. Two networks both use a 40-character random passphrase. One is WEP, one is WPA2-AES. Which is secure against passive key recovery, and why does passphrase length matter for one but not the other? 2. What specific WPA2-Personal weakness does WPA3's SAE handshake eliminate, and why can't an attacker who captures a WPA3 handshake brute-force it offline?

Answers

1. Only the WPA2-AES network is secure. WEP's attack exploits IV reuse in the protocol to recover the key from captured traffic regardless of passphrase length, so a 40-character WEP key falls as fast as a short one. WPA2-AES has no such protocol break; its only practical attack is offline guessing of the passphrase from a captured handshake, which a 40-character random passphrase makes infeasible — so length matters for WPA2 but is irrelevant for WEP. 2. SAE eliminates offline dictionary/brute-force attacks against the captured handshake; SAE (Dragonfly) does not transmit material that lets an attacker test passphrase guesses without interacting live with the access point, so each guess requires a fresh, rate-limited, detectable exchange instead of billions of free offline attempts.

8.3 Enterprise wireless: 802.1X and EAP

Everything in §8.2 about the weakness of a shared passphrase points to a single architectural answer for any organization larger than a household: stop sharing a secret, and give every user and device its own credential that can be issued, audited, and revoked. That is what WPA-Enterprise does, and it is the most important wireless design decision Meridian makes.

The concrete scenario: at a Meridian branch using WPA2-Personal, the passphrase is the same for the branch manager, every teller, the printer, and the conference-room TV. When a teller resigns, that passphrase is still in their phone, and the only way to revoke their access is to change the passphrase for everyone and re-key every device — a painful operation nobody wants to do, so in practice it never happens, and former employees retain working wireless credentials for years. There is also no record of who connected; the access point sees one shared identity. This is unacceptable for a bank, and it is exactly the problem enterprise authentication solves.

The architecture: supplicant, authenticator, server

WPA-Enterprise (the Enterprise mode of WPA2 or WPA3) replaces the pre-shared key with per-user authentication carried by a framework called EAP (Extensible Authentication Protocol). EAP is not itself an authentication method; it is a container — an extensible envelope that can carry many different authentication methods (passwords, certificates, tokens). The actual checking is done by a central authentication server, almost always using the RADIUS protocol (which you will meet again in identity chapters). The three roles, defined by the 802.1X standard you met in Chapter 7, are worth fixing precisely because the whole flow is just these three parties talking:

   [Supplicant]            [Authenticator]              [Authentication
    the user's              the access point /            server]
    device + its            switch — a gatekeeper         RADIUS + identity
    EAP "supplicant"        that blocks all traffic       store (AD / Entra)
    software                until 802.1X says OK
        │                          │                          │
        │  1. "I want to join"     │                          │
        ├─────────────────────────►│                          │
        │                          │  2. relays EAP exchange  │
        │  ◄═══ EAP auth (tunneled, mutual) ═══════════════════►
        │                          │                          │
        │                          │  3. server verifies the  │
        │                          │     user's identity, then│
        │                          │     says ACCEPT/REJECT   │
        │                          │  ◄───────────────────────┤
        │  4. port opens only      │     (+ which VLAN to put  │
        │     if ACCEPT            │      this user on)        │
        │  ◄───────────────────────┤                          │

Figure 8.2 — The 802.1X/EAP flow. The access point (authenticator) is a gate that passes the user's credentials to the RADIUS server (authentication server) and opens only on success — and can place each user on the correct VLAN. There is no shared passphrase anywhere in this picture.

The supplicant is the device wanting on. The authenticator is the access point, acting purely as a gatekeeper — it forwards the authentication conversation to the server and forbids all other traffic until the server says yes. The authentication server (RADIUS, backed by Meridian's Active Directory or Entra ID) makes the actual decision. Notice what this buys you, point for point against the shared-passphrase problems above: every user authenticates as themselves, so the logs show who connected; a departing employee is disabled in the directory once and loses wireless instantly with no re-keying; and the server can tell the access point which VLAN to place each user on — tellers onto the teller segment, guests onto the guest segment — enforcing the segmentation of Chapter 6 at the moment of connection.

EAP methods: the part that actually matters for security

Because EAP is just a container, the security of enterprise wireless depends heavily on which EAP method you choose, and this is where real deployments succeed or fail. The methods differ mainly in how the server proves itself and how the user proves themselves. Three matter for Meridian:

• EAP-TLS is the gold standard. Both sides present X.509 certificates (Chapter 4): the server proves its identity to the client, and — crucially — the client proves its identity with a certificate too, so there is no password to phish, capture, or guess. It is the most secure and the most work to deploy, because it requires issuing and managing a certificate on every device (a public key infrastructure, which Meridian builds in its identity program).
• PEAP and EAP-TTLS are the common password-based methods. They build an encrypted TLS tunnel using a server certificate, then send the user's password (often their Active Directory password) inside that protected tunnel. They are far easier to deploy than EAP-TLS because users just type their normal password — but they have a critical dependency we are about to see.
• EAP-FAST and older methods exist; for a defender, the rule is to prefer EAP-TLS where the device fleet allows certificates, and PEAP/EAP-TTLS with strict server-certificate validation everywhere else.

How an attacker abuses enterprise wireless — and how you stop them

Enterprise wireless is dramatically stronger than PSK, but it has one signature failure mode you must understand, because attackers target it specifically. In the password-based methods (PEAP, EAP-TTLS), the client is supposed to verify the server's certificate before sending the password into the tunnel — exactly as your browser verifies a website's certificate before you type a password. If the client is misconfigured to skip server-certificate validation — a depressingly common default on hastily provisioned devices — then an attacker can stand up an evil twin (the rogue access point of §8.4) advertising the same enterprise SSID, present any certificate, and the client will happily build the tunnel to the attacker's server and send the user's Active Directory password straight into it. The attacker harvests the credential, often the user's primary corporate password, without the user noticing anything.

The defenses are precise and they are the things you actually check in an audit:

1. Prefer EAP-TLS where you can. With mutual certificate authentication there is no password to steal even if a user connects to a rogue server, because the credential is a private key that never leaves the device.
2. Enforce server-certificate validation on every client that uses PEAP/EAP-TTLS — pin the expected RADIUS server certificate or its issuing CA, and lock down which certificate names are acceptable. This is configured centrally through Group Policy or your mobility management. A device that will connect to "any" server is the vulnerability.
3. Disable insecure inner methods. Some legacy configurations allow weak inner authentication that is exploitable even inside the tunnel; restrict to known-good methods.
4. Detect the evil twin with the WIDS techniques of §8.4 — an access point advertising your enterprise SSID that is not one of yours is a high-fidelity alert.

⚠️ Common Pitfall: Deploying PEAP and considering the job done because "it uses our AD passwords, so it's integrated and secure." The integration is the risk: because the wireless password is the Active Directory password, a single evil-twin credential capture against a device that skips certificate validation yields the user's corporate password — usable far beyond WiFi, for email, VPN, and more. PEAP without rigorously enforced server-certificate validation is a credential-harvesting trap. Either deploy EAP-TLS, or treat strict server-cert validation as a mandatory, audited control — not an optional checkbox.

🔗 Connection: The 802.1X framework here is the same one Chapter 7 introduced for wired Network Access Control — the access point is doing for the air what a NAC-enabled switch does for the wire: refusing to pass traffic until the device authenticates. Wireless is simply the highest-stakes application of port-based access control, because on the wire you at least had to get into the building first.

🔄 Check Your Understanding: 1. List three concrete advantages WPA-Enterprise has over WPA2-Personal for an organization like Meridian. 2. An attacker sets up an evil twin advertising Meridian's enterprise SSID and captures employee credentials anyway. What client-side misconfiguration made this possible, and what are the two strongest fixes?

Answers

1. (a) Per-user identity, so logs show who connected and a departing employee can be revoked individually with no re-keying; (b) no shared secret exists to capture-and-crack offline; (c) the RADIUS server can assign each user to the correct VLAN at connection time, enforcing segmentation. (Also: credentials can be password or certificate based, and policy is centrally managed.) 2. The clients were configured to skip server-certificate validation, so they built the EAP tunnel to the attacker's rogue RADIUS server and sent passwords into it. Strongest fixes: move to EAP-TLS (mutual certificates — no password to steal), and where password methods remain, rigorously enforce server-certificate/CA validation (pin the expected RADIUS certificate) via centrally managed device policy.

8.4 Rogue access points and evil twins — detection

We now arrive at the attacks from the cold open, and at the most important operational skill in wireless defense: noticing that a hostile access point has appeared. There are two related threats here, and precision about the difference matters because they call for different responses.

Rogue AP vs. evil twin

A rogue access point is any wireless access point connected to your network without authorization. The classic case is not even malicious: a well-meaning employee, frustrated by poor coverage in a back office, buys a cheap consumer access point and plugs it into a wall jack so their corner gets WiFi. They have just created an unauthenticated, probably WPA2-Personal-with-a-weak-passphrase, possibly WPS-enabled doorway from the parking lot directly onto Meridian's internal wired network — bypassing every careful control on the official wireless. The rogue AP is defined by the network connection: it is plugged into your LAN, so compromising it is a path inside. This is one of the highest-impact wireless findings precisely because it is so often well-intentioned and invisible to the people who would object.

An evil twin is a rogue access point that impersonates a legitimate one — it advertises the same SSID (and often the same apparent network) as a network the victims trust, to lure devices into connecting to the attacker instead. The evil twin is defined by the impersonation: it may not be connected to your network at all (the parking-lot attacker's box was not), because its goal is to be the network your devices talk to, so the attacker can intercept traffic (a wireless man-in-the-middle, building on Chapter 6) or harvest credentials (the PEAP attack of §8.3). The cold open was an evil twin. So is the fake Airport_Free_WiFi that harvests logins in a terminal.

The two often combine, and both are enabled by a third technique that deserves its own treatment because it is the enabling move for so many wireless attacks.

The deauthentication attack: the enabling move

The deauthentication attack exploits a design decision in the original WiFi standard that has haunted it ever since: the management frames that control association — including the "deauthenticate" frame that tells a client it has been disconnected — were, for most of WiFi's history, unauthenticated. Any device in range can forge a deauthentication frame that appears to come from the access point, and the victim's device, unable to tell it is forged, obeys and disconnects. By sending these frames continuously, an attacker can keep a device (or every device on a network) knocked offline — a wireless denial of service, an availability attack in the sense of Chapter 1's CIA triad.

But the more dangerous use is not denial of service; it is coercion. A deauthentication attack forces devices to disconnect and then reconnect, and that reconnection is the attacker's opportunity:

• It forces the four-way handshake to happen again, so an attacker who wants to capture a WPA2-Personal handshake for offline cracking (§8.2) does not have to wait for a device to join naturally — they deauthenticate it and capture the handshake on its forced reconnection.
• It pushes devices toward an evil twin: when the real network keeps kicking a device off and a louder identically-named access point is steadily available, the device (or the user, frustrated) ends up on the attacker's access point.

So the deauthentication attack is rarely the whole attack; it is the lever that makes handshake capture and evil-twin luring reliable. Recognizing it is therefore doubly valuable — it is both an attack to stop and an early warning that one of the others is underway.

The real defense against deauthentication is a standard called 802.11w (Protected Management Frames, PMF), which authenticates management frames so they cannot be forged. PMF is mandatory in WPA3 and available in WPA2 — turning it on is one of the highest-value, lowest-effort wireless hardening steps you can take, and it is a concrete reason to prefer WPA3. With PMF enforced, the classic deauthentication flood simply stops working.

Detecting rogue APs and evil twins: WIDS

You cannot prevent an attacker from transmitting in a parking lot — radio is radio. What you can do is watch the airwaves and detect hostile access points fast, and the system that does this is a wireless IDS (wireless intrusion detection system, WIDS) — the wireless cousin of the IDS/IPS you met in Chapter 7. A WIDS uses sensors (often built into your enterprise access points, which listen on the air in addition to serving clients) to monitor the radio environment and alert on the signatures of wireless attack. Concretely, a WIDS detects:

• Rogue APs on the wire: the highest-value detection. The WIDS sees an unknown access point on the air and correlates it to your wired network (for example, by recognizing that a device with that access point's MAC address also appears on your switches, or that the AP bridges to your network). An AP that is both broadcasting and plugged into your LAN, but is not in your inventory, is a rogue AP — a near-certain finding worth an immediate response.
• Evil twins / SSID impersonation: the WIDS knows the legitimate access points that should be advertising each Meridian SSID (by their authorized MAC/BSSID addresses). When a different radio starts advertising Meridian-Staff, that mismatch — the right SSID from the wrong hardware — is a high-fidelity evil-twin alert.
• Deauthentication floods: an abnormal volume of deauthentication/disassociation management frames is the signature of a deauth attack (or someone capturing handshakes), and the WIDS flags the spike.
• Other signatures: networks using deprecated protocols (WEP/WPA appearing where they shouldn't), unexpected ad-hoc networks, and known attack-tool fingerprints.

The detection logic for the two headline threats is simple enough to state as pseudo-rules, and it is the model your wifiaudit work and any SIEM correlation will follow:

ROGUE AP (on your wire):
   IF an AP is observed on the air
   AND that AP's identity (BSSID/MAC) is NOT in the authorized inventory
   AND the AP is determined to bridge to the internal wired network
   THEN raise CRITICAL: unauthorized AP on internal network.

EVIL TWIN (impersonation):
   IF a beacon advertises a known-corporate SSID (e.g., "Meridian-Staff")
   AND the transmitting BSSID/MAC is NOT one of the authorized APs for that SSID
   THEN raise HIGH: possible evil twin impersonating a corporate network.

The prevention side stacks the controls you have now collected: enforce 802.11w/PMF so deauthentication does not work and evil-twin luring loses its lever; deploy WPA3 (or WPA2-Enterprise with EAP-TLS) so there is no PSK handshake to capture and no password to harvest even if a device reaches a rogue server; run a WIDS so rogue APs and evil twins are seen within minutes; and — the control that makes the whole category survivable — segment so that even a device that does connect to an evil twin, or even a rogue AP on the wire, reaches nothing of value (§8.6).

📟 War Story: A constructed but representative incident. A regional retailer's loss-prevention team noticed nothing wrong, but its WIDS fired a low-priority alert one Saturday: an access point advertising the store's StaffWiFi SSID from an unrecognized radio. The on-site manager, following the runbook, walked the floor with a signal-strength app and found a matchbox-sized device velcroed behind a display, plugged into a network jack — a rogue AP placed by someone who had walked in as a customer. It was bridging the store network to the parking lot. Because the store had segmented its point-of-sale systems away from the general staff network, the rogue AP reached email and the public web but not the cardholder data environment. The detection found it; the segmentation contained it. Neither alone would have been enough. (We return to this exact scenario, in depth, in this chapter's second case study.)

🛡️ Defender's Lens: A deauthentication flood and an evil twin look very different in telemetry, and knowing the difference speeds your triage. The deauth flood is loud and obvious to a WIDS — a sudden burst of deauthentication frames, often targeting many clients — and frequently precedes something else, so treat a deauth spike as a leading indicator: check immediately for a new SSID-impersonating AP or unusual handshake captures nearby. The evil twin is quieter — it may produce no flood at all, just a single unauthorized beacon advertising your SSID — which is why the BSSID-allowlist detection (right SSID, wrong hardware) matters: it catches the evil twin that never bothers to deauthenticate anyone.

🔄 Check Your Understanding: 1. Distinguish a rogue access point from an evil twin by what defines each, and state why the rogue AP is often the higher-impact finding. 2. Why is the deauthentication attack so useful to an attacker even though, by itself, it only disconnects devices? Name the standard that defeats it.

Answers

1. A rogue AP is defined by being connected to your network without authorization (a doorway from outside onto your internal wire); an evil twin is defined by impersonating a legitimate network's SSID to lure devices to the attacker (it may not touch your network at all). The rogue AP is often higher-impact because it provides a direct, unauthenticated bridge from the parking lot onto the internal wired network, bypassing the controls on the official wireless. 2. Because forcing devices to disconnect makes them reconnect, which (a) forces a fresh four-way handshake an attacker can capture for offline cracking, and (b) drives frustrated/automatic devices onto a waiting evil twin. The standard that defeats it is 802.11w / Protected Management Frames (PMF), mandatory in WPA3.

8.5 Bluetooth and NFC exposure

WiFi is the loudest wireless attack surface, but it is not the only radio your organization runs. Two short-range technologies deserve proportionate attention — proportionate being the operative word, because the right defensive posture for Bluetooth and NFC is neither panic nor neglect, and a good defender can tell the difference between a real risk and a demonstration that requires the attacker to be standing on your foot.

Bluetooth: pervasive, short-range, occasionally serious

Bluetooth is the short-range wireless technology that connects peripherals — headsets, keyboards, mice, medical devices, point-of-sale card readers, the hands-free system in a car. It operates over much shorter distances than WiFi (typically up to about ten meters for common devices, though attackers with good antennas extend this), which materially limits the threat: most Bluetooth attacks require the attacker to be quite close. That proximity requirement is the single most important fact for risk-scoring Bluetooth, and it is why Bluetooth risk is usually lower than WiFi risk for the same organization — but "lower" is not "zero," and three considerations keep it on the map.

The first is the class of vulnerabilities exemplified by BlueBorne, a set of flaws disclosed in 2017 that allowed an attacker, with no pairing and no user interaction, to compromise a vulnerable device merely by being in Bluetooth range. BlueBorne mattered because it broke the comfortable assumption that an unpaired device is safe; it was a reminder that the Bluetooth stack is a large, complex piece of software with the same kind of memory-corruption bugs as any other (and the same fix: patch). BlueBorne-class vulnerabilities are the reason "keep Bluetooth stacks patched and turn Bluetooth off when not in use" is real advice and not paranoia. The second consideration is that Bluetooth devices are often forgotten infrastructure — a wireless keyboard or a card reader can sniff or inject keystrokes if compromised, and these devices rarely get patched or inventoried. The third is simple discoverability hygiene: a device left perpetually discoverable and pairable invites attempts.

The proportionate controls are modest and mostly operational:

• Patch Bluetooth-capable devices, especially anything that processes sensitive input (card readers, keyboards) — BlueBorne-class bugs are patchable.
• Disable Bluetooth when not in use, and do not leave devices in discoverable/pairable mode permanently.
• Inventory Bluetooth peripherals as the small computers they are, especially in the cardholder-data path — a compromised Bluetooth card reader is a PCI problem (this connects to the device-inventory work of Chapter 14).
• Prefer modern pairing (Bluetooth's "Secure Connections" with numeric comparison) over legacy pairing modes with weak or no authentication.

NFC: very short range, narrow but real

NFC (Near Field Communication) is the very-short-range technology — a few centimeters — behind contactless payments (tap-to-pay), transit cards, and many badge/access systems. Its defining security property is its range: an attacker generally has to be within a couple of centimeters, which makes remote attack essentially impossible and dramatically narrows the threat. Most NFC "attacks" are either physical proximity attacks (someone bumping a reader against a wallet, which yields little because payment NFC uses one-time cryptograms, not reusable card numbers) or relay attacks (relaying the NFC conversation between a victim's card and a distant reader in real time, which is real but requires specialized equipment and tight timing).

For Meridian, NFC matters in two concrete places. The first is contactless payment at the point of sale: the payment-card networks designed contactless EMV with cryptographic protections specifically so that skimming an NFC payment does not yield reusable card data, so the residual risk is genuinely low — but the terminals are still devices that must be kept current and tamper-evident. The second, and the one defenders more often overlook, is NFC-based access badges. Older badge technologies (legacy 125 kHz proximity cards and early MIFARE) can be cloned by an attacker who gets brief proximity to a badge, turning a borrowed elevator ride into a copied credential. The control is to use modern, cryptographically secured badge credentials and to treat the physical-access system as part of the security program — a theme that returns when we discuss operational technology and facilities.

⚖️ Authorization & Ethics: Bluetooth and NFC assessment can shade quickly from defensive testing into intercepting other people's communications, which is illegal in most jurisdictions regardless of how easy the radio makes it. Assess only devices your organization owns or you are explicitly authorized to test; never capture, relay, or clone a credential or a transaction that is not yours to handle. The short range of these technologies does not make eavesdropping on them lawful — it just makes it physically close.

🔄 Check Your Understanding: 1. Why is Bluetooth risk usually lower than WiFi risk for the same organization, and what category of Bluetooth flaw (named after a 2017 disclosure) shows that "lower" still isn't "zero"? 2. Why is skimming a contactless (NFC) payment far less rewarding for an attacker than the public fear suggests, and where does NFC nonetheless pose a real cloning risk?

Answers

1. Bluetooth's much shorter range (roughly ten meters vs. WiFi's reach into the parking lot and beyond) means most attacks require close proximity, sharply limiting exposure. BlueBorne (2017) — a set of flaws allowing compromise of a vulnerable device in range with no pairing or user interaction — shows the Bluetooth stack still carries serious, patchable software vulnerabilities. 2. Contactless EMV payments use one-time cryptograms rather than reusable card numbers, so a skimmed transaction yields nothing replayable; the residual risk is low (terminals still need patching and tamper-evidence). NFC poses a real cloning risk in access badges — legacy proximity/early MIFARE cards can be cloned from brief proximity — which is why modern cryptographically secured badge credentials matter.

8.6 Securing Meridian's branch and guest WiFi

Now we assemble everything into a design for a real environment, advancing the Meridian network architecture you began in Chapter 6. Meridian operates roughly 120 branches, each of which needs wireless for three distinct populations with three different trust levels — and the entire design turns on keeping those populations apart. This is where the chapter's controls stop being a list and become an architecture.

The three wireless populations

1. Staff devices — bank-issued tablets and laptops used by tellers and branch staff. These need access to internal banking applications and must be strongly authenticated and tightly segmented.
2. Guest devices — customers and visitors who want internet access in the lobby. These must reach the internet only and must be completely isolated from everything internal. Many regional banks offer guest WiFi as an amenity; it is a courtesy, and it must never become a doorway.
3. Operational devices — branch IoT: networked printers, perhaps digital signage, security cameras, and the like. These are notoriously weak (default credentials, no patching — the subject of Chapter 14) and must be quarantined on their own segment where their weakness cannot hurt anything.

The cardinal sin, and the most common real-world finding, is the one Chapter 1's first risk register flagged for Meridian: guest WiFi sharing a network segment with teller workstations. When that happens, a customer in the lobby — or an attacker impersonating the guest network — sits on the same broadcast domain as the machines that touch customer accounts. Everything else in this design exists to make that impossible.

The design, as separate SSIDs mapped to separate segments

The architecture uses three separate SSIDs, each mapped (by VLAN, the Chapter 6 mechanism) to a separate, firewalled network segment:

   ┌──────────────────────── MERIDIAN BRANCH WIRELESS ────────────────────────┐
   │                                                                          │
   │  SSID "Meridian-Staff"   ── WPA3-Enterprise (802.1X / EAP-TLS) ─► VLAN 10 │
   │     authenticates each user via RADIUS → AD/Entra                        │
   │     │                                                                    │
   │     └─► STAFF SEGMENT ── firewall ──► internal banking apps (least priv) │
   │                                                                          │
   │  SSID "Meridian-Guest"   ── WPA3 (Enhanced Open) + captive portal ─►VLAN 90│
   │     │   client isolation ON (guests can't see each other)                │
   │     └─► GUEST SEGMENT ── firewall: INTERNET ONLY, deny all internal ─────►│
   │                                                                          │
   │  SSID "Meridian-Ops"     ── WPA3-Personal, strong unique PSK ────► VLAN 50│
   │     │   (printers, signage, cameras — small, weak devices)               │
   │     └─► OPS SEGMENT ── firewall: deny internet, deny to staff/guest ─────►│
   │                                                                          │
   │  Cross-segment rule (default-deny): NO path from Guest or Ops to Staff;  │
   │  NO path from Guest to Ops; everything not explicitly allowed is denied.  │
   └──────────────────────────────────────────────────────────────────────────┘

Figure 8.3 — Meridian's branch wireless design. Three SSIDs map to three firewalled VLANs. The default-deny rules between segments (Chapter 7) are what make a wireless compromise survivable: even a fully owned guest or ops segment reaches nothing that matters.

Walk the design decision by decision, because each one is an application of something earlier in this chapter or this book:

• Staff uses WPA3-Enterprise with EAP-TLS (§8.3): per-user certificate authentication, so there is no PSK to crack and no password to phish, departing staff are revoked individually, and RADIUS drops each authenticated user onto VLAN 10. Where some older staff device cannot do EAP-TLS, PEAP with strictly enforced server-certificate validation is the fallback, never PEAP with validation off.
• Guest uses WPA3 Enhanced Open (§8.2) so that even open guest traffic is encrypted against passive sniffing, behind a captive portal for terms-of-use and basic accountability, with client isolation on so guests cannot attack each other. The guest firewall policy is the entire point: internet only, deny everything internal, no exceptions.
• Operational devices get their own WPA3-Personal SSID with a strong, unique passphrase, on a segment that can reach neither the internet (so a compromised camera cannot phone home or be reached from outside) nor the staff segment. These weak devices are quarantined by design.
• Protected Management Frames (802.11w) are enforced everywhere (automatic with WPA3), defeating deauthentication attacks and the evil-twin luring that depends on them (§8.4).
• A WIDS runs across all branches (§8.4), alerting on rogue APs bridged to any segment and on any radio advertising a Meridian SSID from unauthorized hardware.
• The default-deny cross-segment rules (Chapter 7) are the keystone. Even if an attacker fully compromises the guest segment — or stands up an evil twin and intercepts a guest's traffic, or plugs a rogue AP into the ops segment — they reach nothing of value, because no path exists from those segments to the staff segment or the banking applications. This is defense in depth applied to wireless: every wireless control above may fail, and segmentation is the layer that holds.

🛡️ Defender's Lens: The reason segmentation is the keystone and not just one control among many is the asymmetry from Chapter 1. You cannot guarantee that no employee will ever plug in a rogue AP, that no device will ever connect to an evil twin, that every PEAP supplicant is perfectly configured. Each of those is a "defender must be right every time" bet, and you will eventually lose one. Segmentation changes the stakes of losing: it converts "wireless compromise" from "attacker is now adjacent to the core banking network" into "attacker is on an isolated segment that reaches the public internet and nothing else." You design the blast radius in advance, on the assumption that the wireless layer will be breached — because over 120 branches and years of operation, somewhere, sometime, it will.

⚠️ Common Pitfall: Treating guest WiFi as low-risk because "it's just internet for customers." Guest WiFi is low-risk only if it is genuinely isolated. The danger is never the guest internet access itself; it is the quiet assumption that a network labeled "guest" is therefore harmless, leading someone to "temporarily" allow a guest-segment device to reach an internal printer or file share for convenience — and now the isolation is broken and the guest network is a path inside. Audit the guest firewall rules specifically and regularly for any allow-rule toward an internal destination. The label "guest" guarantees nothing; the firewall rules do.

This design is the wireless policy artifact Meridian's security program needs, and we formalize it in the Project Checkpoint.

🔄 Check Your Understanding: 1. Meridian's branch has three wireless populations. Name them and the single design principle that keeps a compromise of one from harming the others. 2. Suppose an attacker successfully stands up an evil twin in a Meridian branch parking lot and a guest's laptop connects to it. With the design above, what has the attacker actually gained access to, and why is that survivable?

Answers

1. Staff (bank-issued devices needing internal access), guest (visitors needing internet only), and operational/IoT devices (printers, cameras, signage). The principle is segmentation with default-deny between segments: each population is on its own VLAN/segment, and no path exists from guest or ops to the staff segment, so compromising one reaches nothing in the others. 2. The attacker can intercept that guest's own internet traffic (which is why guest gets Enhanced Open encryption and why sensitive sites use TLS) — but the guest device was on the internet-only guest segment with no route to anything internal, so the attacker gains no access to Meridian's banking applications, customer data, or internal network. It is survivable because the segmentation made the guest segment's blast radius "the public internet and nothing else," designed in advance on the assumption the wireless layer could be breached.

Project Checkpoint

This chapter advances Meridian's security program with a wireless policy and adds the wifiaudit.py module to your bluekit toolkit.

Program increment — the wireless policy. Sam Whitfield writes Meridian's wireless standard, and it is short, specific, and enforceable — exactly the qualities a policy needs to survive an OCC examination and actually change behavior. The policy codifies the §8.6 design as rules: WPA3 required on all new wireless (WPA2-AES permitted only where hardware cannot do WPA3, with an expiry date); WEP and WPA(TKIP) prohibited and treated as critical findings; staff wireless must use WPA-Enterprise (802.1X) with EAP-TLS preferred and PEAP permitted only with enforced server-certificate validation; guest wireless must be internet-only and fully isolated from internal segments by default-deny firewall rules; operational/IoT wireless must be segmented from both staff and internet; Protected Management Frames (802.11w) required; a WIDS must monitor all branches for rogue APs and SSID impersonation; and unauthorized access points are prohibited and removed on detection. The policy joins the network-architecture artifact from Chapters 6–7 in Meridian's growing program document; the full policy template lives in Appendix I.

bluekit increment — wifiaudit.py. We turn the §8.2 protocol rule and the §8.6 design rules into a function that grades a wireless configuration the way an auditor would — flagging the dangerous settings so a human does not have to remember every rule. As always, the code is never executed during authoring; the expected output is hand-traced in a comment.

# bluekit/wifiaudit.py  — Chapter 8 increment
"""Assess a wireless network configuration against Meridian's policy.

Input cfg is a dict describing one SSID/network. We return a list of
finding strings (empty list == passes). Defensive: we only flag
misconfigurations; we never attack anything.
"""

WEAK_PROTOCOLS = {"open", "wep", "wpa", "wpa-tkip"}   # prohibited or deprecated

def assess_wifi(cfg: dict) -> list[str]:
    """Return policy findings for one wireless network config."""
    findings = []
    proto = cfg.get("protocol", "").lower()
    if proto in WEAK_PROTOCOLS:                       # §8.2: WEP/WPA/open are findings
        findings.append(f"CRITICAL: weak/deprecated protocol '{proto}'")
    if proto == "wpa2-personal" and len(cfg.get("psk", "")) < 20:
        findings.append("HIGH: WPA2-PSK passphrase < 20 chars (offline-crackable)")
    if cfg.get("role") == "staff" and "enterprise" not in proto:
        findings.append("HIGH: staff network not using WPA-Enterprise (802.1X)")
    if proto.endswith("enterprise") and not cfg.get("server_cert_validation", False):
        findings.append("CRITICAL: enterprise EAP without server-cert validation (evil-twin risk)")
    if cfg.get("role") == "guest" and not cfg.get("isolated_from_internal", False):
        findings.append("CRITICAL: guest network not isolated from internal segments")
    if not cfg.get("pmf", False):                     # §8.4: 802.11w stops deauth
        findings.append("MEDIUM: Protected Management Frames (802.11w) not enforced")
    return findings


if __name__ == "__main__":
    bad_guest = {"protocol": "wpa2-personal", "psk": "guest", "role": "guest",
                 "isolated_from_internal": False, "pmf": False}
    good_staff = {"protocol": "wpa3-enterprise", "role": "staff",
                  "server_cert_validation": True, "pmf": True}
    for name, cfg in (("Branch-Guest", bad_guest), ("Branch-Staff", good_staff)):
        issues = assess_wifi(cfg)
        print(f"{name}: {'PASS' if not issues else str(len(issues)) + ' finding(s)'}")
        for i in issues:
            print(f"    - {i}")

# Expected output:
# Branch-Guest: 3 finding(s)
#     - HIGH: WPA2-PSK passphrase < 20 chars (offline-crackable)
#     - CRITICAL: guest network not isolated from internal segments
#     - MEDIUM: Protected Management Frames (802.11w) not enforced
# Branch-Staff: PASS

Trace the bad-guest case by hand to see the tool think: its protocol is wpa2-personal (not in WEAK_PROTOCOLS, so no critical-protocol finding), but the PSK "guest" is 5 characters — under 20 — so the offline-crackable finding fires; its role is guest and isolated_from_internal is False, so the isolation finding fires; and pmf is False, so the management-frames finding fires. Three findings, exactly the output shown. The good-staff config uses wpa3-enterprise with server-cert validation and PMF on, and is not a guest network, so every check passes. You have written a tool that turns Meridian's wireless policy into an automatic check — the same move from "human must remember the rules" to "the tool enforces the rules" that you will make again for firewalls, baselines, and cloud posture.

Summary

This chapter built the defender's model of wireless security: a trustworthy network on an untrustworthy medium.

• Wireless removes physical access control. The cable was a control; radio leaves the building. Assume the medium is observed and writable by an unauthenticated attacker, so: encrypt everything, authenticate strongly, segment ruthlessly.
• Protocol evolution, with the rule to memorize: WEP (RC4 + 24-bit IV) is broken — key recoverable from traffic in minutes regardless of passphrase, a critical finding. WPA (TKIP) is a deprecated stopgap, treat as near-WEP. WPA2 (AES-CCMP) is sound when patched, but Personal/PSK mode is offline-guessable, so passphrase strength is everything. WPA3 (SAE/Dragonfly) resists offline guessing, adds forward secrecy and Enhanced Open, and mandates PMF. Decision rule: WPA3 if you can, WPA2-AES with a long random passphrase if you must, never WPA/WEP.
• A shared passphrase is a liability at scale — un-revocable, unattributable, sticky-note-prone. WPA-Enterprise (802.1X + EAP, via a RADIUS server) gives every user a revocable, auditable identity and assigns VLANs at connect time. EAP-TLS (mutual certificates) is the gold standard; PEAP/EAP-TTLS (password in a TLS tunnel) are easier but demand enforced server-certificate validation or an evil twin harvests AD passwords.
• Rogue AP = an unauthorized AP connected to your network (a doorway inside); evil twin = a rogue AP impersonating your SSID to lure devices (a man-in-the-middle / credential trap). The deauthentication attack forges unauthenticated management frames to disconnect devices, forcing handshake re-capture and evil-twin luring; 802.11w (PMF) defeats it.
• Detect with a WIDS: rogue AP = unknown radio bridged to your wire; evil twin = your SSID from unauthorized hardware (BSSID allowlist); deauth flood = a spike in deauth frames. You cannot prevent transmission in a parking lot; you detect fast and contain.
• Bluetooth (short range, ~10 m) is usually lower-risk than WiFi but not zero — BlueBorne-class bugs compromise unpaired devices in range, so patch, disable when unused, and inventory peripherals. NFC (~cm range) is narrow: contactless payments use one-time cryptograms (skimming yields little), but legacy access badges can be cloned — use modern credentials.
• Meridian's branch design: three SSIDs → three firewalled VLANs. Staff = WPA3-Enterprise/EAP-TLS; Guest = WPA3 Enhanced Open + captive portal + client isolation, internet-only, deny all internal; Ops/IoT = segmented from both. PMF everywhere, WIDS across branches, and default-deny between segments as the keystone that makes any wireless compromise survivable.
• bluekit: wifiaudit.py with assess_wifi(cfg) grades a wireless config against this policy.

Spaced Review

Retrieval practice over this chapter and earlier ones. Answer before checking.

1. (This chapter) State the single decision rule for choosing a WiFi security protocol, and name the precise flaw that makes WEP unfixable by passphrase strength.
2. (This chapter) Why is segmentation — not WPA3, not the WIDS — described as the keystone of Meridian's wireless design?
3. (Chapter 6) Meridian's wireless design puts each SSID on its own VLAN with default-deny between segments. Define network segmentation and explain why "east-west" isolation matters here even though all three networks are "inside" the branch.
4. (Chapter 4) EAP-TLS authenticates both client and server with X.509 certificates instead of a password. What is a digital certificate, and what does the certificate's signature by a CA let the other party verify?

What's Next

You have now secured the network from its physical-layer foundations (Chapter 6) through its perimeter controls (Chapter 7) to its most exposed medium, the air. But the most dangerous wireless device of all is not an enterprise access point — it is the swarm of phones, tablets, embedded controllers, cameras, and ATMs that fill a modern bank, most of them wireless, many of them unpatchable, and far too many shipped with default credentials. Chapter 14 takes up mobile and IoT security: how to inventory, segment, and monitor the devices that now outnumber the humans, building directly on the segmentation discipline you just applied to Meridian's branch WiFi. The operational-device segment you designed in this chapter is where that story begins.