A year ago we published our Secure by Design 2025 progress update, reviewing our commitments against the seven pillars of CISA’s Secure by Design initiative. Since then, enough has happened – across all our products, and in the threat landscape – that a single annual post covering everything no longer does the work justice. So we’re splitting our updates out per product, starting where the stakes are highest: the firewall.
Network edge devices remain the most attractive target class in enterprise security. They sit at trust boundaries, they’re chronically under-instrumented across the industry, and as we documented in our Pacific Rim research, well-resourced adversaries will spend years studying them — including by attacking the vendors who build them. Nothing in the past twelve months has softened that assessment. If anything, AI-assisted attack tooling has compressed the timeline between opportunity and exploitation, a shift we explored in ‘The vulnerability flood is here.’
This update covers what we’ve shipped for Sophos Firewall in the past year, what we learned from the FortiBleed campaign, how our work maps to the NCSC’s forensic guidance for network device manufacturers , and what we’re committing to next.
FortiBleed: a test of defaults
In June 2026, a large cache of exposed Fortinet device credentials — dubbed FortiBleed — surfaced as part of a broader campaign against edge devices that prompted a CISA hardening alert. Related activity reached us too: credential brute-forcing and stuffing against user-level accounts on internet-facing Sophos Firewall devices.
For Sophos customers, this was password guessing, not exploitation; we found no vulnerability involved and no indications of widespread compromise. Years of default-hardening decisions did their job: no default creds, web admin and user portals off the WAN by default, CAPTCHA on the user portal, MFA enforcement across portals, and the v22 Health Check flagging risky configurations against CIS benchmarks.
Still, two lessons from our post-incident review:
First, MFA enrollment itself was a trust-on-first-use problem. Accounts that exist but have never logged in (particularly common when an AD group sync pulls in dormant or non-human accounts) had no MFA enrolled, and whoever authenticated first got to enroll it. Brute-force that account’s password on the user portal, and the attacker becomes the first user, legitimately setting up their own MFA. We’ve redesigned onboarding to break that. Enrollment QR codes are now delivered by email rather than presented in the portal, so first use requires proving control of the user’s mailbox, not just guessing a password. Codes expire after 24 hours if unused, and email-based onboarding is the default for new deployments. Alongside this, dynamic lockout against brute-force and MFA on SSH are in active development.
Second, confirming a negative at fleet scale took longer than we’d like. We had the observability to establish that customers weren’t compromised, but assembling that evidence across hundreds of thousands of devices was slower and more manual than it should have been. That lesson directly shapes our telemetry and forensics investments below – including failed-login telemetry streamed to SophosLabs, which turns our install base into what we believe will be one of the industry’s best sensors for edge-device attack campaigns. When the next FortiBleed-style campaign hits, we want to characterize it – who’s being targeted, from where, at what scale – in hours, rather than days.
What we shipped this year
We covered the headline v22 architectural work when the release went into early access: a re-architected, containerized control plane; a hardened 6.6+ kernel with KASLR, stack canaries, and hardened usercopy; integrated XDR Linux Sensor for remote integrity monitoring of the fleet; and the Health Check feature. v22 is now our most widely deployed firmware version, and this year’s work builds on that foundation.
SLS on SFOS. The Sophos Linux Sensor now runs across the entire XGS appliance line, down to the smallest XGS 88, as of v22 MR1. It detects post-exploitation behaviors such as interactive and reverse shell access and detects associated command-and-control (C2) activity. Critically, detection rules are now updatable over the air, decoupled from firmware releases, and we’re building a CI/CD pipeline for detection content jointly across our network security engineering, SophosLabs, and internal detection-and-response teams. To our knowledge, no other firewall vendor operates a continuously delivered, fleet-wide behavioral detection capability of this kind on the appliances themselves. Prevention is ideal; detection is a must.
Traceable telemetry. Virtual and software deployments now require registration before use; we removed the registration deferral mode that previously allowed anonymous, unregistered instances. That closes an avenue attackers (and vulnerability researchers with unclear motives) used to probe our software anonymously, and it means every deployment is attributable in our telemetry.
Foundation hardening. Less glamorous, but equally important: we modernized the SFOS build toolchain (current GCC and glibc, with the exploit mitigations that come with them), continued reducing privileged execution paths (including removing sudo usage in several components), and expanded static analysis with CodeQL and Semgrep across firewall repositories, with findings feeding a gated CI/CD pipeline.
Hotfix visibility. Sophos Firewall has long been unique in shipping zero-touch over-the-air hotfixes, with over 99% of customer firewalls receiving them automatically. The gap was verifiability: customers (and auditors) had to take on trust that a fix was applied. Hotfix status is now visible directly in the firewall UI, log viewer, email notifications, and Central Firewall Reporting. If our advisory says “you’re already patched,” you can now see the evidence yourself.
Scheduled firmware updates. In our 2024 pledges we committed to automatic scheduling of firmware updates. This ships from Sophos Central in August 2026: recurring schedules for maintenance releases, with per-firewall override so administrators keep full control. Fleet hygiene backs this up. The install base has consolidated onto current firmware faster than any previous cycle, with v22 becoming the most widely deployed version within roughly six months of release. Consistent and predictable, automatic patching is one of the highest-leverage security features we can ship, and the adoption curve suggests customers agree.
Turning AI loose on our own firewall
We’ve written about how frontier AI models are reshaping vulnerability research from the outside. The inside-out story matters more. External researchers work against binaries and black-box behavior; we have the source code, the build system, and racks of real appliances. That’s an asymmetric advantage for defenders – if we use it.
This year we built an internal agentic vulnerability-hunting platform and pointed it at SFOS first. It’s not a chatbot wrapper: it drives real firewall appliances (including HA pairs) in an isolated, reproducible lab, works from source, and produces evidence-backed, triaged findings, with every agent action recorded and attributable. Product engineers operate it alongside our red team, hunting with frontier models including OpenAI’s GPT-5.6 Sol and Anthropic’s Claude Mythos Preview.
Early results have exceeded our expectations, at a fraction of the cost of a traditional penetration test, and with some findings validating prior hardening work rather than exposing new gaps (the most serious finding to date had already been eliminated in current releases by architecture work our engineers completed proactively; consistent with our CVE pledge, we will publish a CVE for it). There’s a full article’s worth of detail here – methodology, results, and what it means for how products should be tested – and we’ll publish that separately.
Alignment with NCSC forensic guidance
In 2024, the NCSC and international partners published guidance on digital forensics and protective monitoring for producers of network devices and appliances. In our view, this is the most concrete articulation yet of what ‘evidence of intrusions’ (also a CISA Secure by Design pillar) should mean for edge devices. We’ve assessed SFOS against it section by section, shared our detailed mapping with the NCSC, and kept them updated on progress. Here’s where we stand:
Where we meet the guidance today. Secure logging and remote logging: v22 delivered protected, append-only-style log handling, secure log transport to central repositories, and unique per-device identifiers in logging. Logging coverage of authentication, process, filesystem, and network events has expanded substantially through SLS and related v22 work.
Where we’re partial. Some event categories aren’t yet captured with the completeness the guidance specifies, and volatile data collection is partially addressed today via our real-time telemetry stream and file-integrity monitoring. Our IDR team has successfully analyzed volatile memory from appliances, but a productized capture mechanism is still needed.
Where we don’t yet meet it. Non-volatile data collection – capturing persistent storage images from devices, remotely and at scale – is the biggest remaining gap, for us and (we’d argue) for the industry.
For readers tracking our CISA Secure by Design pledge: this year’s firewall work lands squarely on several pillars. Scheduled firmware updates close out our security patches pledge; hardened MFA onboarding extends the MFA pillar to the device itself; SLS, hotfix visibility, and the telemetry work all serve the evidence-of-intrusions pillar; and the v22 control-plane containerization continues our pledge to reduce entire classes of vulnerability.
That brings us to commitments.
- Commitment 1 — Fleet forensic capture. We commit to delivering a forensic capture capability for Sophos Firewall, enabling collection of volatile and non-volatile artifacts from deployed devices, and closing the remaining gaps against the NCSC forensic guidance. Design is underway with stakeholders; we will report progress in the next firewall Secure by Design update.
- Commitment 2 — Attack telemetry. We commit to expanding attack-facing telemetry from the firewall fleet — including failed-authentication telemetry streamed to SophosLabs — and to further protecting the integrity of the telemetry services themselves against tampering, so that fleet-scale campaign detection doesn’t depend on the honesty of a compromised device.
We’re publishing this level of detail because we think buyers should demand it – from us, and from every vendor in this market. As Ollie Whitehouse of the NCSC has argued, product security is ultimately a market-incentives problem: it improves when transparency is rewarded, rather than punished. If this article helps you ask harder questions of your other infrastructure vendors, it’s done its job.
And if you’re a security researcher: our bug bounty program pays up to $50,000 for findings on the firewall platform. The harder you make our engineers work, the better this update gets next year.
About Author
