How a phone decides which wifi network to join
Every time a phone comes out of a pocket, it runs a small negotiation nobody sees. Before a single app loads, the radio has already scanned the air, checked a stored list, weighed signal strength, and picked a network to trust. That decision happens in milliseconds and it looks trivial. It isn’t. Wifi network selection is one of the oldest attack surfaces in wireless security, and the defenses built around it explain a lot about how modern operating systems think about identity and trust.
The preferred network list is a memory of the past
Every time a phone joins a wifi network successfully, the operating system stores an entry in what’s usually called the preferred network list, or PNL. The entry holds the SSID (the network name), often a priority value, and security parameters like the WPA key or enterprise certificate. iOS and Android both maintain this list indefinitely unless a user manually forgets a network.
When the phone wakes up and starts scanning, it isn’t just looking for “a wifi network.” It’s checking the visible networks against this stored list. A network the phone has joined before gets treated very differently from one it’s never seen. This is why a phone reconnects instantly to a home router but has to go through a full handshake and captive portal for a new coffee shop network.
The PNL is also the reason wifi selection is inherently a matching problem, not a ranking problem. The phone isn’t asking “which network is best.” It’s asking “which known network is present, and if more than one is, which one wins.”
Signal strength decides among the visible
When multiple known networks are visible, or when a phone is deciding whether to roam from one access point to another on the same SSID (common on enterprise or mesh networks with several APs broadcasting the same name), the primary input is received signal strength, RSSI, measured in dBm.
Modern chipsets don’t just grab the strongest signal the instant it edges ahead. Roaming logic usually applies a hysteresis margin, meaning the new access point has to beat the current one by a meaningful threshold, often several dB, before the phone switches. Without that margin, a phone sitting at the boundary between two APs would flap back and forth, dropping packets each time. Standards like 802.11k (neighbor reports), 802.11v (BSS transition management), and 802.11r (fast roaming) exist specifically to make this handoff faster and more informed, letting the access point tell the phone which neighboring APs are worth considering instead of making the phone discover them blind.
This is also where “signal strength” and “network quality” diverge, something anyone who has debugged a flaky wifi deployment already knows. A phone can lock onto a strong signal from a congested or backhaul-starved AP and stay there, because RSSI alone doesn’t measure throughput, latency, or how many other devices are fighting for the same channel.
Probe requests used to give away a phone’s history
Before it associates with anything, a phone scans. Scanning can be passive, listening for beacon frames that access points broadcast on their own, or active, where the phone sends out probe requests asking “is anyone here?” For years, active probes on most phones included the SSIDs from the preferred network list, effectively broadcasting a phone’s wifi history to anyone with a receiver in range.
That was a real problem. A device announcing “HomeWifi-Smith,” “OfficeCorp-Guest,” and “HotelChain-Lobby” in three consecutive probe frames is handing out a rough travel itinerary to anyone running a packet capture. Security researchers used this for years to build tracking and correlation tools, and it’s part of why retail analytics companies got interested in wifi scanning in the first place: probes are a passive census of who’s nearby and, if directed, what networks they trust.
iOS and Android both moved away from this behavior. Modern devices lean much more heavily on passive scanning and only send directed probe requests for hidden networks, which by definition don’t show up in a beacon. The shift didn’t eliminate the signal entirely, since hidden-network probes and scan timing patterns can still be fingerprinted, but it closed off the easiest version of the leak.
MAC randomization broke a simpler kind of tracking
The other half of the fingerprinting problem was the MAC address itself. Wifi radios used to broadcast a fixed hardware MAC address in every probe and every association, which made a phone trivially trackable across visits to the same venue, mall, or transit station, regardless of what SSID it connected to.
Both major mobile platforms now randomize the MAC address used for scanning, and separately randomize (or at least vary) the MAC used per network for association, so a phone can present a different address to every SSID it joins. This breaks the naive version of cross-venue tracking that relied on a stable hardware address. It doesn’t break all correlation. A venue that captures other identifiers, connection timing, signal strength patterns, or app-layer signals like advertising IDs can still stitch a visit together. MAC randomization closes one door, not the whole hallway.
Why an evil twin works on trust in a name, not a network
An “evil twin” is an access point set up to broadcast the same SSID as a legitimate network, sometimes with a stronger signal, sometimes with matching security settings, in the hope that nearby phones or their users pick it automatically or manually. The underlying weakness it exploits is simple: SSIDs are just text strings. Nothing in the base 802.11 standard cryptographically ties a network name to a specific physical access point or operator, which is why enterprise networks that care about this lean on 802.1X with server-side certificate validation rather than a shared passphrase.
The way these get caught, from a defensive standpoint, comes down to a handful of signals that don’t match. A rogue AP usually has a different BSSID (the AP’s own hardware MAC) than the legitimate one, and organizations running wireless intrusion prevention systems maintain a known-good list of BSSIDs per SSID, flagging anything new that shows up broadcasting a trusted name. The OUI (the vendor prefix of the MAC address) can be wrong for the hardware a venue is known to use. On networks that use certificate-based authentication, a rogue AP can’t present a valid certificate signed by the real network’s authority, and a properly configured device will refuse to connect or throw a visible trust warning rather than silently accepting it. Captive portal behavior can also be a tell: a rogue AP designed to harvest credentials often serves a suspiciously generic or slightly-off login page, which is exactly the kind of mismatch automated wireless security monitoring is built to flag.
None of this makes evil twins rare. It’s precisely because the base protocol trusts a broadcast string that wireless security teams have to build detection on top of it rather than relying on the standard to prevent it.
What a captive portal is actually checking
The little “sign in to this network” prompt that pops up on public wifi isn’t magic. Phones run a connectivity check after associating: they request a specific, known URL, like Apple’s captive.apple.com or Google’s connectivity check endpoints, and look for an expected response. If the network intercepts that request and returns something else, a login page, a redirect, anything other than the expected content, the OS concludes the network is walled off and surfaces the captive portal browser. If the expected response comes back untouched, the phone assumes it has real internet access and skips the prompt entirely. It’s a narrow, specific check, not a general audit of the network, which is part of why some restrictive networks can still let certain traffic through undetected by this mechanism.
Why this matters beyond a single phone
None of this is really about one device picking one network. It’s about how much implicit trust gets extended based on a broadcast name, a signal strength number, and a stored history list, and how much of modern mobile security has been retrofitted to add verification where the original protocol assumed good faith. Every layer discussed here, PNL matching, RSSI thresholds, probe behavior, MAC randomization, certificate validation, connectivity checks, exists because an earlier, simpler version of wifi selection turned out to be exploitable, trackable, or both. The cat-and-mouse didn’t stop with 802.11i and WPA2. It just moved up a layer, into how the radio decides who to talk to in the first place.
If you want more of this kind of teardown, on the infrastructure that decides who a device trusts and how that trust gets tested, check out the rest of the site here.
Get new guides and videos first — join the Telegram channel.