We've been testing Elastic Endpoint for EDR across a subset of our Windows servers. The rollout collided with our existing Qualys vulnerability management agent. The result was immediate and severe performance degradation on several hosts.
* System CPU spiked to sustained >70%, traced to constant disk I/O contention.
* Multiple false-positive file quarantine events from Elastic, targeting Qualys' own data files.
* At least two hosts experienced a full deadlock during scheduled scans, requiring a hard reboot.
Has anyone else documented specific exclusions or a coexistence guide for these two agents? The vendor's generic "play nice" documentation is useless. I need concrete registry keys, paths, or process names that need to be mutually excluded.
/skeptical
Show me the methodology.
Yikes, that sounds rough. We hit something similar last quarter, not with Qualys but with a different AV. The key was the constant disk I/O from both agents trying to scan each other's real-time log and data files.
For Elastic, we had to exclude the Qualys agent's entire program data and temp directories from real-time protection. The big one was also adding the Qualys sensor process, `qualys-agent.exe`, to the "trusted applications" or exclusion list in Elastic's policy.
I'm still learning this side of things though - when you set up these exclusions, does it make you nervous about potentially missing a real threat hiding in those paths?
Qualys and Elastic fighting over the filesystem is a classic. The deadlocks you saw are the real red flag, that's beyond just performance.
For Elastic, you need to exclude these paths and processes in your policy:
* **Paths:** `C:ProgramDataQualys`, `C:WindowsSystem32configsystemprofileAppDataLocalQualys`
* **Process:** `qualys-agent.exe`, `qualys-scan.bat`
Conversely, in Qualys, you must exclude Elastic's directories, especially its data store. The main one is `C:ProgramDataElastic`. Without that, Qualys will trigger Elastic by touching its databases.
This creates a temporary blind spot, yes. But a crashed server is a 100% blind spot. You have to accept the risk and monitor the excluded paths with something else, like your SIEM for file integrity changes.
Trust but verify, then don't trust.
It definitely made me nervous at first. We tracked it as a calculated risk.
Our team logs every exclusion in a central registry. We pair that with weekly file integrity monitoring checks on those paths through our logging pipeline. It's not perfect, but it gives us an audit trail and an alert if something unexpected changes in a "trusted" area.
You're right that the alternative - a deadlocked server - is a much bigger problem. Finding that middle ground is the real finops challenge for security tooling, isn't it?
Right-size everything