MAC randomisation breaks device rules

A home router sees the device on Wi-Fi as a MAC address. Modern phones rotate that address. A rule that says “the child’s device is 11:22:33:44:55:66” silently points at a different address after the next join [source: source-android-mac-randomization].

MAC randomisation is a privacy feature, not a circumvention tool. But it makes a router rule that identifies the child by MAC into a rule that points at nobody [source: google-android-android-private-dns].

This page explains how MAC randomisation works, where the assumption breaks, and what a router rule should use instead [source: source-android-mac-randomization].

Why this matters

A router with per-device schedules and content filters usually identifies the device by MAC address. The parent sets the schedule. The parent trusts the schedule.

When the device rotates its MAC, the schedule still applies to the original address. The new address is a stranger on the network [source: source-android-mac-randomization].

Two visible failures follow:

• The schedule no longer applies to the child’s device.
• A stranger on the network looks like the child’s device when the MAC happens to match [source: www-rfc7754-filtering].

Both are bad. Neither is what the parent intended.

Definition

A MAC address is the link-layer identifier a device uses on a local Wi-Fi network. It is normally a unique, fixed value burned into the hardware [source: www-rfc7754-filtering].

MAC randomisation is the practice of using a different, randomly chosen MAC address on each Wi-Fi connection. Android 10 and later randomise the Wi-Fi MAC by default [source: google-android-android-private-dns]. Android 11 and later support a non-persistent variant on implementations that expose it [source: source-android-mac-randomization].

iOS, iPadOS, and most current desktop operating systems randomise the Wi-Fi MAC for untrusted networks by default.

Scope

This page covers per-connection MAC randomisation and per-network identity rotation on consumer Wi-Fi. It does not cover Bluetooth MAC, Ethernet MAC, or cellular identity. Those use different identifiers and are not in scope for a home-router parental-control plan.

It does not cover content filtering, time scheduling, or DNS filtering; those are covered elsewhere in the network-layer package.

What Android documents

Google’s Android help page “Manage advanced network settings on your Android phone” states that Android 10 and later use randomised Wi-Fi MAC addresses. The same page is the first-party documentation of the Private DNS system setting [source: google-android-android-private-dns].

Google’s AOSP documentation, “Wi-Fi MAC randomization behavior”, states that Android 11 and later support a non-persistent randomisation mode on implementations that expose the developer option for it [source: source-android-mac-randomization].

A non-persistent MAC changes between connections. A persistent randomised MAC changes per Wi-Fi network, but stays constant within one network.

The default on most consumer Android phones is the persistent variant: the device keeps the same randomised MAC for the duration of its association with one Wi-Fi network.

How a MAC-only rule breaks

A router rule that uses the MAC as the device identity has three failure modes:

• A non-persistent MAC means the device presents a new address on every join. The router sees a new device each time [source: source-android-mac-randomization].
• A persistent randomised MAC means the device keeps its random identity for the duration of the connection, but a different random identity on a different network. A rule set up on the home network does not follow the device to school or to a friend’s house.
• An OS update can change the randomisation behaviour. A rule that worked last year can stop working after the upgrade [source: source-android-mac-randomization].

The rule is still in force. The rule points at nobody.

What works as an identity

A router rule can attach to one of three things instead of the bare MAC:

• An authenticated network association. Where the Wi-Fi uses WPA2-Enterprise or a similar per-user authentication, the user identity survives MAC rotation [source: www-rfc7754-filtering].
• A device profile that the router recognises by association behaviour. Some routers can identify a device by other stable signals, such as DHCP fingerprints or by a registered device certificate.
• A device-side or account-side control that does not depend on the network at all. Screen Time on iOS, Family Link on Android.

The first two keep the rule on the network. The third removes the rule from the network.

What Google says about parental controls

Google’s Android help page notes that parental controls that rely on MAC identity should account for both the device MAC and the randomised MAC [source: google-android-android-private-dns].

The recommendation is not that parents learn the randomised MAC. The recommendation is that MAC-only identity is fragile. Use a stronger identity where the router supports it [source: google-android-android-private-dns].

What this means for a router rule

Three honest limits to keep in mind:

• A MAC-only rule is a maintenance burden. Re-binding the rule after every OS update is a real cost [source: source-android-mac-randomization].
• A MAC-only rule can also be too restrictive. A new device on the network looks like a stranger because its MAC is unfamiliar [source: www-rfc7754-filtering].
• A MAC-only rule is not the right tool for content control. Content belongs on the device or the account [source: saferinternet-technischer-kinderschutz].

A router rule based on MAC is acceptable for “pause this device” and similar broad gestures. It is not acceptable as the load-bearing setting for the parental plan.

How to notice it stopped working

A MAC rule that has stopped working does not announce itself. The schedule or filter that used to apply no longer applies.

Three signals:

• The router’s client list shows the child’s device under a different name or no name at all.
• A device-pause setting no longer pauses the child’s device.
• A new “unknown” device appears on the network whenever the child joins.

To distinguish these from a configuration mistake:

• Test the rule from the child’s device on the home Wi-Fi. If the rule does not apply, the MAC is rotated.
• Re-bind the rule using the current MAC. The rule applies for this session, and may break again at the next join [source: source-android-mac-randomization].
• Move the rule to the device or the account. This is the durable fix.

Talking about it

MAC randomisation is a privacy default. A child who knows what it is has read about it. A child who does not know what it is has the OS default, which is already randomised [source: source-android-mac-randomization].

State the difference. “This rule works at the network layer. It identifies the device by its MAC address. Modern phones rotate that address, so the rule points at nobody after the next join.”

State the move. “The rule is moving to your phone and to your account. That way it follows you.”

Re-check the device settings once a year. A new phone, a new OS update, a new SIM can each change the default [source: source-android-mac-randomization].

Related wiki pages

The article on Why router rules miss the phone covers the broader network-layer pattern.

The honest limits page, What the network layer cannot do, lists the gaps the network layer leaves open.

Sources

• source-android-mac-randomization — AOSP, “Wi-Fi MAC randomization behavior”. First-party documentation of Android’s MAC randomisation modes [source: source-android-mac-randomization].
• google-android-android-private-dns — Google Android Help, “Manage advanced network settings on your Android phone”. First-party documentation of Android Private DNS and the parental-control MAC implication [source: google-android-android-private-dns].
• saferinternet-technischer-kinderschutz — Austrian Safer Internet Centre. Documented layered-defense guidance [source: saferinternet-technischer-kinderschutz].
• www-rfc7754-filtering — IETF, RFC 7754. Scope and efficacy of blocking, including identity-based filtering [source: www-rfc7754-filtering].

[source: source-android-mac-randomization] [source: google-android-android-private-dns] [source: saferinternet-technischer-kinderschutz] [source: www-rfc7754-filtering]