Recently, we are seeing a lot of issues in our 5+ year old Omada Network regarding frequent authentication challenges by the Captive Portal, evben though the default lifetime of authenticatioin is set at 3 years. Our analysis points to Mac Address Randomization to be the trigger for this. Following is our understanding is on this matter:
 

A randomized MAC address is distinguishable, if it has 2,6,A,E as the second character in the first Octet of the MAC Address. Android and IOS devices no longer show you the device's Mac, but a network administrator can see them at the switch/router side. 

MAC randomization is now enabled as default for user device privacy across all operating system. If user disables it entirely, Hardware MAC Address will be used as with legacy OS versions. Most users DO NOT  tinker with the default settings OF MAC Address randomization, mostly because of informed motive to do so. So the defaukst behavior will vbe the most common scenario seen.

Android 15
Scope: Network Specific User Configuration. The device uses a different Mac Address for each SSID it joins
Default: Enabled. The other option is Disabled (use Hardware MAC)
Lifetime of Randomized MAC: 
    Persistent (Default) - Once Mac randomized for network, it will stay same till either SSID forgotten, network settings are reset or device is factory reset
        Non-Persistent (Developer mode switchable option or firmware hard-coded) - Potentially *MAY* change every time you connect to the same network. There are finer rules based on hours elapsed since last seen, DHCP expiry, last seen timestamp, etc.
        
NOTE: Device never disconnects just to randomize MAC. Only after disconnection, and on reconnection the MAC randomization policy will come into effect

So the worst case scenario in normal usage is that the Android device's MAC will change (rotate) its randomized MAC address very time it connects to the same SSID network, but the most common case would be that the randomized MAC is stable.
        
        
IOS 18
Scope : Network Specific User Configuration (same as above)
Default: Enabled. But:
    (a) If network is having poorer than WPA2 security (Open, WEP), then it will rotate every 2 weeks by default. 
    (b) If the network is having WPA2 or better security, then device will use a FIXED Randiomized MAC Address.
    And you can change behavior to between (a), (b) and OFF (use hardware MAC address)
Lifetime of Randomized MAC: 
    Once Mac randomized for network, it will stay same 24 hours *even after either SSID is forgotten or network settings are reset  (difference from android), but after that change. It will anyways change if device is factory reset (same as android).
    
So the worst case scenario in normal usage is that device will change (rotate) its randomized MAC address every 2 weeks for open or weak security networks, but stay stable (not rotate) for secure (WPA2/WPA3 or better) networks

Windows 11
Scope: Network Specific User Configuration
Default: Disabled. The other option is enabled
Lifetime of Randomized MAC: Persistent.  Once Mac randomized for network, it will stay same till either SSID forgotten, network settings are reset or OS is reinstalled.

So the worst case scenario is that the randomized Mac is stable (not rotated) frequently. Its just not stable, if SSID is forgotten, OS is reinstalled, or network settings are reset which are abnormal scenarios.

Linux 6.x
Scope: Network or System Specific User Configuration (Distribution based Choice)
Default: Disabled. The other option is enabled
Lifetime of Randomized MAC: Per session (Changes every time you connect to the SSID) or per Network (stay same till SSID forgotten, network settings reset or OS reinstalled). This behavior again varies with Distribution and Network config tools used.
    
Its very hard to predict what will happen as linux users are usually depply aware of technical aspects and may tweak stuff more agressively than Windows users. So the worst is likely that the MAC changes every time user connects.

Impact on Omada Network Users
The entire Omada Captive Portal Authentication relies heavily on MAC Addresses of connecting devices. A device is identified by its MAC Address only, as the IP changes usually on a per session basis in most cases due to DHCP. So if this device MAC rotates due to any reason or configuration, the authentication will fail, and the portal will challenge the user to again key in his UserID-Password, Voucher-ID or perform SMS authentication. Long timeframes of authentication (SMS, Voucher, UserID) will not work, anymore. The trend seems to be towards more aggressive MAC randomization (in the interest of user privacy) or completely non-persistent MAC addresses. So expect the challenges to go up as their OS version gets upgraded.

The only way for users to fix this for their devices is to fallback to either Hardware Mac address use or no randomization OR if using randomization, decrease the persistence to network level i.e persistent (and not per session or semi-persistent). If they are hyper sensitive about privacy of their communications, they have to put up (and handle) with hassle of repetitive challenges to authenticate their identity.They can however maintain different policy for different networks. 


Any other solutions to this problem or better way of handling this situation.