Wi-Fi Tracking, Probe Requests and MAC Randomisation

Every phone and laptop with Wi-Fi switched on announces itself to the radios around it, and for years that announcement carried a fixed, globally unique hardware address that anyone with a sensor could log. Shopping centres, transport operators and advertising networks built footfall and location analytics on top of it, and attackers used the same frames to profile people and lure devices onto fake hotspots. MAC address randomisation in iOS, Android and Windows closed the easiest hole, but research shows devices can still be fingerprinted from probe request content, sequence numbers and the network names they ask for. This guide explains how Wi-Fi tracking works, what each operating system randomises and when, why hidden networks make the problem worse, and how enterprise network teams can support randomised addresses without switching privacy off. It is written for network, endpoint and privacy practitioners.

Key takeaways

The MAC address is only one identifier. Probe request information elements, sequence numbers, DHCP host names and the list of saved network names can all re-identify a device after its address changes.
Randomisation behaviour differs by platform. Apple offers Off, Fixed and Rotating per network, Android derives a persistent random address per network profile, and Windows exposes a Random hardware addresses toggle where the hardware supports it.
Hidden networks hurt client privacy. A device configured for a non-broadcast SSID has to ask for that name by itself, which leaks the network name wherever the device goes.
Do not build security on MAC addresses. Allow lists, captive portal sessions and NAC rules keyed on MAC break under randomisation and were always spoofable; use 802.1X with certificates or device identity instead.
Collected MAC data is personal data in most cases. If you run Wi-Fi analytics, treat device identifiers as personal data under UK and EU GDPR, minimise them and hash them with a secret salt.

How Wi-Fi tracking works

A Wi-Fi client discovers networks in two ways: it listens for beacons that access points broadcast, and it actively scans by sending probe requests. A probe request is a management frame sent in the clear before any association or encryption, so any receiver on the channel can read it. RFC 9724 notes that a Wi-Fi device exposes its MAC address in probe requests while scanning, and in the unicast address fields of every frame once associated. A universally administered (factory) MAC address is globally unique and static, which is exactly what makes it useful for tracking.

Passive sensors: footfall counters, retail analytics nodes and many enterprise access points log every probe request they hear, with timestamp and signal strength.
Wildcard probes: ask "which networks are here?" and carry no network name. They still carry the source MAC and a set of information elements describing the radio's capabilities.
Directed probes: name a specific SSID. Older devices, and devices configured for hidden networks, send directed probes for saved networks, which reveals where the owner has been (home, employer, hotel).
Association traffic: once connected, the client MAC appears in every frame and in the DHCP request, often alongside a host name such as "Sarahs-iPhone" in DHCP option 12, which the IETF MADINAS working group draft lists as an identifier randomisation does not hide.
Active lures: a rogue access point that advertises a common public SSID can attract devices that have saved it. Vanhoef and colleagues found that fake hotspots using popular SSIDs caused 17.4% of observed devices to connect with their real MAC address. See the Public Wi-Fi Safety Guide.

Real deployments show the scale. Transport for London piloted Wi-Fi data collection in December 2016 and then turned it on across the Underground, collecting the MAC addresses of Wi-Fi enabled devices that searched for a network. TfL hashed each address twice and encrypted the result, and told passengers who did not want to take part to switch Wi-Fi off or use flight mode.

What randomisation changes, platform by platform

A randomised address sets the locally administered bit and clears the multicast bit, and randomises the remaining 46 bits, as the Android Open Source Project documentation describes. That bit pattern is also how a network team can tell a random address from a factory one: the second hexadecimal digit of the first octet is 2, 6, A or E.

Platform	Setting name	Modes and defaults	When the address changes
iOS and iPadOS 18, macOS Sequoia 15, watchOS 11, visionOS 2 and later	Private Wi-Fi Address	Off, Fixed or Rotating per network. New networks using WPA2 or stronger default to Fixed; open or weak networks default to Rotating	Rotating changes every two weeks. Forgetting a network discards its address unless it was forgotten less than 24 hours earlier. Erase all content or reset network settings also changes it
iOS and iPadOS 14 to 17	Private Wi-Fi Address (toggle)	On or off per network	Forgetting a network discards its address unless forgotten less than two weeks earlier; a network not joined for six weeks gets a new address
Android 10 and later	Privacy, Use randomized MAC (per network)	Persistent randomisation by default, derived from the network profile (SSID and security type, or FQDN for Passpoint)	Persistent address stays the same until factory reset, even if the network is forgotten and re-added
Android 12 and later, selected cases	Non-persistent randomisation	Requested by a network suggestion app through `setMacRandomizationSetting`, or for open networks with no captive portal when the device maker enables `config_wifiAllowEnhancedMacRandomizationOnOpenSsids`	Re-randomised at connection start if the DHCP lease has expired and four hours have passed since disconnect, or if the address is more than 24 hours old
Windows 10 and 11	Random hardware addresses	Global toggle under Settings, Network and internet, Wi-Fi, plus a per-network toggle under Manage known networks	Only where the Wi-Fi hardware supports it; applies to scanning and to connections

Apple also documents scan-time protections beyond the address: devices use a randomised address for scans while not associated, randomise frame sequence numbers whenever the address changes (from iOS 16.1 and macOS 13.1), change the scrambling seed for every probe request, and randomise dialogue tokens. Apple states that scans made while trying to join a preferred network are not randomised.

RFC 9724, an Informational RFC published in March 2025, summarises tests from September 2021: per-network randomisation appeared in all the operating systems tested, randomisation during scanning appeared in all of them, daily rotation appeared only in Windows 10, and per-connection rotation only in Linux.

Why randomisation is not enough

The 2016 ASIA CCS paper "Why MAC Address Randomization is not Enough" by Vanhoef, Matte, Cunche, Cardoso and Piessens remains the clearest account of the residual identifiers. The table below combines its findings with RFC 9724 and the MADINAS draft.

Residual identifier	How it re-identifies a device	Mitigation status
Information elements in probe requests	The set, values and order of IEs form a fingerprint; across over 8 million probe requests the combined IEs carried more than 5.4 bits of entropy, sometimes unique to a device	Paper recommends minimising IEs and standardising order; varies by chipset and driver
Frame sequence numbers	Most devices kept incrementing the 12-bit counter across address changes, letting an observer link old and new addresses; with IE fingerprints about half of devices were tracked for at least 20 minutes	Apple randomises sequence numbers on address change from iOS 16.1; check other platforms
Saved network names	Devices that send directed probes broadcast their SSID list; 53 to 65% of SSID-broadcasting devices had a unique list	Modern OSes avoid directed probes except for hidden networks
WPS UUID-E	On Linux the UUID was derived from the MAC with an unsalted hash, so the real address could be recovered for most devices that sent it	Driver and supplicant specific
Hotspot 2.0 ANQP queries	Fake Passpoint access points triggered queries that revealed the real MAC (Linux, Windows) or a predictable dialogue token (iOS)	Apple now randomises dialogue tokens
DHCP and higher layers	DHCP client identifiers and host names (option 12) correlate across address changes; RFC 9724 reports some systems sent persistent identifiers periodically	Needs coordinated privacy across layers, as RFC 9724 concludes

The practical conclusion: randomisation defeats casual, large-scale MAC logging, but a determined observer with good sensors can still link a device across short periods, and an active attacker with a rogue access point can often learn more. Treat Wi-Fi as a channel that leaks presence, and decide what level of tracking resistance each user group needs.

Hidden networks: a privacy cost, not a security control

Hiding an SSID stops the access point from naming the network in its beacons. It does not hide the network: the SSID still appears in probe responses and association frames whenever a client connects, and any wireless survey tool lists the network as present. The cost falls on clients. Because the network does not announce itself, every device configured for it has to send directed probes naming it, at home, in the office and in every airport and café the owner visits. The Vanhoef paper notes that broadcasting SSIDs in probes is still needed for hidden networks, which is why it remains a fingerprinting source.

Enterprise profiles: in Windows Wi-Fi profiles delivered through the WiFi configuration service provider, the WLAN profile XML carries a nonBroadcast element inside SSIDConfig. Set it to true only for networks that genuinely do not broadcast, because it forces the client behaviour described above.
Decision: broadcast the SSID and protect the network with WPA3 or 802.1X. See the Securing Your Wi-Fi Network Guide and the WPA3 Migration and Transition Mode Guide.
Legacy cases: if an operational network must stay hidden, limit which managed devices carry its profile, and do not push it to laptops and phones that travel.

Supporting randomised addresses on enterprise and guest networks

The IETF draft draft-ietf-madinas-use-cases-19 (Internet-Draft, Informational intent, dated 20 December 2024, a work in progress as of November 2026) catalogues what breaks when clients randomise and change addresses. The table maps each effect to a fix that keeps privacy on.

What breaks	Effect	Better approach
MAC allow lists and MAC authentication bypass	Known devices appear new; users are blocked or sent to onboarding	802.1X with EAP-TLS and device certificates. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide
DHCPv4 leases	Scope exhaustion as servers hold leases for addresses that never return	Shorter lease times on guest and high-churn scopes; size scopes for randomisation. See the DHCP Security Guide
802.1X sessions	Port stays closed until the AAA server validates the new address; extra AAA load	Expect re-authentication; tune session timeouts and RADIUS capacity
Captive portal sessions	Guests asked to log in again after rotation	Passpoint or OpenRoaming profiles, or accept re-login on open networks where Rotating is the default
Parental controls and per-device policy at home	Rules keyed on MAC stop matching	Per-network Fixed or persistent addresses are stable; policy by device account rather than MAC

For corporate devices, turning randomisation off is a deliberate exception, not a default. Apple supports an MDM-defined network profile that disables Private Wi-Fi Address for enrolled devices on that network. Microsoft Intune's Android Enterprise Wi-Fi profiles have a MAC address randomization setting with three values: Use device default, Use randomized MAC and Use device MAC (Android 13 and later). Microsoft's own documentation recommends Use device MAC only when necessary, for example for NAC support, because the device can then be tracked by that address. See the Mobile Device Management Security Guide.

Where identity fits

MAC addresses were never a strong device identity: they are sent in the clear and trivially changed. Randomisation simply makes that obvious. Network access decisions should rest on credentials a device can prove: a device certificate issued through MDM, an 802.1X identity, or a posture check tied to the endpoint management record. Those are machine identities, with the same lifecycle problems as any other: issuance, renewal, revocation when a device is lost, and inventory. See the Network Access Control Buyer's Guide.

If you run Wi-Fi analytics

The UK GDPR definition of personal data, which the ICO quotes, lists an online identifier among the identifiers that can make a person identifiable directly or indirectly. A device MAC address seen repeatedly in a store, a station or an office is linked to one person's movements, so plan on treating it as personal data. See the Location Data Privacy Guide.

Decide the purpose first: occupancy counts need far less than dwell time or repeat-visit analysis. Record the lawful basis and purpose (NIST SP 800-53 PT-2 and PT-3 describe the same discipline).
Pseudonymise at the sensor: hash the MAC with a secret salt before it leaves the sensor, and rotate the salt on a schedule that matches the purpose. TfL's double hash and encryption approach is one published example.
Drop locally administered addresses where the purpose is counting unique visitors, since randomised addresses inflate counts and add no value.
Tell people and set retention: signs, an online notice and a practical opt-out (turning Wi-Fi off); aggregate to counts and delete raw identifiers quickly, with a retention period set per purpose (an NHI Mgmt Group recommendation, not a regulatory figure).
Test the result: try to re-identify a known test device in the stored data. If you can, so can someone else.

Detection and measurement

Randomised share: percentage of client associations using locally administered addresses, per SSID. A sudden drop on a guest network may mean a profile disabled randomisation.
MAC-based exceptions: count of MAC allow list or MAC authentication bypass entries; target a declining trend as devices move to certificates.
Use device MAC profiles: number of managed devices with randomisation disabled, each with a documented reason.
Hidden SSIDs: number of non-broadcast SSIDs in production and number of devices carrying those profiles.
Rogue lures: wireless intrusion detection alerts for access points advertising your SSIDs or common public SSIDs in your buildings. NIST SP 800-53 SI-4(14) covers wireless intrusion detection. See the Wireless intrusion detection guide.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	AC-18, AC-18(1)	Wireless access usage restrictions, authentication and encryption rather than MAC filtering
NIST SP 800-53 Rev. 5	SC-40, SC-40(4)	Wireless link protection; SC-40(4) asks for mechanisms that prevent identification of devices from transmitter signal parameters
NIST SP 800-53 Rev. 5	SI-4(14)	Wireless intrusion detection for rogue access points and lures
NIST SP 800-53 Rev. 5	PT-2, PT-3	Authority and purpose for processing device identifiers in Wi-Fi analytics
NIST CSF 2.0	PR.AA-03, PR.PS-01, DE.CM-01, ID.AM-01	Authenticate hardware, configure endpoint Wi-Fi profiles, monitor wireless networks, keep a device inventory that does not depend on MAC
ISO/IEC 27001:2022 Annex A	A.5.34, A.8.1, A.8.20	Privacy and protection of PII, user endpoint devices, networks security
CIS Controls v8.1	Control 12	Network infrastructure management, including secure wireless configuration
MITRE ATT&CK v20	T1669 Wi-Fi Networks	Adjacent threat: adversaries gaining access through Wi-Fi, which the same rogue access point monitoring helps detect. See MITRE ATT&CK T1669 Wi-Fi Networks

Common failure patterns

Disabling randomisation fleet-wide to fix NAC: a single "Use device MAC" profile applied to every SSID exposes factory addresses everywhere the device goes. Scope it to the networks that need it, and plan the move to certificates.
Hiding the corporate SSID for security: the network stays visible to any survey tool, and every corporate laptop now announces the company's network name in public places.
Counting randomised addresses as people: analytics that do not filter locally administered addresses overcount, and teams then push for more invasive identifiers to fix the numbers.
Storing raw MACs "for later": unhashed identifiers kept indefinitely turn a footfall project into a movement database that must be disclosed and protected.
Trusting MAC allow lists: any device in radio range can copy an allowed address it has observed. Randomisation did not create that weakness; it only exposed how often MAC filtering stood in for authentication.

Practitioner checklist

Inventory SSIDs and flag any non-broadcast networks; plan to broadcast them with strong authentication.
Review MDM Wi-Fi profiles for disabled randomisation (Apple MDM network profiles, Intune Use device MAC) and document each exception.
Replace MAC allow lists and MAC authentication bypass with 802.1X and device certificates where devices support it.
Size DHCP scopes and lease times for guest and BYOD networks with address churn in mind.
Enable wireless intrusion detection for rogue access points advertising your SSIDs or common public SSIDs.
For Wi-Fi analytics, document purpose and lawful basis, hash identifiers with a secret rotating salt and aggregate early.
Advise travelling staff to keep randomisation on, prune saved open networks and turn Wi-Fi off where tracking matters.
Re-check platform behaviour after major OS releases, since rotation rules have changed several times since 2020.

Wi-Fi Tracking Guide: Probe Requests, MAC Randomisation and Hidden Networks