Enable FIPS 140-3 on Sophos Firewall

Sophos Firewall supports FIPS 140-3 Level 1 mode under SFOS 22 on XGS 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 an approved migration plan, 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.

The FIPS help for SFOS 23 repeats the statement about SFOS 22.0 GA and its maintenance versions. This alone does not confirm certification of an SFOS 23 build. For formal acceptance, those responsible for compliance must confirm the actual target build, the cryptographic module used, and the corresponding validation evidence; an enabled mode is not evidence of certification for the entire firewall.

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 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 minimum PSK length of 14 bytes does not mean 14 arbitrary characters. A newly generated, random PSK consisting of ASCII characters makes the length unambiguous to check, as each character corresponds to one byte. The minimum length alone says nothing about the strength of a predictable password. Agree the PSK with the peer over a secure channel and do not include it in acceptance records or logs.

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.

For remote-access IPsec under Remote access VPN > IPsec > Authentication type, only FIPS-compliant certificates are permitted; External CA cannot be selected as the remote certificate. The compliant-certificate requirement also applies to certificate-based L2TP remote access and the SSL server certificate under Site-to-site VPN > SSL VPN > SSL VPN global settings. The IPsec wizard offers FIPS-compliant settings. Before migration, check the actual certificate assignment of each connection, not only key size and digest. Use IKEv1 only on legacy systems and with FIPS-approved algorithms; use IKEv2 for new installations.

Sophos describes use of the FIPS-certified cryptography library for IPsec tunnel establishment in phase 1 and for SSL VPN in phase 1 and phase 2. Do not infer blanket certification of the entire VPN deployment or an arbitrary target SFOS version from this statement.

Do not assume a default L2TP policy exists

The FIPS help for SFOS 22 and 23 contains two contradictory statements: it describes a default L2TP policy with SHA1 instead of MD5, but also states that FIPS devices have no default L2TP policy. Neither the existence of such a policy nor a safe default can be inferred from this. If L2TP is required, the policy actually present and its permitted authentication values must be checked for the target build before the production migration, and the behaviour clarified with Sophos Support if necessary. Do not replace a missing policy with MD5 or another disallowed algorithm. The L2TP service is approved for use only after successful acceptance testing; this migration remains stopped until the policy has been clarified.

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 backup and rebuild

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.

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
• rebuild and acceptance testing don’t fit within 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

Before approval, record the current mode in the Device Console using the read-only command system certification fips show. If FIPS is already active, enable is not a verification command: do not repeat the destructive activation step; check the existing configuration instead. Beforehand, verify that the platform-appropriate console access path for initial access is actually reachable; for a VM or cloud deployment, this means the independent platform console, not an SSH connection through the management path that will subsequently be reset.

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.

Verify the status

Show the current mode with:

system certification fips show

Record the result with the device, SFOS build, and time. The Device Console also lists an option to turn FIPS off, but the official FIPS help does not document its effects and recovery sequence end to end. Do not derive a command workflow from that listing. Involve Sophos Support for turning FIPS off or unresolved restore behavior, providing the platform, build, HA status, and backup metadata.

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; this explicitly does not establish the inconsistently documented default L2TP policy as a confirmed starting point. A FIPS-capable default still does not confirm 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. The certification boundary, SSH interruption, and safe procedure are covered in Understand and enable LINCE mode on Sophos Firewall.

Validate the migration

Cryptography and configuration

• The FIPS change is visible in Log Viewer and, where supported by the model, in local reports. XGS 87/87w and XGS 88/88w do not support local reports; perform this check in Log Viewer on those models.
• 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.

Evaluate backups and firmware

After the rebuild succeeds, create a new backup in FIPS state and store it securely together with the password, SSMK, build, and acceptance record. When restored to a compatible FIPS-capable version, the backup applies its FIPS status. A backup with FIPS disabled accordingly restores a state with FIPS disabled. On a version without FIPS support, the mode is unavailable regardless of the backup’s status.

A backup is therefore not a neutral copy of just the rules. Before restoring it, separately confirm the backup’s FIPS status and the target build’s support for FIPS, and obtain approval for the compliance implications. Do not use the non-FIPS backup created before activation as a shortcut for the FIPS rebuild: a successful restore is no substitute for ensuring that the objects are FIPS-compliant and rechecking the mode and all services.

Sophos documents a narrow rollback case: If FIPS is enabled after a migration or upgrade, the firewall can return to the previous version where FIPS was disabled, provided that version’s configuration remains available. This is not a general downgrade guarantee or a way to restore the current FIPS configuration to any older version. First check the target build, retained configuration, upgrade path, backup, password, and SSMK, and obtain approval for the recovery path. Do not derive an ad-hoc turn-off command from this case; the support and HA restrictions above still apply.

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.

FAQ