Removing Sophos Tamper Protection Without Access to the Cloud Portal
I ran into this exact problem after a migration away from Sophos. Some machines never checked in after Tamper Protection was disabled centrally. They still block local uninstalls. This guide walks through what to look for, where it happens, how to diagnose root cause, and how to remove Sophos Tamper Protection offline using Safe Mode and other techniques. I give real checks, commands to run and clear remediation steps.
What you see
Symptoms are blunt and repetitive. The local uninstall fails. Programs and Features will show Sophos components, but the uninstall button either does nothing or shows a Tamper error. Expect one-line messages or logs that look like this: “Tamper protection is enabled. Uninstall blocked.” You may also see the user-facing quote from others: ‘Zap doesn’t work if Tamper Protection is enabled.’
Common visible signs
- Uninstall blocked dialogs or greyed out uninstall controls.
- Sophos services present and restarting automatically.
- Sophos icons in the system tray that do not respond to local controls.
Exact log lines will vary by product version. If you can read the Windows Event Log, search for entries from “Sophos” or “SAVService”. Look for messages around the time you attempted an uninstall. If you have access to the Sophos logs folder (C:\ProgramData\Sophos…), check recent .log files for “Tamper” or “TamperProtection”.
Basic diagnostic commands and expected vs actual
- Command: sc queryex | findstr /i sophos
Expected: list of Sophos services with STATE: RUNNING or STOPPED.
Actual problem: services present and immediately restart, or SERVICE_NAME not found if agent corrupted. - Command: reg query “HKLM\SOFTWARE\Sophos” /s
Expected: Sophos keys present and readable.
Actual problem: keys exist but include flags that indicate Tamper is active, or registry access denied.
If the uninstall attempt produces a specific error code, copy that line. It helps if you later contact support.
Where it happens
This problem crops up on endpoints that never checked in to Sophos Central after a policy change. The common scenarios are machines left offline during migration, or devices that were imaged from old snapshots. It also shows on standalone laptops that had local Tamper Protection set by an admin.
Locations and devices affected
- Machines that were powered off or offline when Tamper Protection was removed centrally.
- Devices with broken outbound connectivity to Sophos Central. DNS or proxy rules are common causes.
- Workstations and servers where Sophos agent fell out of sync after an OS restore.
Devices unable to check in will not receive the central setting that disables Tamper Protection. That means a global change in Sophos Central does nothing on those endpoints until they phone home. Sophos Zap failures are common in these cases. The Zap tool is meant as a last resort, but Zap is blocked by active Tamper Protection unless you supply the tamper code.
Practical indicator: if the machine has no Internet or its Sophos agent reports “Last check-in: never” or an old timestamp, it has not received the cloud change.
Find the cause
Do not guess. Test. The cause is almost always one of these three: Tamper Protection was left enabled centrally but the endpoint did not receive the change; local policies or registry flags re-enabled Tamper; or network issues prevent cloud communication.
Checks to run
- Network connectivity: ping the Sophos Central endpoints or check DNS resolution for your Sophos management URLs. If DNS fails, the agent cannot check in.
- Local policy and permissions: confirm the logged-on user is not blocked from changing security settings. Tamper is designed to stop local admin changes.
- Corrupted agent: if files or services are missing or repeatedly fail, the agent may be partially installed and refuse commands.
Commands to gather evidence
- ipconfig /all and nslookup
to verify DNS and IP routing. - sc queryex | findstr /i sophos to list services.
- netstat -ano | findstr :443 to see if the agent is attempting outbound HTTPS connections.
Root cause examples
- The endpoint trapped on an old image with Tamper Protection active and no route to central.
- Proxy or firewall blocking the agent from checking in.
- The tamper code is unknown because the admin who enabled Tamper is no longer available.
Fix depends on the root cause. If the device can check in, fix the network and let it receive the change. If it cannot, use the offline path below.
Fix
I use a dual-path approach. Try the clean online route first. If that is impossible, use Safe Mode removal and, if necessary, escalate to Sophos support for a tamper code or remote unlock.
A. Online-first (preferred)
- Restore connectivity so the endpoint can reach Sophos Central. Check DNS and proxy rules.
- Force a check-in from the device or run the Sophos diagnostics agent if available.
- From Sophos Central, re-apply the Tamper Protection disable policy and wait for check-in. Verify “Last check-in” updates.
B. Offline removal with Safe Mode
- Reboot to Safe Mode. Use F8 or hold Shift and restart. On newer Windows use Settings > Recovery > Advanced startup.
- In Safe Mode, many Sophos drivers and services do not load. Open an elevated command prompt.
- Run sc queryex | findstr /i sophos to confirm services are inactive. Expected: no Sophos services running in Safe Mode.
- Locate the Sophos installation folder, typically C:\Program Files\Sophos or C:\Program Files (x86)\Sophos. Move or rename the folder to break service paths.
- Run the vendor uninstaller if present, or run msiexec /x {product-GUID} if you know the GUID. If you do not, remove the files and clean related registry keys under HKLM\SOFTWARE\Sophos and HKLM\SYSTEM\CurrentControlSet\Services<sophos-service>.
- Reboot normally and confirm Sophos components are gone.
Notes on Safe Mode removal
- Safe Mode is not flawless. Some Tamper components may still persist. The steps above are blunt but practical when the cloud is unreachable.
- If SophosZap is available and you have the tamper code, run SophosZap in Safe Mode with the code. Without the code, Zap will fail when Tamper is active.
C. When you need Sophos support or the tamper code
- If you cannot obtain the tamper code and Safe Mode fails, raise a case with Sophos. Provide machine serial, agent ID and the exact log lines you collected. Sophos can often provide a tamper reset or a one-time code after identity checks.
Check it’s fixed
Verification is crucial. Do not assume the agent is gone just because the tray icon is gone.
Checks to run after removal
- Reboot and run sc queryex | findstr /i sophos. Expected: no Sophos services, or SERVICE_NAME not found.
- Check Programs and Features. Expected: no Sophos entries related to the old agent.
- Inspect ProgramData and Program Files for leftover Sophos folders. Remove any residual files.
- Confirm network: if the device should be managed by another product, confirm the new agent installs and registers.
Confirming endpoint functionality post-removal
- Run a full network check: ping, DNS, and test the service that was being blocked.
- Watch for reappearance of Sophos processes. If they restart, Tamper may still be present or the machine is still linked to central and pulling down policy.
- Document the exact changes you made, including timestamps and command outputs. Keep those logs with the device record.
Final takeaways
- Tamper Protection blocks local removal. It must be disabled centrally or bypassed using the tamper code or Safe Mode.
- Start by diagnosing connectivity and check-in state. That saves time.
- Safe Mode removal works when you cannot reach Sophos Central, but it is invasive. Record everything and, if in doubt, contact Sophos support with your logs and machine identifiers.