Stable Wi-Fi MAC Addresses for Industrial Devices: Reservations, Admission Rules and Factory Resets

A stable Wi-Fi address is a lifecycle policy, not merely a setting called “stable.” Decide which identity survives a reboot, profile replacement, firmware reinstall, factory reset and radio replacement. Then prove that the address observed by the network owner follows that policy. A reservation or admission entry can silently stop matching when an input to address generation changes.

This guide uses NetworkManager 1.46.0 on Linux Wi-Fi station devices as its concrete software boundary. The wireless driver must support the selected address behavior, and the module’s permanent-address provisioning must be verified separately. It does not prescribe DHCP server configuration or claim that a MAC address authenticates a device.

Choose the identity that the installation needs

Start with the network owner’s intended relationship. Does the entry identify a particular radio module, the product enclosure after service replacement, or one installation profile? Those are different requirements. Write the expected outcome for each service event before choosing an address source.

• Radio-bound identity: use the verified permanent address as the lifecycle anchor. A radio replacement becomes an explicit network-registration change.
• Product-bound identity: provision a product-specific address under an approved allocation policy and preserve it through the service operations that should retain identity.
• Profile-bound generated identity: document every generation input and which reset operations preserve those inputs.

These are design choices, not interchangeable guarantees. A product-bound address also requires collision prevention and a replacement policy that prevents the old and replacement units from presenting the same identity simultaneously. Do not invent globally administered addresses or reuse a sample address across a fleet.

Separate permanent, active and generated addresses

In NetworkManager 1.46.0, the wireless mac-address property restricts which permanent-address device a profile can apply to; it does not change the transmitted station address. The address-changing property is called cloned-mac-address in nmcli and libnm, while the newer D-Bus property is assigned-mac-address. See the versioned wireless settings reference.

The 1.46.0 nmcli settings manual documents the applicable address modes. Select the mode explicitly in the released profile, and check the effective configuration rather than assuming a distribution default. Record the permanent address and the address actually used while associated as separate observations.

Do not derive the station identity from a single packet seen during scanning. Qualification should identify traffic belonging to the established connection and compare it with the network’s station record. A label printed on the enclosure is another input to verify, not evidence that the active profile uses that address.

Make generated identity inputs part of the reset design

NetworkManager’s connection.stable-id seeds stable generated addresses and can use context-dependent substitutions. In 1.46.0, the documented default ultimately incorporates the connection UUID; supported substitutions include the profile, device, permanent MAC, SSID, boot and random context. A configuration containing a boot-dependent input cannot satisfy a requirement to keep the same generated address across boots. See the stable-id definition.

The NetworkManager 1.46.0 daemon manual also describes the machine identity used in stable generation, including its secret-key file and the machine-id contribution with newer secret-key format. Backup restoration and cloning intentionally have different identity goals. Consequently, preserving only a profile’s visible name does not establish that a generated MAC will survive reinstallation.

For the product image, document which per-device identity material is created during manufacturing or first boot, where it is retained, and which operations replace it. Keep secret material out of support exports. A useful support record needs the selected policy, build identity and observed address, not the secret generation seed.

Test fleet imaging separately from single-device recovery. A restoration procedure that correctly preserves one unit’s identity may be wrong when used to manufacture many units. Make uniqueness checks part of provisioning rather than relying on an engineer to remember to remove cloned state.

Build an identity-transition matrix

For each transition, state “same identity expected” or “new identity expected,” name the owner of any network change, and define the evidence. At minimum, include:

1. A warm reboot and a complete power cycle with the same profile and hardware.
2. A firmware update that claims to preserve configuration.
3. A profile edit versus deleting and recreating the profile.
4. A full firmware reinstall using the supported recovery image.
5. Each distinct reset mode exposed to users or service staff.
6. Radio replacement and main-board replacement.
7. Two devices provisioned from the same production image and connected at the same time.

Do not collapse all resets into one row. “Reset network settings” and “erase all product identity” may have different intended outcomes. The acceptance criterion must match the documented product behavior, even when that behavior deliberately changes the station address.

Correlate three records before declaring a pass

Run the matrix on a bench network with recovery access. For each row, capture the device’s effective address configuration, the associated station address observed by the network, and the identifier used by the reservation or admission rule. Ask the network owner to confirm the matching key; a reservation may depend on a client identifier rather than only the MAC address.

If the device configuration says one address but the network observes another, investigate profile activation, driver behavior and observation timing. If the address is unchanged but the reservation no longer matches, inspect the actual matching identifier and stale network state. If the address changed exactly as the reset policy intended, the engineering issue is coordinated re-enrollment, not unexplained randomness.

Record mismatches before making fixes. Changing both the device identity and the network rule in one step destroys the evidence needed to determine which side violated the contract. The matrix above is a proposed qualification procedure; no fleet or hardware measurements are claimed here.

Hypothetical example: recovery recreates the profile

Imagine a hypothetical factory gateway whose normal updates retain its generated station address. The recovery image recreates the Wi-Fi profile with a new UUID and replaces machine identity state. The SSID and profile name look familiar, yet the network sees a different station address and rejects its old admission entry.

The appropriate correction depends on the intended lifecycle. If recovery should preserve product identity, revise the preservation and provisioning design and retest it. If recovery intentionally creates a new identity, make the service procedure report that address and obtain the network owner’s authorized enrollment change. Neither outcome is established by simply selecting the word “stable.”

Release with a compact identity contract that manufacturing, firmware, service and network administrators can all apply. It should specify address ownership, uniqueness checks, preservation boundaries and the exact service events that require re-enrollment.