As of September 30, 2025, Microsoft officially retired Basic SKU public IP addresses, and for anyone deploying Sophos Firewall in Azure, the message is clear: you must use Standard SKU public IPs for new builds or risk broken connectivity and unsupported configurations. This change—bundled with Azure’s requirement that Standard IPs follow a ‘secure by default’ model—reshapes how security teams design, automate, and harden their cloud perimeter appliances.

Sophos Firewall admins who have relied on the Marketplace wizard or ARM templates now face a mandatory pivot. Dynamic Basic IPs are gone; static Standard IPs, NSG rules, and zone-aware load balancer setups are the new baseline. The community discussion around Sophos in Azure is buzzing with questions on how to migrate, avoid costly missteps, and keep high availability intact.

Why the Basic SKU Retirement Matters for Sophos Deployments

Microsoft’s retirement of Basic SKU public IPs means you can no longer create new Basic IPs, and existing ones must be upgraded to Standard to continue functioning with newer Azure features. For Sophos Firewall deployments, this change hits multiple layers:

  • Marketplace deployments that historically allowed selection of Basic SKU IPs will now fail or require updating to Standard.
  • High availability (HA) designs that pair firewalls behind an Azure Load Balancer demand Standard SKU IPs and a Standard Load Balancer—no more mixing Basic.
  • Availability zone support, critical for resilient architectures, is only available with Standard SKU (Basic IPs are not zone-aware).
  • Security defaults on Standard IPs block all inbound traffic unless you explicitly create network security group (NSG) rules, meaning post-deployment steps must include NSG configuration to avoid locking yourself out of the Sophos admin UI on port 4444.

The forum post compiled by the community emphasizes that Azure’s announcement “affects how new Sophos deployments should be planned and which public IP SKU to select for HA and availability.” The original source—Microsoft Learn’s upgrade guide—confirms the retirement date and walks through the upgrade process, noting that “in most cases, Public IPs upgraded from Basic to Standard SKU continue to have no availability zones” unless they were originally zonal. This nuance matters for HA designs that rely on zone redundancy.

Sophos Firewall on Azure: Quick Architectural Overview

Sophos provides a marketplace image and ARM templates for deploying Sophos Firewall as a virtual appliance. Two licensing models—Pay-As-You-Go (PAYG) via the Azure Marketplace and Bring-Your-Own-License (BYOL)—let you match billing to your needs. The minimum recommended instance size is Standard F2s v2 (2 vCPU, 4 GB RAM), but production workloads with TLS inspection will need larger VMs.

Typical topologies include:
- Standalone single-instance for labs or non-critical workloads.
- Active-passive HA pair behind an Azure Public Load Balancer for production egress and inspection.
- Single-arm deployment with one network interface, used for transparent inline inspection or scenarios where Azure User-Defined Routes (UDRs) make a second interface unnecessary.

The community discussion highlights that Sophos Central management is strongly recommended: claiming each firewall instance in Sophos Central unifies logging, policy, and update management, shortening response times during incidents.

Step-by-Step: Deploying with Standard SKU and Avoiding the Pitfalls

Here’s a production-minded walkthrough that builds on the community guide and incorporates the public IP upgrade path detailed by Microsoft Learn:

1. Plan for Standard SKU from Day One

Create a Public IP resource in the Azure portal and select Standard SKU with Static assignment. If you have an existing Basic IP, Microsoft’s upgrade instructions require it to be disassociated from all resources, assigned statically, and then upgraded via portal, CLI, or PowerShell—this operation is irreversible. The IP address itself is retained, but the SKU changes permanently.

Important: Standard SKU IPs are secure by default. Immediately after deployment, create an NSG rule allowing inbound TCP 4444 (HTTPS) from your trusted IP ranges to the firewall’s management interface. Without this, you won’t be able to access the Sophos admin console.

2. Prepare the Virtual Network

Create a VNet with at least two subnets—commonly named WAN and LAN. Use address spaces like 10.0.0.0/16 with subnets 10.0.1.0/24 (WAN) and 10.0.2.0/24 (LAN). If you plan to route entire subnet traffic through the firewall, later you’ll associate a route table pointing 0.0.0.0/0 to the firewall’s LAN private IP.

3. Launch the Marketplace Deployment

Search “Sophos Firewall” in the Azure Marketplace, choose your license type (PAYG or BYOL), and select the VM size (at least F2s v2). During configuration, map the WAN subnet to the NIC that will hold the public IP and the LAN subnet to the internal NIC. Attach the previously created Standard SKU public IP to the WAN NIC.

4. Post-Deployment: Registration and Initial Config

Once the VM is running, open a browser to https://<dns-name>:4444 (the DNS name is on the public IP resource). Log in with the admin password you set during deployment. Accept the EULA and claim the device in Sophos Central or register it with a serial number for BYOL. Complete the setup wizard to define zones, interfaces, and NAT rules.

5. Configure Routing and NSGs

If the firewall is the central egress point, assign a static private IP to the LAN NIC. Create a route table with a default route (0.0.0.0/0) pointing to that IP as the next hop type “Virtual appliance,” and associate the table with all subnets that need internet access.

Don’t forget inbound NSG rules:
- Allow TCP 4444 from your management IPs.
- If using HA, allow health probe traffic (typically TCP 8443 or custom port) from the Azure Load Balancer IP (168.63.129.16).
- Allow any expected business traffic (e.g., UDP 500 for IPsec VPNs).

The community warns that powering down the VM when changing NIC IP assignments is a best practice to avoid transient routing issues.

High Availability and Load Balancer Patterns

For active-passive HA, Sophos supports placing two firewall VMs behind an Azure Standard Load Balancer. Key requirements:
- Standard Load Balancer paired with Standard SKU Public IP on the frontend.
- Floating IP (Direct Server Return) must be enabled on load balancer rules so the active firewall can respond directly.
- Health probes should point to the Sophos HA monitoring endpoint (commonly port 8443) with the correct path.
- Each firewall instance needs its own license (BYOL) or PAYG subscription.

Sophos’ GitHub repository (github.com/sophos-iaas/xg-azure) includes an ARM template that automates the HA deployment, creating two VMs, the load balancer, probes, and routing. This reduces manual errors, especially around NSGs and UDRs.

During failover testing, ensure that the Azure Load Balancer redirects traffic cleanly and that stateful session synchronization meets your requirements. The community emphasizes measuring performance under realistic loads; TLS inspection can spike CPU usage and may require scaling to a larger VM size.

Common Deployment Pitfalls and How to Avoid Them

  1. Public IP SKU Mismatch
    - Using a Basic SKU IP with a Standard Load Balancer will fail. Always choose Standard SKU for new deployments and plan to upgrade any existing Basic IPs before the retirement deadline.

  2. Locked Out by Secure Defaults
    - Standard IPs drop all inbound traffic unless an NSG explicitly allows it. After creating the public IP, attach an NSG to the NIC or subnet with a rule for port 4444 before you even try to access the firewall web console.

  3. DNS Name Instability
    - Sophos uses the DNS label on the public IP for admin UI access. If you delete and recreate the IP, the DNS label changes. Use static assignment and consider reserving a DNS name you control.

  4. Licensing Confusion
    - PAYG instances bill through Azure, but you still need to claim them in Sophos Central for policy management. BYOL requires manual serial number registration. Confirm your model before deployment to avoid orphaned VMs.

  5. HA Probe and Routing Misconfigurations
    - Incorrect health probe ports or missing IP forwarding settings on NICs will break failover. Use Sophos’ HA documentation and test failover with live traffic before declaring production readiness.

Automation and Infrastructure as Code

For repeatable, auditable rollouts, lean on Sophos’ ARM templates or build your own with Bicep/Terraform. The xg-azure repository provides a mainTemplate.json with parameters for VM size, networks, licensing, and HA. By integrating these templates into a CI/CD pipeline, you can deploy a fully configured Sophos Firewall environment—including NSGs, route tables, and load balancer—in minutes.

The community notes that template deployments enforce Sophos’ password complexity rules (minimum eight characters, mixed case, numbers, symbols). Failing to meet these will cause deployment errors, so validate parameters beforehand.

Cost, Sizing, and Performance Guidance

  • Minimum VM: Standard F2s v2 (2 vCPU, 4 GB RAM). For production with deep packet inspection and TLS decryption, consider Standard F4s v2 or higher.
  • Public IP and Load Balancer costs: Standard SKU resources incur hourly charges. Include these in your total cost of ownership (TCO) models, especially for long-running HA deployments.
  • License trade-offs: PAYG is convenient for trials and short-term projects but may cost more over a year; BYOL often yields savings for steady-state usage but requires upfront license procurement.

Monitor VM CPU and throughput metrics closely. If usage consistently breaches 70%, scale up or add a second HA node.

Final Checklist Before Production Cutover

  • [ ] Public IP is Standard SKU, static, with a DNS label.
  • [ ] NSG rules allow management (TCP 4444), health probes (TCP 8443), and required business traffic.
  • [ ] NSG is associated with the firewall’s NIC or subnet.
  • [ ] Firewall instance is claimed in Sophos Central (or registered with BYOL serial).
  • [ ] For HA: both nodes deployed, load balancer health probes passing, floating IP enabled.
  • [ ] Route tables point default internet traffic to the firewall’s LAN IP.
  • [ ] Failover tested with active sessions and stateful inspection.
  • [ ] Monitoring and log forwarding to SIEM/XDR configured.

Looking Ahead: Sophos Firewall’s Place in Azure’s Security Ecosystem

The Basic SKU retirement is a forcing function, but it also aligns Sophos deployments with Azure’s best-of-breed networking features. Standard IPs unlock availability zone support, zone-redundant load balancers, and improved security defaults—all of which harden the firewall’s position in the network.

Sophos’ increasing integration with cloud resilience and backup services means that the firewall is no longer an island. By centralizing management in Sophos Central and coupling it with Azure’s native security capabilities, enterprises can build a defense-in-depth model that spans endpoints, networks, identities, and data.

For administrators currently planning a deployment, the roadmap is straightforward: start with a Standard SKU template, automate with ARM or Terraform, test failover rigorously, and claim every instance in Sophos Central. The Azure upgrade guide provides a clear path for migrating existing Basic IPs, but for net-new environments, there’s no reason to touch Basic at all. The time to standardize on Standard is now—your firewall deployment’s resilience and your security team’s sanity depend on it.