Teams should baseline each SCCM execution path separately, including script deployment, application enforcement and software update activity, because they produce different parentage, command lines and log sequences. Build normal profiles for expected caller, child process, account context and timing for each path. A single baseline across all SCCM activity hides abnormal execution that only stands out within one delivery method.
Why separate SCCM baselines by execution path?
Different SCCM delivery methods do not look the same on the host, so one broad profile is too blunt to be useful. Script deployment, application enforcement and software update activity each create distinct parentage, command lines, account context and timing patterns. The baseline has to reflect those differences or it will either miss real misuse or overload analysts with expected noise.
The practical value of path-level baselining is that it turns SCCM from a generic “trusted admin tooling” bucket into a set of observable behaviours. That matters because defenders usually need to decide whether a process chain is normal for the specific function being performed, not merely normal for the platform overall.
For teams that want a structured way to think about the platform itself, the Microsoft Configuration Manager Security Guide is useful background on the control surfaces around Configuration Manager, including administration and relay-path considerations.
What should each SCCM path profile capture?
Each profile should describe the expected execution shape for that path, not just the initiating console action. For script deployment, that usually means the caller, the script host, the signing or trust context, and any child processes that are normal for the script’s purpose. For application enforcement, focus on installer wrappers, execution policy, service context and the software distribution chain. For updates, capture the update agent behaviour, maintenance windows and the timing of repeat executions.
It is also worth separating what is stable from what is variable. The account context may stay consistent while the command line changes by package or task sequence. Child process trees may be predictable for one deployment method and completely wrong for another. If teams collapse those into one baseline, they lose the ability to spot unusual execution that is only abnormal within a single SCCM path.
A broader endpoint-management view can help when teams are deciding how much normal variation they need to account for across managed devices, policies and deployment methods. The UEM Buyer's Guide is a useful companion for understanding how endpoint management choices shape operational visibility and control expectations.
How do analysts use the baseline without making it too rigid?
The baseline should be descriptive enough to support detection, but not so strict that every legitimate package or update becomes an alert. A good approach is to anchor on the invariant parts of the path, then allow for controlled variation where the business process demands it. That means comparing observed activity to the right peer group, such as script-deployment to script-deployment or update activity to update activity, rather than to all SCCM activity combined.
When reviewing alerts, analysts should ask whether the execution path matches the intended SCCM function, whether the expected parent process is present, and whether the account context is appropriate for that delivery method. If one of those pieces is off, the event deserves closer review even if SCCM is otherwise an authorised tool. That is the point of path-specific baselining: it makes the abnormal shape visible without assuming every SCCM event is equally benign.
Risk and Threat Considerations
Attackers and insiders can abuse SCCM because it is already trusted to run code, distribute software and apply changes at scale. If the environment treats all SCCM activity as one normal class, a malicious payload can hide inside a legitimate management workflow, especially when the parentage and timing resemble routine deployment activity.
Failure mechanism: A single baseline masks method-specific execution differences, so abnormal script chains, installer behaviour or update-triggered activity blend into expected SCCM noise and evade detection.
Impact: Teams may miss unauthorised code execution, credential exposure through management context, or early signs of lateral movement that only become obvious when each execution path is judged against its own normal pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-10 — Malware Defenses | Baselining SCCM execution paths improves detection of malicious or unusual code execution. |
| Recommendation — Baseline expected SCCM execution patterns and alert on process chains that deviate from them. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Path-specific baselines support anomaly monitoring for distinct SCCM execution behaviours. |
| Recommendation — Track SCCM execution paths separately and flag deviations from each path’s normal process shape. | ||
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | SCCM abuse often relies on hiding malicious execution inside legitimate administrative activity. |
| Recommendation — Map suspicious SCCM chains to ATT&CK techniques and investigate disguised execution. | ||
Practitioner Guidance
What to prioritise: Start with the three SCCM paths that generate the most administrative execution on your estate, then document their normal parent processes, child processes, service accounts and timing windows. That gives you the highest-value detection baseline fastest.
What to verify: For each path, confirm that the observed process tree matches the intended delivery method and that the account context is consistent with how that workload should run. If the same command line appears under a different parentage, treat it as a separate case, not a harmless duplicate.
Practitioner takeaway: The useful baseline is not “what SCCM usually does”, but “what this SCCM path should look like when it is behaving normally”.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org