Wi-Fi Probe Requests Explained: Phone Tracking and MAC Randomisation

A Wi-Fi probe request is a short frame your phone broadcasts to ask which networks are nearby. It carries a hardware address, often a list of capabilities and sometimes the names of networks you have saved, so sensors can count and follow devices without them ever connecting. MAC randomisation hides the address; other fields can still give a device away.

The same frame feeds retail footfall counters and venue analytics, and the fix most people know, a random MAC address, solves the obvious part of the problem and leaves subtler parts untouched. This post goes one level deeper than our history of network cards and MAC randomisation and our guide to wardriving and protecting your Wi-Fi: what is inside a probe request, what regulators said, how each operating system randomises addresses according to its own documentation, what research says still leaks, what the new standards do, what breaks on networks, and how to inspect your own phone's probes in a lab.

Key takeaways

• Phones send probe requests during active scanning to find networks faster and to find hidden networks. A probe can be broadcast (asking for any network) or directed (naming one network), and directed probes can reveal the names of networks you have saved.
• A probe request identifies a device through more than its MAC address: the set and order of information elements, the sequence number, the timing between bursts and the received signal strength all help an observer link frames together.
• The US Federal Trade Commission settled with a retail tracking firm on 23 April 2015 over in-store tracking via MAC addresses; its complaint said the firm collected information on about nine million devices in the first nine months of 2013. The UK ICO published Wi-Fi location analytics guidance (version 1.0, 16 February 2016) that called for salted hashing, notices, limited collection zones and short retention.
• Apple, Android, Windows and Linux all randomise addresses, with different defaults. Android randomises scan addresses from Android 8.0 and connection addresses by default from Android 10. Apple offers Off, Fixed and Rotating per network from iOS 18 and macOS Sequoia 15. Windows has a per-device and per-network switch. NetworkManager randomises scans by default and lets you choose per connection.
• Research from 2016 and 2017 showed that information element fingerprints, sequence numbers and a few active tricks could link or unmask randomised devices. Vendors have since randomised sequence numbers, scrambler seeds and dialog tokens.
• IEEE 802.11bh (published 3 June 2025) helps networks keep services working when clients change addresses. IEEE 802.11bi (board approved 25 September 2026, listed as published 23 October 2026) adds privacy protection to the 802.11 MAC. The IETF MADINAS working group published RFC 9724 (March 2025) and RFC 9797 (June 2025) and then closed.
• Randomisation breaks things that assumed a fixed address: captive portal sessions, DHCP reservations, MAC based parental controls, MAC allow lists and some network access control. The durable fix is to identify users with authentication, not with hardware addresses.

What a probe request is and why devices send them

Wi-Fi clients find networks in two ways, and the difference is the whole story of probe request tracking.

Passive scanning and active scanning

In passive scanning the client tunes to each channel and listens for beacons. Access points send beacons several times a second, each announcing the network name (the SSID), supported rates and security settings. Passive scanning sends nothing, so it reveals nothing about the client, but it is slow: the client has to dwell on each channel long enough to hear a beacon.

In active scanning the client transmits a probe request on a channel and waits briefly for probe responses. Access points that match answer straight away. Active scanning is faster, which matters for battery life, roaming between access points, and the moment you unlock your phone and expect it to find the café network. The UK Information Commissioner's Office described the consequence plainly in its 2016 guidance: when a Wi-Fi enabled device is switched on, it will "continually broadcast 'probe requests'" to discover networks in range.

Operating systems also scan for reasons unrelated to joining a network: Apple's Platform Security Guide says its scans can "assist Location Services", for example for geofenced reminders.

Broadcast probes, directed probes and hidden networks

A probe request carries an SSID field. If it is empty (a wildcard), the probe asks every network on the channel to respond. If it contains a name, it is a directed probe asking only that network to respond.

Directed probes exist mainly because of hidden networks. A hidden network leaves its name out of beacons, so a client cannot learn of it by listening. The only way to find it is for the client to call out its name. NetworkManager's settings reference has a hidden property for exactly this case: setting it to true indicates "a non-broadcasting network that hides its SSID", so the client knows it has to ask for that name.

That design has a privacy cost. A device that has saved a hidden network will keep asking for it by name wherever it goes, so anyone nearby can learn the name of your home or office network, and a list of directed probes from one device can be as distinctive as a fingerprint. Exactly which saved names a device includes in directed probes depends on the operating system and driver, and vendors do not all document it, but a network you have marked as hidden is the case where the client has no other way to find it. That is one reason the most useful privacy setting in this whole post is simply not to hide your own network's name.

What is inside a probe request

A probe request is an 802.11 management frame. Its header and body contain these fields, each of which can help or hurt privacy.

Our post on Wi-Fi generations from 802.11b to Wi-Fi 7 and Wi-Fi 8 explains where those capability elements came from. Each generation added optional detail, and each optional detail is another bit an observer can use.

Reading a MAC address: OUI, the local bit and the multicast bit

A MAC address is six bytes. In a factory address the first three bytes are an organisationally unique identifier assigned by the IEEE Registration Authority to the manufacturer, which is why the ICO guidance points out that the first part of an address identifies the maker of the Wi-Fi chip. The two lowest bits of the first byte carry special meaning. RFC 9724 shows the layout: bit b1 is the universal or local (U/L) bit, and when it is set to 1 the address is locally administered rather than burned in by a manufacturer. Bit b0 marks multicast.

That is how you can spot a randomised address by eye. Android's implementation guide tells testers to check that a randomised address has the locally generated bit set to 1 and the multicast bit set to 0. In hexadecimal that means the second character of the address is 2, 6, A or E. An address that starts x2:, x6:, xA: or xE: is locally administered and is very likely random. RFC 9724 also notes that IEEE 802c-2017 divides the local address space into quadrants (the Structured Local Address Plan), including ranges for administratively assigned and standard assigned identifiers, which is why some tools describe local addresses by quadrant.

How venues, retailers and cities count and track phones

How Wi-Fi analytics sensors work

The technique needs no cooperation from the phone. A sensor, often an ordinary access point with analytics firmware, records each probe request it hears: the source address, the time and the signal strength. The ICO's guidance explains the next step. Signal strength gives a rough distance, and when several access points hear the same device its position can be pinpointed more accurately. Repeat the measurement every few seconds and you have a path through a building.

Venues then compute aggregates: footfall per hour, how many passers by became visitors, dwell time, queue length, how often a device returns and whether it visited other sites in the same chain. Because the device never has to join a network, the ICO warned that data about a person may be processed covertly. The 2016 research paper by Vanhoef and colleagues opens with an example of the same idea outside shops: smart rubbish bins in the UK that used Wi-Fi to follow people's movements.

The same signals serve legitimate purposes such as troubleshooting and IoT presence detection, which RFC 9797 lists. The privacy question is not whether a network may see the address of a device that joins it. It is whether passers by who never connect should be followed, linked across days and sites, and kept on file.

What the FTC said in 2015

On 23 April 2015 the US Federal Trade Commission announced a settlement with Nomi Technologies, a company whose technology let retailers track consumers' movements through their stores. The FTC called it its first complaint against a retail tracking company. According to the FTC's press release:

• Nomi placed sensors in clients' stores that collected the MAC addresses of shoppers' phones as the phones searched for Wi-Fi networks.
• It hashed the addresses before storing them, but the FTC said the hash was still "unique to a consumer's mobile device and can be tracked over time".
• It recorded the address, device type, date and time and signal strength, tracking devices both inside and outside client stores.
• Its reports told retailers how many people passed by without entering, how long visitors stayed, how many were repeat customers and how many had visited another location in the same chain.
• The complaint alleged the company collected information on about nine million devices within the first nine months of 2013.

The legal theory was deception, not tracking as such. From late 2012 Nomi's privacy policy promised an opt out at stores using the service; the FTC alleged none existed and shoppers were not told. The proposed order barred the company from misrepresenting consumers' choices. The Commission vote was 3 to 2, and the agreement was open for public comment until 25 May 2015. The lesson: a privacy promise is a legal commitment, and hashing a fixed identifier does not make it anonymous.

What the UK ICO said

The ICO published "Wi-Fi location analytics" as version 1.0 on 16 February 2016, written under the Data Protection Act 1998, which has since been replaced by the UK GDPR and the Data Protection Act 2018. The specific legal references are dated, but the practical guidance still reads as a sound design checklist. In summary, it said:

• Processing device identifiers collected through Wi-Fi can be processing personal data. Using a MAC address to single someone out or treat them differently involves personal data even if you never learn a name.
• Do a privacy impact assessment and define the purpose before collecting.
• Tell people clearly, before collection happens.
• Remove identifiable elements. The ICO's worked example counts visitors per hour by hashing addresses with a salt, then rotating the salt after a short period so hashes from different periods cannot be linked to the same device.
• Define the bounds of collection. An airport example keeps sensors away from doors and windows to avoid collecting from passers by, and limits collection near toilets, staff rooms, first aid and prayer rooms.
• Set a retention period. A stadium example keeps individual level data only until aggregate reports are produced after the match.
• Give people a simple and effective way to control collection.

Our post on GPS, GNSS and location privacy covers the satellite side of location data; Wi-Fi analytics is the indoor counterpart.

Timeline

How MAC address randomisation works on each platform

Every major operating system now randomises addresses, but "randomisation" means three different things, and it helps to keep them apart:

1. Scan randomisation. A random address is used for probe requests while the device is not associated with any network.
2. Per-network randomisation. Each network sees a different address, which stays the same for that network so the network can still recognise you.
3. Rotating randomisation. The address used with one network changes over time, so even that network cannot follow you for long.

The descriptions below come only from each vendor's own documentation.

iPhone, iPad, Mac, Apple Watch and Apple Vision Pro

Apple's support article says its devices present a different Wi-Fi address to each network and may rotate that address periodically. The feature requires iOS 14, iPadOS 14, watchOS 7 or visionOS on mobile devices, and macOS Sequoia 15 or later on Mac.

From iOS 18, iPadOS 18, macOS Sequoia 15, watchOS 11 and visionOS 2, each network has three settings:

• Off: the device uses its hardware MAC address.
• Fixed: a private address that does not rotate. The device chooses Fixed by default for a new network that uses WPA2 or stronger security.
• Rotating: a private address that changes every two weeks. The device chooses Rotating by default for a new network with weak or no security.

If you make the device forget a network, it also forgets that network's private address, unless less than 24 hours have passed since you last forgot it. Before iOS 18, the rule was two weeks, and a device that had not joined a network for six weeks used a new address next time. Erasing all content and settings or resetting network settings produces a new private address.

Apple's Platform Security Guide covers the scanning side separately. Apple platforms use a randomised MAC address for Wi-Fi scans when not associated with a network, including scans for Location Services. Apple notes one exception: scans made while trying to connect to a preferred network are not randomised. The same page describes three further protections aimed squarely at the research described below:

• Sequence numbers are randomised whenever the MAC address changes, including for each new scan while unassociated. This was introduced in iOS 16.1, iPadOS 16.1, macOS 13.1, tvOS 16.1, watchOS 9.1 and visionOS 1, on iPhone 7 and later, iPad (5th generation) and later, Macs from late 2018 and later, and other listed hardware.
• The scrambler seed, a value used in the physical layer, is changed for every probe request and discovery frame, when an interface starts or stops, on association, disassociation and roaming, and at random intervals.
• Dialog token fields in information elements take a new random value in each transaction, across client, access point and peer to peer interfaces.

Apple also tells organisations that might need a fixed address to update their network security or use an MDM profile to turn the feature off for enrolled devices, rather than asking users to disable it.

Android

The Android Open Source Project documentation gives a clear version history. Starting in Android 8.0, devices use randomised addresses when probing for new networks while not associated with one. In Android 9 a developer option, off by default, allowed a random address when connecting. From Android 10, randomisation is on by default for client mode, the hotspot (SoftAp) and Wi-Fi Direct, and addresses are also randomised for Wi-Fi Aware and Wi-Fi RTT operations.

Android uses two types of randomisation for connections:

• Persistent randomisation, the default. Android derives the address from the network profile's parameters, including SSID, security type, or FQDN for Passpoint networks. It stays the same until a factory reset, and forgetting and re-adding the network does not change it. The documentation says this keeps features working that rely on a stable address, such as skipping a login page or parental controls. For Android 10 and 11 all networks with randomisation enabled use this type.
• Non-persistent randomisation, from Android 12, used when a network suggestion app asks for it through WifiNetworkSuggestion.Builder#setMacRandomizationSetting, or for an open network that has not shown a captive portal when the device maker has set the config_wifiAllowEnhancedMacRandomizationOnOpenSsids overlay to true. That overlay is false by default. With non-persistent randomisation the address is re-randomised at the start of a connection if the DHCP lease has expired and more than four hours have passed since the device last disconnected, or if the current address is more than 24 hours old. It never disconnects just to change address.

Users can turn randomisation on or off per network in the network details screen, but cannot choose the type there. From Android 11, a developer option called "Wi-Fi non-persistent MAC randomization" applies non-persistent randomisation to every network that has randomisation on. Device makers implement the feature with chip vendor HAL methods, and the documentation warns that devices upgraded from Android 9 or earlier might not support it.

Windows

Microsoft's support article explains the reason in one line: shopping malls, stores and other public areas "might use this unique address to track your movement". If the Wi-Fi hardware supports it, Windows offers two controls under Settings, Network and internet, Wi-Fi:

• Random hardware addresses for all networks, which uses random addresses both while the PC scans and when it connects to any network.
• Random hardware addresses for a specific network under Manage known networks, which takes effect the next time you connect to that network.

The article does not describe rotation intervals, and the key condition is the first one: the feature depends on the Wi-Fi hardware and driver supporting it.

Linux with NetworkManager

On most Linux desktops NetworkManager controls Wi-Fi, and its documentation separates scanning from connections.

For scanning, the NetworkManager.conf option wifi.scan-rand-mac-address "defaults to yes", in which case a random, locally administered address is used. A companion option, wifi.scan-generate-mac-address-mask, can keep certain bits, for example a vendor OUI.

For connections, the per-connection setting 802-11-wireless.cloned-mac-address (shown as assigned-mac-address on D-Bus) accepts an explicit address or a special value. The nmcli settings reference defines them: preserve means not to touch the address on activation, permanent uses the hardware address, random "creates a random MAC address on each connect", stable creates a hashed address from the connection's stable ID and a machine dependent key, and stable-ssid hashes the address from the SSID. If no global default is set in NetworkManager.conf, the value defaults to preserve, and the documentation notes that older versions may use a different default. The older mac-address-randomization property is deprecated in favour of cloned-mac-address. A generate-mac-address-mask property lets administrators keep some bits fixed; by default every bit is scrambled and a locally administered unicast address is produced.

The practical consequence, going by NetworkManager's documented defaults, is that a Linux laptop randomises its scans but keeps its existing (usually factory) address when connected, unless the distribution or the user sets stable, stable-ssid or random. Some distributions ship their own defaults, so check rather than assume.

Platform summary

Why randomisation is not enough

Randomising the source address removes the easiest identifier. It does not make probe requests anonymous, and the research record on this is unusually clear.

Information element fingerprints

In "Why MAC Address Randomization is not Enough" (ASIA CCS 2016), Mathy Vanhoef, Célestin Matte, Mathieu Cunche, Leonardo Cardoso and Frank Piessens showed that the information elements in probe requests can fingerprint devices. The set of elements a device includes, their order and their contents vary between models and software versions, and many devices send the same elements in every probe. Combined with other signals, the authors reported an algorithm that could correctly track as much as 50% of devices for at least 20 minutes in real world datasets, without relying on MAC addresses. Their conclusion, in the abstract, was that random MAC addresses "on its own, does not guarantee privacy".

The fingerprint is not unique the way a MAC address is, since phones of the same model and software send identical elements, but combined with timing and location it can link a stream of random addresses to one device during a visit.

Sequence numbers and scrambler seeds

The same paper combined fingerprints with incremental sequence numbers. If a device changes its address but its frame counter keeps counting from where it was, the next frame with a new address and the next sequence number is very probably the same device. The authors also showed that commodity devices used predictable scrambler seeds, a physical layer value, which helped tracking.

These are exactly the leaks Apple's Platform Security Guide now addresses by randomising sequence numbers on each address change, changing the scrambler seed for every probe request and randomising dialog tokens. Whether other devices do the same depends on the chipset and driver; their public documentation does not say, so treat it as unknown unless your vendor documents it.

SSID leakage

Directed probes for saved hidden networks reveal network names. A set of names can single out a person, and network names can appear in public wardriving databases with locations attached. The 2016 paper also described an active technique: an observer who imitates popular network names can induce some devices to try to connect, at which point older implementations used their real address. The authors reported that imitating only five network names revealed the real address of 17.4% of devices in their test. The mechanism, and the lesson, is that any automatic connection to a network a device believes it knows is a moment of exposure.

Active techniques that revealed real addresses

The researchers described two ways older systems revealed their real addresses: the fake hotspot approach above, and Hotspot 2.0 (802.11u) queries, where they found Linux and Windows sent Access Network Query Protocol requests using their real address.

Martin and colleagues at the US Naval Academy published what they described as the first wide scale study of randomisation in the wild in 2017. They found devices that sent frames with their true global address when they should have used a random one, extended the passive identification techniques of Vanhoef and colleagues to defeat randomisation in about 96% of Android phones in their data, and reported a method that elicited responses using low level control frames (Request to Send and Clear to Send) which they said could track 100% of devices using randomisation, regardless of manufacturer, by exploiting what they called a previously unknown flaw in how wireless chipsets handle those frames. This post does not describe the methods beyond that. The important point is that these were implementation flaws in specific devices and software of the time, and some of them are exactly what vendors such as Apple now document mitigations for, which is why keeping phones and laptops updated is part of Wi-Fi privacy.

Timing and signal strength

Even with perfect randomisation, a device's probing rhythm (how often it scans, how many probes per burst) can be distinctive, and signal strength from several sensors gives position. In a busy place these are weak identifiers; in a quiet one they may be enough to link two random addresses.

Identifiers above Wi-Fi

Once a device connects, higher layers can undo the work. RFC 9724 notes that some DHCP options carry unique identifiers that enable tracking even when MAC addresses are randomised, and RFC 9797 points to DHCP option 12, the host name, which is visible to the network. A phone named after its owner announces that name to every network it joins. RFC 9724 also summarises the IPv6 side: RFC 8064 stopped deriving IPv6 interface identifiers from MAC addresses, RFC 7217 produces stable identifiers that change between networks, and RFC 8981 temporary addresses rotate over hours to days. On top of that sit accounts, cookies and app identifiers, covered in our post on browser fingerprinting. A random MAC address does nothing about a login.

What each leak needs and what fixes it

What IEEE 802.11bh, 802.11bi and IETF MADINAS are doing

Where the standards started

The IEEE 802.11 task group page for 802.11bh records that IEEE Std 802.11aq formalised MAC privacy for 802.11 stations, including changing or randomising addresses. RFC 9724 adds that IEEE Std 802E-2020 recommends temporary and transient identifiers when there is no compelling reason for a new identifier to be permanent, and that IEEE 802c-2017 defined the local address plan described earlier. With randomisation shipping by default, two problems remained: networks that relied on fixed addresses broke, and randomisation alone did not stop the leaks above. The IEEE split the work along those lines.

IEEE 802.11bh: operation with randomised and changing MAC addresses

802.11bh is formally "Amendment 1: Operation with Randomized and Changing MAC Addresses". Its project authorisation was approved on 10 February 2021, the IEEE SA board approved it on 26 September 2024, and it was published on 3 June 2025. The IEEE abstract says it modifies 802.11 so that services that would otherwise break when stations use randomised or changing addresses keep working "without affecting the privacy of the users". It adds mechanisms for session continuity when there is no unique mapping from address to device, and preserves the ability to provide customer support, run diagnostics and detect device arrival in a trusted environment.

In practice this means a client and a network it trusts can agree on an identifier that lets the network recognise the client again, without that identifier being visible to passive observers. RFC 9797 adds an important constraint from 802.11bh: an address may not change during an association, only through a disconnection and reconnection. That keeps sessions stable but means each change costs a reauthentication.

IEEE 802.11bi: enhanced service with privacy protection

802.11bi is "Amendment 5: Enhanced Service with Privacy Protection". RFC 9724 describes the task group as chartered to define modifications to the 802.11 MAC "that address and improve user privacy". The IEEE standards page lists a project authorisation approval date of 10 December 2025 (the latest version of the authorisation), board approval on 25 September 2026 and publication on 23 October 2026, the day before this post was written. The public abstract is one sentence long, saying only that it modifies the 802.11 MAC to "enhance user privacy protection", and the full text is a paid standard, so we do not describe its specific mechanisms here. Expect support to arrive in chipsets, drivers and operating systems over the coming years, as it did for 802.11bh, and check vendor release notes rather than assuming any device supports it today.

IETF MADINAS

MADINAS (MAC Address Device Identification for Network and Application Services) looked at the same problem from the IP and services side. According to its closing note on the IETF datatracker, the BoF was held in October 2020 and the working group created in September 2021 with three planned deliverables. It dropped the planned Best Current Practice document and published two informational RFCs:

• RFC 9724, "State of Affairs for Randomized and Changing Media Access Control (MAC) Addresses" (March 2025). It summarises IEEE, Wireless Broadband Alliance and IETF work, including IPv6 address privacy and DHCP identifiers.
• RFC 9797, "Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases" (June 2025). It lists environments from homes to enterprises and public venues, the network services that break, and existing frameworks such as 802.1X with WPA2 or WPA3, OpenRoaming and vendor schemes.

The group has since concluded. Protocol work continues in IEEE 802.11 and, for public Wi-Fi authentication, in the Wireless Broadband Alliance and the IETF RADIUS work that RFC 9797 mentions.

Standards at a glance

What breaks when MACs are randomised, and how networks should adapt

RFC 9797 is the best single list of what breaks. Here are the common cases, with the fix that does not involve asking users to turn privacy off.

Captive portals

Hotel and café networks often remember that a device accepted the terms or paid, keyed by MAC address. A new address means a new login page. Android's documentation says persistent randomisation exists partly so a device can "bypass the login screen as expected", and Android only uses non-persistent randomisation on open networks that have not shown a captive portal. Apple's Rotating mode changes the address every two weeks on open networks. Operators should keep session lengths reasonable, expect returning devices to look new, and consider Passpoint or OpenRoaming style authentication, which RFC 9797 describes as a privacy preserving way to recognise subscribers.

DHCP reservations and address exhaustion

DHCP servers key leases to a client's address. RFC 9797 warns that when a device changes address without releasing its lease, the server keeps the old lease and the pool can run out, a risk it says exists even when the address is released because the server cannot tell randomisation from a brief disconnection. Fixes: shorter lease times on guest networks, larger pools, and reservations by a stable identity (an 802.1X identity, a DHCP client identifier the device presents on purpose, or a fixed private address on that one network) rather than the hardware address.

Parental controls and home device rules

RFC 9797 notes that home policies such as parental controls and blocklists are often based on MAC addresses, and that randomisation "removes the possibility for such control". On a home network, a per-network persistent address (Android's default, Apple's Fixed, NetworkManager's stable) usually keeps such rules working. If a router rule stops working after a phone update, check whether the phone switched to a rotating address for that network.

Enterprise network access control and 802.1X

RFC 9797 explains that 802.1X authenticators use the MAC address to confirm the device is authorised and to find the keys for its traffic, and that a change closes the port until the AAA server confirms the new address. The recommendation in the RFC's appendix and in Apple's guidance is the same: authenticate users and devices with credentials (802.1X with WPA2 or WPA3 Enterprise and certificates) and manage corporate devices with profiles, rather than trusting MAC allow lists, which were never strong authentication anyway because addresses can be changed in software, as the ICO noted in 2016.

Support, troubleshooting and analytics

Help desks can no longer look up a device by an old address; RFC 9797 notes real time support needs the user to read out the current one, and 802.11bh mechanisms target this case. For analytics, the ICO's 2016 advice still applies: count, do not follow; rotate salts; aggregate quickly; delete the rest.

Adaptation summary

Comparison: four ways a device can behave

This is the decision table for a user choosing settings, or an administrator choosing defaults.

Two notes. First, passive-only scanning is not a switch most phone operating systems expose to users; it is how a device behaves when it is not actively looking, and the closest a user gets is turning Wi-Fi off. Second, "low" never means zero, because of the fingerprinting and higher layer issues above. The sensible default for most people is the one Apple and Android ship: a fixed private address for trusted encrypted networks, a changing one for open networks, and scan randomisation always on.

Step by step: check what your own devices reveal

These steps check and reduce what your own phone and laptop broadcast. The final step captures probe requests in a lab, and it is written so you only look at frames from your own device.

Step 1: check private address settings

iPhone or iPad (iOS 18 or later). Settings, Wi-Fi, tap the info button next to a network, then Private Wi-Fi Address. Choose Fixed for your home and work networks, Rotating for public open networks. The address shown there is the one that network sees.

Mac (macOS Sequoia 15 or later). System Settings, Wi-Fi, Details next to the network, Private Wi-Fi Address. From Terminal you can see the address in use:

# Show the current address of the Wi-Fi interface (usually en0 on a Mac)
ifconfig en0 | grep ether

Android 10 or later. The AOSP documentation says the per-network option lives in the network details screen in Settings. Open Wi-Fi settings, tap the network and find the MAC randomization or privacy option; menu labels vary between device makers. Keep randomisation on. The same screen usually shows the address in use.

Windows. Settings, Network and internet, Wi-Fi, turn on Random hardware addresses. For one network, open Manage known networks, select it and set Random hardware addresses. Check the address in use from PowerShell:

# List adapters with their current MAC addresses
Get-NetAdapter | Select-Object Name, InterfaceDescription, MacAddress, Status

Linux with NetworkManager. Check whether scan randomisation has been turned off and what each connection uses:

# Scan randomisation: no output means the default (yes) applies
grep -rs "scan-rand-mac-address" /etc/NetworkManager/

# Per-connection address policy for a saved network called "Home"
nmcli -g 802-11-wireless.cloned-mac-address connection show "Home"

# Use a stable private address for this network, then reconnect
nmcli connection modify "Home" 802-11-wireless.cloned-mac-address stable
nmcli connection up "Home"

# Use a new random address on each connection for a public network
nmcli connection modify "Cafe" 802-11-wireless.cloned-mac-address random

To make stable the default for every new Wi-Fi connection, add a drop-in file such as /etc/NetworkManager/conf.d/30-mac-randomization.conf:

[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=preserve

Then restart NetworkManager with sudo systemctl restart NetworkManager. Expect a brief disconnect.

Whatever the platform, confirm the result: the second hexadecimal character of the address in use should be 2, 6, A or E.

Step 2: forget networks you no longer use

Every saved network is a reason for your device to probe, and an old open network is a candidate for automatic joining. Delete networks you will not join again.

# macOS: list saved networks for en0, then remove one (asks for your password)
networksetup -listpreferredwirelessnetworks en0
sudo networksetup -removepreferredwirelessnetwork en0 "Old Hotel WiFi"

# Linux: list saved Wi-Fi connections, then delete one
nmcli -f NAME,TYPE connection show | grep wifi
nmcli connection delete "Old Hotel WiFi"

# Windows: list saved profiles, then delete one
netsh wlan show profiles
netsh wlan delete profile name="Old Hotel WiFi"

On iPhone, iPad and Android, open the network's details and choose Forget. On Apple devices from iOS 18, remember the 24 hour rule: forgetting a network and rejoining it within 24 hours reuses the same private address.

Step 3: stop probing for hidden networks

If you run a hidden home network, unhide it. Hiding the name does not stop a determined observer from learning it, because it still travels in the frames exchanged whenever a client joins, and it makes every device you own call out the name everywhere you go. Rename it to something that does not identify you or your address, then unhide it on the router.

On Linux, check whether a saved connection is marked hidden:

nmcli -g 802-11-wireless.hidden connection show "Home"
# If it prints "yes" and the network is no longer hidden:
nmcli connection modify "Home" 802-11-wireless.hidden no

Step 4: set generic device names

Your device name often travels as the DHCP host name. Rename phones and laptops to something generic such as "phone" or "laptop-2" in each system's About or General settings. On Linux:

hostnamectl                       # show the current host name
sudo hostnamectl set-hostname laptop-2

Step 5: capture your own probe requests in a lab

This step is for learning what your own device transmits. Read these rules before starting.

Only capture your own devices, on your own premises. Recording other people's Wi-Fi frames can be unlawful interception or unlawful processing of personal data in many countries, and the ICO's guidance treats device identifiers as potentially personal data. Do this at home or in a lab, keep the capture short, display only frames from your own device and do not save captures. Do not do this in shops, offices, public places or anywhere others' devices are in range. Use a spare USB Wi-Fi adapter that supports monitor mode, not your main connection.

The trick that makes this self-contained is a test network name that only your phone knows. When your phone has saved a hidden network, it probes for that exact name, so you can filter for it and see nothing else.

1. On your phone, add a network manually with a made-up name such as probe-lab-7f3k, mark it hidden and use any WPA2 password. The network does not need to exist.
2. On a Linux machine with the lab adapter plugged in, find its PHY and interface name. The kernel wireless documentation uses iw for this.

# Identify the lab adapter. Check the output carefully and use the
# PHY that belongs to the USB adapter, not your main Wi-Fi card.
iw dev
iw phy | grep -E "^Wiphy|monitor"

3. Add a monitor interface on the lab adapter's PHY. The command form comes from the kernel documentation. Replace phy1 with the PHY you identified.

sudo iw phy phy1 interface add mon0 type monitor
sudo ip link set mon0 up
sudo iw dev mon0 set channel 6

4. Watch only the probe requests that name your test network, for 60 seconds, printed to the screen with nothing saved to disk. The capture filter limits collection to probe request frames; the display filter shows only the ones naming your made-up SSID, so other devices' frames are never displayed or stored.

sudo tshark -i mon0 -a duration:60 \
  -f "type mgt subtype probe-req" \
  -Y 'wlan.ssid == "probe-lab-7f3k"' \
  -T fields -e frame.time_relative -e wlan.sa -e wlan.seq \
  -e radiotap.dbm_antsignal -e wlan.ssid

While it runs, turn the phone's Wi-Fi off and on and open the Wi-Fi settings screen to prompt a scan. Probes go out on each channel in turn, so you may need to repeat on channels 1 and 11, or 36 for 5 GHz.

5. To see every information element in one of your probes, run the same filter once more and print the first matching frame in full:

sudo tshark -i mon0 -a duration:60 -c 1 \
  -f "type mgt subtype probe-req" \
  -Y 'wlan.ssid == "probe-lab-7f3k"' -V

If your tshark version refuses a display filter during live capture, run it in a place where your phone is the only device in range, such as a room with no other Wi-Fi devices switched on, rather than dropping the filter in a shared space.

What to look for:

• The source address. Is the second character 2, 6, A or E? Does it change when you toggle Wi-Fi?
• The SSID. Your phone is broadcasting the name of a network it is not near. That is the hidden network leak in one line.
• Sequence numbers. Do they continue across an address change, or jump to a new random value?
• Information elements. Count them and note the capability elements and any vendor specific ones. Compare two of your own phones, or one phone before and after an update.

6. Clean up: remove the test network from the phone and remove the monitor interface.

sudo iw dev mon0 del

Step 6: compare settings

Repeat step 5 with the test network's private address setting at Off, then Fixed or persistent, then Rotating or non-persistent, toggling Wi-Fi each time, and note which values change.

Common mistakes

• Turning off private addresses to fix a captive portal. It fixes one login screen and exposes a permanent identifier everywhere. Choose Fixed or persistent for that network instead, or just log in again.
• Hiding your home network name for security. It adds little protection and makes your devices advertise the name everywhere. Use WPA3 or WPA2 with a strong password and leave the name visible. The Wi-Fi Alliance notes that WPA3 is mandatory for Wi-Fi CERTIFIED devices and that WPA3-Personal adds protection against password guessing.
• Assuming hashing anonymises MAC addresses. The FTC said in 2015 that a hashed address is still a unique, trackable identifier. Salt and rotate, as the ICO suggested, or count without storing identifiers.
• Relying on MAC allow lists for security. Addresses can be changed in software. Use 802.1X with certificates or per-device credentials.
• Treating a random MAC as invisibility. Information elements, timing, DHCP host names and accounts still identify you.
• Forgetting the laptop. Phones randomise by default; a Linux laptop may connect with its factory address unless you set stable or random.
• Keeping years of saved networks. Each one is a probe or auto join opportunity. Forget networks you do not use.
• Running a capture where others are in range. Even with good intentions, recording other people's frames creates personal data you then have to justify and protect. Filter to your own test SSID and do not save the capture.
• Expecting 802.11bi support from a firmware update this month. It was only approved in September 2026. Check vendor documentation before relying on it.

FAQ

Can stores track my phone if I do not connect to their Wi-Fi?

They can detect it. A phone with Wi-Fi switched on sends probe requests that sensors can hear without any connection, as both the FTC and ICO documents describe. Modern phones use random addresses for those probes, which makes long term tracking from the address much harder, but sensors can still count devices and may link frames within a visit using other fields.

Does turning off Wi-Fi stop probe requests?

Turning Wi-Fi off stops your device joining networks. Scanning can also serve other purposes, such as location: Apple notes that its scans can assist Location Services. How a given phone behaves when Wi-Fi is toggled from a quick settings panel varies, so check its location and scanning settings too. Where scanning happens while unassociated, current systems use a random address for it.

Should I use Fixed or Rotating on my iPhone?

Apple's defaults are a good guide: Fixed for networks with WPA2 or stronger security that you trust, Rotating for open or weak networks. Rotating changes the address every two weeks, which may mean logging in to captive portals again.

How do I tell if a MAC address is randomised?

Look at the second hexadecimal character. If it is 2, 6, A or E, the locally administered bit is set and the address is almost certainly not the factory one, which matches the check Android's documentation tells testers to perform.

Why does my router show my phone as a new device?

Because it is using a different private address, perhaps after a rotation, after you forgot and rejoined the network, or after a reset. Apple notes that routers configured to alert on new devices will alert when a device first joins with a private address.

Is Wi-Fi tracking legal?

It depends on the country and the purpose. In the US the FTC acted in 2015 over a broken privacy promise. In the UK the ICO's 2016 guidance said identifiers collected this way can be personal data, requiring notices, minimisation and retention limits. Anyone planning analytics should take local legal advice.

What is IEEE 802.11bh?

An amendment to the Wi-Fi standard, published on 3 June 2025, that helps networks keep services such as session continuity, support and diagnostics working when clients use randomised or changing addresses, without giving passive observers a stable identifier.

What is the IETF MADINAS working group?

An IETF group, created in September 2021 and now concluded, that documented how randomised MAC addresses affect network services. It published RFC 9724 in March 2025 and RFC 9797 in June 2025.

Does a VPN stop Wi-Fi tracking?

No. A VPN encrypts traffic after you connect. Probe requests, MAC addresses and DHCP happen below and before the VPN, so it does not change what Wi-Fi sensors see.

Where Safeguard fits

Safeguard does not control Wi-Fi settings, randomise addresses, detect sensors, scan firmware or manage devices, and nothing in the advice above depends on it. The fit is indirect. The software that implements this behaviour, Wi-Fi supplicants and network managers on Linux, router firmware, captive portal and guest Wi-Fi platforms, and the analytics backends that receive sensor data, is built from open source components like any other software. If your team builds or ships that software, for example a captive portal service, a venue analytics pipeline or a Linux based appliance image, Safeguard can scan its repositories, container images and SBOM files, build an inventory of the components inside, and match them against vulnerability databases, so you know which projects carry a vulnerable library when an advisory lands. It cannot see inside closed vendor firmware on an access point, so that part of the inventory still has to come from the vendor.

Fix it without waiting for upstream

Wi-Fi privacy lives in operating systems and drivers, but the services around it, captive portals, guest Wi-Fi platforms and analytics pipelines, are built on open source dependencies that need patching like any other software. That fit is indirect, and the fork and patch route described below is early access.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a lodash CVE in a repository, reads the finding and advisory, asks before each command, edits package.json to a fixed version and runs npm install and npm test with approval, pushing nothing. The same flow applies if a scan of your captive portal or guest Wi-Fi web app shows an outdated library: you ask for the upgrade and approve each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. It suits a team building a venue analytics pipeline or an appliance image that wants a component inventory before a privacy review, without sending source anywhere first.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It helps when you want to ask an assistant which of your projects carry a particular library version while you review the software behind your guest network.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Apple Support: Use private Wi-Fi addresses on Apple devices
• Apple Platform Security: Privacy features when connecting to wireless networks (published 19 December 2024)
• Android Open Source Project: Implement MAC randomization
• Android Open Source Project: MAC randomization behavior
• Microsoft Support: Random hardware addresses in Windows
• NetworkManager: 802-11-wireless settings
• NetworkManager: NetworkManager.conf
• NetworkManager: nm-settings-nmcli
• Linux wireless documentation: iw
• IEEE SA: IEEE 802.11bh-2025, Operation with Randomized and Changing MAC Addresses
• IEEE SA: IEEE 802.11bi, Enhanced Service with Privacy Protection
• IEEE 802.11 Task Group BH (RCM) status page
• IETF Datatracker: MADINAS working group (concluded)
• RFC 9724: State of Affairs for Randomized and Changing MAC Addresses (March 2025)
• RFC 9797: Randomized and Changing MAC Addresses: Context, Network Impacts, and Use Cases (June 2025)
• US FTC: Retail Tracking Firm Settles FTC Charges it Misled Consumers About Opt Out Choices (23 April 2015, archived copy)
• UK ICO: Wi-Fi location analytics, version 1.0, 16 February 2016 (archived copy)
• Vanhoef, Matte, Cunche, Cardoso, Piessens: Why MAC Address Randomization is not Enough (ASIA CCS 2016)
• Martin et al.: A Study of MAC Address Randomization in Mobile Devices and When it Fails (arXiv, 2017)
• Wi-Fi Alliance: Security

Related reading: network cards from Ethernet to 800G, MAC randomisation and SmartNICs, Wi-Fi generations from 802.11b to Wi-Fi 7 and Wi-Fi 8, what wardriving is and how to protect your Wi-Fi, browser fingerprinting explained and GPS and GNSS evolution and location privacy.

Last reviewed: 24 October 2026. Operating system defaults and standards status change; check the vendor and standards pages linked above for the version you run.