Selectively export and import Sophos Firewall configuration

Under Backup and firmware > Import export, Sophos Firewall can export the full configuration or a selected part of it. The export can be reviewed on a protected admin system, changed in a controlled manner, and imported again as a .tar file. This is useful for clearly scoped object changes, migrations, and documented bulk changes.

However, an import isn’t a restore. It doesn’t replace the entire current configuration, but adds new settings and overwrites matching settings from the import package. Settings not included remain in place. Every production import therefore requires a full firewall backup with its password and SSMK, a management recovery path, and a test plan.

⚠️ Important: Entities.xml can contain passwords, secrets, users, network objects, rules, and other sensitive data. Process the files only on a trusted admin system, don’t distribute them through uncontrolled cloud storage or messaging services, and archive or delete them securely after the change.

Perform a selective import in ten steps

1. Record the objective, affected object types, and expected changes.
2. Create a full restore backup and verify the backup password and Secure Storage Master Key.
3. Record target firmware, pattern version, platform, number of ports, and model compatibility.
4. Go to Backup and firmware > Import export and select Export selective configuration.
5. Select only the required configuration types and deliberately include dependencies.
6. Store the exported .tar file securely and keep it unchanged as a reference.
7. Extract the package, review Entities.xml, and change only the planned fields.
8. Package Entities.xml and any existing companion files again as a .tar archive without changing their names.
9. Import the package during a maintenance window and enter the SSMK if sensitive information is involved.
10. Check objects, dependent policies, the expected Firewall Rule ID, logs, and real traffic.

If the import shows an unexpected scope, a dependency is missing, or target-platform compatibility isn’t clear, don’t import it into production. The unchanged export package serves as a comparison and the full backup as the recovery path.

Don’t confuse import/export with a backup

A full backup represents the firewall as a recovery package. During a restore, it replaces the current configuration, activates the management address contained in the backup, and restarts the firewall. The import/export area works with configuration objects instead:

• New settings from the package are added.
• Existing matching settings are updated with the imported values.
• Settings not included in the package remain unchanged.
• A selective import therefore doesn’t automatically remove old objects or previous values outside the imported object.
• A successful import proves neither that all dependencies exist nor that the traffic path works.

For hardware replacement, reimaging, full recovery, or a major model change, backup and restore remains the primary workflow. Import/export fits when the scope is clearly limited, object dependencies are understood, and the effect can be validated individually.

Prepare the export

Define scope and dependencies

Under Export selective configuration, select the required configuration types. Include dependent entity includes dependent objects. This option is helpful, but it doesn’t replace a content review.

One example is a firewall rule that refers to hosts, services, a schedule, a web policy, or NAT objects. If only the rule is exported, dependencies may be missing on the target firewall or may point to objects with different names. Before the export, document:

• which primary object is to be changed or transferred;
• which hosts, networks, services, groups, profiles, and policies depend on it;
• which identically named objects already exist on the target;
• which production flows may be affected after the import;
• how the previous state will be restored.

There is a documented exception for RED configurations: REDDevice doesn’t automatically export the required DHCP server configuration, even when Include dependent entity is enabled. Select DHCPServer separately or recreate the DHCP server in a controlled manner after the import.

Check version and target platform

Sophos supports importing to the same or a later firmware version. The target firewall’s pattern version must also be the same or later. If it is older, update the patterns first and then schedule the import again.

Selective configurations can only be transferred from a lower model to the same or a higher compatible model. The target needs at least the same number of Ethernet ports. If port names or platform capabilities differ, clarify the mapping beforehand. For such migrations, the Backup Restore Assistant is often more suitable than a manual XML modification.

Wireless models have additional limits for LocalWiFi, frequency bands, SSIDs, older Security Modes, TKIP, and bridge assignments. A successful partial import doesn’t mean every wireless setting was transferred. Review the target configuration object by object.

Classify the SSMK and sensitive information

The Secure Storage Master Key isn’t entered during export. It is decisive during the later import if the package contains passwords, secrets, keys, or dependent configurations.

• On another firewall, or after a factory reset or reimage, enter the SSMK that belongs to the export.
• Without the matching SSMK, SFOS can import the remainder, but sensitive information and dependent configurations are lost.
• If the export contains no sensitive information, no SSMK is required.
• An import without an error message therefore doesn’t prove that every secret and dependency was transferred.

The SSMK isn’t stored with the export file. Protect the export, full backup, backup password, and SSMK separately, but associate them unambiguously with the same firewall and time period for recovery.

Review and edit the export package safely

Understand the package contents

After export, a .tar file is available. A package without sensitive information may contain only Entities.xml. For sensitive configurations, it also contains:

• hashFile.json
• propertyfile

Extract the package into a dedicated working directory:

tar -xvf <export-file>.tar

Don’t rename Entities.xml. If hashFile.json and propertyfile exist, keep these files as well and include them again. A file export isn’t a suitable format for uncontrolled global search-and-replace operations.

Prepare changes traceably

For reports, comparisons, and structured preparation, Sophos Firewall Config Studio can analyze Entities.xml locally in the browser. The same rule applies there: review generated configuration before importing it. Interfaces, zones, NAT, VPN, Device Access, Authentication, certificates, and HA in particular require their own validation.

Before a manual edit, copy the unchanged Entities.xml. Change only the planned values and then review the diff against the original. Don’t rebuild element names, IDs, references, or filenames on suspicion. If the meaning of a field is unclear, the process stops before import.

Package the files again as a TAR archive:

tar -cvf <import-file>.tar Entities.xml hashFile.json propertyfile

If the original export contained only Entities.xml, package only that file. Don’t invent empty companion files or take them from another export.

Import the configuration

1. Keep an existing full-admin session and an alternative management path open.
2. Confirm the maintenance window, backup file, password, SSMK, and rollback decision.
3. Open Backup and firmware > Import export.
4. Under Import file, select only the prepared .tar package.
5. Start Import and enter the matching SSMK when SFOS requests it.
6. Document success, warnings, and rejected objects in full.
7. Before further imports, first validate the effect of this package.

For a change, several small, logically separated packages are usually safer than one large unspecific import. They make the error scope, dependencies, and recovery path easier to understand. This is an operational decision, not a guarantee that arbitrary objects can be imported independently.

For recurring automation on SFOS 22.0 MR2 or later, use the separate workflow export and import configuration through the Sophos Central API. Local WebAdmin import remains relevant for targeted manual changes and independent verification.

Validate the import completely

Validation starts with the object and ends with the real traffic path:

1. Open the imported objects and their values in WebAdmin.
2. Check dependent hosts, services, groups, profiles, and policies.
3. For passwords, secrets, or keys, test the function, not only the visible object row.
4. Open the affected firewall, NAT, web, VPN, or Authentication rule and verify order and references.
5. Run one controlled positive and negative test.
6. In Log Viewer, compare the expected Firewall Rule ID, Action, user, Source, Destination, and Service.
7. For HA, separately check cluster state and functionality after a planned role switch; don’t assume session continuity.
8. Document the Audit Trail, time, import file, test result, and rollback decision.

For multi-layer policy validation, see systematically test firewall rules. For import errors, apiparser.log, validation.log, validationError.log, applog.log, and the service-specific log may be relevant. Sophos Firewall services and logs maps the log files.

Troubleshoot typical errors safely

Import reports an incompatible version

Compare active firmware, export version, and pattern status on both firewalls. Don’t try to make an older target firewall fit through manual XML changes. First establish a supported firmware and pattern status or redesign the migration path.

Objects are missing despite a successful import

Check whether Include dependent entity was used and which dependencies the object type actually has. For RED, also check DHCPServer. Don’t hide missing dependencies with broad replacement objects or Any.

Users, OTP, or secrets are missing

Externally authenticated users that appeared locally automatically at sign-in aren’t exported like manually created users. For MFA, OTPSettings exports the settings, while OTPTokens contains only issued tokens for manually created local users. Also check the SSMK and import target.

If sensitive information is missing, don’t simply place a new secret over the existing object. First determine whether the wrong SSMK, an export without SSMK protection, or a non-exportable external identity is the cause. Then test the user and group effect with a fresh sign-in. Create and manage local users describes the account lifecycle.

TAR file is rejected

Check filenames and package contents. SFOS expects a .tar file; Entities.xml must not be renamed. Existing hashFile.json and propertyfile must come from the same export. Don’t rename a ZIP file to .tar.

Import succeeded, but traffic doesn’t work

Check object references, zones, rule order, NAT, routing, user/group context, and the expected Firewall Rule ID. A green import status confirms only the configuration operation, not its functional effect.

Rollback and checklist

A selective import has no universal undo switch. For small, fully documented object changes, previous values can be restored in a controlled manner. If scope or dependencies are unclear, use the prepared full restore path.

Before completion, all of the following must be true:

• full backup, password, and SSMK are available;
• unchanged export package and edited version are archived separately;
• target version, patterns, and model compatibility are confirmed;
• only required objects and dependencies were imported;
• warnings and failed partial objects have been reviewed;
• secrets and dependent functions were tested in practice;
• positive and negative production traffic hit the expected rule;
• logs and Audit Trail match the change;
• for HA, the state of both nodes was checked;
• working copies aren’t left unprotected on the admin system.

Frequently asked questions