Correctly evaluate Sophos Endpoint Windows logs and services

A Sophos Endpoint on Windows consists of several protection, update and communication components. A red Health State therefore does not automatically mean that the entire agent has failed. For reliable diagnosis, first associate the symptom with a component and then examine only its log for the relevant time window.

Most operational logs are under C:\ProgramData\Sophos. Installation logs are typically under C:\Windows\Temp, C:\Windows\SystemTemp or the %TEMP% directory of the account that started the installer. In recent Core Agent versions, some user-interface logs are stored under %LOCALAPPDATA%.

Quick workflow:

1. Record the incident time, time zone and visible symptom.
2. In Sophos Endpoint Agent > About > Open Endpoint Self Help Tool, check Services and Components first.
3. Record the platform, Core Agent version and installed components; the licence and Agent Mode determine the expected state.
4. Select the relevant log below and read forwards from the first relevant error.
5. After a correction, refresh Self Help and repeat the same test. For escalation, also preserve an SDU from the same time window.

Under Computer details > Status, Central separates overall health into Communication, Operations, Services, System, Threat and Update. The Good, Warning, Bad and Info details can vary by operating system and agent version. Always correlate the affected category with the exact component in Endpoint Self Help rather than inferring a failed service from the overall colour alone.

From symptom to the correct log

File names and service mappings can change with a Core Agent version. Before assessing them, match the installed package version to the overview of Sophos Endpoint updates and component changes; for the diagnosis itself, use the components that belong to the installed version and the files actually present on the affected device.

Updates and AutoUpdate

SophosUpdate.log is the most important log for the update process itself. On currently supported Windows versions, sau-service.log shows when Central or a changed update or communication policy triggered an update. SophosLaunchUpdate.log records the start of the update process.

Do not assess an update failure from only the last Error line. First check:

1. which update destination was actually used,
2. whether direct access, a proxy or an Update Cache was involved,
3. which HTTP or TLS error occurred first,
4. whether the same time is visible in the firewall or proxy log.

Invalid entries in the Windows hosts file can direct Sophos destinations to the wrong address. For reproducible errors, compare SophosUpdate.log, DNS, proxy data and a simultaneous packet capture.

The classic Sophos AutoUpdate Service no longer exists on modern Windows platforms. If it is missing on an explicitly supported legacy platform, repair the cached AutoUpdate MSI with administrator rights and then trigger About > Update Now again. Do not use this old MSI procedure on Windows 10 x64, Windows Server 2016 or newer platforms.

Central communication and policies

The Sophos MCS Client maintains the connection to Sophos Fusion (formerly Sophos Central). McsClient.log answers whether the endpoint can reach Central. McsAgent.log then shows which policies and commands were processed. A recent Last Active time in Central is a useful indication of working MCS, but it is updated only approximately once an hour at most.

For a communication error, check the broker address, DNS, routing, proxy and firewall. After correcting the issue, the Sophos MCS Client service can be restarted and Endpoint Self Help refreshed. Disable Tamper Protection only if the specific intervention requires it.

Protection, blocks and cleanup

sed.log is the central operational log for Sophos Endpoint Defense. Among other details, it contains access to protected registry keys, processes and files, and blocked actions. seds.log helps determine whether drivers and the service loaded.

For cleanup, SophosCleanup.log and the associated Scan_*.log files are relevant. They show the detected threat, action performed, SafeStore check and duration. Before restoring from SafeStore, determine whether the file is safe and why it was detected.

A single log entry is not a reason to approve an exception. Create one only after checking the file, publisher, hash, reputation and business need.

A concrete example is Splashtop Streamer 3.5.6.0: many rapidly rotating and renamed log files can fill the Sophos scan queue and increase CPU and RAM use. Prefer updating to Splashtop Streamer 3.5.8.0 or later and then restarting. Only when the update is temporarily impossible, assess the log path actually used as a narrowly scoped file or folder exclusion for the affected group. A global exclusion of the entire Splashtop directory is too broad.

Another clearly identifiable cause of sustained high SEDService.exe CPU is a Sysmon rule for file-delete events that also tries to archive .bin files under C:\ProgramData\Sophos. Sysmon and Endpoint Defense then contend for compressed event-journal files, and sed.log repeatedly refers to the Sysmon archive path. Exclude the Sophos ProgramData structure specifically from this FileDelete archiving in the active Sysmon configuration, not from Sophos scanning. After reloading the Sysmon configuration, SEDService.exe should process the open journal files within a few minutes and the load should fall.

Windows Security Audit Logging: volume and rollback

Enable additional audit policy logging is enabled by default with Sophos Endpoint Core Agent 2026.1 and Sophos Server Core Agent 2026.1. The list of additional Windows audit events, which cannot be configured individually, improves the data available for detection and Threat Hunting. These events are recorded in the Windows Security Event Log, not in a Sophos text log under C:\ProgramData\Sophos. The mapping and rollback described here apply to Windows endpoints and Windows Server; they do not describe a Linux feature.

Manage the effective policy in Threat Protection for endpoints or Server Threat Protection for servers. Higher event volume alone is not a protection failure. Before disabling the feature, check log retention and SIEM processing, because less audit data limits the investigation of later attacks.

Map events to audit subcategories

The table lists the English Windows subcategory names. On German-language Windows, the names may differ; use the GUID identified below for local commands. The IDs provide a mapping, not a test plan: not every server role or activity generates every event. Use existing, authorised operational activity for verification; do not trigger account, task or service changes solely for a test.

Prior state, retention and evidence preservation

Before a planned change, document each device’s policy name and assignment, Core Agent version, server role, change time with time zone, and owners. For each affected subcategory, record success and failure auditing separately and establish whether GPOs, a security baseline or another product require them. If the feature is already active, a new backup records only the current state, not automatically the state before Sophos made its change. Do not disable any subcategory on suspicion without a reliable earlier configuration and owner approval.

The following commands are intended for a Windows Command Prompt opened as administrator. They read configurations or write a backup file; they do not change audit settings. C:\Audit-Sicherung is an example of an access-protected directory that must be created beforehand with sufficient free space. Use a new filename for each capture so that the prior state is preserved.

auditpol /get /category:* /r
auditpol /list /subcategory:* /v
auditpol /backup /file:"C:\Audit-Sicherung\audit-vorher.csv"
wevtutil gl Security
wevtutil gli Security

The CSV backup captures system and per-user audit settings as well as audit options; it does not replace a GPO backup. Preserve the query output with the change record. For later comparison, record the specific subcategory’s GUID from the list together with its locally displayed name.

wevtutil gl Security shows the maximum size, log path and retention mode, among other settings; wevtutil gli Security shows the log state. Inspect the Security log in Windows Event Viewer: record the oldest timestamp still present, events in the defined comparison window, and predominant IDs. Before and after the change, under comparable load, compare event counts per time window, the locally available time span, free space, and the SIEM ingestion rate, delay and dropped events. For a circular log, file size alone does not show how much history is still available.

With retention:false, new events overwrite the oldest events once the maximum size is reached. With retention:true and no automatic backup, new events are then dropped. autoBackup:true requires retention:true; archives still require storage and controlled retention. Do not therefore reduce log size indiscriminately or confuse “do not overwrite” with unlimited retention. Coordinate changes to maximum size, retention mode or archiving with the Windows/SIEM owners, and document all three starting values beforehand. During rollback, restore those exact values through the governing local or GPO configuration path and verify them with wevtutil gl Security. Events that have already been overwritten or dropped are not recovered.

Before an intervention, export relevant events; do not clear the Security log. Here too, use a new filename and a protected destination with sufficient space:

wevtutil epl Security "C:\Audit-Sicherung\Security-vorher.evtx"

Open the exported file in Event Viewer and verify the required time window. Audit data can contain user, account and activity information; restrict access, transfer and retention accordingly.

Selective rollback after disabling the policy

First turn off Enable additional audit policy logging in the Endpoint or Server Threat Protection policy that is actually applied, save it, and verify policy receipt on the device. Windows audit settings that have already been enabled remain in place and must be rolled back manually if necessary. Do not remove the entire audit policy: that would also affect settings required independently of Sophos. Likewise, do not blindly restore an entire CSV backup, because legitimate changes may have been made since it was captured.

Only with approval from the Windows/security owners, restore each demonstrably affected subcategory individually to its documented prior values. The following configuration-changing example applies only if success auditing was previously enabled and failure auditing was disabled. Replace <GUID> in full with the identified subcategory GUID, including {...}; the placeholder cannot be executed. Read the local state again before setting it:

auditpol /get /subcategory:"<GUID>"
auditpol /set /subcategory:"<GUID>" /success:enable /failure:disable
auditpol /get /subcategory:"<GUID>"

For other documented prior states, choose the two values independently: enable preserves or enables the respective auditing setting, while disable disables it. Disable both settings for that specific subcategory only if both were previously off and no other applicable requirement needs them. A subcategory can control more events than the IDs listed here; the change is not a filter for individual Event IDs.

After each change, compare expected and actual values, read them again later after the regular GPO/product refresh, and check the required event flow and log/SIEM volume. If values are re-enabled, first identify the governing GPO or other security product rather than repeatedly counteracting it locally. If the prior state, ownership or receipt of the Sophos policy remains unclear, stop rollback and escalate the policy, agent, audit and volume findings. To restore the additional visibility, re-enable the Sophos option and, after receipt, check the audit state and event flow; this does not fill any intervening data gap.

Assess services correctly

Self Help distinguishes Windows SCM Services from Sophos SCM Services. Only the first group is registered with Windows Service Control Manager and visible in services.msc. Sophos SCM Services run as processes but don’t appear there. On modern platforms, Sophos Live Query, Sophos Health Service and Sophos System Protection Service moved to this second group from Core Agent 2025.2. A missing services.msc entry alone therefore doesn’t prove an installation failure.

Sophos describes this consolidation in 2025.2.1 as a performance optimisation. Diagnosis must still use the installed Core Agent version and its matching Self Help article: the current Services article is explicitly marked for Core Agent 2026.1, and other packages may require a different workflow. Check status in Self Help first. It also states whether the affected service is handled through Windows SCM or Sophos SCM. Its repair procedures require administrator rights and Tamper Protection to be off; don’t perform them merely because an old service list differs.

On Core Agent 2025.x, a rare counterexample can occur after a failed Windows 11 feature update from 23H2 to 24H2 or 25H2 with rollback. If the rollback coincides with a DecisionCache update, registry and file-system versions can diverge. The endpoint turns red, System Protection does not start and C:\ProgramData\Sophos\Endpoint Defense\Logs\SSP.log reports a missing rules version.

Do not wait up to 96 hours for possible automatic repair while System Protection is absent. Temporarily assign the device an Update Management policy with a supported FTS or LTS package. The resulting reinstallation realigns the references. Remove the device from the repair policy only after green health, a running component and a current SSP log. Align the registry manually only with a Tamper Protection override, a backup and the exactly matching rules directory.

The official components and services list includes the following mappings. This table is a diagnostic aid, not a complete expected-state list for every device:

The components that must be present depend on the platform, Agent Mode and licence. An XDR Sensor, for example, installs telemetry components but not full Sophos malware protection. Determine the expected state in Central first, then compare it with services and processes.

Network and web protection

SophosNetFilter.log contains website connections and actions from Web Control and real-time internet scanning. SophosIPS.log shows the configuration and detection content of network threat protection. SntpService.log includes information about isolation and other network functions.

For a blocked website, compare the time, URL, process and effective policy. The log alone does not always reveal whether Endpoint Web Control, DNS Protection or an upstream firewall blocked first. Check these control points separately.

User interface and Self Help

In current Core Agent versions, SophosUI.Net.log and SophosUITray.log are located under:

%LOCALAPPDATA%\Sophos\Sophos UI\Logs

They record actions in the local interface and at the taskbar icon respectively. From Core Agent 2026.1, Self Help logs can also be stored per user under %LOCALAPPDATA%\Sophos\Endpoint Self Help\Logs. Depending on the component, the machine-wide directory under C:\ProgramData\Sophos\Endpoint Self Help\Logs remains relevant as well.

Evaluate a log properly

Before opening the log, define a narrow error window including the time zone. Then read forwards from the first relevant error. Later consequential errors such as service unavailable, timeout or component unhealthy are often only symptoms.

A reliable note includes:

• the visible symptom and a reproducible test,
• the log name, timestamp and first relevant message,
• the Endpoint, proxy, cache or relay path involved,
• a comparison with a working device,
• the change tested and its measurable result.

Do not permanently increase logging levels as a precaution. Detailed MCS logging can contain sensitive communication data and consume additional storage. Enable it only for a defined time window according to current Sophos instructions and then reset it.

For MCS communication analysis, Sophos Support may also request a diagnostic message trail. On Windows 10 x64 or Windows Server 2016 and later, it has been enabled by default since Core Agent 2023.2; the XML steps for enabling and subsequently disabling it apply only to legacy platforms. Trail files can contain policy and communication data and should be transferred securely with the SDU. Disable a legacy capture after collection because it can otherwise fill the disk.

Preserve logs for Support

Individual logs help with local diagnosis. For escalation, also create an SDU collection from the same error period. The package can contain hostnames, users, paths, IP addresses and configuration data and must be transferred securely.

Diagnose Sophos Endpoint with Self Help and SDU explains the complete collection. Installation errors are covered separately in Systematically troubleshoot Sophos Endpoint installation on Windows.

Frequently asked questions