Skip to main content

MAC randomization simulator

Simulate how mobile MAC address rotation on iOS, Android, and Windows inflates device counts, exhausts DHCP scopes, and distorts visitor analytics.

Simulate MAC rotation impact and data reconciliation

1. Venue footprint template

Select a benchmark profile matching your venue footprint.

Large physical footprint, high pass-by probe noise from adjacent corridors, long dwell times, high return rate.

True physical human visitors entering the location in a 24-hour cycle.
True return rate40%
Actual repeat visitors.
Average dwell90m
Average physical stay.
Private MAC adoption rate85%
Percentage of smartphones with Private Wi-Fi / MAC randomization turned on.
Simulation ResultsDHCP /24 Exhausted
+93%Raw Device Count Inflation

Without multi-signal identity reconciliation, raw probe sensors record 28,898 devices, distorting your actual footfall of 15,000 guests.

Raw Sensor Logs (Distorted)28,898 devices
Purple Reconciled (99.2% Accurate)14,880 guests
Ground Truth (Actual Physical Visitors)15,000 visitors
Metric
Unique Visitors
Repeat Rate
Avg Dwell Time
Raw Sensor Logs
28,898
3%
48m
Purple Reconciled
14,880
40%
90m
Session Splitting Effect: Rotated MAC addresses truncate multi-hour visits into fragmented 15-to-30-minute sessions, artificially suppressing measured dwell times by up to 55%.

Restore true footfall visibility with Purple multi-signal identity correlation

Purple eliminates MAC address distortion by anchoring guest sessions to verified user profiles (Passpoint, SMS, email, and social login). Achieve 99.2% analytics accuracy without requiring visitors to turn off mobile privacy settings.

Speak to a WiFi analytics specialist →

How MAC address randomization impacts wireless networks and venue analytics

Modern mobile operating systems implement Media Access Control (MAC) address randomization to protect user privacy. Rather than broadcasting a permanent, factory burned-in identifier (BIA) when scanning for networks or connecting to an SSID, mobile devices generate synthetic, locally administered addresses (LAA).

While this safeguards user location privacy against passive RF sniffers, it presents significant technical and operational hurdles for venue operators, network architects, and commercial managers:

  • Footfall and Visitor Distortion: Raw probe listeners count rotated MACs as distinct physical people. Daily unique visitor figures can be inflated by 30% to 250%, while measured repeat visitor rates drop by up to 70%.
  • DHCP Scope Exhaustion: Every synthetic MAC requests a separate DHCP lease. In high-traffic venues with conservative lease timers (such as 24 hours), subnets run out of available addresses rapidly, resulting in client connection timeouts.
  • Captive Portal Re-Authentication: If a device rotates its MAC address upon reconnection, legacy captive portals fail to recognize the returning device and prompt users through redundant splash screens.

IEEE 802 MAC address structure and Locally Administered Address (LAA) detection

Under the IEEE 802 EUI-48 standard, a 48-bit MAC address consists of 6 octets. The first octet contains two critical control bits:

Bit 0 (I/G): Individual vs Group

The least significant bit of the first octet. 0 designates a Unicast address (single device NIC), while 1 indicates a Multicast or Broadcast frame.

Bit 1 (U/L): Universal vs Local

The second least significant bit. 0 indicates a Universally Administered Address (OUI assigned by IEEE), while 1 indicates a Locally Administered Address (LAA, synthetic or randomized).

In hexadecimal notation, whenever the second character of the first octet is 2, 6, A, or E (for example: 02:xx:xx, 06:xx:xx, 0A:xx:xx, or 0E:xx:xx), the address is guaranteed to be a randomized private MAC address.

Mobile operating system MAC randomization comparison matrix

Operating systemFeature designationDefault configurationRotation cadenceProbe behavior
Apple iOS 14 - 17 / iPadOSPrivate Wi-Fi AddressEnabled by default per SSIDFixed per SSID; rotates if network forgotten or inactive for 6 weeksRandomized LAA during pre-association probe requests
Apple iOS 18+ / macOS SequoiaRotating Wi-Fi AddressOptional toggle (enabled in certain privacy profiles)Rotates daily (every 24 hours) even on the same SSIDRandomized LAA on all unassociated probes and beacon responses
Google Android 10 - 15MAC RandomizationEnabled by default per SSIDPersistent per SSID; configurable to Non-persistent per-connectionRandomized LAA for probe requests and network scans
Microsoft Windows 10 / 11Random Hardware AddressesDisabled by default (user-enabled)Daily or persistent per network profileUniversal factory BIA unless random hardware addresses toggled on
Huawei HarmonyOSRandom MAC AddressEnabled by default per SSIDFixed per SSID with periodic renewal upon reconnectionRandomized LAA across pre-association discovery frames

How Purple reconciles rotated MAC addresses and restores analytics integrity

Purple eliminates analytics distortion without requiring visitors to turn off mobile privacy settings. By transitioning from volatile hardware MAC addresses to verified identity correlation, Purple delivers 99.2%+ data accuracy:

1. Verified Identity Anchoring

Guest logins via email, SMS OTP, social OAuth, or enterprise single sign-on anchor sessions to a single unified profile regardless of Layer 2 MAC changes.

2. Passpoint & Hotspot 2.0

Encrypted 802.1X Passpoint profiles authenticate returning visitors automatically across global locations, bypassing browser splash pages entirely.

3. Multi-Signal Stitching

Correlates browser tokens, deterministic user agent properties, and passive RF signal signatures to merge duplicate visitor records into true footfall timelines.

Frequently asked questions about MAC address randomization

What is MAC address randomization and how does it work?

MAC address randomization is a mobile privacy feature introduced in iOS 14+, Android 10+, and Windows 10/11 where the device operating system generates a synthetic 48-bit Layer 2 hardware address (LAA) instead of transmitting its factory burned-in address (BIA). This prevents passive WiFi sniffers and third-party tracking networks from monitoring a person's physical movements across distinct public locations.

How can you identify a randomized MAC address from its octets?

In the IEEE 802 standard, the second least significant bit of the first octet is the Universal/Local (U/L) bit. When this bit is set to 1, the address is Locally Administered (LAA). In hexadecimal notation, this means any MAC address where the second character of the first octet is 2, 6, A, or E (for example, x2:xx:xx, x6:xx:xx, xA:xx:xx, or xE:xx:xx) is a synthetic or randomized address.

Why does MAC randomization cause DHCP pool exhaustion on guest networks?

Standard DHCP servers allocate IP address leases based on the client hardware MAC address (Option 61 Client Identifier). When mobile devices rotate MAC addresses or when brief pass-by devices probe the network, each new synthetic MAC claims a dedicated IP lease. In high-traffic venues with 24-hour lease times, a /24 subnet (254 addresses) can exhaust in hours, blocking new visitors from connecting.

How does MAC rotation distort visitor analytics, dwell times, and return rates?

When a returning customer connects with a newly rotated MAC address, raw probe sensors cannot correlate the visit to previous sessions. The customer is recorded as a brand-new visitor, inflating raw footfall counts by 30% to 150%, reducing calculated repeat visitor rates by up to 70%, and truncating multi-hour dwell time measurements into fragmented brief sessions.

How does Purple reconcile randomized MAC addresses without violating privacy?

Purple decouples identity and analytics from volatile hardware MAC addresses. When a guest authenticates via captive portal login (email, SMS verification, social login, or Passpoint 802.1X profile), Purple links the session to a secure visitor profile. Multi-source correlation stitches rotated MAC sessions back to the verified identity, delivering 99.2%+ footfall and repeat visitor accuracy while respecting mobile privacy standards.

What DHCP lease time should network engineers configure for guest WiFi?

For guest WiFi networks in venues, retail centers, and transit hubs with high mobile device turnover, Purple recommends setting DHCP lease durations between 30 minutes and 2 hours (1800 to 7200 seconds), combined with a sufficiently sized subnet (such as /22 or /20). This allows inactive leases from transient pass-by devices to expire rapidly, preventing subnet pool depletion.

Related network diagnostic and WiFi tools

Is MAC rotation skewing your visitor data?

Address rotation on iOS and Android can inflate raw footfall metrics and exhaust DHCP pools. Purple reconciles guest signals through multi-source identity correlation, restoring analytics integrity.

Book a 20-min demo
Free Desktop App

Netforge Network Multi-Tool

Run offline network health checks, path analysis, and latency diagnostic scans directly from your desktop.

Download Multi-Tool