Plan and troubleshoot Sophos Endpoint scans
Real-time Scanning checks files when they are read, written, or renamed. A scheduled or manually started scan instead examines a defined set of data. These controls do not replace each other: dormant malware on a drive may never be opened, and a file may have been stored before the appropriate detection became available.
A scan should still not be run reflexively across every drive each day. Scope, timing, and depth must suit the device, otherwise the additional control creates heavy I/O, long runtimes, and unnecessary disruption.
Choose the right scan type
A Quick Scan focuses on commonly abused and active areas such as running processes, startup entries, memory, and boot information. It is suitable for a quick initial check but is not a complete drive inventory.
A Full Scan, or a scan of the entire computer, examines considerably more files. A targeted file, folder, or drive scan is useful when the suspected location is already narrowed down. On-demand scans use the same scan engine as real-time protection but differ in their selected scope.
For automated or precisely scoped Windows checks, the Sophos Endpoint Scan CLI also provides exit codes and JSON output.
Operate scheduled scans as a policy
Scheduled Scanning is configured in the effective Threat Protection Policy. Assign the policy to a clearly defined computer group and select a local start time and maintenance window. A device that is switched off at the scheduled time does not automatically catch up on the scan later.
When Real-time Scanning is active, a scheduled scan is not inherently required. Use it deliberately for older, rarely opened files or an investigation. Background Scanning is available only on Windows computers; this platform boundary is part of deciding whether an additional schedule is useful.
For mobile devices, assess several realistic online windows or a separate RMM runbook. Scan all files, Archive Scanning, and Deep Scanning substantially increase both coverage and runtime. Do not enable them simultaneously for every device without first running a representative pilot that includes large profiles, developer files, and slow storage.
Assess runtime realistically
Runtime depends particularly on occupied data volume, file types, archive content, storage throughput, and available CPU. Sophos scan tasks run at low priority, so a busy device scans more slowly. A 100 MB archive can expand into several times that amount of data, while many plain text files do not require the same default scanning effort.
Major and VDL updates can interrupt a scheduled scan by restarting a service. IDE-only threat updates do not. When investigating a slow or interrupted scan, compare the policy, update timing, SophosScanCoordinator.log, storage I/O, and system load for the same period.
Change only one option in a pilot group so that its effect remains measurable. Disabling Archive Scanning or Scan all files globally because one developer workstation was slow is not a reliable correction.
When Quick Scan or Scheduled Scan does not start
First distinguish between policy, coordinator, and File Scanner errors:
- Check the effective Threat Protection Policy and last Central contact.
- Check the local health state and installed Core Agent version.
- Review
SophosScanCoordinator.logfor the first error at the start time. - Verify the Sophos File Scanner service and its worker process.
- Decide on an update, restart, ACL correction, or support case only after identifying the cause.
A historical issue in the FTS 2025.2.1 line caused Quick Scans to stop with The file cannot be accessed by the system (1920). It was fixed in FTS 2025.2.1 MR2. On an affected package, first move to a current supported maintenance version. An older Core Agent 2023.1 issue involving Google Drive File Stream or RamDisk was also fixed by a maintenance release at the time; obsolete package tokens do not belong in a current runbook.
Sophos File Scanner service runs but no worker starts
The Windows service can appear to be running even though the actual File Scanner process does not start. Scanner log locations differ between current Core Agent versions, legacy versions, and older modern versions. One documented trigger is missing LOCAL SERVICE rights on registry keys used by Sophos.
Do not grant Full Control broadly on registry ACLs. First confirm that the log signature, affected keys, and existing inheritance match the current Sophos KBA exactly. Export the keys and ACLs before changing them. Then grant LOCAL SERVICE the required permission only on the documented key and its subkeys, restart the device, and update the agent.
Red health state caused by Cryptographic Services
Another cause is a hardened GPO for Windows Cryptographic Services. If it removes the Query status right from NT AUTHORITY\SERVICE, Sophos File Scanner cannot query the state of CryptSvc and does not start.
Apply the correction at the managed GPO source under Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Cryptographic Services. Grant NT AUTHORITY\SERVICE specifically Query status. After gpupdate, or the normal policy refresh, check File Scanner again. Local ACL changes have no effect while the GPO continues to overwrite them.
After the scan
A successful scan without a detection is a useful signal but not a complete incident closure. Assess inaccessible or encrypted files, effective exclusions, and a missing Live Protection connection separately. After a detection, follow the Threat Cleanup runbook instead of automatically creating an exclusion.