Start with the incident record, not the endpoint

Before changing policy, collect the alert details from Sophos Central and the affected host. Identify the device name, logged-in user, time of detection, threat name, file path, parent process, command line where available, SHA-256 hash, action taken, and whether the item was blocked, quarantined, cleaned up, or left for manual action. Record the Intercept X and endpoint agent versions as well.

This evidence separates three very different conditions that are often described as a single “Sophos problem.” A prevention policy may have blocked a known bad file. Exploit prevention may have stopped suspicious behavior from an otherwise legitimate process. Or an EDR investigation may have generated a detection that needs analyst validation. The right response differs in each case.

Check scope immediately. If one endpoint is affected after a software update, investigate local compatibility, application signing, and device health. If many endpoints report the same detection, assume a policy, application release, certificate, or widespread compromise issue until evidence proves otherwise. A fleet-wide exclusion made under pressure can create a much larger security gap than the original alert.

Tamper protection: recover control through approved administration

Tamper protection is designed to prevent local users, malware, and unauthorized administrators from disabling Sophos services, changing protected configuration, or removing the agent. When it blocks a legitimate maintenance task, that behavior is usually evidence that the control is working as intended.

The first question is whether the endpoint remains centrally managed and visible in Sophos Central. If it does, use the authorized management workflow: confirm the device's assigned policy, obtain the applicable tamper protection authorization from the console, perform the approved maintenance task, then verify that protection is restored and the endpoint checks back in. Access should be limited to designated administrators and documented in the service record.

Do not treat tamper protection as an obstacle to work around with local registry edits, forced service termination, or unverified scripts. Those approaches can leave drivers, services, and policy state partially removed. They also make it harder to determine whether a failed uninstall is a software issue or a sign of endpoint compromise.

A more difficult case occurs when a device is no longer checking in. Validate basic connectivity to required Sophos services, DNS resolution, proxy behavior, system time, and whether the endpoint has been moved between tenants or management groups. Then review the last known policy and the timing of the failure. A device that went offline after ransomware containment, a VPN change, or a failed operating system update deserves a broader endpoint health review before any removal attempt.

For offboarded or rebuilt devices, confirm ownership and change authorization first. In managed environments, the endpoint security platform, RMM tool, identity provider, and asset register should agree that the device is intended for decommissioning. That small control prevents accidental removal from a production system that was merely renamed or temporarily disconnected.

Cleanup failures need classification before remediation

A cleanup failure does not automatically mean Sophos missed the threat. It means the platform could not complete the configured action under the conditions present on that host. Common causes include a locked file, an active process, insufficient rights, an inaccessible location, damaged agent components, a pending reboot, or a file that was changed after detection.

Begin by reading the exact action status. “Cleanup failed” alongside a quarantine action is a different risk from “cleanup failed” with the executable still active in a user-writable folder. Establish whether the file still exists, whether its hash is unchanged, whether the associated process is running, and whether persistence mechanisms are present. Review scheduled tasks, services, startup entries, browser extensions, and relevant identity activity when the detection suggests credential theft or remote access behavior.

If the endpoint is potentially compromised, isolate it according to the incident response plan while maintaining access for investigation. Isolation should be proportionate. A finance server with a suspicious binary requires a planned containment decision that accounts for business continuity, while an unmanaged laptop on a public network may warrant immediate isolation.

For routine cleanup failures on a healthy endpoint, complete prerequisites first: reboot if required, ensure sufficient disk space, confirm the agent is current, and remove conflicts introduced by unsupported legacy antivirus or endpoint tools. Then rerun the approved remediation action or follow the vendor-supported repair and removal process. Cleanup utilities should be used only under documented support guidance, especially on servers and systems with encryption, VPN, DLP, or other kernel-level security components.

If remediation repeatedly fails, preserve logs and escalate with a concise case package. Include the alert ID, device details, timestamps in a consistent time zone, relevant agent logs, hash values, screenshots of the status, and actions already attempted. This reduces back-and-forth and gives the security provider or vendor support team what they need to distinguish a product defect from an endpoint-specific condition.

Sophos Intercept X troubleshooting for false positives

False positives are costly because they interrupt trusted software, but they should not be assumed simply because a user recognizes the application name. Legitimate software can be abused, installers can be bundled with unwanted components, and a signed executable can still exhibit suspicious behavior.

Validate the file and the behavior separately. Confirm the publisher signature, certificate chain, download source, version, hash, installation path, and prevalence across the organization. Then assess why it was detected. A detection based on a malicious hash calls for a different review than an exploit prevention event triggered by an application injecting code into another process.

Consider business context. Custom software, database administration utilities, PowerShell automation, remote support tools, and DevOps deployment agents often perform actions that resemble attacker tradecraft. That does not make the alert wrong. It means the security team needs to decide whether the behavior is expected, controlled, and limited to the right users, hosts, paths, and execution conditions.

When an exclusion is justified, make it as narrow and temporary as practical. A hash-based exception can be appropriate for a single verified binary but will break when the vendor releases an update. A path exclusion may be necessary for an application that frequently updates, but it is riskier if users can write to that location. Process and policy exceptions can support a known workflow, yet they require careful testing because they may permit broader behavior than intended.

Avoid exclusions for entire drives, common executable folders, scripting engines, or all activity from a business application. Those shortcuts reduce operational friction at the expense of an attacker-friendly blind spot. Set an owner, business justification, expiration or review date, and validation requirement for every exception. If the same application repeatedly triggers detections, engage the software vendor and consider a formal tuning standard rather than accumulating one-off exclusions.

Build a repeatable operating model

The technical fix is only one part of endpoint resilience. Define who can change tamper protection settings, who approves exclusions, who owns cleanup validation, and when an event becomes a security incident. For regulated organizations, retain this evidence as part of change management and incident response records. It supports audit readiness and demonstrates that security controls are governed rather than routinely bypassed.

A practical monthly review should examine stale endpoints, repeated cleanup failures, exclusions that have outlived their purpose, agent version drift, and high-noise detections. Correlating Sophos endpoint events with identity, firewall, SIEM, and vulnerability data gives the team better answers than endpoint telemetry alone.

AdvisionIT approaches these cases as a shared operational responsibility: restore service quickly, preserve the evidence needed to make a sound security decision, and leave the endpoint estate better governed than it was before the ticket opened.

Author: Yavor Y. Zlatev CEO of AdvisionIT

Date: 14.08.2026