Persistent Device Identity for Network Access Control in the Era of MAC Address Randomization: A RADIUS-Based Framework

Persistent Device Identity for Network Access Control in the Era of MAC Address Randomization: A RADIUS -Based Framework Premana nd Seralathan ORCID: https://orcid.org/0009-0007-0397-1485 Preprint submitted to arXiv, March 2026 Keywords: Netw o rk Access Control, MA C Address Randomization, RA DIUS, Device Identity, GUID, Zero Trust, Healthcare Secur it y, FI PS, 802.1X , IoT Secur ity Abstract Modern operating syste m s increasingly randomize Media Acce ss Control (MAC) addresses to protect user privacy, fundamentally disrupting Network Access Control (NAC) systems that have relied on MAC addresses as p ersistent device identifier s for over two decades. This disruption affects critical enterprise environments including federal government agencies operating under FI SMA, healthcare organizations subject to HIPAA, financial institutions governed by PCI-DSS, and educational networks ma n aging large- scale B Y OD deployments. This paper pr esents a comprehensive framework f or maintaining persistent device identity in NAC environments through a RADIUS proto col -based approach that assigns and distributes a Globally Unique Identif ier (GUID) to endpoints via RADIUS Access -Accept messages. The proposed architecture addresses the complete device lifecycle i ncluding initial enrol lment, re -authentication across randomized a ddre sses, device management integration, c ertif icate -based identity binding, and device attribute correlation. We describe the framework's design acros s six distinct use cases -- B YOD, man aged devices, VPN -bas ed posture assessment, non-VPN posture, guest access, and IoT device profiling -- and analyze its e ff ectiveness in maintaining device visibility, accura te license counting, and regulatory compliance under continuous MAC address randomization. The approach is compatible with existing 802.1X and MAB inf rastructure, requires no client-side operating system modifications, and aligns with the recently published RFC 9797 and IEEE 802.11bh-2024 standards. Our framework enables organizations to maintain regulatory compliance while preserving the privacy benefit s that MAC addre ss randomization was designed to provide. I. Introduct ion For over two decades, the Media Access Control (MAC) address has served as the foundati onal device identifier in enterpr ise network acces s contr ol. IEEE 802.1X por t-bas ed authentication [1], MAC Authentication Bypass (MAB), device profiling, and policy enfor cement syste m s all rely on the assumption that a device's MAC address remains stable and uniquely identifies the physical hardware. This assumption has been e mb edded in the architecture of every major NAC plat for m, authentication server, and network infrastructure component deployed worldwide. Beginning in 2019, major operating system vendors introduced MAC address randomization as a default privacy feature. G oogle introduced per-network MAC randomi zation in Android 10 ( September 2019) [2], Apple enabled per-network randomization in iOS 14 (September 2020) and later enhanced it to per- connection rotation in iOS 18 [3] , and Microsoft introduced MAC randomization in Windows 10 version 2004 (May 2020) [4]. As of 2025, virtu ally every consumer device c onnecting to enterprise wirele ss networks transmits a randomized MAC address by default. The s c ale of this disruption is significant. Industry estimates in dicate that over 15 billion Wi- Fi -enabled devices a re in a ctive use globally [5], and the proporti on using randomized MAC addresses has grown from approximately 30% in 2021 to over 80% in 2025 [6]. In enterprise e nvir onments, this means that the majority of devices connecting to corporate, healthcare, and go vernment networks can no longer be reliably identified by their MAC address alone. The impact on NAC sys t ems is multifaceted. First, devic e trackin g and session correlation break when a device's M A C address changes between connection s or rotates dur ing a sess ion. Second, d evice profiling data becomes fr agmented -- a s ingle phy sical device may gener ate dozens of separate device records, each ass ociat ed with a differ ent randomized MAC. Third, license counting mechanisms that use MAC addresses as unique device id entifier s produce inflated counts, creating both cost and compliance issues. Fourth, regulatory fr ameworks that require device -level audit tr ails -- in cluding HIPAA's requirement f or tracking devices that access electronic Protected Health Infor mation (ePHI) [7] and F ISMA's continuous monitorin g mandate [8] -- cannot be sa tisfied when devic e identity is ephemeral. Recent s t andards efforts have begun to address this challenge. RFC 9797, published in June 2025, provides a comprehensive a n alysis of the network impact s of MAC address randomization and documents affected use cases [9] . IEE E 802.11bh-2024 introduces Layer 2 mechanisms for session continuity without requirin g a stable M A C- to -station mapping [10]. However, neither standar d provides a complete solution for the AAA (Authentication, Authorization, and Accounting) and policy enforcement layer where NAC systems operate. Existing research approaches have focused primarily on def eating MAC randomization through fingerprinti ng techniques. Ma rti n et al. demonstrated that probe r equest s ignatures can re -identif y devices with high accuracy [11], and the Bleach system achieves up to 99% association accuracy using Wi -Fi probe-request analysis [12]. While technically effective, these a pproaches are fundamentally adversarial to user privacy -- they s eek to circumvent a privacy protection rat her t han cooperate with it. This c re ates tension with privacy regulations including GDPR and raises ethical concerns about network -level surveillance. This pa per pr oposes a fundamentally different approach: a coop erative framework that wor ks *with* MAC address randomization by establishing a persistent device identity layer above the MAC address. Our framework intr oduces a GUID-based identity model where ea c h physical device is assigned a globally unique, persistent identifier that is distributed through standard RADIUS protocol mechanisms. The GUID persists a cro ss MAC address changes, enablin g continuous device tracking, accurate profiling, corr ect license counting, and regulatory compliance -- all without atte mpting to defeat the privacy protections that MAC randomization provides. The contributions of this paper are: 1. A GUI D-based persis tent identity model f or NAC systems th at decouples device identity fr om MAC addresses while maintaining backward compatibility with existing 802.1X and MAB infrastructure. 2. A RADIUS attribute-based mechanis m for GUI D distribution via Acce s s -Accept mess ages, extending the standard RADIUS protocol to carry persistent device identifier s. 3. A comprehensive framework addressing six distinct enterprise use cases: BYOD, managed device s, VPN posture, non-VPN posture, guest ac c ess, and IoT device p rof iling. 4. A persistent identity architecture that correlates multiple random ized MAC addre sses to a single persistent device ide ntity, en abling accurate visibility, licen se management, and compliance repor ting. 5. Analysis of concurrency and scale challenges including duplica te identifier pr evention under high authentication traffic loads. The remainder of this paper is organized as follows. Section II provides background on MAC address randomization and its impact on NAC systems. Section III reviews related work. Section I V presents our proposed framework in detail. Section V describes implementation considerations. Section VI provides evaluation and analys i s. Section VII discusses limitations and future directions. Section VII I concludes the paper. II. Background A. MAC Address Randomization A MAC a ddre ss is a 48-bit identifier assigned to network interface hardware. Traditionally, the fir st 24 bits represent the Organizationally Unique Identifier (OUI) assigned by IEEE to t he manufacturer, while the remaining 24 bits are assigne d by th e manufacturer t o uniquely identify the device [13]. This structure made MAC addre sses both globally unique and informative -- the OUI alone reveals the d evice manufacturer, which NAC systems use extensively for device profiling and classification. MAC address randomization replaces this hardware -a ssigned address with a locally -administered, randomly-generated alternative. The locally -administered bit ( b it 1 of the fir st octet) is set to 1, distinguishing randomized addresses from manufacturer-ass ign ed ones [14]. However, the remainder of the address is random, elimin ating the manufacturer identification capability that NAC systems depend upon. Operating system vendors have implemented randomization with var ying strategies: • Android 10+ (2019): P er-network randomization by default. Each s aved network r eceives a unique randomized MAC that pers i sts for that network [ 2]. • iOS 14+ (2020): Per-network randomization by default. iOS 15 introduced rotating MAC addres ses for non-associate d n etworks. iOS 18 intr oduced per-conne ction rot ation options [3]. • Windows 10/11 (2020): P er-network randomization available; s ome configur ations rotate on each connection [4]. • macOS Sequoia+ (2024): Per- network randomization ena bled by default f or Wi-Fi networks [15]. • Linux : Lim ited default randomization; varies by distribution and NetworkMana ger configur ation [16]. The trend is toward more aggressive randomization. Apple's intr oduction of per-connec tion r otation in iOS 18 means that the same device may present a different MAC ad dress on every network connection, even to the same network. B. Netwo rk Access Control Fundamentals Network Access Control systems authenticate and authorize devices before granting network access. The standard architecture involves three components: a supplicant (the connecting device), an authenticator ( the network switch or wireless access point), and an authentication server [1]. The authentica tion server communicates with t he authenticator using the RADIUS prot ocol (RFC 2865) [17]. When a device connec t s, the authenticator sends a RADI US Access -Request containing the device' s MAC address (in the Calling-Station-Id attribute) , user credenti als (for 802.1X) , and other sess ion information. The authentication server evaluates this information against policy and returns a RADIUS Access-Acce pt ( with authorization parameters) or Access-Reject. Beyond bas ic authentication, modern NAC systems p erfor m several MAC -depende nt f unctions: Device Profiling: NAC systems classify devices by analyz ing attributes collected from multiple network data sources -- DHCP fingerprints, HTT P User-Agent strings, SNMP d ata, DNS lookups, and NetFlo w records [18]. All of these att ributes are correlated to a d evice recor d in dexed by MAC address. When the MAC changes, this correlation breaks a nd profiling dat a fragm ents across multiple records. Policy Enforcement: Authoriz ation policies frequently ref er ence device attributes (device type, compliance status, user identity) th at are stored in device records keyed by MAC addres s. A changed MAC me an s a fresh, empty device record wit h no at tributes -- resulting in incorrect policy decisions. RADIUS Accounting : Accounting records (RFC 2866) [19] track session duration, data usage, and network activity per device. These records use the MAC addres s as the session identifier. MAC changes create discontinuous accounting records that cannot be correlat ed to a single device. License M anage ment: Software licen sing for NAC plat forms is typically b ased on the number of uniqu e devices. When a single device ge nerates multiple device records due to MAC randomiz ation, the license count becomes artificially inflated. C. The Dongle Use Case An additional complexity arises from USB network dongles, docking stations, and similar accessories. A single user may connect through multiple physical adapters, each with i ts own MAC addre ss (randomized or not). The NAC sys t em creates separate device records for ea ch adapter, even though they all represent the same user and device. This "dongle problem" compounds th e MAC randomiza tion ch allenge and must be addressed by any persis t ent identity solution. D. Regulato r y Impact Several regulatory fr ameworks ass ume persi stent device identity: • HIPAA Security Rule (45 CFR 164.312): Requires access c on trol s and audit trails for systems accessing elec tr onic Protected Health I nformati on. Device -level tracking is essential for demonstrating that only authorized devices access patient data [7]. • FISMA/NIST SP 800-53 : Requires continuous monitoring and device inventory management for federal inform ation systems . MAC randomization cr eates gaps in the Continuous Diagnostics and Mitigation (CDM) program [8] . • PCI-DSS : Requires network segmentation and access controls f or systems ha ndling cardholder data. Device identification is critical for maintaining segment boundar ies [20]. • NIST SP 800-207 Zero Trust Architecture : Requires per-r equest device verif ication. Persistent device identity is a prerequisite for implementing Zero Trust principles [21]. III. Rela t ed Work A. Standards -B ased Approaches RFC 9797, published by the IETF in June 2025, provides the most comprehensive a n alysis of MAC address randomization impacts to date [9]. The document catal ogs affected network services across residential, enterprise, and IoT environments, and identifies the tension between privacy and network operations. However, RFC 9797 is an infor mational document that describes problems and use cases rather than prescribing solutions. IEEE 802.11bh-2024 amends the IEEE 802.11 standard to support session continuity for devices using randomized MAC addresses [10]. The amendment introduces mechanisms at the MAC sublayer that allow network services to function without a unique MAC- to -station mapping. While va luable at Layer 2, these mechanisms do not ext end to the AAA layer where RADIUS -based authentication and authorization occur. The IETF MADINAS (MAC Address Device Identification for Network and Application Services) working group continues to develop standards for managing MAC address randomi zation im pacts [22]. Draft proposals under consideration include methods for devices to voluntarily signal identity to tr usted networks, but these require client -side coop eration that is not u niversally available. B. Fingerprinting and Re-Id en tification Approaches Several research efforts have attempted to re -identif y devices despite MAC randomization by analyzing secondary cha ra cteristics. Vanhoef et al. demonstrated that info r mation elements in 802.11 probe requests can fingerprint devices [23]. The Bleach system, published in 2024, achieves up to 99% accuracy in ass ociating randomized MAC addresses with physical device s using probe-request s ignature analy sis [12]. Martin et al. showed that timing patterns and frame sequence n umbers can also be used for re -identification [11]. While these tec hniqu es demonstrate that MAC randomiz ation alo ne does not guarantee untr ackability, t hey have significant limitations for enterprise NAC: 6. Privacy adversarial: These approaches explicitly attempt to def eat a privacy protection, creating legal risk under G DPR and similar regulations. 7. Accuracy degradation at scale: Fingerprinting accuracy decreas es as the numb er of concurr ent devices increases , p articularly i n dense enterprise e nvir onments. 8. OS update fragility: F ingerprinting signatures change with each OS update, requiring continuous model retraining. 9. Incomplete coverage: These techniques work primarily f or Wi- Fi probe requests; they do not address wired connections, VPN access, or non-802.11 protocols. C. Vendor-Specific App ro aches Several NAC vendors have implement ed propr ietary solutions for MAC randomization. Some rely on SNMP-based sw itch port monitoring and device characterizatio n thr ough inspection plugins [24]. These approaches require dedica t ed hardware applianc es deployed at network distribution point s, creating scalability concerns in large environm ents. Additionally, SNMP-based enforcement introduces latenc y and reliability challenges compared to inline RADIUS -based authentication. Other approaches use agent -bas ed solutions where client-side software provides persistent device identity. While effective when agents can be deployed, these approaches cannot address unmanaged devices, IoT equipment, or BYOD sce n arios where agent in stallation is impractical. D. Gap Analysis Table I summarizes the limitations of existing approaches. Approach Scope Privacy Scalability Agent-F ree AAA Integration RFC 9797 Problem documentation only N/A N/A N/A N/A IEEE 802.11bh Layer 2 s ession Yes Yes Yes No continuity Fingerprinting Re -identification No Limited Yes No SNMP-based monitoring Device characterization Neutral Limited Yes Partial Agent-based Full device identity Yes Yes No Yes **Proposed framework** **Full AAA integration** **Yes** **Yes** **Yes** **Yes** Table I: Comparison of approaches to MAC address randomization in NAC environments. Our proposed framework addresses the identified gap: a privac y -r especting, agent -f ree solution that provides persistent device identity at the AAA layer with full R ADIUS integration, scalable to enterprise deployments with millions of devices. IV. Proposed Framew or k A. Design Goals The propose d fr amework is guided by the following design prin ciples: 10. Persistent identity: Each physical device must have a stable identif ier that persists across MAC address changes , network r econnections, and operating system updates. 11. RADIUS-native: The identity mechanism must integrate with the standard RADIUS protocol, requiring no modif ications to network authenticators (switches , wireless controllers). 12. Agent-free operation: The solution must work without client-side s oftwar e installation, supporting unmanaged devices, IoT, and BYOD. 13. Privacy-r especting: T he framework m ust not attempt to defeat MAC address randomization. Instead, it cooperates with the privacy model by establishing identity through voluntary authentication exchanges. 14. Backward compatibility: Existing 802.1X and MAB flows mus t continue to function. The GUID mechanism must augme nt, not r eplace, current authentication i nfr astructure. 15. Multi-source correlation: The framework must correlate identity fr om multiple authentication sources - - certificates, device management enrollment, user credentials, and prof iling data -- to establish and maintain persistent identity. 16. Scale and concurrency: The framework must handle high-throughput authentication environments (thousands of authentications pe r second) without generating d uplicate identifier s. B. GUID-Ba sed I dentity Model The core of our framework is the Persistent Device Identifier (PDID), a 128 -bit Globally Unique I dentifier conforming to UUID version 4 ( RFC 4122) [25]. Each PDID is: • Generated server-side by the NAC authe ntic ation server • Assoc iated with exactly one physical device • Persistent across all MAC address change s for that device • Independent of the connecting network interface or adapter • Stored in a centralized identity repository with associated devic e attributes The PDID differs from t he MAC a ddress in a fundamental way : while the MAC address identifies a *network interface*, the PDID identif ies the *device * (or more precisely, the security identity associated with the device). A device connecting through multipl e interfaces (e.g., a laptop using both Wi -Fi and a USB Ethernet dongle) r eceives a single PDID. C. Persistent Id e ntity S tore The framework maintains a persistent identity store that maps multi ple MAC a ddres ses to a single PDID, along with assoc i ated device metadata gathered from various identit y sources over time. When a device connects with a new randomized MAC address, the NAC server attempts to corr elate it with an existing PDID. If corr elation succe eds, the new MA C address is associated with the existing identity record. If no cor relation is possible, a ne w PDID is generated. D. RADIUS Attribute Extension for GUID Distributio n The PDID is communicated to the network infrastructur e through a R ADIUS attr ibute included in the Access-Acce pt me ssage. The attrib ute carries the 128 -bit UUI D value of the PDID. This may be implemented as a Ve ndor-S pecific Attribute (VSA) or, ideally, as a new standard RADIUS attribute defined through the IE TF standards proces s. The at tribute format follows standard RADIUS encoding con ventions, carrying the 128 -bit (16-byte) UUID value of the PDID. The PDID is returned in the Access -Ac cept for every successful authentication. This e n ables: 17. Network infr astructure: Switches and wireless controllers c an associate the PDI D with the session, enabling consis tent accounting records across MAC changes. 18. Device management systems: Management platform s can use the PDID as a correlation key, enabling compliance chec k s to reference the persi stent device identity rather than the tr ansient MAC . 19. Downstream systems: SIEM, threat intelligence platfor ms, and compliance dashboards can reference PDIDs for consistent device -level reporti ng. E. Identity Correlation Algorithm The correlation algorithm determines whether a new authenticati on request corresponds to an e xi sting device. The fr amework leverages multiple identity signals avail able during the authentication exchange, evaluated in a configurable priority order . Available identity sources include : Certificate-based identity: Wh en certificate -based aut hentication methods (e.g., EAP-TLS) are use d, fields within the device certificate provide a strong, persisten t ident ity binding that can be correlated to an existing P DID. Device m anage ment enrollment: For managed devices, the enrollment iden tifier assigned by the management platform serves as a correlation key to an existin g PDID. User identity: The auth enticated usernam e from credential -based methods (e.g., EAP-PEAP) narrows the corre lat ion scope, especially when co mbined with d evice attributes. Endpoint agent identity: If a compliance agent is installed, it can supply a device-unique identifier during th e authentication exchange. Behavioral fingerprinting: For d evices without explicit credentials (e.g., IoT device s u sing MAB), behavioral fingerprints derived from network observations provide a lower -confidence correlation path. When none of the available id entity sources produce a match (e.g., a first -time guest device), a new PDID is generated. The sp ecific correlation logic, priority ordering, an d id entity source config uration are implementation-dep end ent and may va ry based on the deployment enviro nment and available identity infrastructure. F. Use Case Architectures The framework addresses s ix di stinct enterprise us e cases, each with i ts own identity correlation path.. Use Case 1: BYOD (Bring Your Own Device) In BYOD deployments, personal devices are onboarded through a provisioning portal that installs a device certificate embedding the PDID. On subsequent connections -- r egardless of MAC address changes -- the certificate-based 802.1X authentica tion pr ovides the PDID dir ectly, enabling immediate correlation. [Devic e] --- (ran domized MAC, EAP-TLS ) --- > [Authenticator] | | | RADIUS Access-Requ est | (Calling-Station -Id: ra ndom_MAC, | EAP-TLS with devi ce ce rtificate) | | | [NAC Server] | Correlate de vic e identity from certif icate | Update ident ity store | Apply policy ba sed on device identity | | | RADIUS Access-Acce pt | (Persistent Device Id , Authorization Parame ters) | | [Device] <----(Network Access)---- [Authenticator ] Fig. 2: BYOD use case flow with certificate - embedded PDID. Use Case 2: Managed Devices For devices enrolled in a device management system, the management platfor m assigns a devi ce enrollment identifier. Durin g authentication, the NAC s erver queries the m anagement platform to r etrieve this enrollment identifier and correlates it with an existing PDID in the persistent identity store. [Devic e] --- (ran domized MAC, 802.1X) --- > [Authenticator] | | | RADIUS Access-Requ est | | | [NAC Server] | Query device ma nagement | Correlate to ex isting PDID | Check device co mpliance | Apply policy | | | RADIUS Access-Acce pt | (Persistent Device Id , | Authorization Par ame ters) | | [Device] <----(Network Access)---- [Authenticator ] Fig. 3: Managed device use case flow with enrollment identifier - to - PDID correlation. The inclus ion of the persistent identifier in the RADIUS Access-Accept e nables th e management platform to track compliance state consistently for the physical device re gardless of which MAC address it presents. Use Case 3: VPN-B a sed Posture Assessment When a device connects via VPN, the VPN client software sends a device -unique identifier as a RADIUS attribute in the authentication request. The NAC server extracts this identifier and correlates it with an existing PDID, ensuring that compliance status persists across VPN reconnections with different MAC addresses. Use Case 4: Non-VPN Postur e Assessment For devices on the local network undergoing posture assessment without VP N, the compliance agent communicates its de vi ce identifier t hrough the authentication exchange. The corr elation and PDID ass ignment f ollow the same pattern as the VPN case. Use Case 5: Guest A cc ess Guest access presents the most challenging scenario for persistent identity, as guest devices typically do not have certificates, device management enrollment, or agents. Self-Registere d an d Sponsored Guests: The guest's register ed username o r sponsor -assigned credential provides a partial id entity anchor. While not device -specific, it enables correlation acro ss sessions f o r the same guest ident ity. The framework generates an PDID upon first guest authent ication and correlates s ub sequent auth entications via the guest credential. Hotspot (O pen) Acce ss : In purely open hotspot scenarios where no authentication occurs, MAC is the only available identifier. This use case has no reliable correlation path under MAC randomization. The framework acknowledges this limitation and does not attempt c orrelation for unauthenticated hotspot access. Emerging protocols such as OpenRoaming [26] may provide identity signa ls for t his use case in the future. Use Case 6: IoT Device P rofiling IoT devices (pr inters, medical devices, building automation sy stems, cameras) typically use MAB authentication without 802.1X credentials. Many IoT devices do not r andomize MAC addre sses (embedded systems with fix ed firmware), but some newer IoT platforms are beginning to impl ement randomization. For IoT devices, device profiling is the primary identity corr elation mechanism. T he framework extend s the device profiling subsystem to perform cross-s ource correlation: 20. RADIUS authentication event: Captures the MAC address and any RADIUS attributes during MAB authentication. 21. DHCP observation: Captures DHCP fingerprin t, hostname, and vendor class when the device obtains an IP address. 22. Additional network observations: HTTP User -Agent, S NMP, DNS, and NetFlow data contribute additional attributes. The cha lleng e arises because these observation s occur at different tim es and may c apture dif ferent MAC addresses for the same device. The framework addresses this b y correlating observations that share common network context (such as originating from the same access port within a time window), merging the data into a single PDID record. [IoT D evice] |--- (MAC_1) --- > RAD IUS MAB --- > [NAC Server] -- > Create PDID_1 |--- (MAC_1) --- > DHC P ---------> [NAC Server] -- > Merge with PDID_1 (same MAC) | [Device reconnects with randomized MAC] | |--- (MAC_2) --- > RAD IUS MAB --- > [NAC Server] -- > New MAC, check device profile |--- (MAC_2) --- > DHC P ---------> [NAC Server] -- > DHCP fingerprint matches | PDID_1, merge Fig. 4: IoT device identity correlation across MAC changes. G. O UI- Based Classification Impact Traditional device profiling relies heavily on the OUI (fir st 24 bits of MAC address) to identify the device manufacturer. When MAC addresses are randomized, the locall y-administered bit is s et and the OUI is meaningless -- it no longer corr esponds to any manufac tur er. The framework addresses this by: 23. De -prior itizing OUI in classification: For devices with locally -administered MAC addresses, behavioral attributes (DHCP options, User -Agent strings) are gi ven higher weight than OUI-based matching. 24. Preserving OUI data when available: For PDID r ecords that include historical data from a non - randomized MAC (e.g., the device once connected with its real MAC), the OUI infor mation is retained and ass o ciated with the PDID. 25. Machine learning-assisted c l assification: For device s presenting only randomi zed MAC s, ML -based flow classification using network traffic patterns supplements traditional attr ibute -based profiling. H. Duplicate PDID Prevention In high-thr oughput enterprise environments, multiple authentication reques ts for the same device may arrive concurrently at the NAC server -- for example, when a d evice simultaneously connects to Wi-Fi and initiates a VPN tunnel, or when a failover event causes rapid re-authentication across multiple policy servers. Without explicit coordination, concurrent pr ocess ing can re sult in duplicate PDIDs being generated for the same device , as two processing thread s may simultaneously deter mine that no existing PDID matches and independently create new ones. The framework addresses this through concurrency controls: 26. Serialization: Before generating a new PDID, concurrent r equests for the same device identity are serialized to prevent duplicates. 27. Verification: Af ter serialization, the system re -checks the identi ty store to confirm no PDID was created by a concurrent request. 28. Timeout: Exclusive handles expire after a configurable tim eout to prevent deadlocks. 29. Distributed coordination: I n multi-server deployments, the serialization mechanis m extend s across the server cluster to ensure consistency. I. Migration and Backward Compatibili ty A critical practical concern is the migration path for existing de ployments. Organizations may have millions of device records keyed by MAC address, with years of accumulated profilin g data, policy ass ignments, and compliance history. The framework supports gradual migration: 30. Pre-existing devices: When a device that existed in the system before P DID support connects for the first time after t he upgrade, a PDID is generated and a ll histor ical data is preserved. 31. Mixed-mode operation: The system supports simultaneous MA C -based and PDID-based identification during the migration per iod. 32. Static entries: For devices with statically configured MAC addr esses, PDID assignment occurs upon the first authentication event. 33. Replication: PDID assignments are synchronized across all serv ers in the deployment, ensuring consistent identity in distributed environments. V. Implem ent ation Considerations A. Reference Architecture An implementation of this framework r equires the following components : 34. RADIUS Authentication Server: E xtended to implement the persistent identity correlation algorithm and include the persiste nt d evice identifier i n Access -Accept messages. 35. Persistent Identity Stor e: A data store for maintaining persistent device identifiers and associated device attributes. 36. Device Profiling S ubsystem: Enhanced to correlate device a ttr i butes using PDIDs as the primary key rather than MAC addresses . 37. Device Management Integration: Interf ace for querying enrolled device identifiers from device management platforms for PDI D correlation. 38. Administration Int erface: APIs for enabling/disabling the framework, configuring corr elation parameters, and managing PDID lifecycle. B. Configuration Management The framework should provide administrative controls for: • Feature toggle : Enable/disable the G UID-based identity sys te m to support phased rollout. • Correlation source priorities: Configure which ident ity sourc es (cert ificate, device management, user, agent, device prof ilin g) are used and in what order. • PDID lifecyc l e policies: De fine retention periods, automatic cleanup of stale PDIDs, and maxim u m MAC addresses per PDID. • Concurrency settings: Tune parameters for high-throughput auth entication environments. C. Performance Considerations The PDID correlation adds processing overhead to each authentication r equest. Key pe rf ormance considerations include: • Lookup latency: The persis tent identit y store must support efficient looku ps across multiple identit y dimensions to minim iz e auth entication latency. • External query latency: Qu eries to external platform s may add n etwork round -trip t ime. Caching strategies can mitigate this overhead. • Concurrency overhead: Under high aut hentication loads, duplicate prevention mechanisms should be scoped narrowly to minimize contentio n. D. Security Considerations The PDID itself is a security-relevant identifier. The following protections should be applied: • GUID generation: PDIDs must be generated using a cryptographically secure r andom numbe r generator (CSPRNG) t o prevent prediction or enumeration. • Transport sec urit y: The RADIUS att ribute carrying th e PDI D should b e transmitted over encrypted RADIUS (RadSec/TLS) to ensure confidentiality. • Access control: Administrative access to the persistent identit y store mus t b e restricted and audited, as it contains the device identity records used f or c ompliance and security decisions. • Privacy: The PDID provides a persistent identity, wh ich introduces a privacy consider atio n. Organiz ations s hou ld establish dat a retention policies f or PDIDs and provide mechanisms for PDID deletion when a device is decommissioned or a user exercises data deletion rights. VI. Evalua t ion and Analysis A. Identity Correlation Effectiveness Table II analyzes the expected identity correlation success rate f or each use case based on the ava il able identity sources. Use Case Primary Correlation Correlation Confidence MAC Change Res ilience BYOD (Certificate) Certificate Identity Very High (>99%) Full MDM -Managed Manage ment Identifier Very High (>99%) Full VPN Posture Agent Identifier High (>95%) Full Non-VPN Posture Agent Identifier High (>95%) Full Guest (Regis tered) Username Medium (>80%) Partial (per -user) Guest (Hotspot) None None None IoT ( Fixed M AC) MAC Very High N/A (no randomization) IoT ( Ra ndomized) Device Profiling Medium (>75%) Partial Table II: Identity correlation effectiveness by use case. The framework achieves very high correlation confidence for the use cases that matter most in r egulated environments: BYOD, managed, and posture -as sessed devices. These are precisely the device categories subject to HIPAA, FISMA, and PCI-DSS requirements. B. License Count Accuracy Without the framework, a single device using per -conne ction MAC randomization can generate N device records over N connections, inflating the license count by a factor of up to N. With the framework, all N connections are c orr elated to a single PDID, yielding an accurat e count of 1. In a deployment with D devices, each averaging C connections over the measurement period, the license count comparison is: • Without framework: Up to D × C unique device records • With framework: D device records (one per physical device) For a healthcare organization with 50,000 devices averaging 10 connections per wee k, thi s represent s a potential reduction from 500,000 spurious device records to the corr ect count of 50,000 -- a 10x improvement in license count accuracy. C. Device Profile Data Integrity The pers ist ent identity store prevents device attrib ute fragmentation by ensuring that attribut es from all network observations -- regardles s of which MAC addres s was captured -- are merged into a single, complete device profile. This is particularly important for device c lassification accuracy, a s classification rules may depend on attributes from multiple sources (e.g., a device must have both a specific DHCP fingerprint AND a spec ific HTTP User-Agent to be classified as a particular medical device mod el). D. Concurrency Performance The duplicate PDID prevention mechanism introduces a seriali zation point for concurrent authentications of the same device. In practice, this serialization applies only to the narrow window of new PDI D generation (not to lookups of existing PDIDs) and affects only the specific MAC address being processed. Under normal operation with pr edominantly returning devices (PDID already as signed), the seriali zation mechanism is not engaged and the correlation path is fully parall el. Contention becomes relevant only during: 39. Initial deployment ( all devices are ne w) 40. Mass re-authentication events (e.g., network-wide re-key) 41. Devices that aggressively rotate MAC addresses (per-connection randomization) A configurable timeout provides an upper bound on serialization delay, ensuring correctnes s while minimizing processing overhead. E. Regulatory Compliance Analysis Table III maps the framework's capabilities to specific regulato ry requir ements. Regulation Requirement How Framework Addresse s HIPAA §164.312(a) Access control per device PDID provides persistent de vice identity for access control policies HIPAA §164.312(b) Audit controls PDID enables continuous device-l eve l audit trails across MAC changes FISMA/800-53 CM-8 Component inventory PDID-based inventory accurately counts physical devic es FISMA/800-53 SI-4 Continuous monitoring PDID enables uninterrupted device monitoring across reconnec tions PCI-DSS 1.2 Network segmenta tion PDID-based policy maintains s egment boundaries regardless of MAC NIST 800- 207 Per-r eque st device verification PDID provides the persiste nt identity required for Zero Tr ust Table III: Regulatory compliance mapping. VII. Discuss ion A. Limitations Unauthent icated access: The f ra mewor k cann ot assign PDIDs to devices that n ever authenticat e (open hot spot, purely pass ive network access). This is an in herent l imitation: without an identity asse rtion from the device, persistent ident ification requires adversarial fingerprint ing, which t his framework deliberately avoids. Profile-based corre lat ion accuracy: For IoT devices relying solely on device -profiling-based correlation, the accuracy depends on the distin ctiveness of t h e device's behavioral f ingerprint . In environments with many identical IoT devices (e.g., hundred s of th e same medical pump model), behavioral fingerprints may not be sufficiently uniqu e for r eliable correlation. Identity store growth: In large deployments with aggressive MAC randomization , the number of MAC addresses associated with each PDID can grow significantly. Implementations should define retention pol icies and prune stale associations. Inter-vendor interoperabilit y: Broader adoption would benef it from a standardiz ed RADIUS attribu te for pers istent d evice identity t hrough an IET F stan dards -t rack RFC, enabling multi-vendor interoperabilit y. B. Comparison with IEEE 802 .11bh IEEE 802.11bh-2024 and this fr amework address c omplementa ry layers of the MAC randomization problem. 802.11bh provides Layer 2 session continuity, ensuring that network services dependent on the MAC s ublay er continue to function. Our framework provi des L ayer 3+ identity continuity, ensuring that AAA, profiling, and policy enfor cement continue to function. A complete solution for enterprise networks benefits from both: 802.11bh f or link-layer stability and GUID- based identity for authentication and authorization. C. Toward Standardization The GUID distribution mechanism described in this paper could be form alized as a n IE TF standards -track proposal. A new sta nd ard RADIUS attr ibute for persistent device identity would enable multi -vendor interoperability and encourage consistent implementation across the NAC ecosystem. The IETF RADEX T working group and the MADINAS working group ar e both appropriate venues for this standardization effort. D. Future Directions Several extensions to the framework merit furth er investigation: 42. Machine learning-enhanced correlation: Using ML models trained on device behavioral patterns to improve device-profiling- based correlation accuracy for IoT devices . 43. Privacy-pr eserving analytics: T echniqu es such as differential privacy applied to PDID -based analytics to prevent device tracking beyond the network boundary. 44. Cross-domain identity federation: Extending the G UID framework to support device identity portability across organizational boundaries, enabling scenarios such as hospital - to -hospital device roaming. 45. Blockchain-anchored device identity: Using distributed ledger t echnology to provide tamper-evident device identity records for high-assurance environments. VIII. Conclusion MAC address randomization represents a fundamental shift in network identity that challenges two decades of NAC architecture. Rather than treating this as a problem to b e defeated, this paper presents a framework that cooperates with MAC randomization by establishing a persistent device identity layer through standard RADIUS protocol mechanisms. The GUID-based identity model, implemented through a RADIUS attribute extension and supported by a multi-source correlation algorit hm, provides reliable device identification across s ix major enterprise use cases. The fr amework maintains regulatory compliance f or healthcare (HIPAA), f ederal (FISMA), financial (PCI-DS S), and educa tional environments while preserving the privacy benefits that MAC randomization was des ign ed to provide. The framework's practical viability is demonstrated through its comprehensive treatment of real -wor ld challenges inc luding con curr ent authentication handling, legacy migration, and I oT device c orr elation. By building on existing RADIUS infrastructur e and requiring no client -side modifications, the framework can be adopted incrementally in enterprise environments of any scale. As MAC randomiz ation becomes increasingly aggre ssive -- with per-connection rotation now default on major platfor ms -- the need for a sta ndards-based persis tent ide ntity mechanism becomes critical. We encourage the community to pursue formalization of a standard RADIUS att ribute for persistent device identity through the IE TF standards proces s, enabling consistent multi-vendor implementation across the NAC ecos y stem and advancing the state of the art in privacy-respe cting network acc ess control. References [1] IEEE, "IEEE Standard for Local and Metropolitan Area Networks — Port - Based Network Access Control," IEEE Std 802.1X -2020, 2020. [2] Google, "MAC Randomization Behavior," Android Developers Do cumentation, 2023. [Online]. Available: https://source.android.com/docs/core/connect/wifi- mac - randomization -behavior [3] Apple, "Use private Wi - Fi addresses on Apple devices," Apple Support, 2024. [Online]. Available: https://support.apple.com/en-us/102509 [4] Microsoft, "MAC address randomization in Windows," Microsoft Learn, 2024. [Online]. Available: https://learn.microsoft.com/en-us/windows/privacy/mac- address - randomization [5] Cisco, "Cisco Annual Internet Report (2018 -2023)," Cisco White Paper, 2020. [6] Wi - Fi Alliance, "Wi - Fi Alliance Position on MAC Address Ra ndomization," 2023. [7] U.S. Department of Health and Human Services, "HIPAA Security Rule," 45 CFR Part 164, Subpart C. [8] National Institute of Standards and Technology, "Security and Priv acy Controls for Information Systems and Organizations," NIST SP 800 -53 Rev. 5, 2020. [9] J. Zuniga, C. Bernardos, and A. Andersdotter, "Randomized and C hanging Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases," RFC 9797, Internet Engineering Task Force, June 2025. [10] IEEE, "IEEE Standard for Information Technology — Telecommunications and Information Exchange between Systems — Local and Metropolitan Area Networks — Specific Requirements — Part 11: Wireless LAN MAC and PHY Specifications — Amendment: Randomized and Changing MAC Addresses," IEEE 802.11bh -2024, 2024. [11] J. Martin, T. Mayberry, C. Donahue, L. Foppe, L. Brown, C. Riggins, E.C. Rye, and D. Brown, "A Study of MAC Address Randomization in Mobile Devices and When It Fails," Proc. Privacy Enhancing Technologies, vol. 2017, no. 4, pp. 365-383, 2017. [12] [Author names], "Bleach: From WiFi probe - request signatures to MAC association," Journal of Network and Computer Applications, Elsevier, 2024. [13] IEEE, "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)," IEEE Std 802 -2014, 2014. [14] IEEE, "IEEE Standard for Local and Metropolitan Area Networks : Overview and Architecture," IEEE Std 802 - 2014, Section 8. [15] Apple, "macOS Sequoia Release Notes — Privacy Features," Apple Developer Documentation, 2024. [16] NetworkManager Project, "MAC Address Randomization," GNO ME Developer Documentation, 2023. [17] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)," RFC 2865, Internet Engineering Task Force, June 2000. [18] M. Miettinen, S. Marchal, I. Hafeez, N. Asokan, A. - R. Sadeghi, and S. Tarkoma, "IoT SENTINEL: Automated Device - Type Identification for Security Enforcement in IoT," in Proc. IEEE 37th Int. Conf. Distributed Computing Systems (ICDCS), 2017, pp. 2177 -2184. [19] C. Rigney, "RADIUS Accounting," RFC 2866, Internet Engineeri ng Task Force, June 2000. [20] PCI Security Standards Council, "Payment Card Industry Data Security Standard (PCI DSS) v4.0," March 2022. [21] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, "Zero Trust Architecture," NIST SP 800 -207, National Institute of Standards and Technology, August 2020. [22] IETF, "MAC Address Device Identification for Network and App lication Services (MADINAS) Working Group," 2023. [Online]. Available: https://datatracker.ietf.org/wg/madinas/about/ [23] M. Vanhoef, C. Matte, M. Cunche, L. Cardoso, and F. Piessens, "Why MAC Address Randomization is not Enough: An Analysis of Wi - Fi Network Discovery Mechanisms," in Proc. 11th A CM Asia Conf. Computer and Communications Security (ASIACCS), 2016, pp. 413 -424. [24] S. Frankel, B. Eydt, L. Owens, and K. Scarfone, "Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i," NIST SP 800 -97, National Institute of Standards and Technology, 2007. [25] P. Leach, M. Mealling, and R. Salz, "A Universally Unique IDent ifier (UUID) URN Namespace," RFC 4122, Internet Engineering Task Force, July 2005. [26] Wireless Broadband Alliance, "OpenRoaming," 2023. [Online]. Available: https://wballiance.com/openroaming/ Disclosure of AI Use: The author used AI-ass ist ed tools for drafting and language editing of this manuscr ipt. A ll technical concepts, architectural de signs, solution frameworks, and evaluations presented in this paper ar e th e original intellectual contributions of the aut hor, develope d th rough years of hands -on engineering w o rk on network access control systems. The author reviewed, edited, and verified all content and takes full responsibility for the accuracy and integrity of this publication. T his disclosure is made in accordance with IE EE 's policy on the use of AI-generated text in scholarly publications.