The Remote Authentication Dial-In User Service (RADIUS) protocol has relied on Media Access Control (MAC) addresses as the default device identifier for over two decades. Every time a device connects to a managed network, the MAC address is carried in the RADIUS Calling-Station-Id attribute and used as the primary key for device profiling, policy enforcement, license counting, and compliance audit trails.
Starting in 2020, Apple, Google, and Microsoft made MAC address randomization the default behaviour on iOS, Android, and Windows. A device now presents a different MAC address each time it connects — or periodically while connected — depending on the Operating System (OS) policy. From the RADIUS server’s perspective, a single laptop that reconnects after a MAC rotation looks like a brand-new device.
The implications are immediate and operational: Endpoint records proliferate, profiling data fragments across unrelated MAC-keyed records, accounting sessions can’t be correlated, license counts inflate, and regulatory audit trails lose device-level continuity.
IEEE 802.11bh-2024 addresses session continuity at Layer 2, but nothing extends that continuity up to the Authentication, Authorization, and Accounting (AAA) layer. There is currently no standard RADIUS mechanism to maintain a stable device identity across MAC address changes.
Why not just reuse an existing RADIUS attribute?
The obvious question is whether an existing RADIUS attribute can fill this role. The short answer is no — each candidate has a fundamental mismatch:
- User-Name (Type 1) identifies a user, not a device. One user has multiple devices; one shared device has multiple users.
- Chargeable-User-Identity (CUI) (RFC 4372) is semantically a billing identity with a temporary binding lifetime. Overloading it for persistent device identity violates its defined semantics and conflicts with existing roaming billing deployments.
- Class (Type 25) is opaque, session-scoped, and not guaranteed to persist across sessions or MAC changes.
In the absence of a standard, vendors have built incompatible workarounds. Some repurpose the User-Name attribute to carry device identifiers — violating RFC 2865. Others use Vendor-Specific Attributes (VSAs) that only work within single-vendor deployments. The result is a fragmented ecosystem where persistent device identity is available only within vendor silos.
The approach: Certificates you already have, a new attribute you need
The framework ties persistent device identity to the X.509 certificate that devices already use for certificate-based Extensible Authentication Protocol (EAP) authentication (EAP-TLS, EAP-TTLS, TEAP). During device enrolment — through a mobile device management (MDM) system or a self-service onboarding portal — a UUID (version 4, per RFC 9562) is generated and embedded in the certificate’s Subject Alternative Name (SAN) URI field using the urn:uuid: namespace.
When the device authenticates, it presents this certificate inside the encrypted EAP tunnel. The RADIUS server extracts the UUID and includes it as a new standard RADIUS attribute — Persistent-Device-Id — in the Access-Accept message. The network access device then includes this identifier in all subsequent Accounting-Request messages, enabling cross-session correlation regardless of MAC address changes.
This approach requires no changes to the device itself (the certificate is provisioned through standard enrollment), no changes to the EAP protocol, and no changes to network access device firmware beyond recognizing one new RADIUS attribute — which, per standard RADIUS behaviour, is silently ignored by devices that don’t yet support it.
What this looks like in practice
Two scenarios illustrate how this works — one for Bring Your Own Device (BYOD), one for managed devices.
BYOD with self-enrollment
An employee brings a personal laptop to work and connects to the onboarding SSID. The captive portal walks them through enrollment: The employee accepts a certificate profile, and the portal provisions a certificate with a UUID embedded in the SAN URI field. The employee’s device now authenticates via EAP-TLS.
On the first connection (MAC_1), the RADIUS server extracts the UUID from the certificate, creates a device record, and returns Persistent-Device-Id = UUID_A in the Access-Accept. A week later, the laptop’s OS rotates its MAC address to MAC_2. The device reconnects, presents the same certificate, and the RADIUS server extracts the same UUID_A — finding the existing record instantly.
The profiling data (DHCP fingerprint, HTTP user-agent, OS version) accumulated under MAC_1 is still associated with this device. The license count stays at one.
MDM-managed corporate device
IT deploys a fleet of corporate iPhones via an MDM system. During enrollment, the MDM generates a certificate for each device with a unique UUID in the SAN URI field and pushes it silently.
When phone #247 connects to the office Wi-Fi with MAC_1, the RADIUS server extracts UUID_247 from its certificate and records the mapping. The phone travels to a branch office, connects with a different randomized MAC_2 on the branch wireless controller, authenticates with the same certificate, and the branch RADIUS server (or the same centralized server) correlates it back to device #247.
Accounting records from both sites — different MACs, different access points, different cities — are linked under one device identity. When the compliance team runs the quarterly HIPAA audit, the trail is intact.
Guest access — the deliberate gap.
A visitor connects to the guest Wi-Fi. No certificate, no enrollment, no MDM. The RADIUS server has no certificate to extract a UUID from, so no Persistent-Device-Id is assigned. The guest’s device continues to benefit fully from MAC randomization — each connection is a fresh, unlinkable session. This is by design: Persistent identification requires an explicit identity assertion from the device. Without one, privacy is preserved.
Privacy by design, not privacy by accident
A persistent device identifier sounds like it could undermine the privacy that MAC randomization was designed to provide. The key distinction is where the identifier lives and who can see it.
The MAC address appears in plaintext in every Layer 2 frame header — visible to any passive listener within radio range. MAC randomization exists precisely because the MAC address lacks transport protection.
The Persistent-Device-Id is never present in any Layer 2 frame. It travels in two protected channels: The encrypted EAP tunnel (device to RADIUS server) and RADIUS messages protected by RADIUS/TLS (server to network access device). Its visibility is strictly narrower than even a randomized MAC address.
The framework is also consent-based. The identifier exists only because a certificate containing it was explicitly provisioned onto the device — by an administrator (corporate MDM) or by the device owner (BYOD self-enrollment). Unenrolled devices — guests, personal devices without certificates — are completely unaffected and continue to benefit fully from MAC randomization privacy.
Toward a standard: The IETF effort
The Persistent-Device-Id attribute is proposed as a standards-track IETF Internet Draft (‘draft-seralathan-radext-persistent-devid-00‘), now published on the IETF Datatracker. The draft is co-authored by engineers from Cisco and Hewlett Packard Enterprise — two vendors that have independently built incompatible proprietary solutions and recognize the need for a common standard.
The full technical analysis is published on arXiv. The IETF draft standardizes only the attribute format and usage rules, deliberately leaving generation, provisioning, and downstream usage to implementations. This separation keeps the standard focused and avoids prescribing operational choices that vary across deployments.
The IETF MADINAS Working Group documented the impacts of MAC randomization in RFC 9724, which directly motivated this work. The Persistent-Device-Id specification builds on the MADINAS analysis by providing a concrete protocol-level solution at the AAA layer.
What’s next
The current specification covers certificate-based EAP authentication — the strongest identity assertion in the RADIUS ecosystem. An open question is whether persistent device identity can be extended to non-certificate scenarios (Internet of Things devices using MAC authentication bypass credential-based methods) without compromising the privacy properties.
Feedback from the operational community is essential. If you’re running RADIUS-based access control and dealing with MAC randomization at scale, the IETF RADEXT mailing list (radext@ietf.org) is where this work is being discussed. The draft is available on the IETF Datatracker.
Premanand Seralathan is a Senior Technical Leader at Cisco Systems, where he has spent over 15 years working on Cisco Identity Services Engine (ISE). He is the inventor of the Randomized and Changing MAC (RCM) solution, the sole architect of ISE’s API Gateway, and the FIPS 140-2/140-3 certification lead enabling ISE’s deployment across U.S. federal networks. He is an active contributor to the IETF RADEXT Working Group and holds patent filings in network access control and behavioural trust evaluation.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.