The MAC address is probably the least understood piece of the offline tracking puzzle. Most users know a website can set a cookie. They know an ad network can follow them across sites. But few know their phone keeps broadcasting a unique tag to every Wi-Fi setup in range. It does this even when Wi-Fi is not joined to any network. Shops, airports, hotel chains, transit operators, and some cities rolled out this offline tracking at scale between 2015 and 2022. Things have got better since native MAC randomisation came to iOS and Android. But the topic stays poorly grasped and the protections are partial.
This guide explains what a MAC address is and how it is used to track you. It covers what native randomisation closes and does not close. It shows how to manually spoof per OS if you want to go further. And it lays out the built-in limits (other fingerprints). Those limits mean MAC spoofing alone does not equal anonymity on public Wi-Fi.
What a MAC address is, and why it can be tracked
Every network interface has a unique MAC address. That covers the Wi-Fi chip in your phone, the Ethernet card in your PC, the Bluetooth chip, and even some external USB Wi-Fi dongles. Standard format: 48 bits, written in hex split by colons, for example D4:3B:04:9F:1A:2E. The Wi-Fi chipset maker assigns this address at the factory (Broadcom, Qualcomm, Intel, MediaTek). It is meant to be globally unique, so any device can be spotted clearly on any network.
Structure of the address - why it reveals the maker. The first 24 bits (first 3 bytes) form the OUI (Organizationally Unique Identifier). The IEEE assigns this to each maker. Apple has several OUIs (D4:9A:20, A4:5E:60, etc.), Samsung has around a hundred, Intel likewise. The last 24 bits identify the single interface within the maker's allocation. So a MAC 04:DB:56:xx:xx:xx reveals an Apple device, and 48:5D:36:xx:xx:xx reveals a Samsung. OUI databases are public. The IEEE publishes the official list, and sites like Wireshark OUI lookup search it online. This map lets Wi-Fi operators profile the people in range: '60% iPhones, 30% Samsung, 10% other'.
Broadcast in plaintext, continuously. The MAC address is broadcast in every Wi-Fi frame sent. There is a subtler case too. When your phone is not connected to any network but Wi-Fi is on, it regularly emits probe requests. These are broadcast packets asking 'Is HomeWifi around? Is OfficeWifi here?'. The requests contain your real MAC (unless randomised) and the SSIDs you have saved. A Wi-Fi setup in range - airport access point, shopping centre antenna, urban sensor - can therefore identify you without you connecting to anything. It just needs to be within radio range. This is documented in RFC 7042, which formalises MAC allocation and privacy considerations.
Stable over time. Without randomisation, your MAC never changes. It is the same identifier over five years, across dozens of different networks, across thousands of interactions. Some actors hold logs from many Wi-Fi setups (a retail chain, an urban sensor operator, an airport access point provider). They can rebuild your movement history with impressive precision. This is exactly what iOS 14+ and Android 10+ close with per-SSID randomisation.
How public Wi-Fi and retailers use your MAC to track you
MAC tracking is an industry in its own right. It was deployed at massive scale between 2014 and 2020, then partly disrupted by OS randomisation. Here is an overview of documented uses.
In-store Wi-Fi analytics (offline analytics). Several companies (Euclid Analytics, RetailNext, Cisco Meraki with its CMX module, Cloud4Wi) sell retailers a solution that measures footfall, dwell time, and repeat visits. They use the MACs of smartphones in range. The principle is simple. Wi-Fi access points capture probe requests in the background, log the MACs seen, and work out presence duration and return frequency. The customer does not need to join the store's Wi-Fi. Just having Wi-Fi on a nearby phone is enough. Data is sold in aggregate form to retailers: 'how many visitors today, X% new, average dwell time Y minutes'. On non-randomised MACs (pre-2020), precision was near-individual.
Flow optimisation at airports and stations. UK airports (Heathrow, Gatwick) and rail operators have used Wi-Fi counting solutions since around 2015. They measure queue times at security, terminal flows, and bottlenecks. The goal is legitimate (improving passenger experience). The method is intrusive if not anonymised. The ICO has issued guidance on the topic. It requires aggregation and non-retention of individual MACs, but compliance has been uneven.
Hotel chains and longitudinal profiling. Managed Wi-Fi solutions (Cisco Meraki, Aruba, Ruckus) include a module by default. It logs the MACs of guests connected across all properties in a chain. So a guest who stays at two different Marriott properties in six months is cross-referenced via their MAC. A stay profile is then rebuilt (durations, room types, services used). Data is sold to third-party marketing providers or used internally for personalisation. On per-SSID randomised MAC (iOS 14+/Android 10+), the link is broken. You present a different MAC on each SSID (potentially different per property).
Urban sensors. Several cities have deployed Wi-Fi sensors in street furniture to measure pedestrian flows. London did so as early as 2013 with Renew Plc's Wi-Fi bins - a media scandal that shut the programme down. Various Asian and European cities have followed since. The industry defends the use for urban planning (measuring where people walk). Privacy advocates contest it on proportionality grounds. In the UK, the ICO has confirmed that such devices fall under UK GDPR and that immediate MAC aggregation is mandatory.
Captive portals with email collection. Beyond passive tracking, many public Wi-Fi networks ask for an email address or phone number in exchange for access. That data is then cross-referenced with your MAC at connection time. This lets the operator turn an anonymous technical identifier (MAC) into a personal identifier tied to an email. Most fast-food chains, many hotels, and some airports use this model.
Native MAC randomisation - iOS 14+, Android 10+, Windows 10+
Pressure from privacy advocates and new regulation pushed OS makers to build in a native fix. The drivers were GDPR in 2018 in Europe and rising ICO enforcement in the UK. Here is the state of deployment in 2026.
iOS 14+ (September 2020). Apple turned on the 'Private Wi-Fi Address' feature by default on iOS 14, then extended it to iPadOS and watchOS. The principle is simple. For each SSID the device connects to, iOS generates a distinct MAC, and it stays the same for that SSID. So at home you present 02:AB:CD:11:22:33; at the coffee shop, 02:EF:01:55:66:77; at the airport, yet another. An operator who only has one setup can no longer link your visits across their different locations. iOS 16 (2022) added automatic 24h rotation on some networks. This also breaks the link between visits to the same SSID. Settings: Wi-Fi → network info (i) → Private Wi-Fi Address → On.
Android 10+ (September 2019). Google turned on per-SSID MAC randomisation by default on Android 10, with a distinct MAC per SSID. The implementation varies by device maker. Samsung, Pixel, Xiaomi, and OnePlus generally follow the spec. Some entry-level makers had early bugs. Settings: Wi-Fi → current network → Details → Randomised MAC / Phone MAC (depending on ROM). Android 12+ offers a clear periodic rotation option.
Windows 10 build 1703+ and Windows 11. Microsoft added optional MAC randomisation from 2017 onwards. Activation: Settings → Network & Internet → Wi-Fi → Random hardware addresses → On. It is off by default on Windows 10, so you must turn it on by hand. On Windows 11, the option is more often on by default, depending on the build. Important: randomisation can be set per SSID (On for this network / Off / Change daily).
Known limits of native randomisation. First, the MAC stays constant per SSID unless explicit rotation is set. So your second visit to the same coffee shop can still be linked to your first (unless Apple 24h or Windows 'change daily' is active). Second, probe requests can leak on some older or buggy OS versions. Researchers showed in 2020–2022 that certain models kept emitting the real MAC in the background in specific edge cases. Third, other fingerprints can identify the device beyond the MAC. These include Wi-Fi Information Elements, probe timing, and the manufacturer model visible via OUI. To go further, turning Wi-Fi off when not in use remains the simplest step - no probe emitted, no tracking possible.
Manual spoofing - how to change your MAC per OS
If native randomisation is not enough (old OS version, specific need, deliberate OPSEC), here are the commands per OS. Note: on a recent, up-to-date device, native randomisation is usually easier and enough.
macOS - temporary until reboot.
sudo ifconfig en0 ether 02:11:22:33:44:55
en0 is usually the Wi-Fi interface (verify with networksetup -listallhardwareports). Important: disconnect Wi-Fi before changing (Wi-Fi → Turn Off), run the command, then reconnect. The 02: prefix marks a 'locally administered' address (U/L bit set to 1). This is a convention recommended by RFC 7042 to avoid collisions with manufacturer-assigned MACs.
Linux - with macchanger (standard package).
sudo ip link set dev wlan0 down
sudo macchanger -r wlan0 # -r for random; -m XX:XX:XX:XX:XX:XX for a specific value
sudo ip link set dev wlan0 up
On Ubuntu/Debian: sudo apt install macchanger. To make the change persistent, create a systemd script that runs at boot. On NetworkManager (modern Ubuntu desktop), you can set per-connection randomisation graphically.
Windows 10/11 - via settings or third-party tools. For native randomisation: Settings → Network → Wi-Fi → properties → Random hardware addresses → On. For precise spoofing (a chosen address), use a third-party tool like Technitium MAC Address Changer (free, open source) or a registry edit. Note: some Windows Wi-Fi drivers reject MACs where the first byte is odd (multicast bit set to 1). Prefer an even first byte (02, 06, 0A, 0E, …).
Android - native randomisation or root. Without root, you are limited to the native per-SSID randomisation described above. With root and ADB: adb shell ip link set wlan0 address 02:11:22:33:44:55 (manufacturer-specific commands, may differ). Several Play Store apps claim to change the MAC without root. Most only change the displayed value, not the MAC actually broadcast.
iOS - no manual spoofing without jailbreak. The 'Private Wi-Fi Address' feature is the only supported option. Apple has limited this on purpose for security and simplicity.
Verification. Once the MAC is changed, confirm it is actually broadcast. Sniff your own traffic from another device (Wireshark in monitor mode). Or check the router admin interface (DHCP table) - the displayed MAC should match the one you set.
Complete MAC spoofing with a VPN - encrypted IP layer
Deloitte no-log audit 2024 · System kill switch · 30-day money-back guarantee
Spoofing limits: other fingerprints that persist
This is the most important point to understand. Spoofing your MAC closes one door, but not all of them. A determined actor can identify you through other signals. Three residual layers are worth knowing.
Wi-Fi Information Elements (IE) - model fingerprint. Wi-Fi probe requests carry more than the requested SSID and the MAC. They also carry Information Elements that describe the device's capabilities: supported 802.11 version, speeds, features, QoS options. The mix of these IEs forms a telltale fingerprint of the smartphone model. A Pixel 7 has a distinct IE profile from an iPhone 14, a Samsung S22, or a OnePlus 10. Researchers (Vanhoef et al., PoPETs 2016) showed that an IE fingerprint alone identifies the model in most cases. Spoofing the MAC does not change IEs. The countermeasure would be to change the device's Wi-Fi stack - basically impossible without changing the kernel.
IMSI catchers and cellular identifiers. On mobile networks (4G/5G), the MAC equivalent is the IMSI (International Mobile Subscriber Identity). It is tied to your SIM card. A rogue IMSI catcher (Stingray, devices used by law enforcement in multiple countries) captures the IMSI when your phone registers on a cell tower. 5G added IMSI encryption at registration time. But many towers remain on 4G or are subject to downgrade attacks. MAC spoofing has zero effect on this vector. It is a separate identifier.
Application behaviour and timing. Beyond technical identifiers, your device's behaviour makes it identifiable. Installed apps make telltale connections (Apple iCloud services on iOS, Google Play services on Android). Connection timing follows your daily routine (morning/lunch/evening). Traffic volumes signal your usage patterns. An actor with several signals (MAC + visited IPs + schedule + IEs) can re-identify you even across session-randomised MACs. Countermeasure: compartmentalise (a dedicated device for sensitive activities).
Captive portals and application identifiers. Say you connect to the coffee shop's Wi-Fi and receive an auth email or SMS. Your email or phone number is then linked to your MAC in the provider's database, whether or not it was spoofed. To break this link, either don't authenticate (decline Wi-Fi that requires email) or use a disposable alias email.
Cookies and browser identifiers. MAC spoofing does not affect application-layer tracking at all. A DoubleClick third-party cookie follows you whatever your MAC. The countermeasure is a hardened browser, tracker blocking, and removing iOS/Android ad IDs - not network-level spoofing.
Legal considerations in the UK and US
MAC spoofing is legally unremarkable in the UK and US for personal use. A few important clarifications follow.
On your own hardware - fully legal. Changing the MAC of your own Wi-Fi or Ethernet card is a standard technical operation. OS makers document it (Microsoft, Apple, Google all provide native functionality). No part of UK or US law specifically criminalises MAC spoofing. It has the same legal status as changing your browser User-Agent or using a proxy. It is a technical tool with no special legal label.
To impersonate a specific third party's MAC - criminal. This means setting your MAC to match that of an identified person (colleague, neighbour, targeted victim). Doing so to bypass a Wi-Fi access control (a company that filters by MAC), to pose as that person, or to hide your identity in an unlawful activity is different. It falls under the Computer Misuse Act 1990 in the UK (up to 10 years on aggravated charges) and the Computer Fraud and Abuse Act in the US. In Australia, similar provisions exist under the Criminal Code Act. The line is not the spoofing itself but the intent - impersonating someone else.
In a corporate context - check the policy. Many internal IT policies ban or discourage spoofing on company hardware. The reasons are IT traceability or avoiding disruption to NAC (Network Access Control) solutions. The sanction is disciplinary, not criminal - a warning, formal reprimand, or termination depending on severity. On your personal device used under BYOD, you have more latitude, but the policy may still impose rules.
To bypass an access control - grey area. Classic case: a public Wi-Fi offers 1 free hour per MAC, and you change your MAC to get a second free hour. Strictly speaking this gets around a technical access measure. But in practice it is not prosecutable for an incidental, low-stakes personal use. The operator can technically ban you, and the establishment can refuse you service. It is legally negligible in practice, but worth avoiding as a matter of form.
Special case - wardriving and third-party sniffing. This means capturing other users' MACs in range for analysis (research, journalism, audit). It is technically lawful if limited to passive observation of plaintext radio signals. But the UK GDPR applies. MACs count as personal data (CJEU 2016 Breyer judgment, confirmed by the ICO). So large-scale collection needs a legal basis and a documented purpose. For private educational use on your own hardware, there is no issue.
Summary: the real value of MAC spoofing in 2026
MAC spoofing remains a useful but marginal protection layer in 2026. Three points sum up the practical situation.
Native iOS/Android randomisation covers 95% of use cases. On an up-to-date device (iPhone iOS 14+, Android 10+), per-SSID randomised MAC already blocks cross-location tracking by retail chains and Wi-Fi operators. It is the highest-impact measure at zero effort. Check the feature is on by default on your usual Wi-Fi networks. It usually is, but it is worth confirming.
Manual spoofing serves specific cases. Think penetration testing on your own network, security research, advanced OPSEC for high-risk profiles, or bypassing a reasonable access control on your own hardware. For typical mainstream use, the gain over native randomisation is marginal.
The priority remains the VPN and application hygiene. On public Wi-Fi, MAC spoofing closes none of the main leaks (SNI, DNS, destination IP, browser fingerprint). A VPN with kill switch remains the structural measure. It encrypts all outbound traffic, whatever the MAC identifier seen locally. A hardened browser (Brave, Firefox resistFingerprinting, uBlock) closes the application layer. Without these two parts, spoofing your MAC is like locking the front door while the window is open.
Going further
MAC spoofing is the most visible piece of offline tracking, but far from the only one. To truly control what Wi-Fi infrastructure sees of you, you need to combine several steps: native MAC randomisation on, Wi-Fi off when not in use, VPN with kill switch on all public hotspots, and a hardened browser for web browsing. Other signals (Wi-Fi IEs, application behaviour, cellular identifiers) stay beyond ordinary user control. Their impact is residual for most people, structural for high-stakes profiles. To check that your VPN setup actually works and that no leak undercuts the expected protection, follow our complete VPN audit in 9 tests on a quarterly basis.
See also. Related: WPA2 vs WPA3.
Privacy and network security - related guides
Article published on 29 May 2026. Methodology: synthesis of the IEEE 802 specification (MAC allocation, EUI-48 format), IETF RFCs (RFC 7042 on allocation and privacy considerations), academic publications on Wi-Fi fingerprinting (Vanhoef et al. PoPETs 2016, multiple USENIX and NDSS papers on randomisation), ICO guidance on Wi-Fi tracking (2018, 2021), and official documentation from Apple (Private Wi-Fi Address), Google (Android Compatibility Definition), and Microsoft (Wi-Fi randomisation Windows 10).
Secure your connection with NordVPN
Threat Protection blocks trackers & malware · kill switch · 30-day money-back

