Server Lockdown to Unauthorized File Protection: Pilot and Migration
In brief: Select one currently locked-down policy group, document its current state and recovery path, and prepare a disabled, unassigned Monitor copy before unlocking. Unlock pilot servers only during the approved change window, then assign and enable the copy for those servers alone. Wait at least 24 hours after each policy change before reviewing UFP events; narrowly allow legitimate executions and repeat the cycle. Only then test the refined Monitor copy as a separate Block policy with tightly limited assignments. Leave the original Lockdown policy and its assignments unchanged for servers that are still locked down.
Starting point and approval
Support for Server Lockdown is scheduled to end in October 2026; no specific day has been given. Existing Lockdown policies are now called Unauthorized File Protection (UFP/SUFP). Their allowed and blocked entries survive the rename. But the rename does not migrate a locked-down host: it must be unlocked before an enabled UFP policy can be applied. Lockdown also trusts files created or modified by allowed software; identical policy entries do not imply the same trust baseline under UFP. This procedure is for existing Windows servers with Server Lockdown, not a new Lockdown installation; Server Lockdown is unavailable with XDR Sensor.
Before making changes: For each tenant and policy group, record the servers, owners, maintenance window, and Lockdown status under My Products > Server > Servers. In each server’s Summary view, record product/agent versions; under Policies, record the policy actually applied to each host. Document the original policy, its entries, assignments, and priority as an unchanged reference. Identify representative test workloads and owners for services, scheduled tasks, updates, and MSI installations; a successful MSI setup does not prove that extracted PE files will run later. Check licensing, operating system, versions, and permissions. Confirm application backups, the recovery path, and escalation contacts. Do not start without an approved window, a tested recovery path, and explicit acceptance of the risk of unlocking. Portal views alone do not prove that protection is working on the host.
Pilot one policy group
- Define the pilot. Identify a small number of representative test servers, their group, and intended policy. Record their Lockdown status, service state, and critical application workflows beforehand. Stop if the effect of the policy is unclear or recovery is unavailable; do not migrate a second group at the same time.
- Prepare Monitor before unlocking. Under My Products > Server > Policies, clone the existing UFP policy (formerly Lockdown) and name it
Monitor – [Original name]. Immediately, in the copy, inspect and remove inherited Assigned Servers and Assigned Server Groups: the clone must not broadly include the still-locked group or other servers. Only in this copy, remove all inherited entries under Allowed items (called Allowed files/folders in older Lockdown views); do not delete the original policy’s allowances. Review inherited Blocked items (formerly Blocked files/folders) for obsolete entries and entries that are still needed. Under Settings, enable Enable tracking of unauthorized file changes and select Monitor execution of unauthorized files without blocking. Save the copy disabled and without assignments for now. Do not change the enabled original policy, its priority, or its assignments for hosts that are still locked down. - Unlock the pilot and enable Monitor. During the change window, go to My Products > Server > Servers > [Server name] for each selected host, choose Unlock, confirm, and then check its status. Unlocking does not automatically remove the local Lockdown component; uninstalling it is not a pilot step. Only now, under My Products > Server > Policies, add exclusively the unlocked pilot servers or their narrowly defined test group to the Monitor copy’s Assigned Servers/Assigned Server Groups. Before enabling and saving, check again that no inherited or other broad assignments remain. Enable and save the copy. Under My Products > Server > Servers > [Server name] > Policies, verify for each pilot server that the Monitor copy is actually applied as its UFP policy. If another policy applies, correct the scope and priority of the pilot copy first, without changing the original or priorities for hosts that are still locked down. Monitoring reports unauthorized executions instead of blocking them.
- Observe and allow selectively. Exercise representative services, jobs, updates, and installers. No earlier than 24 hours after assignment or each subsequent policy change, review UFP events under My Products > Server > Servers > [Server name] > Events or Reports > General Logs > Events. Match the server, time, file, and operation against the test workload. Add narrow allowances under Allowed items in the Monitor copy only for executions confirmed to be legitimate by the responsible team; do not broadly allow writable temporary or download folders. Document the decision and owner, choose Save on the policy page, wait at least another 24 hours, and review new events. Repeat until no unexplained events occur during the legitimate workflows tested. No events without a relevant test workload do not constitute approval to enable Block; investigate unknown activity rather than allowing it blindly.
- Test Block separately. Clone the refined Monitor copy and name it
Block – [Original name]. Immediately inspect and remove all inherited Assigned Servers/Assigned Server Groups from the Block copy; before enabling it and selecting Save, assign only the intended unlocked pilot servers so that no other host inadvertently receives Block. Under Settings, select Block execution of unauthorized file, then enable and save the copy. Retain the Monitor copy as a targeted fallback. Under My Products > Server > Servers > [Server name] > Policies, check that Block is actually applied to each pilot server; if necessary, adjust only the scope/priority of the pilot copies. Positively test services, jobs, and updates, check Events for unexpected blocks, and review again no earlier than 24 hours after assignment or changes. Do not run a test file in production without separate approval. Only after documented acceptance should you take the next policy group through the same procedure.
Stop, rollback, and escalation
Stop expanding the rollout if blocks remain unexplained, applications fail, expected events are missing despite a relevant test workload, or the wrong policy is applied. Preserve the server, time, file, applied policy, and service state; do not use a broad Allow exception as a quick fix. If Block causes problems after approval, remove the Block assignment for affected pilot servers or disable the Block copy for that scope. That alone is not a rollback: the enabled Monitor copy must be assigned to each affected host and be the highest-priority matching UFP policy, or another policy could take effect after Block. Correct the scope and priority of the pilot copies accordingly, without changing the original policy or assignments for hosts still locked down. Save and verify the Monitor policy actually applied to each host under My Products > Server > Servers > [Server name] > Policies; then retest services and installers and observe events. Reverse erroneous Allow/Block entries only against the documented change. If the disruption persists, invoke the application recovery plan and involve the operations owners and Sophos Support.
Limit of the rollback path: Switching to Monitor does not restore the host’s former locked-down state, the Lockdown trust baseline, or changed files. Even the retained original policy does not guarantee that the host can be locked down again with identical effects. Do not improvise a relock or remove the agent; if needed, review the host-specific recovery path with Sophos Support. Protection may differ between unlocking and Block acceptance; an uninterrupted level of protection is not guaranteed.
For UFP entries and a general pilot on Windows servers that are already unlocked, see Unauthorized File Protection for Windows Servers.