Safely Roll Out Unauthorized File Protection for Windows Servers

Quick path: In My Products > Server > Policies, create an Unauthorized File Protection policy for a small pilot group of Windows servers and enable the policy itself. Under Settings, also turn on Enable tracking of unauthorized file changes and select Monitor execution of unauthorized files without blocking. On each server, check the applied policy under Policies, review events and required software, and allow only specifically justified items. Only then test Block execution of unauthorized file for the same pilot. Saving and assigning a policy alone proves neither that it is enabled nor that it is taking effect on the server.

Important for existing Server Lockdown installations: Renaming the policy to Unauthorized File Protection (SUFP) is not evidence that the installed Lockdown product has been migrated. According to Sophos, allowed and blocked files and folders already configured in existing Lockdown policies are unaffected by the renaming. A locked-down server must be unlocked before the new policy can be used. Do not use this article as instructions to remove Lockdown components, automatically convert policies, or restore a previous host state. Inventorying existing installations, unlocking servers, and changing the host setup belong to the separate Lockdown-to-UFP migration process; the team responsible for that process must first review and approve the steps appropriate for the specific host.

What the policy protects—and where its limits lie

Unauthorized File Protection is a policy for Windows servers only. It tracks file operations by non-privileged processes that create, modify, or move Portable Executable (PE) files. Creating hard links and renaming folders are also monitored activities. Its purpose is to control the execution of unauthorized files, not to block all write operations in general or provide File Integrity Monitoring for arbitrary files.

File reputation affects the decision: local files with a high reputation can run unless they are on the block list. Changes to files with low to medium reputation are tracked; after an unauthorized process modifies such a file, execution may be blocked in Block mode. In Block mode, a block-list entry blocks files regardless of reputation, subject to the exceptions Sophos specifies for Sophos and system files; in Monitor mode, unauthorized execution is reported instead. If the aim is to prohibit a legitimate, widely used application altogether, consider the separate Server Application Control policy rather than a blanket SUFP allow-list exception.

MSI is not PE. An MSI installation package is not simply blocked as a PE file. PE files extracted during installation or launched afterward can, however, be blocked, particularly if they lack a high reputation and are not covered by the allow list. An installation can therefore fail or appear to succeed while the installed application subsequently fails to start. MSI paths, or folders containing MSI files, can be added to the allow or block list; Sophos takes them into account when deciding whether installation and execution of the resulting PE files are permitted. Allowing an MSI is therefore not a risk-free substitute for checking the vendor, source, and executable files actually needed.

Prepare the pilot and start in Monitor mode

Choose a few representative, unlocked Windows servers with a known maintenance window—for example, a test server with the same application and update chain as the production group. Record the tenant, server names, assigned server group, currently effective policy, services, and scheduled installation or update jobs. Preserve the previous policy settings and assignment so you can restore them selectively if needed. An application backup or a tested application recovery procedure does not replace policy verification.

1. Open My Products > Server > Policies and create a policy of type Unauthorized File Protection. Give it a distinctive name such as SUFP-Windows-Pilot; the name is your choice, not a Sophos default. Assign it only to the documented pilot servers or their small server group. Before saving, check whether a higher-priority policy of the same type overrides the pilot policy or whether the assignment inadvertently includes other servers. On the policy detail page, explicitly check that the policy itself is enabled; assigning a disabled policy or enabling tracking does not enable the policy.
2. Open Settings, turn on Enable tracking of unauthorized file changes, and select Monitor execution of unauthorized files without blocking. Save the policy. Enable tracking is a setting within the policy, not the policy’s separate on/off switch. Monitor mode reports unauthorized executions rather than blocking them; it is not an approval check that automatically distinguishes legitimate files from malicious ones.
3. For each pilot server, open My Products > Server > Servers > [server name] > Policies. Before testing, confirm there that the applied policy’s name and type Unauthorized File Protection match the pilot policy; if Base or another higher-priority policy applies instead, correct the scope, enabled state, and priority first. Record the initial state and check the same tab again after making changes. Only then run normal services, scheduled tasks, updates, and an approved application-installation test during the pilot window. For noteworthy events, record the server, time, file, path, SHA-256 or signer (if available), executing process, and the application owner. Without a representative workload, a period without events does not prove that Block mode is safe for production.

Keep allow and block entries narrow

Under Allowed items, Add allowed item lets you add a File, Folder, SHA256, or Signer entry; after completing the dialog, also click Save on the policy page. Matching allowed items are treated as privileged. Prefer a fully qualified file path or, for a specific file that does not change, its verified SHA-256 hash. A folder and its subfolders, or a signer, can cover more software and need a separate risk assessment. Do not broadly allow writable download or temporary folders; check the actual update chain and write permissions first.

Under Blocked items, Add blocked item likewise offers File, Folder, SHA256, or Signer. A block list is no substitute for malware detection or a directory inventory that has not been reviewed. Wildcards and variables are available for file and folder paths, not generally for SHA256 or Signer. For mapped remote drives, use the original UNC path; for local folders mapped with subst, use the original local path. The mapped drive letters are not reliable policy paths here. Save each entry in the dialog and on the policy page, then check its effect again in the pilot.

Verify the effect and test Block mode selectively

Open My Products > Server > Servers, select a pilot server, and check again that the SUFP pilot policy is applied in the Policies tab. Also check Events and, for blocks, the recent entries in Summary: the Policies tab establishes which policy is applied, while events show observed executions or actual blocks. The event list includes the time, event, and Details where available. For a defined time window, use Reports > General Logs > Events. With EDR or XDR, authorized administrators may obtain further details through their own Live Discover queries against sophos_unauthorized_actions_journal; this is not required for the basic procedure and does not mean every environment provides the same query data.

Once legitimate workflows have been observed in Monitor mode and necessary exceptions are justified, change only the pilot policy to Block execution of unauthorized file and check again under Policies on the pilot server that this policy is applied. Positive test: Repeat the approved application or update workflow previously observed in Monitor mode. It must continue to work without unexpected block events; if no execution is deliberately blocked, a block event is not required. Optional negative test: Only in an isolated pilot environment and with approval, run a harmless PE file created specifically for this test and not allowed by the policy, whose unauthorized execution was previously observed as an event in Monitor mode. Expect a matching block event on the correct server only if execution is actually blocked; otherwise, do not assume blocking works—check the settings and reputation. Do not use malware or an unintended production workflow as a test. A block may also trigger a Sophos Endpoint Agent notification; on an unattended server, the console or event is the more reliable way to verify it.

Acceptance criteria before expanding the rollout: The enabled policy is applied with the correct name and type in the Policies tab of every pilot server; necessary services and installers still work after updates; unexpected events have been investigated; and an owner is assigned to handle new exception requests. Document any optional negative test separately; its block event is not a mandatory result for a successful positive test. Only then expand the scope gradually. Do not import a tenant-wide allow list from Monitor events without reviewing the entries.

If something is blocked: narrow down the cause and revert the change

If a service will not start or an MSI installation fails, first correlate the time and server with Events. Check whether the event actually belongs to Unauthorized File Protection, which PE path is affected, and whether another policy, the MSI contents, or another protection mechanism could be responsible. Then check the effective assignment, the path (UNC rather than a mapped path), reputation, block-list entries, and any existing narrow exceptions. Do not blindly allow an entire installation folder just because one PE file appears in an event.

To revert your own pilot policy change, set the documented pilot policy back to Monitor execution of unauthorized files without blocking, selectively remove unsuitable allow/block entries added during the pilot, and restore the original scope or assignment from your earlier record. Save, verify in the Policies tab of every affected server that the policy actually applied matches the documented initial state, retest the application workflow, and monitor new events. This reverts the policy change; it does not promise to restore files already modified or automatically roll back an MSI installation or a legacy Lockdown migration. If a service still does not work even in Monitor mode, or the host is still locked down, do not improvise further Lockdown or agent changes: preserve the status and events, then resolve the specific case with Sophos Support and the team responsible for the separate legacy migration.