Back to insights
Cybersecurity

Replacing Antivirus with SentinelOne: A Rollout Checklist

Moving from signature antivirus to SentinelOne is a project, not an installer. This checklist covers the inventory, removing the old product, Defender on servers, policy staging and rollback checks.

The case for replacing signature antivirus with behavioural endpoint detection and response is made in SentinelOne vs traditional antivirus. What that comparison does not cover is the week in which the change happens. A rushed rollout leaves two products fighting over the same files, laptops that never received the agent and a rollback feature that was never tested.

This is the checklist we work through when we deploy SentinelOne for a client, written for the IT manager who will run the project or hold us to it.

Start with an inventory you trust

SentinelOne protects the devices it is installed on, so the first task is a list of every device that touches company data: desktops, laptops, physical and virtual servers, Citrix or Azure Virtual Desktop hosts, and the machines that travel with sales staff and executives.

Compare that list with what the current antivirus console reports. The difference is your real exposure: devices rebuilt and never re-enrolled, home-office machines that have not checked in for months, servers that were "temporary" three years ago. Because OAS deploys the agent through N-able N-central, the N-central device list becomes the authoritative inventory, and a device missing from it is a visible gap.

Remote devices need the same attention. SentinelOne's detection runs on the device, so a laptop on guest-house Wi-Fi in Upington is protected like a desktop in Sandton, but the agent still has to reach it. Deploy over the remote management channel and track agents that installed but have not reported in; our guide to endpoint protection for remote workers covers the surrounding controls.

Remove the old product, and handle Defender deliberately

Two products providing real-time protection on one machine is not a belt-and-braces arrangement: each intercepts the other's file operations and detections become unreliable. Plan the exit:

  • Confirm the uninstall method for the existing antivirus, including any tamper password. Test it on one machine.
  • Remove the old product and install SentinelOne in the same maintenance window, so no device sits unprotected overnight.
  • Keep the outgoing licence active until the last device has migrated. Lapsed protection is not a theoretical risk: the Information Regulator's 2023 enforcement notice against the Department of Justice and Constitutional Development found that antivirus, SIEM and intrusion-detection licences had expired in 2020 and were never renewed, leaving, in the Regulator's words, "no protection against a known and detectable virus".

Microsoft Defender Antivirus behaves differently on clients and servers. On Windows 10 and 11, Microsoft's compatibility documentation says Defender switches to disabled mode automatically when a non-Microsoft product is installed, provided the Windows Security Center service is running; if a hardening script has disabled that service, Defender stays active, which Microsoft calls unsupported. On Windows Server 2016 and later, Defender does not enter passive mode on its own. Set passive mode on servers onboarded to Microsoft Defender for Endpoint, or disable or uninstall the feature on servers that are not, and add Defender's binaries to the SentinelOne exclusion list where it stays in passive mode. Put a line in the plan for every server and verify with Get-MpComputerStatus afterwards.

Stage the policy instead of flipping it

A SentinelOne policy sets what the agent does on detection: alert only, or kill the process, quarantine the file, remediate the changes and roll back encryption. Switching everything to full protection on day one is tempting; resist it for the pilot. We recommend:

  1. Pilot a small group that covers each operating system, the main line-of-business applications and at least one server role. Run it in detect mode for one to two working weeks.
  2. Review every detection. Some will be real. Others will be a backup agent, a bespoke ERP client or a deployment script doing something that looks hostile. Create exclusions for those by path or certificate, as narrowly as possible, and document why each exists.
  3. Move the pilot to protect mode and watch it for another week. Confirm that nothing you depend on is being killed.
  4. Roll out in waves by department or site with the tuned policy, and tell the help desk each wave's date so "my application closed" calls are routed correctly.

Review exclusions quarterly; one left behind for a tool you no longer use is a hole an attacker can stand in.

Check the rollback prerequisites

SentinelOne's rollback of ransomware encryption relies on Windows Volume Shadow Copy snapshots, which the agent protects from the tampering ransomware attempts. SentinelOne's own documentation is clear that this makes rollback a Windows capability and that storage limits apply. Two consequences follow:

  • Shadow copies need disk space. A volume that is nearly full cannot hold snapshots, so check free space on servers and file-heavy workstations before go-live.
  • Rollback is one recovery path, not the only one. SentinelOne states that you should still keep regular external backups. That is why the Three Pillar model pairs SentinelOne (Protect) with N-able N-central (Detect) and Cove Data Protection (Recover): if rollback is incomplete, the second path is a backup that ransomware could not reach. Our article on immutable backups explains what that path needs.

Test rollback during the pilot on a test machine, and record the result.

Keep the evidence

POPIA section 19 requires reasonable technical and organisational measures to secure personal information, and the Regulator's enforcement notices show that it looks for proof that safeguards were maintained, not just bought. From the first day, keep the device inventory and coverage percentage week by week; the exclusion register, with an owner and reason for each entry; the pilot detection reviews; the rollback test result and date; and the decommissioning record for the old product. The same documents turn an auditor's or insurer's questionnaire into a short exercise.

For managed clients, OAS runs the inventory reconciliation, the staged policy, the exclusion reviews and the reporting, and monitors the console around the clock; the SentinelOne product page describes the service. Either way, this checklist is the difference between a product that is installed and protection that is in place.

Sources

Plan the move from antivirus to behavioural protection with SentinelOne deployed and managed by OAS.

Keep exploring

All insights