Plan Sophos Endpoint system requirements and lifecycle
An installed agent does not automatically remain supported in the long term. The operating system, architecture, Sophos components, certificates and licensing model evolve independently. Reliable Endpoint operations therefore check not only whether installation works today, but also when platforms leave support and how new agent versions are introduced.
Scope: Endpoint is not Server or Linux
This guide covers Sophos Endpoint for Windows and macOS workstations. Windows Server is managed under Server Protection in Sophos Fusion (formerly Sophos Central); Linux workloads use Sophos Protection for Linux and its own requirements, release notes and lifecycle dates. Server or Linux entries in the shared retirement calendar therefore do not approve an Endpoint deployment and belong in a separate runbook.
Approval snapshot and lifecycle decision
Specific version numbers and support boundaries age quickly. The owner therefore performs the same controlled review before an initial installation, an operating-system upgrade, a package change, and at least monthly. Start with an inventory snapshot containing device type, OS edition and full build, architecture, CPU, memory, free space on the system drive, encryption, required protection scope, and installed Sophos components and their versions.
Next, check the currently maintained Sophos matrices for Windows or macOS and the retirement calendar internally. The approval record must capture the check date, exact entry reviewed, platform and architecture, installation and upgrade eligibility, minimum prerequisites, exclusions, Maintenance, Retirement, licence or Extended Support conditions, and every footnote. A stored snapshot proves a decision; it is not a permanently valid support list. Replace it at the next change and record the difference.
Mark the decision approved, pilot only, migration required, or not approved. Include the owner, scope, required functions, known constraints, vendor and Sophos deadlines, migration target, and next review date. If the exact OS/architecture entry is absent, statements conflict, or the matrix is unavailable, do not issue a new approval. Preserve the last approved state, record the query time and ambiguity, and resolve it with Sophos Support before the pilot.
Windows requirements and support boundaries
For Windows, check the edition and full build, x64 or ARM64, CPU and memory, free space and system drive, required Microsoft updates and certificates, and intended protection mode separately against the current entry. Minimum values are entry conditions, not capacity recommendations. Insider, Preview, and other prerelease builds remain unapproved unless the exact entry explicitly includes them.
Record Microsoft’s support end date too. Successful installation, healthy status, and current platform support are three separate claims. Windows Server is not a Windows Endpoint even when its build is similar and is outside this approval.
macOS requirements and support boundaries
For macOS, check the full operating-system version, Intel or Apple silicon, free space, installation method, and required protection scope. The approval pack must also contain the MDM profiles used for System Extensions, Network Extensions, web/content filtering, Full Disk Access, and notifications. A matching OS row alone therefore does not prove effective protection.
Test a new macOS major or point release, including current installer and upgrade eligibility, on a representative pilot Mac. Record differences between a fresh installation and an existing agent explicitly; “macOS supported” does not imply that both paths or every function are supported. Accept Extended Support only when the exact macOS entry states it.
Component and release review
Sophos Endpoint comprises independently updated components such as AutoUpdate, Endpoint Defense, Health Service, Management Communication, Network Threat Protection, Endpoint UI, and licence-dependent modules. A Central product stage or one local version number cannot describe the complete state.
At this exact review step, the lifecycle owner opens the live stream for Sophos Core Agent for Windows or Sophos Anti-Virus for macOS, as applicable. Capture the target build, rollout status, fixes, and known limitations live during every review. The release record documents that point-in-time check and does not replace a fresh check at the next review.
The release record captures the check time, platform, selected product/version node, publication and rollout notice, component builds, fixes, known issues, and differences from the previous entry. The lifecycle owner maps every item to deployed functions and pilot devices and decides approve, defer, or reject. An empty, failing, or contradictory stream is not approval evidence: preserve a screenshot or error, check selection parameters and network access, retry later, and escalate persistent ambiguity to Sophos Support. Keep package assignment and the next rollout ring blocked until it is resolved.
Test resources and third-party software in the pilot
The official minimum is only an entry threshold. A representative pilot measures startup and sign-in time, CPU, memory, free storage and I/O with the real business software. Include SSD/HDD, encryption, DLP, backup, VPN, remote-control and application-allowlisting products as explicit sample attributes.
For a regression, use Sophos Performance Analysis and component logs. Do not disable protection features or Event Journals globally as a performance experiment. A narrowly scoped temporary mitigation needs an owner, end date, risk approval and retest; the sustainable resolution may be a vendor fix, platform upgrade or hardware replacement.
Understand phased releases
Sophos sometimes publishes Release Notes on the first day of a rollout that lasts several weeks. A documented new version may therefore not be available immediately to every tenant or Endpoint.
This prevents two misinterpretations:
- A device is not automatically out of date because it has not received the new version on release day.
- A manual reinstall does not reliably force a software stage that has not yet been released to that device.
Pilot and production stages
Software Packages and Update Management Policies support controlled stages:
- Pilot: IT and representative hardware, OS and software combinations.
- Early production: a small production cross-section after pilot criteria pass.
- Production: broad assignment after change approval.
- Fixed package: only for a justified need, with an owner and monitored expiry.
Verify package names, availability, support type, expiry and overlap directly in Sophos Fusion and on the current Software packages page. This article does not freeze package durations. Treat security-content updates separately from product versions.
Define success measures before every stage: healthy devices, expected component versions, no new alert concentration and acceptable performance. Define rollback in advance too: pause assignment, isolate the group, preserve policy and package evidence, reassign a package currently offered and tested by Sophos, and recheck health. A manual downgrade or old installer is not a reliable rollback.
Extended Support is transitional
“Legacy” or “Extended Support” is a transition, not a blanket approval. Check the exact client OS entry, maintenance and retirement dates, available features, and any required licence in the current retirement calendar. Give every affected device a migration deadline.
Windows Server and Linux rows do not belong in the Endpoint device group. Plan them against the specific requirements and licences for Server Protection or Sophos Protection for Linux. Do not assume Extended Support for macOS unless Sophos explicitly states it for the exact version.
Plan restarts
Sophos does not always force an immediately required restart. Protection and Detection updates can continue while a component waits for the next maintenance restart.
Devices that have not restarted for a long time can require several consecutive update states, each followed by another restart. Allow enough time between cycles for the first update to be processed completely. Recheck Central Alerts and local software status after each restart.
Early Access Programs
An Early Access Program is not a normal production channel. Before joining, define the purpose, target devices, expected changes, support route, exit plan and privacy implications.
EAP devices belong in a clearly named pilot group. After leaving, verify when they return to the regular software version. Do not enable an EAP on critical devices merely to bypass one problem without root-cause analysis.
Apply, validate, and troubleshoot
The implementing engineer applies only the package approved in the approval record to the defined pilot group; ad hoc installer changes, manual downgrades, and old installation packages are excluded. First preserve the device group, policy and package assignments, component versions, health, open alerts, and a repeatable functional test. Keep the target group and success criteria unchanged throughout the observation period.
After installation, update, and every required restart, check Last active, health, and alerts in Central, plus local service status and expected component versions. Then run identical before-and-after tests for sign-in and startup time, policy receipt, update capability, a malware test under the internal security procedure, network/web protection, and all licence-dependent functions. On macOS, also prove that extensions and privacy permissions are active. The lifecycle owner reconciles the result against the release record and approval record and documents discrepancies in both; only a complete pass opens the next ring.
Classify a failure before changing anything: platform not approved, installer blocked, component out of date, rollout not yet offered, restart pending, MDM permission missing, or third-party conflict. Capture the time, device, full OS build, architecture, Central package and policy, all component versions, health/alerts, restart state, reproducible steps, and relevant logs together. Then stop package assignment to additional devices and reverse the last change in isolation if Central provides a currently offered and previously tested package for that purpose. Do not disable protection globally or force an old installer. If the cause or a safe recovery path remains unclear, isolate the pilot, mark the release record deferred, and engage Sophos Support with this diagnostic bundle.
Monthly lifecycle review
A useful operational rhythm includes:
- reviewing new Endpoint and Central Release Notes,
- comparing the Retirement Calendar with platforms in use,
- exporting devices by operating system, architecture and Agent Mode,
- assigning an owner to Legacy and inactive devices,
- checking expiring Fixed-Term or LTS packages,
- resolving restart and update Alerts,
- documenting pilot results.
The technical update architecture is explained in Sophos Endpoint updates, Cache and Message Relay.