Trellix Application Control is widely deployed in enterprise and industrial environments to enforce application whitelisting, prevent unauthorized changes, and protect mission-critical systems from malware and zero-day attacks.
In industrial automation and control systems (IACS) environments, administrators deploying Trellix Endpoint Security (ENS) alongside Trellix Application Control (previously Solidcore) should carefully evaluate Script As Updater (SAU) and Memory Protection (MP). While these settings can strengthen security in traditional IT environments, they can also increase the risk of compatibility issues on legacy and real-time ICS endpoints, especially where multiple endpoint products apply low-level memory controls.
How SAU and Memory Protection Work
Before discussing the impact on ICS applications, it helps to understand what SAU and MP do:
- Script As Updater (SAU): Lets you grant “updater rights” to scripts (for example .bat, .vbs, .py) so they can perform update-like modifications.
- Memory Protection (MP): Application Control provides multiple memory-protection techniques intended to reduce exploitation (for example, buffer overflow-style attacks) and protect the integrity of running processes and DLLs.
In many deployments, SAU and MP are enabled by default, unless explicitly disabled during initial configuration/enablement.
Why ICS Applications Can Be Sensitive When SAU/MP Are Enabled (Especially with ENS)
Trellix also documents cases where applications can be unable to start when Memory Protection is enabled, which is a risk pattern you want to avoid on uptime-critical OT endpoints.
Additionally, OT vendor guidance highlights a broader point: if two products provide overlapping “memory protection” functions, they may be incompatible—meaning one product’s memory protection should be disabled to maintain stability. Siemens documents this explicitly in an OT allow-listing context.
Key Product Behavior You Must Understand First
SAU and MP are typically enabled by default
Script as Updater (SAU) and Memory Protection (MP) are commonly enabled by default unless you disable them at initial configuration/enablement.
Disabling SAU and MP in initial feature configuration is permanent
- Disabling SAU and MP during the Initial feature configuration is permanent—you can’t enable them again after installation.
- Any later attempt to change SAU/MP status via policy can be ignored by the endpoint.
This “one-way switch” is exactly why you must set the initial ePO task correctly before broad deployment.
Step-by-Step: ePO Task to Disable SAU and MP for ICS Nodes
Use this exact approach in McAfee ePO / Trellix ePO to ensure SAU and MP are disabled permanently during activation. Trellix explicitly documents the enable flow where you can select MP disabled and SAU disabled as part of initial configuration.
Create a new client task (based on SC: Enable)
- Change Control = Selected
- Application Control = Selected
- Initial Scan Priority = Low (recommended for endpoints controlling a live plant process; the node may be taken out of production control while completing this procedure)
- MP disabled = Selected
- SAU disabled = Selected
- Full Feature Activation = Selected
- Start Observe Mode = Not Selected
- Pull Inventory = Selected
Recommended Deployment Pattern for ICS
For most plants, a conservative, repeatable approach is:
- Use Application Control/Solidcore for allow-listing and change control
- Use ENS carefully (module selection and overlap matters)
- Disable SAU and MP during initial activation (using the ePO task above)
- Validate SAU/MP status in System Tree columns
- Pilot test on representative nodes before plant-wide rollout
