MAC spoofing on public Wi-Fi: what it actually changes for your privacy

The MAC address is probably the least understood piece of the offline tracking puzzle. Most users know a website can set a cookie, that an ad network can follow them across sites, but few realise their phone is constantly broadcasting a unique identifier to every Wi-Fi infrastructure in range — even when Wi-Fi is not connected to any network. Shopping centres, airports, hotel chains, public transport operators, and some cities deployed this offline tracking at scale between 2015 and 2022. The situation has improved since native MAC randomisation arrived on iOS and Android, but the topic remains poorly understood and the protections are partial.

This guide explains precisely what a MAC address is, how it is used to track you, what native randomisation closes and does not close, how to manually spoof per OS if you want to go further, and the structural limits (other fingerprints) that 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 — the Wi-Fi chip in your phone, the Ethernet card in your PC, the Bluetooth chip, even some external USB Wi-Fi dongles — is identified by a unique MAC address. Standard format: 48 bits, expressed in hexadecimal separated by colons, for example D4:3B:04:9F:1A:2E. This address is assigned at manufacture by the Wi-Fi chipset maker (Broadcom, Qualcomm, Intel, MediaTek), and is intended to be globally unique so any device can be identified unambiguously on any network.

Structure of the address — why it reveals the manufacturer. The first 24 bits (first 3 bytes) form the OUI (Organizationally Unique Identifier), assigned by the IEEE to each manufacturer. Apple has several OUIs (D4:9A:20, A4:5E:60, etc.), Samsung has around a hundred, Intel likewise. The last 24 bits identify the individual interface within the manufacturer's allocation. Consequence: observing a MAC 04:DB:56:xx:xx:xx reveals an Apple device; 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 mapping lets Wi-Fi operators profile the population in range: '60% iPhones, 30% Samsung, 10% other'.

Broadcast in plaintext, continuously. The MAC address is broadcast in every Wi-Fi frame sent. More subtly: when your phone is not connected to any network but Wi-Fi is on, it regularly emits probe requests — broadcast packets asking 'Is HomeWifi around? Is OfficeWifi here?'. These requests contain your real MAC (unless randomised) and the SSIDs you have saved. A Wi-Fi infrastructure in range — airport access point, shopping centre antenna, urban sensor — can therefore identify you without you connecting to anything, simply by being 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. An actor with access to logs from multiple Wi-Fi infrastructures (a retail chain, an urban sensor operator, an airport access point provider) can reconstruct your movement history with impressive precision. This is precisely 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, deployed at massive scale between 2014 and 2020, then partially 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) offer retailers a solution that measures footfall, dwell time, and repeat visits via the MACs of smartphones in range. The principle: Wi-Fi access points capture probe requests in the background, log observed MACs, and calculate presence duration and return frequency. The customer does not need to connect to the store's Wi-Fi — simply having Wi-Fi enabled 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 to measure queue times at security, terminal flows, and bottlenecks. The objective is legitimate (improving passenger experience); the method is intrusive if not anonymised. The ICO has issued guidance on the topic, requiring aggregation and non-retention of individual MACs — compliance has been uneven.

Hotel chains and longitudinal profiling. Managed Wi-Fi solutions (Cisco Meraki, Aruba, Ruckus) include by default a module that logs the MACs of guests connected across all properties in a chain. Consequence: a guest who stays at two different Marriott properties in six months is cross-referenced via their MAC, and a stay profile is reconstructed (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 correlation is broken — you present a different MAC on each SSID (potentially different per property).

Urban sensors. Several cities (London as early as 2013 with Renew Plc's Wi-Fi bins — media scandal, programme shut down; plus various Asian and European cities since) have deployed Wi-Fi sensors in street furniture to measure pedestrian flows. 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 are subject to 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 — data that is then cross-referenced with your MAC at connection time, allowing the operator to 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 the arrival of regulation (GDPR in 2018 in Europe, increasing ICO enforcement in the UK) pushed OS makers to integrate a native mitigation. State of deployment in 2026.

iOS 14+ (September 2020). Apple introduced the 'Private Wi-Fi Address' feature by default on iOS 14, extended to iPadOS and watchOS. The principle: for each SSID the device connects to, iOS generates a distinct MAC, persistent for that SSID. Consequence: 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 access to one infrastructure can no longer cross-reference your visits across their different locations. iOS 16 (2022) added automatic 24h rotation on some networks, which also breaks correlation between visits to the same SSID. Settings: Wi-Fi → network info (i) → Private Wi-Fi Address → On.

Android 10+ (September 2019). Google introduced per-SSID MAC randomisation by default on Android 10, with a distinct MAC per SSID. Implementation varies by device manufacturer — Samsung, Pixel, Xiaomi, and OnePlus generally comply with the spec; some entry-level manufacturers had initial bugs. Settings: Wi-Fi → current network → Details → Randomised MAC / Phone MAC (depending on ROM). Android 12+ offers an explicit 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. Disabled by default on Windows 10, it must be enabled manually. On Windows 11, the option is more often enabled by default depending on the build. Important: randomisation can be configured 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 correlated with 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 continued emitting the real MAC in the background in specific edge cases. Third, other fingerprints (Wi-Fi Information Elements, probe timing, manufacturer model visible via OUI) can identify the device beyond the MAC. To push protection further, turning Wi-Fi off when not in use remains the simplest measure — 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 generally more practical and sufficient.

macOS — temporary until reboot.

sudo ifconfig en0 ether 02:11:22:33:44:55

en0 is typically 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 indicates a 'locally administered' address (U/L bit set to 1) — 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), per-connection randomisation is configurable 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 (chosen address), use a third-party tool like Technitium MAC Address Changer (free, open source) or registry modification. 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 — the majority only modify 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 deliberately limited this for security and simplicity reasons.

Verification. Once the MAC is changed, confirm it is actually being broadcast by sniffing 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.

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 contain, beyond the requested SSID and the MAC, Information Elements that describe the device's capabilities: supported 802.11 version, speeds, features, QoS options. The combination of these IEs forms a characteristic 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 the majority of cases. Spoofing the MAC does not change IEs. The countermeasure would be to modify the device's Wi-Fi stack — essentially impossible without modifying the kernel.

IMSI catchers and cellular identifiers. On mobile networks (4G/5G), the equivalent of the MAC is the IMSI (International Mobile Subscriber Identity) — 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 an orthogonal identifier.

Application behaviour and timing. Beyond technical identifiers, your device's behaviour makes it identifiable. Installed apps make characteristic connections (Apple iCloud services on iOS, Google Play services on Android), connection timing follows your daily routine (morning/lunch/evening), and traffic volumes signal your usage patterns. An actor with multiple signals (MAC + visited IPs + schedule + IEs) can re-identify you even across session-randomised MACs. Countermeasure: compartmentalise (dedicated device for sensitive activities).

Captive portals and application identifiers. If you connect to the coffee shop's Wi-Fi and receive an auth email or SMS, your email or phone number is linked to your MAC in the provider's database, regardless of whether 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 regardless of 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.

On your own hardware — fully legal. Changing the MAC of your own Wi-Fi or Ethernet card is a standard technical operation, documented by OS manufacturers (Microsoft, Apple, Google all provide native functionality). No provision 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 — a technical tool with no particular legal characterisation.

To impersonate a specific third party's MAC — criminal. Configuring your MAC to match that of an identified person (colleague, neighbour, targeted victim) in order to bypass a Wi-Fi access control (a company that filters by MAC), to impersonate that person, or to conceal your identity in an unlawful activity 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 prohibit or discourage spoofing on company hardware, either for IT traceability reasons or to avoid disrupting 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, the latitude is greater, 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; you change your MAC to get a second free hour. Strictly speaking this circumvents 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. Legally negligible in practice, but worth avoiding as a matter of form.

Special case — wardriving and third-party sniffing. Capturing other users' MACs in range for analysis (research, journalism, audit) is technically lawful if limited to passive observation of plaintext radio signals, but the UK GDPR applies: MACs are considered personal data (CJEU 2016 Breyer judgment, confirmed by the ICO), so large-scale collection requires a legal basis and documented purpose. For private educational use on your own hardware, no issue.

Summary: the real value of MAC spoofing in 2026

MAC spoofing remains a useful but marginal protection layer in 2026. Three observations summarise 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 neutralises cross-location tracking by retail chains and Wi-Fi operators. It is the highest-impact measure at zero effort. Verify the feature is enabled by default on your usual Wi-Fi networks — it usually is, but worth confirming.

Manual spoofing serves specific cases. Penetration testing on your own network, security research, advanced OPSEC for high-risk profiles, bypassing a reasonable access control on your own hardware. For typical mainstream use, the benefit 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, regardless of the MAC identifier observed locally. A hardened browser (Brave, Firefox resistFingerprinting, uBlock) closes the application layer. Without these two components, 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: native MAC randomisation enabled, 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) remain beyond ordinary user control — their impact is residual for most people, structural for high-stakes profiles. To verify that your VPN setup actually works and that no leak contradicts the expected protection, follow our complete VPN audit in 9 tests on a quarterly basis.

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).