Sophos Firewall: Hardware, virtual or cloud?
Sophos Firewall can be operated as XGS Hardware Appliance, virtual appliance, Software Appliance or Cloud Deployment. Technically, everywhere runs Sophos Firewall OS, but the operating model is not the same. The decision affects performance, support, port design, HA, recovery, licensing, monitoring and the question of who is responsible for which platform in the event of a disruption.
For new projects, you shouldn’t just ask which variant is cheaper. What matters is which variant suits the location, the virtualization platform, the cloud architecture and the operations team. The Sophos Firewall Sizing Guide is also important for performance sizing.
The platform choice also determines compliance features: FIPS 140-3 mode is available on XGS, supported virtual platforms, AWS, and Azure, but not on software appliances or XG and SG hardware.
Choose the Operating Model
Quick decision
- XGS Hardware Appliance: Mostly suitable when a location needs a dedicated, clearly supportable firewall with physical ports.
- Virtual Appliance: Mostly suitable if a stable virtualization platform is available and network zones can be cleanly separated virtually.
- Software Appliance: Usually suitable if your own hardware is to be deliberately operated and supported as a firewall platform.
- Cloud Deployment: Most often suitable when protecting workloads in AWS or Azure or connecting them to local networks.
The most important rule: A virtual or cloud firewall is not a free pass for less planning. CPU, RAM, storage, virtual switches, routing, HA, backup and monitoring must be planned just as carefully as with hardware.
When to be careful
The decision should not just be based on what is technically possible. Some environments look flexible on paper, but create unnecessary risks in operation.
- Hypervisor is already heavily utilized: IPS, TLS Inspection, VPN and logging need predictable CPU and I/O reserve.
- WAN, LAN, DMZ and management run through the same physical bottleneck: A logically clean separation is of little help if the real data path is overloaded or incorrectly segmented.
- No team feels jointly responsible for hypervisor and firewall: Incidents remain between platform, network and firewall teams.
- HA was only planned as a checkbox: Without host, storage, network and restore testing, high availability is not proven.
- Cloud routing is not fully documented: The firewall only protects traffic that is actually routed through it.
- Restore was never practiced: A backup is only reliable if a restore has been realistically tested or at least properly planned.
In such cases, a XGS Hardware Appliance is often no less modern, but simply the more robust operational decision. Conversely, a virtual or cloud firewall can be very useful if the platform, network design, monitoring and responsibilities are clearly clarified.
Compare the Platforms
XGS Hardware Appliance
A XGS Hardware Appliance is usually the most plannable variant for classic locations. Hardware, ports, support, RMA, lifecycle and firewall OS come as a coordinated system.
Advantages:
- dedicated firewall hardware,
- fixed port equipment and expansion options,
- clear assignment of WAN, LAN, DMZ, HA link and management,
- easy hardware support and replacement process,
- no dependency on hypervisor resources,
- Well suited for branches, headquarters and edge firewalls. The biggest advantage lies in operation: If there is a problem, you don’t have to first clarify whether the hypervisor, vSwitch, storage, cloud routing or firewall itself is the cause. For many SME locations, this is more important than maximum flexibility.
Virtual appliance
A virtual Sophos Firewall makes sense if a clean virtualization platform already exists and the firewall is to be integrated into a data center, a multi-tenant environment or an internal segmentation design.
Relevant virtual platforms include VMware, Microsoft Hyper-V, KVM, Nutanix Prism, and Citrix Hypervisor. Before deployment, verify the specific platform version against the current Sophos compatibility information. Sophos states a minimum of one vCPU, 4 GB RAM, two vNICs, a 32 GB primary disk, and an 80 GB report disk. These are installation minimums, not a sizing recommendation for production inspection traffic.
Important operational questions:
- Are CPU resources guaranteed or heavily oversubscribed?
- Are RAM and storage sufficiently dimensioned?
- Are virtual NICs and port groups clearly separated?
- Are there dedicated network paths for WAN, LAN, DMZ, HA and management?
- Is promiscuous mode, VLAN trunking or SR-IOV required?
- Is there a clean backup and restore concept?
- Is it clear who troubleshoots the hypervisor, storage and firewall together?
A virtual firewall can work very well. However, things quickly become problematic when it runs on an overloaded host or when WAN, LAN and management only look logically clean, but physically run through the same bottlenecks.
⚠️ Hypervisor snapshots or backups from the virtualization vendor are not a supported replacement for the integrated Sophos backup. For a supported restore, save the configuration under Backup & Firmware > Backup & Restore. Platform backups may exist in addition, but they must not be the only recovery path.
Software Appliance
A Software Appliance is installed on dedicated x86-64 hardware. This can be useful for labs, special environments, or highly targeted designs. In normal customer operations, choose this model deliberately because hardware selection, drivers, spare parts, monitoring, and support are largely the operator’s responsibility.
The installation reformats and repartitions the disk, deleting the existing operating system and all files. For an SFOS 22 Software Appliance, Sophos requires Legacy BIOS, at least 4 GB RAM, two network interfaces, and at least 32 GB storage; 64 GB is recommended. If the minimum requirements are not met, the firewall can enter fail-safe mode.
If an appliance already starts in Failsafe mode, record the cause detected by SFOS with the Check Sophos Firewall in Failsafe mode runbook before changing resources.
Check:
- Is the hardware suitable for continuous operation?
- Are network cards, storage and BIOS/UEFI configuration suitable?
- Is there replacement hardware?
- Is the installation and recovery process documented?
- Who is responsible for hardware errors?
For standard locations, an XGS Hardware Appliance is often easier. For technical special cases, a Software Appliance can still be suitable if the operations team has a good command of the platform.
Cloud Deployment
Cloud deployments are particularly useful when workloads in AWS or Azure need to be protected or when cloud networks are connected to local locations. Different questions are important in the cloud than at the traditional location.
Plan:
- VPC/VNet design,
- routing tables,
- Availability Zones,
- Elastic IPs or Public IPs,
- Site-to-Site VPN or SD-WAN,
- Logging and central evaluation,
- Cloud costs for instance, storage, traffic and HA design,
- Operational responsibility between cloud team and firewall team.
A cloud firewall is not a replacement for clean cloud network design. Only the paths that are actually routed through the firewall are protected.
Plan Operations and Recovery
Performance and sizing
When it comes to hardware, performance depends on the model you choose. For virtual, software, and cloud deployments, performance is more platform dependent.
Particularly relevant:
- CPU performance and CPU reservation,
- RAM,
- storage latency,
- virtual NICs,
- hypervisor or cloud network path,
- number of sessions,
- TLS Inspection,
- IPS,
- VPN throughput,
- Logging and reporting. Data sheet values should therefore always be read in context. Firewall throughput without security inspection is not the same as threat protection, TLS Inspection or IPsec VPN under real load. The differences explained Sophos Firewall Correctly interpret performance data.
HA and recovery
High availability differs significantly depending on the platform.
When it comes to hardware, HA is usually easier to understand: two appliances, HA link, defined interfaces, clear replacement device. Additional questions arise for virtual and cloud deployments:
- Do HA nodes run on different hosts?
- Are storage, network and hypervisor really redundant?
- Are virtual MAC addresses and vSwitch rules compatible?
- Are there any dependencies on cloud routing or load balancing?
- Do backups and restores work on a new instance?
- Has the failure of a host or an availability zone been tested?
The basics of HA variants can be found in Sophos Firewall Setting up High Availability (HA). For recovery, Sophos Firewall Create or restore backup is required reading.
Licensing and Support
Licensing should be considered early because hardware, virtual, and software firewalls are handled differently. Since March 2025, virtual, software, and cloud BYOL licenses are limited by CPU cores; the previous RAM license limit no longer applies. This does not mean that unlimited RAM can compensate for poor CPU, storage, or NIC sizing. The serial number, core license, support, and subscription must still match the instance. For the Base License basics, Sophos Firewall - Base License is suitable. The change in virtual and software licenses, in which RAM is no longer the focus of the license limit, is listed in the blog post Sophos Firewall VM & SW - Only CPU counts - No more RAM limit.
What is important in operation:
- Document license and support status.
- Cleanly record serial number and registration status.
- Check HA licensing before building.
- Check firmware and support eligibility before upgrades.
- Know the RMA or recovery process for the chosen platform.
Before major upgrades, Sophos Firewall before SFOS 22 Check upgrade should also be used because platform support, storage space, backup, HA and old VPN configurations can be upgrade-relevant.
For active-passive HA on virtual or software appliances, the primary requires a Base Firewall license. For active-active HA, both nodes must be appropriately and identically licensed. Resolve this before building the cluster, not while diagnosing the first failover.
Decision matrix
- Classic location with WAN, LAN and DMZ: Mostly hardware. Virtual only with a good virtualization strategy.
- Data center with existing hypervisor team: Hardware is possible, virtual often makes sense.
- Cloud workloads in AWS or Azure: More virtual or cloud, not classic hardware.
- Easy support and RMA important: More hardware. With virtual or cloud, a lot depends on the platform team.
- Many physical ports required: More hardware. Virtual only with clean NIC and vSwitch design.
- Dynamic scaling and Infrastructure as Code: More virtual or cloud.
- Small IT team without specialized hypervisor knowledge: Mostly hardware; Plan virtual firewalls carefully.
- Tenant or segmentation design in the data center: Hardware is possible, virtual often makes sense.
Common errors
- Run virtual firewall on overbooked host.
- Do not cleanly separate WAN, LAN and management on the hypervisor.
- Select hardware only based on price instead of size.
- Deploying a cloud firewall, but not fully thinking through routing tables.
- Plan HA but do not test host, storage or cloud failures.
- Create backup, but never practice restore.
- Check license and support status only during firmware upgrade.
- Activate security features such as TLS Inspection or IPS later, without performance reserves.
- Only bring the platform team, network team and firewall managers together in the event of a disruption.
Checklist
- Location clearly defined: location, data center or cloud.
- Traffic, bandwidth and security features recorded for sizing.
- Hardware, virtual, software or cloud variants deliberately chosen.
- Responsibility for firewall, hypervisor, cloud and network documented.
- HA and recovery design checked.
- Backup and restore process tested or planned.
- License, support and registration clarified.
- Monitoring for firewall and underlying platform available.
- Upgradeability and platform support checked.
- Person responsible for platform, network, firewall, backup and restore named.