What is a one sentence summary of your feature request?
Add support for LSASS Guardian and Process Guardian exceptions to match on attributes beyond process name, including executable path, file hash, and signing certificate.
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
Today, Process Guardian exceptions can only be filtered by process name. This creates a gap when legitimate system activity is reported under a broad process identity such as System, especially in cases where third-party security or endpoint drivers are interacting with LSASS in an expected way.
In these scenarios, the current exception model is too coarse. Allow-listing System by name alone is broader than many customers are willing to accept, because it does not distinguish between trusted, known activity and potentially suspicious activity that presents under the same process name. This makes it difficult to tune LSASS Guardian safely and confidently in high-security environments.
The requested enhancement is to extend exception criteria beyond process name alone, so administrators can create more precise allow-list entries using one or more of the following:
Executable directory or full path
File hash
Program signing certificate or publisher
This would let customers suppress known-good activity with much tighter scope, reduce false positives, and avoid creating broad exceptions that may weaken the value of the detection. It would also improve customer confidence when reviewing LSASS-related alerts, especially when the source activity originates from endpoint protection, EDR, or other kernel or driver-based tooling.
How do you currently solve the challenges you have by not having this feature?
Today, the only available workaround is to create a process-name-based exception, such as allow-listing System for the LSASS Guardian policy, after separate validation with the third-party vendor. This is not ideal because the exception is broader than desired and does not provide enough control to limit the allow-list entry to a specific trusted binary, path, or signed component.