Summary

  • Random generation does not specify how long a MAC address lasts. A private value can remain stable within a network, while another policy changes it at a connection or time boundary.
  • Current Apple and Android documentation describes different persistence and rotation rules. Buying “MAC randomization” is therefore not enough to establish the continuity or privacy a service will deliver.
  • The appropriate decision is not simply more rotation or less privacy. It is which recognition must survive, for what purpose, and what evidence shows the chosen boundary works.

The apparently contradictory setting is the useful one: a private address that does not rotate. It forces two questions apart. Was this identifier supplied as the device's hardware address? And will the device present the same identifier when it returns? A negative answer to the first can coexist with an affirmative answer to the second.

For an operator, the distinction creates room to design a service. Remembering a returning client need not begin with demanding the hardware identifier used elsewhere. For a privacy team, it removes an easy but misleading assurance. Randomness at creation is not a promise that recognition quickly expires.

Neither team can settle the matter by pointing at a setting called private. The word describes an intention and a family of mechanisms. It does not, on its own, define the observer, the network boundary or the duration of a useful association.

Generation is an event; persistence is a policy

RFC 9724, published in March 2025, gives this problem a vocabulary. It is an Informational account, not a new Standards Track protocol. Its taxonomy includes a per-device generated address retained for the device lifetime, a per-boot value, a per-network value reused on return, and period- or session-based changes. Systems can combine policies. The same broad description—randomly generated—therefore spans very different histories. RFC 9724

The managerial error is to purchase a generation property while assuming a retention property. A supplier can truthfully demonstrate that the factory address is not being presented without demonstrating that a returning client becomes unrecognizable. Conversely, observing a familiar private address does not establish that randomization has failed. The relevant question is whether familiarity was allowed within that particular boundary.

Scope must be specified with equal care. A per-network identifier is not necessarily a per-building identifier. The network profile, the physical place, the operator and the service account are different ways of grouping activity. A claim about one does not automatically hold for the others. An acceptance record should say what actually selects the identifier, rather than treating a familiar place name as the technical boundary.

This also changes the interpretation of a reset. A user may expect “forget this network” to mean “return as somebody the network has not seen.” That expectation is a claim about persistence, not merely about deleting a saved connection. It needs platform-specific evidence.

Two current descriptions, not one universal timer

Apple's support documentation distinguishes Off, Fixed and Rotating from iOS 18 and the corresponding named generations of its other operating systems. Fixed uses a private address without periodic rotation; it is the documented default for a new network using WPA2 or stronger security. Rotating changes the private address every two weeks and is the documented default for a new network with weak or no security. Separate reset and forgetting rules mean Fixed should not be read as unchangeable under every operation. Apple's private Wi-Fi address guidance

That distinction does not certify the operator of a WPA2 network as trustworthy. A security mode can select a platform default without establishing the institution's data practices. Nor does an administrator's preference prove which setting an unmanaged visitor has chosen. Documentation describes a policy; a particular connection supplies evidence of its operation.

Android's framework documentation describes persistent randomization as the default. Its value depends on network-profile parameters; forgetting and re-adding the same network does not itself regenerate it. From Android 12, specified app requests or an optional open-network configuration can select non-persistent behaviour. That configuration is not enabled by default.

For documented non-persistent behaviour, regeneration can occur on a new connection when a DHCP lease has expired and disconnection exceeds four hours, or when the value is over 24 hours old. Otherwise the existing value may be reused. Crucially, the framework does not actively disconnect Wi-Fi merely to regenerate the address. Android Open Source Project behaviour documentation

An address-age threshold is consequently not the same thing as a scheduled interruption. If a service owner translates “24 hours” into “every call will drop once a day,” the failure is in the interpretation before it is in the network. If an analyst assumes every new association yields a fresh value, the same documentation contradicts that assumption.

These are vendor and framework descriptions, not a test of every handset or manufacturer customization. The distinction matters especially when historical sources look current. RFC 9724's operating-system test table explicitly comes from September 2021. Its policy vocabulary remains useful; that table cannot establish a 2026 fleet's behaviour.

What exactly needs to be remembered?

A service might need to carry a preference across a brief interruption. Another might need to recognize a return within an enrollment period. Neither requirement necessarily implies recognizing the same hardware across unrelated networks. The required continuity should be stated first; the available identifier should be evaluated second.

Reversing that order is attractive because it appears cheap. If the existing service already keys records by MAC address, preserving that key avoids changing the surrounding assumptions. But an inherited dependency is evidence about the service's design, not a sufficient reason to extend recognition indefinitely. Its owner should identify the user benefit, the failure when continuity ends, and the narrowest context in which persistence is useful.

There is a serious argument for stability. Repeated re-enrollment can inconvenience users and increase support work. A private per-network value can preserve practical functionality while avoiding one universal hardware value. Treating all persistence as a defect would erase precisely this middle ground.

The counterargument is not that every stable association is harmful. It is that the price of convenience must be visible. How long does recognition last? Does the user understand the boundary? Which downstream records inherit it? What ends the association? A service cannot answer those questions by citing the randomness of the original draw.

The rest of the stack can keep the connection

Changing one identifier may leave another available to correlate the old and new observations. RFC 7844 explains the DHCP problem directly: link-layer addresses, IP addresses and DHCP identifiers need coordinated evolution for the privacy objective. A stable DHCP identifier can reconnect histories that a changing MAC address was intended to separate. The anonymity profiles reduce disclosure; they do not eliminate every form of fingerprinting. RFC 7844, section 2

This is not evidence that the Apple or Android settings implement every part of those profiles. Nor is it an argument that limited protections are worthless. A mechanism can remove an easy correlation path without defeating every possible observer. The honest acceptance statement names the path addressed and the paths left outside its scope.

For the operator, the important organizational boundary appears when compatibility work starts recreating the linkage that the client sought to limit. A support fix which quietly restores a broad, persistent identifier is also a data-policy decision. It should not travel through the organization disguised as a harmless repair to a lookup key.

The better question is concrete: which useful recognition must continue, and which recognition should be allowed to end? Once that is answered, address policy becomes something to test. Before it is answered, a private-address checkbox is doing work that belongs to management.