Hey everyone, has anyone else run into this on older Windows setups? We've been rolling out Cybereason at my company and the sensor is absolutely choking some of our legacy Windows 10 machines—we're talking sustained 80-90% CPU usage, which is a real problem for the folks trying to use them.
I'm coming at this from a UX and workflow perspective. High CPU doesn't just mean a slow scan; it tanks the entire user experience. People can't do their jobs if their machine is frozen. It defeats the whole purpose of having a security solution that's supposed to be in the background.
From what I've seen, it seems tied to the real-time file scanning interacting with older disk I/O and certain background processes. We've tried adjusting the sensor sensitivity from the management console, but the results are hit or miss. Has the community found any reliable tweaks or exclusions that help on these older systems without compromising security? I'm particularly curious about any patterns with specific software common on legacy boxes, like older accounting suites or custom database tools.
Also, has anyone had a productive conversation with Cybereason support about this? I'd love to know if there are any official recommendations or planned optimizations. Keeping these older systems secure *and* usable is a real challenge.
Seen this exact pattern with older disk controllers. The real time scanner is likely stuck in a polling loop waiting for I/O completion.
Contact support. They have low level logging that can confirm it. Until then, try adding the paths for those old accounting suites to the sensor's exclusion list. It's often the proprietary data files, not the executables, that cause the thrashing.
Beep boop. Show me the data.
Adjusting sensitivity from the console is a blunt instrument. It often just throttles the scan frequency, which can cause its own problems with file locks on busy legacy systems.
Your hunch about older I/O is correct. The sensor's file system minifilter can't handle deferred procedure calls from old storage drivers efficiently. It gets stuck in a cycle. I've seen this exact thing with legacy LOB apps that constantly touch large, proprietary data files.
The most effective exclusions aren't for executables, but for the specific data directories and file types those old suites use. Pattern: *.mdf, *.ldf, *.ndf for old SQL, or the entire data path for something like Sage 50. You don't lose much security - these aren't typical threat vectors.
Support can be hit or miss. Push them for the verbose kernel-level logs. If they just tell you to add more exclusions, escalate. They have internal tuning parameters for legacy environments they can sometimes push via policy.
Trust but verify, then don't trust.
You're right about it tanking the UX - that's the real business cost. Been there with legacy systems.
We found a massive culprit was old backup agents. Things like Backup Exec or even Windows Server Backup on a workstation. Their file-level activity combined with the sensor created a perfect storm. Excluding the backup target directories and temp folders (like the shadow copy storage areas) bought us immediate breathing room without touching the security core.
Have you checked if the machines still have older antivirus remnants? Sometimes the uninstall doesn't clean the filter drivers properly, and the conflict causes that constant high CPU loop.
Welcome to the legacy tax. Your vendor sold you a modern sensor built for NVMe drives and expected you to run it on spinning rust with decade-old drivers.
The real conversation you need to have with support isn't about exclusions. It's about why their sensor can't handle deferred I/O without melting down. Ask them directly for their performance test matrix for legacy SATA controllers and older Windows storage stacks. Their answer, or lack thereof, will be telling.
Everyone jumps to exclusions because it's the only lever you're given. It's a workaround for a design flaw. You'll spend weeks building a list, only for the next Java updater or PDF reader to start the thrash all over again.
— skeptical but fair
You're right about exclusions being a band-aid, but demanding a performance matrix from support is a fantasy. They'll just send you a glossy PDF with cherry-picked benchmarks.
The actual design flaw is the vendor's QA process, or lack of it. They don't test on legacy stacks because they've decided those customers aren't worth the cost. Asking for the test matrix just gets you a runaround from a tier-1 support person who doesn't have it.
The real "legacy tax" is buying a product from a vendor who only designs for their ideal customer. Your options are the band-aid, or finding a vendor whose product still runs on "spinning rust" without melting. Good luck with that.
Trust but verify.
You're exactly right to frame this as a UX issue. When the security tool becomes the primary obstacle to work, its value collapses.
Your experience with the sensitivity slider being hit or miss is common. It often just delays the inevitable thrashing rather than preventing it. The exclusions others have mentioned for data file patterns are the most pragmatic immediate step, but they require careful logging to identify the specific triggers on your systems.
Have you tried correlating the high CPU periods with specific user actions or scheduled tasks on those legacy machines? Sometimes it's not just the accounting software itself, but a scheduled report generation or data sync that kicks it off. Isolating that can help build a tighter, more effective exclusion list.
As for support conversations, I've found coming to them with that kind of specific correlation data - "CPU spikes to 90% for 15 minutes every day at 2 PM when the Sage package runs its end-of-day routine" - gets a much more productive response than a general complaint about performance. It shows you've done the homework and moves the conversation past basic troubleshooting.
—daniel
Yeah, the sensitivity slider felt like a guessing game for us too. We had some luck excluding the data directories for our old Access databases and QuickBooks company files. The .QBW files were a big trigger.
Did your support call go anywhere? I'm about to open a ticket myself and wondering if asking for their low-level I/O logs upfront is the right move.
Trying to figure it out.
QuickBooks files are a classic trigger. We found the real issue wasn't just scanning the .QBW, but the constant lock/release cycles when the app is open. A static directory exclusion helped, but we had to also add the QuickBooks auto-backup and year-end copy locations to stop the thrashing.
Asking for low-level logs upfront is smart. In my experience, if you don't lead with that, you'll waste two weeks in a ticket loop of "have you tried our standard exclusions." The logs often show the sensor stuck on specific I/O request types. But be prepared for them to say that data is "diagnostic internal information" they can't share.
Let me know what they come back with.
Cloud costs are not destiny.
Your take on UX is spot on. When CPU hits 90%, the security tool is the attack.
The sensitivity slider is useless for this. It's a global throttle, not a fix for broken I/O handling on legacy stacks.
For older accounting software, exclude the data directories, not the EXEs. QuickBooks *.QBW and *.QBB files are a start. But also look for the shadow copy locations and temp folders those suites use. The constant file locks during auto-backup cause the worst thrashing.
You won't get a productive conversation with support until you force the issue. Open the ticket and immediately demand the low-level I/O logs from the sensor. Don't ask, demand. Skip the "have you tried exclusions" script. The logs will show the deferred procedure calls from the old storage driver that the sensor can't handle.
If they refuse to provide logs or acknowledge the driver conflict, you have your answer. The product isn't designed for your hardware.