Persistent MSM Security Rekey Loop on Intel Wi-Fi 7 Adapters (Intel(R) Wi-Fi 7 BE200 320MHz)

[BlazeX]

System Configuration & Environment Information

• Wireless Network Adapter: Intel(R) Wi-Fi 7 BE200 320MHz
• Operating System: Microsoft Windows 11 (64-bit)
• Local Infrastructure Environment: Legacy Wi-Fi 5 (802.11ac) Access Point broadcasting an explicit hybrid WPA-PSK/WPA2-PSK Mixed Mode profile beacon flag.

---

Description of the Issue & Log Sequence

When operating on a network configured for legacy WPA2 parameters, the system intermittently triggers an aggressive, sub-second disconnection and reconnection cascade. The device does not log an orderly administrative link-layer disconnection milestone (such as Event ID 8003). Instead, it falls into a rapid, continuous encryption negotiation trap recorded chronologically in the Microsoft-Windows-WLAN-AutoConfig/Operational log as follows:

1. Event ID 11004 (MsmSecurity): Wireless security stopped. (Forced session termination).
2. Event ID 11010 (MsmSecurity): Wireless security started. Inside the raw text parameters payload, the metadata fields indicate: Authentication: WPA3-Personal and Encryption: AES-GCMP-256, despite the host OS profiles being manually hardcoded to restrict operation to legacy fallback modes.
3. Event ID 11005 (MsmSecurity): Wireless security succeeded. Microsecond session re-establishment after dropping down to an administrative WPA2-Personal (AES-CCMP) link layer state under Event ID 8001.

---

Core Cause: The Intermittent 2.5-Day Loop Trigger Mechanism

The core driver architecture exhibits an unyielding protocol elevation defect. When encountering a hybrid broadcast beacon or even a pure mobile hotspot network, the driver actively disregards manual OS network properties or Advanced Device Manager properties restrictions. The adapter initialization routine (Event 11000/11010) aggressively defaults to constructing a strict WPA3-Personal / AES-GCMP-256 session envelope structure.

The structural failure state does not trigger immediately upon initial authentication. The access point utilizes a standard Group Key (GTK) Update Interval set to an explicit hourly frequency (3600 seconds).

During initial iterations, the calculation mismatch between the router's legacy broadcast packet payload format and the adapter's active forced security profile state is masked. The Windows Network Stack relies on a background Temporal Key Retransmission Tolerance fallback buffer counter to silently absorb parsing anomalies without registering an infrastructure failure.

However, as the system continues to process these mismatched hourly transformations, unaligned cryptographic padding fragments continuously desynchronize the active tracking profile keys. After approximately 48 to 60 hours (2.5 days) of continuous runtime operation, it is assumed that the localized Interface Profile memory buffer cache experiences a terminal overflow condition. Once this internal memory threshold is breached, the fallback safety mechanisms collapse completely. The next sequential background key update causes a terminal authentication parsing fault, throwing the entire network interface into the rapid, persistent 11004 ➔ 11010 ➔ 11005 loop that causes immediate application timeouts and connection dropouts.

---

Actions and Fixes Attempted So Far (All Failed)

To isolate and resolve this issue, the following extensive troubleshooting steps were performed, all of which were eventually overridden by the driver/OS behavior:

1. Driver Isolation: Updated the network card to the latest generic standalone package payload release from Intel (Version 24.50.0.4).
2. Hardware Property Restrictions: Attempted to manually downgrade the wireless card properties via Device Manager by setting the Wireless Mode strictly to 802.11ac (Wi-Fi 5) and configuring the adapter to prefer the 5GHz band.
3. OS Profile Overrides: Completely wiped the profile cache using administrative terminal commands (netsh wlan delete profile), reset the network stack configurations via Windows Settings, and manually re-built a fresh, isolated network profile explicitly locked to WPA2-Personal via the Control Panel.
4. Router Configuration Testing: Accessing the router administration panel revealed a standard Group Key Update Interval of 3600 seconds.
   • Mixed-Mode Testing: The router was initially running on WPA-PSK/WPA2-PSK mixed mode.
   • Hard WPA2 Selection: Toggled the dropdown security type strictly to pure WPA2-PSK to eliminate mixed flags. Despite this router-side enforcement, the Intel driver continues to launch its initial connection handshakes (Event 11010) requesting WPA3-Personal frames, proving it is hallucinating/forcing the protocol regardless of router or hotspot limitations.
     
     
     Similar/related issue : BE200 trying to use WPA3 when WPA2 is selected 
     
     

[JeanetteC_Intel]

Hello BlazeX,

Thank you for reaching out to the Intel Community and for the incredibly detailed breakdown of the issue you've been experiencing. It's clear you've done a thorough job documenting the behavior and the steps you've already taken — that level of detail is genuinely helpful and makes it much easier to dig into what's happening.

To summarize what you've described: your Intel Wi-Fi 7 BE200 320MHz adapter is entering a persistent MSM Security Rekey Loop (Event IDs 11004 → 11010 → 11005) approximately every 2.5 days, and despite manually locking the OS profile to WPA2-Personal, resetting the network stack, updating to driver version 24.50.0.4, and even enforcing pure WPA2-PSK on the router side, the adapter continues to initiate WPA3-Personal / AES-GCMP-256 handshakes — overriding all manual restrictions. We understand this has been a challenging experience, and we want to help get this resolved.

To assist with further investigation, please check your email for our private message requesting additional information that may help. Be sure to check your inbox, as well as your spam and junk folders, as the message might have been directed there

Best regards,

JeanetteC.

Intel Customer Support Technician