Hey folks, I've been knee-deep in monitoring our endpoint performance across a few hundred machines since the Intercept X 15.2 rollout, and I'm seeing a pretty consistent pattern of elevated CPU usage from the `InterceptX` agent process. It's not a spike—it's more of a sustained 10-25% load on modern multi-core systems, which is enough to get our users complaining about fan noise and battery drain on laptops.
I've built a custom dashboard to pull metrics from our RMM, and the correlation with the update is clear. Before I go down the rabbit hole of building a workaround or a suppression script, I wanted to check if this is a widespread observation or something unique to our environment. A few specifics from my notes:
* The process in question is usually `InterceptX.exe` or `SophosUI.exe`, and it seems tied to real-time scanning and the behavioral analysis component.
* The load is persistent, not just during scans or updates.
* We're on the latest 15.2.5 MR-5 build. Rolling back to a pre-15.2 version (where possible) immediately resolves the issue.
* Our configuration is mostly out-of-the-box for the EDR features, with some custom exclusions for development tools.
Has anyone else run into this and found a reliable mitigation that doesn't involve disabling core protection features? I'm considering trying to tweak the scan sensitivity via policy or building a scheduled task to restart the service during non-hours, but I'd prefer a more elegant solution.
If you're seeing the same, could you share your setup (e.g., OS versions, other security layers in place, specific Intercept X modules enabled)? I'm happy to share the queries I used for our data pull if it helps others compare.
api first
api first
Yep, definitely seeing that here too. We pushed to about 150 laptops and the CPU charts in our Tableau server lit up.
I noticed something interesting in my query pulling the perf data - the load seems to correlate with specific processes being active, like when VS Code or Chrome has a lot of file handles open. It's like the behavioral engine is just working way harder. Makes me wonder if there's a logic loop in the new version's file watching.
Have you tried tweaking the real-time scan exclusions at all, or is that a no-go for your security policy?
Data is the new oil - but it's usually crude.
Your methodical approach to correlating the update with the performance hit is commendable, but I think we're focusing on the symptom rather than the underlying architectural decision. This pattern of "enhanced" EDR features consuming significantly more resources isn't unique to this vendor or update - it's an industry-wide shift.
The persistent 10-25% load you're measuring is essentially the tax for the newer, more aggressive behavioral heuristics. While rolling back resolves it, that's a temporary and increasingly untenable position. The real question isn't about tweaking exclusions or building suppression scripts; it's whether the security value of this constant, intensive monitoring justifies its operational cost for all workloads. For a developer's machine with high I/O, maybe not. For a finance workstation, perhaps.
We're accepting a design that assumes all CPU cycles are free. They're not, especially on mobile hardware. The pragmatic path might be accepting that a one-size-fits-all policy is broken and creating a tiered deployment based on user role and risk tolerance, even if it's messier to manage.
James K.
I've seen the same thing on our developer workstations. Your custom dashboard approach is smart. I built something similar to isolate the specific subsystem causing the load.
What I found, which might explain the persistent nature you're seeing, is that the CPU load is heavily tied to file system filter driver activity. It's not just process watching. When I instrumented a test machine, the spikes correlated directly with high file I/O operations, even from excluded processes. This suggests the new version may be inspecting metadata or relationships for every operation, not just the file content scans.
Have you looked at the `SophosFileScanner` driver's activity in Process Monitor? That's where the bulk of the cycles seem to be going in my traces.
Data > opinions