Enable FIPS 140-3 on Sophos Firewall

Sophos Firewall supports FIPS 140-3 Level 1 mode under SFOS 22 on XGS hardware appliances, supported virtual platforms, AWS, and Azure. Enabling it is not a normal configuration change: The command performs a factory reset, restarts the firewall with factory settings, and then requires a new FIPS-compliant configuration.

The safe sequence is therefore:

1. Confirm the platform, firmware, and compliance requirement.
2. Inventory VPN peers, certificates, and required algorithms.
3. Store the backup, Secure Storage Master Key, and configuration documentation externally.
4. Plan a maintenance window, local console access, and a complete rebuild.
5. Enable FIPS only on a firewall that is still standalone.
6. Rebuild the basic setup and production configuration with approved algorithms.
7. Fully validate management, routing, rules, VPNs, certificates, and logs.
8. Configure HA only afterwards.

⚠️ Warning: system certification fips enable deletes the current configuration. The command must not be run without a tested recovery path, local console access, and a planned rebuild.

What FIPS 140-3 means on Sophos Firewall

FIPS 140-3 is a United States standard for cryptographic modules. SFOS 22.0 GA and its maintenance versions use FIPS-certified cryptographic modules. Enabling FIPS mode additionally restricts the algorithms that can be selected, creates suitable default policies, and validates newly created or imported certificates against FIPS requirements.

FIPS compliance is a formal operating requirement and does not automatically mean the strongest configuration available today. For example, Sophos documentation permits SHA1 within the FIPS boundaries for certain VPN authentication cases. For new IPsec designs, IKEv2 and modern algorithms agreed with the peer remain the better starting point. Understanding and creating Sophos Firewall IPsec profiles explains the fields and security decisions.

Check supported platforms

Sophos supports FIPS mode on:

• XGS Series hardware appliances
• VMware vSphere
• Microsoft Hyper-V
• KVM
• Xen
• AWS
• Azure

It is not supported on:

• Software appliances
• XG Series hardware
• SG Series hardware

This distinction matters: A virtual appliance is supported, while a software appliance installed on custom x86 hardware is not. Sophos Firewall: Hardware, virtual, or cloud? explains the operating models.

Stop if the model, platform, or target version is not clearly supported. An available FIPS setting or executable CLI command is not a substitute for platform approval.

Inventory the impact before enabling FIPS

VPN peers and algorithms

Before the factory reset, document every production VPN with the parameters it actually negotiates. In FIPS mode, the following algorithms are available for new VPN configurations, among others:

• DH groups 14 through 21
• AES-CBC and AES-GCM with 128, 192, or 256 bits
• RSA keys of 2048 bits and higher, although Sophos classifies only 2048 and 3072 as FIPS-compliant
• EC prime-field curves of 224 bits and higher
• SHA1, SHA256, SHA384, and SHA512 for VPN authentication
• Preshared keys of at least 14 bytes
• TLS 1.2 and 1.3

For IPsec, DH 1, 2, 5, and 25 through 30, DES/3DES, Blowfish, Twofish, Serpent, and MD5 are unavailable. DH 31 can be selected, but Sophos states that the connection is then not FIPS-compliant. MD5 and SHA1 digests aren’t permitted for certificates.

The technical peer must support at least one complete matching phase 1 and phase 2 combination. This also applies to older appliances, provider VPNs, and cloud gateways. If there is no common set, do not improvise during the maintenance window. Adjust the peer first or stop the FIPS project.

SSL VPN and Amazon VPC

For SSL VPN, BF-CBC, 3DES, MD5, and the 1024 key size are unavailable. A password-protected site-to-site SSL VPN profile from a FIPS firewall isn’t interchangeable with SFOS versions earlier than 18.5 MR2, and vice versa.

An Amazon VPC connection in FIPS mode must use Use VPC configuration file. Use AWS security credentials remains visible, but according to Sophos the connection fails. The imported VPC configuration must also be adjusted to use FIPS-compliant DH and encryption algorithms.

Certificates and CAs

In FIPS mode, the firewall generates certificates using the FIPS-certified cryptographic library and validates uploaded certificates and CAs for approved algorithms. Document in advance:

• which certificates use an RSA or EC key
• which digest algorithms occur in the chain
• which IPsec, SSL VPN, portal, WAF, and SMTP services reference a certificate
• whether private keys, CA chains, and passwords are available for the rebuild

A certificate with a formally approved key can still fail because of its name, lifetime, or incomplete chain of trust. Importing and assigning certificates on Sophos Firewall explains the workflow.

Prepare the recovery package and rebuild

A normal configuration backup remains essential, but here it primarily serves as the return path to the previous non-FIPS state. If a backup with FIPS disabled is restored to a compatible firewall, FIPS is also disabled afterwards. The old backup therefore can’t simply be restored to continue using the existing configuration unchanged in FIPS mode.

Store the following externally before enabling FIPS:

• a current encrypted backup
• the backup password and the Secure Storage Master Key used at that time
• Entities.xml as a readable configuration reference
• interface, VLAN, routing, NAT, and firewall rule documentation
• VPN profiles, peers, IDs, certificate assignments, and PSK owners
• Device Access, admin FQDN, DNS, NTP, and licensing data
• HA design, Cluster ID, Peer Admin Port, and cabling
• validation tests and a clear abort decision

Creating or restoring a Sophos Firewall backup explains how backups, the SSMK, restore compatibility, and validation work together. Sophos Firewall Config Studio can additionally provide a structured configuration report.

The rebuild must start from factory settings. Individual objects or editor output may only be imported when every dependency and cryptographic value has been validated in FIPS mode. An unreviewed full import is not a substitute for the planned migration.

Enable FIPS on a standalone firewall

Stop conditions before the command

Do not continue while any of these points remain open:

• no confirmed compliance objective or no approval for the factory reset
• the platform or firmware isn’t demonstrably FIPS-capable
• the firewall is still part of an HA cluster
• there is no local console or equivalent independent management path
• the backup, password, or SSMK is missing
• a production VPN peer supports no common FIPS-compliant combination
• certificates or private keys for the rebuild are missing
• the rebuild, testing, and return path don’t fit into the maintenance window

FIPS can’t be enabled or disabled while HA is enabled. Don’t break up an existing cluster spontaneously in the same operation. Its removal, factory reset, and rebuild require a separate approved migration plan.

Run the command

Run the following command in the Device Console:

system certification fips enable

The firewall restarts with factory settings. The previous management IP and production configuration are no longer guaranteed to be reachable. Continue through the prepared local initial-access path.

Don’t restart repeatedly, import the old configuration blindly, or use undocumented shell changes. Restore the initial setup, management path, time, DNS, and licensing first.

Rebuild the configuration for FIPS

Use a controlled sequence:

1. Configure the management IP, administrative access, DNS, NTP, and current time.
2. Record the firmware build and platform again.
3. Build zones, interfaces, VLANs, and routing, then test them locally.
4. Import certificates and CA chains; don’t bypass rejected algorithms.
5. Create IPsec and SSL VPN profiles using only approved values.
6. Transfer firewall, NAT, WAF, and mail rules in stages.
7. Configure Device Access, MFA, logging, notifications, and Central integration.
8. Validate each production service before moving to the next one.

The firewall generates default policies with suitable settings in FIPS mode. A FIPS-capable default still doesn’t prove that an external peer or imported object is compatible.

Build HA only after FIPS

For a new HA cluster, enable FIPS on the intended primary firewall first and completely reconfigure it. Only then configure HA. Sophos automatically enables FIPS on the auxiliary firewall during HA setup.

While HA is enabled, FIPS can’t be enabled or disabled on either device. If HA is later disabled, the respective FIPS status remains unchanged on both devices.

Before Initiate HA, verify:

• The primary runs stably in FIPS mode.
• The auxiliary is prepared as a supported platform with a matching build.
• Models, ports, licensing, and the HA link meet the normal HA requirements.
• A backup and complete FIPS validation of the primary are available.
• The maintenance window includes HA setup, synchronization, and a failover test.

Configuring Sophos Firewall High Availability provides the complete cluster workflow. LINCE follows a different sequence and must not be confused with FIPS: LINCE must be aligned on both standalone devices before HA, while Sophos transfers FIPS from the primary to the auxiliary during HA setup.

Validate the migration

Cryptography and configuration

• Log Viewer and reports show the FIPS change.
• Disallowed algorithms are no longer available in new VPN and certificate configurations.
• Certificates, CAs, private keys, SANs, and the chain of trust are complete.
• IPsec and SSL VPN tunnels negotiate the expected values.
• A green tunnel status is confirmed with real bidirectional application traffic.

Network and services

• WebAdmin is reachable only through the intended management path.
• Routing, SD-WAN, DNS, and NTP work.
• Firewall and NAT rules match with the expected Rule ID.
• WAF, SMTP TLS, portals, and remote access present the correct certificates.
• Monitoring, notifications, backups, and Central integration work.
• With HA, status, synchronization, failover, and return are tested separately.

Record the build, time, FIPS event, tested VPN proposals, certificate fingerprints, and results of the real connections as evidence. A missing field in one interface or a single successful ping is not sufficient evidence for the complete migration.

Backup, firmware, and rollback

After the rebuild succeeds, create a new backup in FIPS state and store it securely together with the password, SSMK, build, and validation record. When restored to a compatible FIPS-capable version, the backup applies its FIPS status. FIPS mode is unavailable on a version that doesn’t support it.

Active FIPS firmware blocks the upload of firmware that doesn’t support FIPS. Don’t bypass this protection with an unplanned mode change. Release notes, the upgrade path, a backup, and testing of cryptographic dependencies remain mandatory before each upgrade.

If the migration must be aborted, use the non-FIPS backup created before the change as the documented return path. Restoring it returns the firewall to the non-FIPS state stored in the backup. Management, routing, VPN, HA, and services must then be fully tested again.

FAQ