Strange 25H2 issue causing NTLM fallback on 802.1X network

I am seeing an odd issue that I've been banging my head against all day, curious if anyone else has seen 802.1X behavior changes in Windows 11 25H2 compared to 23H2.

On any 802.1X enabled switch port, Windows 11 25H2 is experiencing an odd partial network interruption at the moment GPOs apply, trying to fall back to NTLM (disabled in our domain with few exceptions) and failing to apply GPOs. This is the less visible of two symptoms, as GPO retrieval at boot failing is invisible to the user and our background refresh interval is short enough computers still get policy in a timely manner, but I'd still like to solve it.

The other symptom is that when a folder redirection user signs in less than a minute after bootup, they also get an NTLM blocked error and their desktop does not appear right away (it appears if they click refresh, or after a few minutes automatically). This symptom does not manifest if the user waits a full minute at the logon screen after rebooting their computer.

NOTE: We use DFS-N in our folder redirection path. Since DFS is also used in Group Policy downloads, and I am seeing Kerberos errors for our bare domain name (e.g. CIFS/ourdomain.org@ourdomain.org, not CIFS/dc1.ourdomain.org….) – I am thinking DFS isn't playing nice in close timing proximity to some network state change on the client caused by an EAP request.

I am seeing in the NetworkProfile event logs that there are a few "state change" events even after the network went DomainAuthenticated.

The really odd parts are:

• All the communication that is failing works if tried again a second after you reach the desktop.
• This is 100% not a network connectivity issue, I can SCCM Remote Control the computer at the login screen as soon as it boots and control it through the entire logon process and see this error remotely without being kicked off.
• Tried it with the fallback/not authed role on the switch set to the same VLAN and allow all traffic (basically made 802.1X optional) and took the 802.1X profile off the client and turned off the wired autoconfig service… issue still exists.
• Issue only goes away if I turn off 802.1X completely on the switch port so I think the issue is being triggered any time the client can see a EAPOL request regardless of client configuration or any actual enforcement on the switch.

To clarify – we know nothing is being blocked on the network side, this is not a new/broken 802.1X deployment, but a scenario that has been in place for some time from Windows 10 22H2 to Windows 11 23H2, and is having transient issues right after bootup only on 25H2. (24H2 may or may not be affected, it was skipped in our environment).

I see issues in the Security-Kerberos\Operational event log where SPN is not found for cifs/ourdomain.org@OURDOMAIN.ORG – but DFS should not be making kerb requests for the bare domain name, it should be resolving first. So I am guessing some transient network issue prevents it resolving to a specific DC, so it tries anyway with the bare domain name, which of course doesn't have an SPN to a specific computer and Kerberos fails.

If I let it fall back to NTLM, by putting it on the exceptions list in our GPO that blocks NTLM, it works. But Kerberos is not an issue on 23H2, not an issue on some models of NIC period, and not an issue on a non-802.1X port. This doesn't make sense.