Progress is being made, but too many network devices still remain difficult to investigate after compromise
Westend61 via Getty Images
Organisations' firewalls, VPN gateways and other network devices are increasingly targeted by attackers. This creates a shared challenge for both the vendors that build these products and the organisations that buy and operate them.
When incidents occur, organisations need reliable ways to understand what happened and assess whether a device can still be trusted. This is why forensic observability matters. It enables defenders to investigate compromise using supported capabilities built into the product, rather than relying on reverse engineering, or specialist vulnerability research – as is still often the case.
We are seeing encouraging progress across industry, but there is still some way to go before forensic observability capabilities become standard. Both vendors and buyers have a role to play in making this happen.
What is forensic observability?
Forensic observability means giving defenders reliable ways to understand what a device is doing, what it has done and whether it can still be trusted after an incident. This includes telemetry, logging, configuration state, and the ability to collect forensic data from both memory and data at rest.
It also depends on transparency. When vendors make it easy to understand what software is running on a device – for example through version information or a software bill of materials – defenders can investigate incidents more quickly and confidently.
As highlighted at the CYBERUK 2026 Technology Track panel on radical transparency, the NCSC is encouraging vendors to provide greater transparency because small design decisions can significantly reduce the time needed to triage and investigate incidents.
The goal is simple: defenders should be able to investigate compromise using trustworthy information provided by the system in a way that makes it difficult for attackers to tamper with it.
Why forensic observability matters for network devices
But many network devices still provide only limited support for incident investigation.
Forensic observability is particularly important for edge devices such as firewalls, VPN gateways and other network appliances. These systems often sit at trust boundaries and are increasingly targeted by sophisticated threat actors.
To help address this challenge, in 2025 the NCSC published guidance on digital forensics and protective monitoring specifications for producers of network devices and appliances describing the capabilities that manufacturers should build into network devices and appliances.
Incident response should not depend on workarounds
Despite this growing focus, incident response on many network devices remains unnecessarily difficult. Too often, defenders must rely on improvised techniques, reverse engineering, or even zero-day vulnerabilities to understand what happened on a compromised device. In effect, they can have fewer tools available to them than the attacker.
That should not be normal. Investigating a compromised device should not require discovering or exploiting vulnerabilities in the product itself. Instead, manufacturers should provide supported mechanisms for gathering the evidence needed to investigate incidents, assess impact and restore trust in affected systems.
This benefits everyone involved in incident response:
- Defenders have access to the information they need to determine scope and impact
- Vendors reduce the need for unsupported investigative techniques
- Organisations can respond more quickly and confidently without relying on specialist domain knowledge
Progress towards forensic observability
Encouragingly, we are seeing meaningful progress from parts of the technology industry. Several vendors have begun investing in better logging, forensic data collection capabilities, and greater system transparency.
To support this shift, the NCSC has been working with international partners to develop a reference architecture for forensic observability in network appliances and similar devices. The goal is to describe a practical approach that vendors can adopt to provide safe, reliable forensic access while maintaining strong security boundaries.
A view from industry
Vendors that have invested in forensic observability are already seeing its value in practice. Reflecting on its Pacific Rim campaign, Sophos said:
we proved the value of extending detection and response techniques beyond corporate endpoints to firewall devices, and it materially reduced harm to our customers. The experience reinforced a simple principle: you can't just try to protect firewalls, you have to plan for when they fail. The NCSC's forensic guidance builds on that same thinking, giving manufacturers and buyers a blueprint for making network devices easier to analyse when they're compromised. We're using it to guide our own firewall roadmap, and we'd encourage anyone buying a firewall to make it part of their evaluation criteria.
Three common misconceptions
Despite the progress being made, there are still misconceptions about observability.
Doesn’t this help attackers?
No. One common concern is that exposing additional telemetry or forensic interfaces will provide attackers with more opportunities to exploit a system. But well designed observability features improve security rather than weaken it. Structured logging, authenticated collection mechanisms, and clearly defined forensic interfaces are safer than forcing investigators to rely on undocumented behaviour, or vulnerability research. Security engineering should assume that defenders will need to investigate systems under pressure and design for that reality from the outset.
Won’t customers hate it?
No. Another frequently cited concern is that customers may react negatively to increased transparency. But experience suggests the opposite. Organisations responsible for operating critical infrastructure consistently ask vendors for better visibility into the systems they deploy. Clear telemetry and forensic capabilities build trust because they allow operators to verify what their systems are doing and respond effectively when something goes wrong.
Isn’t it too difficult?
No. There is a belief that implementing forensic observability is too difficult. Although it does require careful engineering, the examples emerging from industry demonstrate that it is achievable. Vendors that prioritise observability early in the design process find that it becomes a natural part of their platform rather than an afterthought bolted on in response to incidents.
Observability is ultimately about enabling defenders to do their jobs properly. When systems provide the information needed to understand their behaviour, organisations can investigate incidents quickly, confidently and safely. That is better for vendors, better for operators, and better for the security of the wider ecosystem.
What next?
Vendors: Following the NCSC’s guidance, build forensic observability into your products early in the design process.
Buyers: If your edge devices don’t have this feature, push for it. The fastest route to widespread adoption may be for customers to ask for these capabilities as standard.
By making forensic observability the norm, we can help organisations respond more effectively to cyber incidents – strengthening the resilience that underpins the UK’s security and economic growth.
Facts Only
Network devices such as firewalls and VPN gateways are increasing targets for attackers.
Forensic observability consists of telemetry, logging, configuration state, and forensic data collection from memory and data at rest.
The NCSC published guidance in 2025 on digital forensics and protective monitoring specifications for network device producers.
A panel on radical transparency occurred at CYBERUK 2026.
The NCSC is developing a reference architecture for forensic observability in network appliances with international partners.
Sophos reported that extending detection and response to firewall devices reduced harm to customers during its Pacific Rim campaign.
Software bills of materials (SBOMs) and version information are listed as tools for system transparency.
The NCSC encourages vendors to integrate forensic observability early in the design process.
Buyers are encouraged to include forensic observability in their evaluation criteria for edge devices.
Executive Summary
Network edge devices, specifically firewalls and VPN gateways, are increasingly targeted by sophisticated actors, yet many remain difficult to investigate post-compromise. Current incident response often relies on unsupported workarounds, reverse engineering, or the exploitation of vulnerabilities to gather evidence. To resolve this, the NCSC is promoting "forensic observability"—the integration of reliable telemetry, logging, and data collection capabilities directly into the product design.
This transition involves a shift toward radical transparency, including the use of software bills of materials to accelerate triage. While some industry concerns suggest that increased observability might provide attackers with new vectors or alienate customers, proponents argue that authenticated interfaces are safer than undocumented behaviors and that operators of critical infrastructure actively demand better visibility. Efforts to standardize these capabilities include the development of a reference architecture by the NCSC and its international partners to ensure security boundaries remain intact while providing necessary forensic access.
Full Take
The strongest version of this narrative is that security is a lifecycle, not a perimeter; if you cannot observe a failure, you cannot recover trust in a system. By shifting the burden of proof from the defender (who currently must "hack" their own device to investigate it) to the vendor (who must provide the tools for investigation), the power dynamic of incident response is fundamentally rebalanced.
The underlying paradigm is a move toward "trust but verify" hardware. The unstated assumption is that compromise is inevitable—a "plan for when they fail" mentality. This echoes the transition from traditional perimeter security to Zero Trust Architecture. The primary beneficiaries are the defenders and the wider ecosystem's resilience, while the cost is borne by vendors who must invest more heavily in engineering and transparency.
The narrative utilizes a structured debunking of "misconceptions" to preemptively neutralize industry resistance. By framing these objections as hurdles already overcome by "meaningful progress," it pushes the reader toward a binary choice: either adopt these standards or remain dangerously blind during a breach.
Patterns detected: none
Root Cause: The narrative is driven by the realization that the "black box" nature of proprietary network appliances has become a strategic liability in the face of state-level or sophisticated threats.
Bridge Questions:
If forensic interfaces are standardized, does this create a new, uniform target for attackers to disable or spoof across different vendors?
How does the requirement for "radical transparency" conflict with proprietary intellectual property protections, and who decides the limit of that transparency?
Counterstrike Scan: A coordinated campaign would use this narrative to force competitors out of the market by lobbying for regulations that only the largest vendors can afford to implement. The current content does not match this pattern; it presents a broad industry shift and a collaborative architectural framework rather than a targeted regulatory weapon.