@DTS Engineer - Thank you for this! Hoping this is the last of this thread.

@DTS Engineer - Any update on this being fixed in 26.6? I see that the 26.6 Developer Beta has been released.

@DTS Engineer - Any update on these recent feedbacks & cases, with the issue still being known?

Uploaded another kernel panic file to my case as I had another crash today.

@DTS Engineer - Case/Bug Number: FB22787524

@DTS Engineer - I might have spoke too soon, as today I had a Kernel Panic crash after sleep and it is still happening after day 3 of being on 26.5. I can send the .panic file if needed. I ran it through Claude and the error is definitely related to a network monitoring tool. In my use case: Root Cause: Kernel panic caused by a Kernel Tag Check Fault (MTE violation) in the SentinelOne Network Monitor Extension (com.sentinelone.network-monitori, pid 725) while performing packet inspection/filtering via the NEFilterExtensionProviderContext on CPU core 5. The crash occurred shortly after the MacBook Pro M5 Pro woke from sleep. The ESR value (0x0000000096000011) confirms an ARM data abort due to a memory tag mismatch, indicating a memory safety bug (likely use-after-free or stale pointer) in the SentinelOne network extension's kernel code path. This is consistent with the previously documented N1 wireless chip / Cisco Secure Client kernel panic pattern on M5 Pro devices.

Thank you @DTS Engineer for being supportive and assiting everyone in this thread. So far so good after updating to 26.5. We will be able to deploy our M5 Pros at an enterprise level again.

We are experiencing the same issue in our enterprise environment. Our MacBook Pro M5 Pro test unit running macOS 26.4.1 (25E253) is intermittently kernel panicking, primarily after sleep/wake transitions. The panicked process is com.cisco.anyconnect.macos.acsoc — the Cisco Secure Client Network Extension content filter. The panic type is a Kernel Tag Check Fault (ARM MTE tag mismatch), and the backtrace points to the NEFilterExtensionProviderContext dispatch queue during packet processing. What strengthens the N1 chip correlation on our end is that we are also validating the MacBook Air M5 in parallel — same macOS 26.4.1, same Cisco Secure Client, same SentinelOne EDR, same network extension stack — and we have observed zero kernel panics on the Air. The Air does not have the N1 wireless chip. Our panic logs on the M5 Pro contain DART references to dart-apcie0 and Centauri wireless silicon (AppleCentauriAlpha, AppleCentauriBeta, AppleCentauriControl), which are not present on the Air. We have placed a deployment hold on all MacBook Pro M5 Pro hardware in our environment until this is resolved. MacBook Air M5 deployment is proceeding as planned with no issues. Curious on timing — is there any indication whether a fix will make it into 26.5 GA, or are we looking at a supplemental 26.4.x update? Any visibility would help us plan our hardware rollout accordingly.