From my own experience, I’d recommend double-checking whether all relevant binaries are fully covered under the Trusted Applications configuration. In a similar case, we observed that using file hash-based trust alone didn’t always prevent Elastic from interacting with processes—especially after application updates or when dynamically spawned processes were involved. Switching to the “Signature” method helped reduce friction significantly.
That said, even with a trusted application configured, it's not entirely clear to what extent Elastic Defend disengages. According to Elastic’s own documentation:
“Trusted applications... don’t monitor the application for threats, nor do they generate alerts, even if it behaves like malware. They might improve performance, but still generate process events for visualizations or internal use.”
You mention you “still observe significant performance degradation” on systems running resource-intensive applications. Could you elaborate on what “significant” means in your case? For example:
What are the average CPU and memory usage levels of the Elastic Agent, Elastic Endpoint, and Beats processes?
How does this compare to the resource usage of Sophos?
Do you observe any impact on the performance of the monitored applications themselves, such as CAD tools or compiler?
In my own testing with a different commercial EDR and Elastic Defend side-by-side, performance was mostly acceptable, though we did see isolated cases where Elastic related processes consumed up to 15% CPU, which is not negligible, especially on developer workstations.
I’ve also come across suggestions to disable process events in the Defend policy to reduce system load. While this may yield short term performance improvements, it comes at a high cost: it creates critical blind spots in your telemetry. Disabling process event collection undermines visibility into parent and child process chains, script execution, and lateral movement, which are core behaviors that many detections rely on. In essence, you are trading security depth for performance. That said, if your environment has compensating controls and you have accepted the residual risk, it might be worth trialing a configuration with process events disabled on specific endpoints.
Also when you create a diagnostics, the user-artifacts folder in the zip contains the endpoint-trustlist-windows-v1.
.\elastic-endpoint.exe diagnostics --log stdout --log-level debug; Start-Sleep -Seconds 2; $zip = Get-ChildItem "$env:WINDIR\TEMP\endpoint-diagnostics-*.zip" | Sort-Object LastWriteTime -Descending | Select-Object -First 1; $ts = Get-Date -Format "yyyyMMdd-HHmmss"; $destZip = Join-Path $HOME $zip.Name; Move-Item $zip.FullName $destZip -Force; Expand-Archive -Path $destZip -DestinationPath "$HOME\Diagnostics-$ts" -Force
When you tune and run
Add-Type -AssemblyName System.IO.Compression.FileSystem
$encodedFile = "$HOME\Diagnostics-<timestamp>\user-artifacts\endpoint-trustlist-windows-v1"
$decodedFile = "$HOME\trustlist-windows-decoded.json"
$inputStream = New-Object System.IO.FileStream($encodedFile, [System.IO.FileMode]::Open, [System.IO.FileAccess]::Read)
$null = $inputStream.ReadByte()
$null = $inputStream.ReadByte()
$deflateStream = New-Object System.IO.Compression.DeflateStream($inputStream, [System.IO.Compression.CompressionMode]::Decompress)
$memoryStream = New-Object System.IO.MemoryStream
$buffer = New-Object byte[] 4096
while (($read = $deflateStream.Read($buffer, 0, $buffer.Length)) -gt 0) {
$memoryStream.Write($buffer, 0, $read)
}
$deflateStream.Close()
$inputStream.Close()
[System.IO.File]::WriteAllBytes($decodedFile, $memoryStream.ToArray())
notepad $decodedFile
You can see the content of user-artifacts\endpoint-trustlist-windows-v1 in notepad and check if the trusted applications you configured are there. The script was provided by ChatGPT and worked for my test system. Test it on a nonproduction system first please. 
(There might be a better way to verify the existance of the correct Trusted Applications)