Skip to content

EPP Exclusions

Exclusions tell the SenseOn antimalware component to skip scanning certain files, directories, or processes. This page explains the available exclusion types, how each works internally, and guidance on choosing the right one for your situation.

💡 Where to configure exclusions: Exclusions are configured in Device Configuration under the Antimalware and Process Protection sections. They can be scoped to specific device segments. See Endpoint Protection for steps on creating segments and applying configuration. If those sections appear locked, Endpoint Protection has not been enabled for your organisation, so contact SenseOn to enable it.

Exclusion Types

Path Exclusions

Exclude files or directories from scanning by path. Supports both absolute paths and wildcard patterns using * (matches any sequence of characters, including across subdirectories) and ? (matches a single character). Matching is case-insensitive on Windows and macOS. UNC paths (e.g. \\server\share\path\*) are supported on Windows.

Examples: - C:\MyApp\data\*: excludes all files under that directory and its subdirectories - C:\MyApp\data\*.tmp: excludes all .tmp files under that directory and its subdirectories - \\server\share\builds\*: network path exclusion - ?:\*\MyApp.exe: excludes MyApp.exe in any folder on any drive - M:\*: excludes everything on the M: drive. Use whole-drive exclusions sparingly, since nothing on that drive will be scanned

⚠ Only exact file path matches avoid locking entirely. When an absolute file path matches exactly, the agent short-circuits before opening a file handle, so no locking occurs. When a wildcard pattern is used, there is a brief moment where the file may be locked while the agent pattern-matches the path against the exclusion list. For most workloads this is imperceptible, but for processes that delete or create large numbers of files rapidly it can cause transient lock contention.

If you cannot enumerate exact file paths, for example a software management tool that deletes dynamically named temporary files, use a process exclusion on that tool instead. Process exclusions bypass locking entirely at the driver level, regardless of which files the process accesses.

Environment Variables in Paths

Windows only. File path exclusions may use Windows environment variable tokens, which the agent expands before matching. Variables can be combined with * and ? wildcards in the same entry.

Examples: - %windir%\CCM\*: excludes everything under C:\Windows\CCM - %ProgramData%\MyApp\cache\* - %windir%\Temp\*.tmp - %ProgramFiles(x86)%\Common Files\MyVendor\* - %ProgramFiles%*\MyVendor\MyApp\*: the * straight after the variable covers both C:\Program Files and C:\Program Files (x86) in a single entry

⚠ Variables are expanded as the SYSTEM account, not as the signed-in user. The agent runs as a Windows service under NT AUTHORITY\SYSTEM, so a variable is resolved using that account's environment rather than the environment of whoever is logged on. Machine-wide variables are unaffected and behave as you would expect:

Variable Resolves correctly?
%windir%, %SystemRoot% Yes, machine-wide
%ProgramFiles%, %ProgramFiles(x86)% Yes, machine-wide
%ProgramData% Yes, machine-wide
%TEMP%, %TMP% No, resolves to the SYSTEM account's temp directory (typically C:\Windows\TEMP), not the user's
%USERPROFILE%, %HOMEPATH%, %APPDATA%, %LOCALAPPDATA% No, resolves inside the SYSTEM profile, not the user's

To exclude a per-user location, use a wildcard instead of a user-scoped variable. For example, to cover every user's local temp directory:

  • ❌ %TEMP%\*: only covers the SYSTEM account's temp directory
  • ✅ C:\Users\*\AppData\Local\Temp\*: covers every user profile stored under the default C:\Users location

Likewise use C:\Users\*\AppData\Roaming\MyApp\* rather than %APPDATA%\MyApp\*.

This assumes the default profile layout. A profile relocated to a different drive or path (a common enterprise policy), or a user's TEMP redirected elsewhere, will not be under C:\Users and needs its own literal path or wildcard to match the actual location in use.

⚠ Only real environment variables are expanded. The configuration field also accepts a number of Windows USMT tokens that look like environment variables but are not, including %CSIDL_SYSTEM%, %CSIDL_PROGRAM_FILES% and the rest of the %CSIDL_*% family, plus %SYSTEM32%, %SYSTEM16%, %PROFILESFOLDER%, %DEFAULTUSERPROFILE%, %SYSTEMPROFILE% and %USERSID%. These are accepted by the form but are never resolved, so an exclusion using one will silently match nothing. Use a literal path or a wildcard instead.

💡 An unresolved variable makes the exclusion inert, not broader. Expansion happens token by token: an unrecognised token like %USERSID% is left exactly as written, but any other, real environment variable in the same entry still expands normally around it. Since essentially no real file path contains a literal %NAME% sequence, the unresolved token simply never matches. The effect is that you have no exclusion where you configured one, so it is worth confirming the expected files are being skipped after adding a variable-based entry.

Process Exclusions

Exclude all files accessed by a specific process from on-access scanning. This is the most effective solution for scenarios where a process touches a high volume of files, for example build systems, backup agents, deployment tools, or cleanup scripts.

When a process is in the exclusion list, the exclusion is applied at the driver level. File accesses by that process never trigger a scan callback at all, so there is no locking window.

⚠ The process executable must be code-signed. The agent performs signature verification before registering the exclusion. Unsigned executables cannot be excluded via this mechanism even if listed.

⚠ Exclusions apply on next process start. If the process is already running when the exclusion is added, it must be restarted for the exclusion to take effect.

Examples: - C:\MyApp\bin\cleanup.exe - C:\Program Files\MyBuildTool\builder.exe

💡 Known issue: UNC paths may not match for process exclusions. The Windows kernel delivers network paths to the sensor in NT device format rather than the UNC format you configure, so an exclusion like \\server\share\app\tool.exe may not match at runtime. As a workaround, try adding the exclusion using each of these alternative path beginnings in turn until one works: - \Device\Mup\server\share\app\tool.exe, most common kernel delivery form - \Device\LanmanRedirector\server\share\app\tool.exe

A wildcard form covering the whole share (e.g. \Device\Mup\server\share\*) can also be used if you want to cover all executables on that share. This issue will be fixed in an upcoming sensor release.

Hash Exclusions (SHA-1)

Suppress the response to detections for a specific file by its SHA-1 hash. Useful for known-safe files that may be flagged as suspicious, for example internal tools or custom binaries.

⚠ Hash exclusions are post-detection only. The file is scanned first; the hash is then checked to decide whether to suppress the response to the detection. This means hash exclusions do not prevent the brief locking that occurs during scanning. They are best used to suppress false positives on known-safe binaries, not to reduce locking contention.

Extension Exclusions

❌ Not currently supported. Use path wildcards as a workaround, for example C:\MyApp\logs\*.log to exclude .log files under a directory.

Choosing the Right Exclusion Type

Scenario Recommended type
A process deletes or modifies many files rapidly Process exclusion
A specific directory contains known-safe files Path exclusion (absolute path preferred)
A specific binary is flagged as a false positive Hash exclusion
Files with a specific extension should be excluded Path wildcard (e.g. C:\App\logs\*.ext)
Mixed or dynamic paths, too many to enumerate Process exclusion

Common Scenarios

A process is failing because SenseOn is locking files it tries to delete

This is expected behaviour, the antimalware component briefly locks files during on-access scanning. The recommended fix is a process exclusion on the process performing the deletions. This removes the locking entirely without needing to enumerate file paths, and is more robust than path exclusions when paths are numerous or dynamic.

Note: the process executable must be code-signed for the exclusion to take effect.

Scanning is slowing down compilation on a build server

Use a process exclusion on the compiler or build tool executable, or a path exclusion on the build output directory using an absolute path. Avoid wildcard path exclusions on high-frequency directories, the pattern-matching window can accumulate under load.

A known internal tool is being flagged as malware

Use a hash exclusion (SHA-1) to suppress the false positive. If the tool is updated frequently and the hash changes, contact support@senseon.io to discuss alternatives.

Key Limitations

  • Process exclusions require a signed executable: unsigned binaries cannot be excluded.
  • Process exclusions apply on next process start: changes are not retroactive to already-running processes.
  • Wildcard path exclusions have a small locking window: for high-frequency file deletion, prefer process exclusions or absolute path exclusions.
  • Hash exclusions are post-detection only: they suppress action on a flagged file but do not prevent the scan or its locking.
  • Environment variables expand as SYSTEM, and Windows only: %TEMP%, %USERPROFILE%, %HOMEPATH% and %APPDATA% resolve inside the SYSTEM profile rather than the signed-in user's. Use C:\Users\*\... wildcards for the default profile layout, or the actual profile root if it has been relocated or redirected.
  • %CSIDL_*% and other USMT tokens are never expanded: they are accepted by the configuration form but match nothing at runtime.
  • Extension exclusions are not yet implemented: use wildcard path patterns as a workaround.