Deploy Sophos Fusion Endpoint systematically

Deploying Sophos Fusion Endpoint involves more than running an installer. A reliable deployment combines administrator access, device and user identities, the correct software scope, policies, network access, a representative pilot, and clearly owned monitoring and response.

This article provides orientation for the overall project. Follow the linked runbooks for installation, policy configuration and troubleshooting details.

The process at a glance

1. Define scope, owners and success criteria.
2. Secure Central access and administrator roles.
3. Check the licence, Agent Mode and supported platforms.
4. Design identities, groups and the policy model.
5. Prepare network paths and update delivery.
6. Pilot Windows and macOS on representative devices, and Linux through the separate Server Protection track.
7. Validate protection, communication, events and rollback.
8. Only then expand in controlled waves and hand over to operations.

Proceed only when the preceding phase has a documented result. A completed installer is not an operational acceptance test.

Direct routes through deployment

If your immediate goal is installation, you can jump straight to the relevant platform path. For a complete deployment, start with the system requirements and lifecycle boundaries and the network and proxy requirements. If macOS is in scope, add the macOS permissions. Microsoft Entra ID can provide users and groups; Active Directory can additionally provide devices and device groups.

Secure administrator access before rollout

Administrator access starts with MFA, passkeys and federated sign-in. Depending on the identity provider, implement federation with Microsoft Entra ID, OpenID Connect or Okta, or AD FS. For RBAC, first restrict tenant-wide administrator roles, followed by Endpoint-specific roles and permissions, to match each task.

Installation by platform and deployment method

For a small pilot or individual devices, the manual guides cover installation on Windows and macOS. Prepare an automated Windows rollout with the command-line and software deployment runbook; prebuilt virtual machines additionally require the VDI gold-image process. For Macs, the Jamf Pro and MDM path explains central deployment, including the required profiles.

Linux is not another variant of the Windows or macOS Endpoint installer. Sophos Fusion (formerly Sophos Central) handles its installation, scripted deployment and gold images as Sophos Protection for Linux, or Server Protection. The dedicated process is described in Install and deploy Sophos Protection for Linux.

Configure protection features deliberately

Enabling every switch indiscriminately does not improve the baseline. The Threat Protection settings explain HTTPS decryption, its privacy implications and the associated exclusions. Set product- or application-specific scanning exclusions as narrowly and transparently as possible. The Scheduled Scans runbook explains whether additional scheduled scans are needed and how to plan them.

Use separate decision and configuration paths for user and device controls: Web Control for websites and categories, Application Control for applications, Peripheral Control for connected Windows and macOS devices, and Data Loss Prevention for data control rules. Define maintenance windows, software versions and distribution infrastructure separately under Updates, Update Cache and Message Relay.

Optionally extend XDR and MDR integrations

With an appropriate XDR or MDR licence, the tenant can combine data from additional Sophos and third-party products. The Central-wide runbook Set up and validate XDR integrations covers selection, licensing boundaries, connection and functional validation; it is not an Endpoint protection policy.

Clarify unresolved MDR questions before deployment

MDR sensor entitlement and the Windows installer product value mdr remain unresolved. The official MDR installation help still names MDR Essentials for XDR Sensor, while the service overview names MDR and MDR Plus. This does not establish entitlement for every current tier. The MDR Windows instructions also use mdr, but the Windows CLI product list does not include it. This proves neither that the value is invalid nor that xdr or xdrsensor is equivalent; do not substitute a value on your own.

Before deploying an MDR sensor, confirm the contracted tier/SKU, active licence in the correct tenant, platform and intended installation path with Sophos or the responsible partner. If anything is unclear, keep that deployment step on hold; obtain written confirmation of the Windows product value for the installer version in use and the resulting software scope. A visible option is not proof of entitlement. Check already-managed devices using Agent Mode and software validation; an Endpoint installation and green health state alone do not confirm an operational MDR service.

Health and reporting

After rollout, the Protection Overview with Events and Reports helps determine whether protection status and event flow are plausible. The Account Health Check adds a view of deviations from Sophos recommendations, but does not replace pilot acceptance or functional testing. Configure and monitor recurring recipients, schedules and delivery failures through scheduled Reports.

If installation or operations fail, Endpoint Self Help and SDU provide local diagnostics and the required logs. You can then open a Sophos Support case with actionable details. Do not improvise partner access: grant and revoke it through Partner Assistance and time-controlled Remote Assistance.

1. Define scope and ownership

Before the first installation, record which devices and operating systems are in scope, what is expressly excluded, and who approves changes. At a minimum, assign organisational ownership for:

• tenant and roles,
• Endpoint and policies,
• network and proxy,
• Alerts and security incidents,
• application pilot and acceptance,
• deputies for critical access and decisions.

Define measurable acceptance criteria as well: the device appears in the correct tenant and group, receives the intended Agent Mode and effective policies, reports healthy, and produces the planned test Events. Name the rollback, support path and decision owner before a failure occurs.

2. Secure tenant and administrator access

Configure MFA for all administrators. Do not use far-reaching privileges for routine work; assign roles by task and review them regularly. Test account recovery and deputy access rather than improvising after an authentication device is lost.

See Secure Sophos Fusion sign-in with MFA and an IdP and Plan Sophos Fusion Endpoint roles and permissions for the detailed decisions.

3. Determine software scope and platform boundaries

Check licence, device type, operating system and intended Agent Mode together. What appears in a tenant depends on the actual subscription and platform, so do not infer availability from a screenshot or general product page.

Endpoint provides Sophos Endpoint protection, XDR adds the intended Detection and Response capabilities, and XDR Sensor is not stand-alone malware protection. A sensor design still needs a separately operated protection product. Manage Sophos Endpoint Agent Mode and software explains selection and changes; Understand Sophos Fusion Endpoint licences covers licensing boundaries.

Use separate pilot paths for Windows and macOS. Check current system requirements and retirement notices before approving a platform, using Plan Sophos Endpoint system requirements and lifecycle.

Linux Runtime Detection Profiles protect Linux workloads and cloud-native environments. Plan their policy selection and sensor deployment as a separate workload track with the current Sophos prerequisites, not as an incidental part of a Windows or macOS Endpoint rollout.

The profile lifecycle starts at My Products > Global Settings > Protection and Remediation > Linux Profiles. Create Profile creates version 1; Profile Name, Content Version and optional Change Description document the state. Then enable or disable individual rules on the Detection Analytics, Smart Policy and BETA Ransomware tabs. Assign a new or changed profile first to a Linux Runtime Detection policy for pilot servers and verify it with an expected test alert. Create New Version preserves history for later tuning. Duplicate clones the latest version as an independent profile; changes and assignments of the copy don’t affect the source profile. You can delete an active profile only after removing it from all assigned policies.

For advanced tuning, use the Category, Enabled, Modified and Configurable filters. Hide filters only hides them; Clear All removes them. Allow/Block List entries apply to the selected rule. Sophos Protection for Linux adopts updated SophosLabs content automatically, while Sophos Linux Sensor content must be updated deliberately. A YAML file from Export Latest Version contains only your changes to the defaults, not a complete runtimedetections.yaml. For Sophos Linux Sensor, merge only these changes into the existing file and edit only fields and data types supported by the schema for the deployed content version. Stop before the pilot on concrete validation failures: invalid YAML syntax or indentation, unknown keys, wrong data types, missing required fields, or invalid rule values. Only after parser and schema validation succeeds, version the file, deploy it to pilot servers, and check alerts and runtime state. If issues occur, reassign the previous profile version or restore the previous validated sensor configuration.

4. Design identities, groups and policies

User policies follow a person, while computer policies follow a device. First define the authoritative source for users and groups and how duplicates or stale identities will be avoided. Manage Sophos Fusion Endpoint users and groups explains the implementation.

A maintainable device model normally starts with a few clear groups:

• pilot devices with actively supported users,
• standard production devices,
• critical or technically different devices,
• time-limited exceptions,
• test devices for new software versions.

For each policy type, the first matching active policy applies. Validate the baseline, order and effective assignment before mass deployment. Deleting a policy in Central can’t be undone: export or document its settings and assignments and identify affected devices first. Follow Build Sophos Fusion Endpoint policies correctly for the complete model.

Do not enable or disable controls indiscriminately. Assess Threat Protection, Web, Applications, Peripherals, DLP, DNS Protection, updates, Tamper Protection, Data Collection and Response according to licence, platform and business need. Introduce new controls in a small pilot where appropriate. Every exception needs a reason, owner, limited scope and review date.

5. Check network and updates before installation

The Endpoint must reach the required Sophos services in the device and service context actually used. A successful browser request by an administrator does not prove that installation, agent communication and updates work through a proxy, TLS inspection or segmented network.

Before the pilot, test DNS, HTTPS, proxy authentication, certificate validation and intended fallback paths. Current connection precedence and dynamic Sophos destinations are covered in Sophos Endpoint network and proxy requirements.

Update bandwidth, software packages, deployment stages, Update Cache and Message Relay require a separate operational decision. A global bandwidth setting is not a substitute for capacity planning or a pilot. See Sophos Endpoint updates, cache and Message Relay.

6. Deploy a representative pilot

Obtain the installer intended for the tenant and purpose under My Environment > Installers. Treat installers as access material and distribute them only through controlled channels.

Under Endpoint, installers are available for Protection, ZTNA and Device Encryption. The complete Windows and macOS installers contain the Endpoint products covered by the tenant’s licence; Choose Components lets you select the required scope before downloading. This Endpoint installer does not apply to Linux, which belongs to the separate Server Protection track described above.

If DNS Protection for endpoints is to be used as part of Workspace Protection, this handoff applies only to supported Windows endpoints; macOS and Windows Server are not included. On these Windows endpoints, the installed Endpoint agent is only the shared prerequisite. Set up and validate the DNS component and its own policy afterwards by following the separate runbook Configure Sophos DNS Protection for endpoints; do not incorporate them into this process as a general Endpoint protection policy.

Keep platform workflows separate:

• Windows: Install Sophos Fusion Intercept X
• macOS: Install Sophos Fusion Endpoint
• automated Windows rollout: Automate Sophos Endpoint rollout on Windows

The pilot must include more than uncomplicated IT laptops. Cover relevant OS versions, network segments, home office or VPN, business-critical applications, and existing security, backup, DLP and encryption software. Observe changes on a few devices first; a delay between waves does not replace technical acceptance.

7. Validate the pilot technically

Approve a pilot device only when all planned controls have passed:

1. The local agent reports healthy.
2. The device appears in the correct tenant and planned group.
3. Agent Mode and installed components match the approved design.
4. The device page shows the expected effective policies.
5. Last Active, Events and updates progress plausibly.
6. An approved protection test produces the expected Event or Alert.
7. Business applications, network changes and any required restart have been tested.
8. Alert delivery, triage and escalation work.
9. Uninstallation or another defined rollback has been verified on a test device.

Safely test Sophos Endpoint protection features covers safe tests. If a device remains unhealthy, do not reinstall blindly: use Handle Sophos Endpoint Alerts and Account Health and Troubleshoot Sophos Endpoint installation errors systematically.

The Account Health Check is an additional control view. It identifies selected deviations from Sophos recommendations, but does not prove application functionality or complete tenant security. Automatic fixes may affect many devices or policies and must be handled as a change. See Use Sophos Fusion Account Health Check correctly.

8. Decide response and forensic readiness deliberately

Before broad rollout, decide who handles Alerts, when a device is isolated and which data may be collected for investigation and support. Forensic Snapshots capture device activity. Their storage, conversion, optional upload to an organisation-owned S3 bucket and access therefore require deliberate security and privacy decisions.

Create, retain and convert Forensic Snapshots

Create a snapshot from My Environment > Computers & Servers > device > Summary > More actions > Create forensic snapshot > Create now, or select Create forensic snapshot in a Threat Graph. Manually created snapshots default to %PROGRAMDATA%\Sophos\Endpoint Defense\Data\Forensic Snapshots\; detection-generated data is stored in %PROGRAMDATA%\Sophos\Endpoint Defense\Data\Saved Data\. With Tamper Protection enabled, access requires an elevated command prompt. The default period is the previous two weeks; choose another period or All log data at Global Settings > Products and Services > Endpoint and Server > Forensic Snapshots. Define free-space requirements, authorised users, retention and secure deletion first.

For analysis, preserve an evidential copy of the .tgz. Choose the 64-bit exporter on 64-bit Windows; only 32-bit Windows requires the 32-bit build. Before downloading, check the architecture in PowerShell with (Get-CimInstance Win32_OperatingSystem).OSArchitecture.

Only at this action, start acquisition from Sophos over HTTPS: obtain 64-bit SDR Exporter or obtain 32-bit SDR Exporter. Complete the Sophos form and accept only the file then supplied by Sophos. Put it in a newly created working directory writable only by the responsible investigators; do not use an email attachment or third-party mirror. Before execution, verify the Authenticode signature and create an evidence hash. The hash records the exact acquired version, but without a separately published Sophos reference value it is not independent proof of origin:

$tool = '.\SDRExporterx64.exe'
$expectedSubject = $env:SDR_EXPORTER_EXPECTED_SUBJECT
$expectedThumbprint = $env:SDR_EXPORTER_EXPECTED_THUMBPRINT
if ([string]::IsNullOrWhiteSpace($expectedSubject) -or
    [string]::IsNullOrWhiteSpace($expectedThumbprint)) {
    throw 'Set the approved signer subject and thumbprint before validation.'
}
$expectedThumbprint = ($expectedThumbprint -replace '\s', '').ToUpperInvariant()
if ($expectedThumbprint -notmatch '\A[0-9A-F]+\z') {
    throw 'The approved signer thumbprint is not hexadecimal.'
}

$sig = Get-AuthenticodeSignature -FilePath $tool
if ($sig.Status -ne 'Valid' -or $null -eq $sig.SignerCertificate) {
    throw "SDR Exporter: Authenticode status is $($sig.Status)."
}
$actualThumbprint = ($sig.SignerCertificate.Thumbprint -replace '\s', '').ToUpperInvariant()
if (-not [string]::Equals($sig.SignerCertificate.Subject, $expectedSubject,
        [StringComparison]::Ordinal) -or
    -not [string]::Equals($actualThumbprint, $expectedThumbprint,
        [StringComparison]::Ordinal)) {
    throw 'SDR Exporter: signer does not exactly match the approved acquisition record.'
}

$chain = [Security.Cryptography.X509Certificates.X509Chain]::new()
$chainBuilt = $chain.Build($sig.SignerCertificate)
[pscustomobject]@{
    Status              = $sig.Status
    StatusMessage       = $sig.StatusMessage
    SignerSubject       = $sig.SignerCertificate.Subject
    SignerThumbprint    = $actualThumbprint
    SignerIssuer        = $sig.SignerCertificate.Issuer
    SignerNotBefore     = $sig.SignerCertificate.NotBefore
    SignerNotAfter      = $sig.SignerCertificate.NotAfter
    ChainBuilt          = $chainBuilt
    ChainStatus         = ($chain.ChainStatus.Status -join ', ')
    TimestampSubject    = $sig.TimeStamperCertificate.Subject
    TimestampThumbprint = $sig.TimeStamperCertificate.Thumbprint
}
$chain.ChainElements | ForEach-Object {
    [pscustomobject]@{
        ChainSubject    = $_.Certificate.Subject
        ChainThumbprint = $_.Certificate.Thumbprint
        ChainStatus     = ($_.ChainElementStatus.Status -join ', ')
    }
}
Get-FileHash -Algorithm SHA256 -Path $tool

Before running the block, set SDR_EXPORTER_EXPECTED_SUBJECT and SDR_EXPORTER_EXPECTED_THUMBPRINT to the exact values in an internally approved acquisition record obtained through a separate trusted process; never copy them from the file being checked. Status Valid and exact matches for both values are release criteria. Retain the displayed signer chain and timestamp details with the SHA-256 output as evidence. The hash identifies the acquired file but, without a separately trusted reference value, does not establish provenance. If an approved value is absent, any check fails, or the hash later differs, do not run the file: delete it and investigate or reacquire it through the Sophos link above. Then run the tool and input only from the protected location in an elevated command prompt, using different input and output paths:

SDRExporterx64.exe -i <snapshot.tgz> -o <snapshot.sqlite> -f sqlite

For JSON, use -f json and a suitable output filename; the 32-bit executable is SDRExporterx86.exe. Quote paths containing spaces. After an error-free exit, verify that the output is non-empty and can be opened and queried as SQLite or parsed as JSON. Record the input hash, exporter hash, command, time and output path in the incident log; protect and retain the converted file like the snapshot.

If conversion fails, do not experiment on the original. Check architecture and filename, signature, quoting, read and write permissions, free space and the integrity of the .tgz working copy, then use a new output path. A partial output is not a result. The exporter installs nothing: rollback means stopping the process and securely removing incomplete outputs and, after completion, the exporter from the working directory. Delete a .tgz working copy only after verified conversion and under the incident process. Keep the evidential original and required logs unchanged until their retention period ends.

Optionally upload to your own S3 bucket

Direct S3 upload is available only for Windows devices with an XDR or MDR licence. In AWS, give a dedicated managed policy only s3:ListBucket for arn:aws:s3:::<bucketName> and s3:PutObject for arn:aws:s3:::<bucketName>/*. At Global Settings > Products and Services > Endpoint and Server > Forensic Snapshots, turn on Upload forensic snapshot to an AWS S3 bucket. Use the displayed AWS Account ID and AWS External ID in a dedicated IAM role trust policy for sts:AssumeRole. After AWS propagation, save the S3 bucket name, optional directory and Role ARN in Central.

Choose the AWS Region with data residency, transfer latency and cost, and disaster-recovery requirements in mind. Before saving in Central, allow the IAM role to propagate to all AWS Regions; this can take up to five minutes.

Restrict access to this role and authorised investigators with a bucket policy and IAM permissions boundary. Add a lifecycle rule for incomplete multipart uploads and later deletion under your retention policy. KMS-encrypted buckets aren’t supported for this upload; AES-256 is supported and requested by Sophos during upload. Bucket names must avoid unsupported special characters, and firewalls must allow S3 access. Approve the setup only after a pilot snapshot appears completely at the expected path, an authorised investigator can read and convert it, and unauthorised access is denied. Remove obsolete roles, policies and Central assignments afterwards.

Investigate Sophos Endpoint detections and Threat Graphs places the wider investigation and response workflow in context.

Allow or block files tenant-wide

File allowances and hash blocks belong to a verified response or false-positive process, not the generic baseline. At Global Settings > Protection and Remediation > Allow and Block > Files, Allowed Applications shows where and how an allowance originated. Depending on platform, you can allow by certificate, SHA-256 or path; certificates and paths may cover more than one file version. An allowed application can run tenant-wide for all users and is excluded from further threat detections, while exploit, ransomware and malicious-behaviour checks continue. Before selecting Allow, verify publisher, signature or hash, owner, reason, scope and expiry. Remove withdraws the allowance; then verify on a pilot device that a deliberately triggered detection works again.

Blocked Items requires an XDR licence and blocks suspicious applications by SHA-256 on Windows devices. It doesn’t block trusted-reputation files or other object types. Select Add, enter SHA-256 and Reason, and select Save to apply tenant-wide. Allowed and blocked file entries share one tenant-wide limit of 5,000 entries, so review the combined capacity of both lists before bulk additions. Test on a pilot device that the application doesn’t start and the expected event appears. Remove is the rollback and must also be checked on the pilot. See Configure Sophos Fusion Endpoint exclusions safely for other exclusion types.

9. Approve waves and transfer to operations

For every wave, define included devices, monitoring ownership and stop signals. Suitable stop signals include clustered installation failures, absent agent communication, unexpected policy assignments, application failures or an Alert volume that cannot be handled.

Routine operations must include at least:

• daily ownership for critical Alerts and outbreaks,
• regular review of inactive or unhealthy devices,
• reviews of licences, Agent Modes and platform lifecycle,
• controlled software and policy pilots,
• expiry checks for exceptions,
• checks of the proxy, Update Cache and Message Relay,
• documented response, privacy and support paths.

A wave is complete only when its devices are not merely installed, but technically accepted and incorporated into these operational processes.

Frequently asked questions