Security Symmetry in Embedded Systems: Using Microsoft Defender for IoT to Detect Firmware Downgrade Attacks

Abstract

Nowadays, the world witnesses cyber attacks daily, and these threats are becoming exponentially sophisticated due to advances in Artificial Intelligence (AI). This progress allows adversaries to accelerate malware development and streamline the exploitation process. The motives vary, and so do the consequences. Unlike Information Technology (IT) breaches, Operational Technology (OT)—such as manufacturing plants, electric grids, or water and wastewater facilities—compromises can have life-threatening or environmentally hazardous consequences. For that reason, this article explores a potential cyber attack against an OT environment—firmware downgrade—and proposes a solution for detection and response by implementing Microsoft Defender for IoT (D4IoT), one of the leading products on the market for OT monitoring. To detect the malicious firmware downgrade activity, D4IoT was implemented in a pre-commissioning (non-production) environment. The solution passively monitored the network, identified the deviation, and generated alerts for response actions. Testing showed that D4IoT effectively detected the firmware downgrade attempts based on a protocol analysis and asset behavior profiling. These findings demonstrate that D4IoT provides valuable detection capabilities against an intentional firmware downgrade designed to exploit known vulnerabilities in the older, less secure version, thereby strengthening the cybersecurity posture of OT environments. The explored attack scenario leverages the symmetry between genuine and malicious firmware flows, where the downgrade mimics the upgrade process, aiming to create challenges in detection. The proposed solution discerns adversarial actions from legitimate firmware changes by breaking this functional symmetry through behavioral profiling.

1. Introduction

Symmetry in system and process behavior is progressively exploited by threat actors to disguise malicious actions as legitimate operations. Annually, hundreds of researchers and security professionals present their findings at conferences such as Black Hat [1] and DEFCON [2]. During the latest conference (August 2024, Las Vegas, USA), SafeBreach security researcher Alon Leviev presented his “Windows Downdate: Downgrade Attacks Using Windows Updates” project [3]. He revealed a method of forcing an up-to-date Windows device to roll back to an older software version, reintroducing vulnerabilities that can be exploited to compromise the system. The novel approach misused a flaw in the Windows update process, leveraging its purpose and, therefore, making it the least-suspicious entity for such an attack [4]. The method targeted the action list (Pending.xml) within the Windows update flow. It is located in a server-controlled folder, contains the update actions the client needs to perform, and is executed during the Operating System (OS) reboot. By exploiting a registry key (PoqexecCmdline) not Trusted Installer enforced, Leviev was able to replace the action list with a custom downgrading one and bypass the integrity verifications. This attack technique goes completely undetectable, which was one of the predefined success criteria:

• Fully undetectable—the Endpoint Detection and Response (EDR) failed to identify the malicious activity.
• Invisible—the system continued to display as up-to-date despite the downgrade.
• Persistent—future updates are compromised, preventing genuine patches from being applied (modification of poqexec.exe).
• Irreversible—integrity and repair utilities did not detect any issues, making the remediation challenging (modification of SFC.exe).

Another real-life scenario involving OS/firmware alternation is the SYNful Knock, a Cisco router implant discovered in 2015 [5]. This sophisticated attack involved a stealthy firmware modification targeting several Cisco models, including 1841, 2811, and 3825. By modifying the firmware, threat actors were able to maintain persistent access to compromised networks and evade traditional detection mechanisms. The initial compromise is believed to have been facilitated by the use of default credentials or credentials discovered by the attackers, rather than exploiting a zero-day vulnerability [6].

While the two examined cases involved malicious OS/firmware modifications in enterprise-grade equipment, similar tactics, techniques, and procedures (TTPs) have also been observed in the OT industry, for instance, in microgrids [7] and other electric power systems [8].

These novel attack concepts often mimic benign update processes, creating a deceptive structural symmetry between legitimate and malicious actions. For that reason, the current publication proposes a detection mechanism for firmware downgrades in OT environments. It leverages the passive agentless network monitoring capabilities of Microsoft Defender for IoT [9], combined with the robust Security Information and Event Management (SIEM) features of Microsoft Sentinel [10]. The solution was designed by considering the main differences in the detection of OS/firmware downgrades in IT vs. OT networks. For instance, a frequent inability to install an agent on the requiring-protection OT device (e.g., Programmable Logic Controller (PLC), Remote Terminal Unit (RTU), etc.) or the requirement for totally passive monitoring in contrast to active scanning, which can affect the determinism of the environment. The proposed approach enhances the visibility of covert threats by examining deviations in these symmetrical patterns at the asset behavior and protocol levels.

As part of this research work, a comprehensive comparative analysis was conducted to examine alternatives to the proposed solution, focusing on D4IoT’s two primary competitors: “Guardian” of Nozomi Networks and “CTD” of Claroty. The investigation specifically targeted firmware alternation detection capabilities across these platforms. This analysis revealed that the standard detection features in all examined solutions lack the necessary sophistication to properly identify and distinguish between legitimate firmware updates and potentially malicious downgrades. Both competitor platforms exhibit similar limitations to those found in D4IoT. Nozomi’s Guardian generates generic “Firmware transfer (Type ID SIGN:FIRMWARE-TRANSFER)” and “Firmware change (Type ID SIGN:FIRMWARE:CHANGE)” alerts, while Claroty’s CTD produces “Firmware Download (Alert Type ID 1000; QID 1003000042)”. These alerts merely identify firmware modifications without providing critical context about version trajectories, such as whether the change represents progressive advancement or regressive downgrade. Our solution distinctively overcomes these industry-wide limitations by implementing version-aware comparison logic, representing a significant advancement in detection capabilities.

The detection mechanism was successfully implemented in a manufacturing organization but is equally applicable to any cloud-friendly environment within the OT domain. The initial results indicated that this approach could effectively identify firmware downgrade attempts, significantly strengthening the security posture of critical infrastructure environments. The presented results validate that this research successfully answered the primary question: How effectively can passive, agentless network monitoring identify and distinguish between legitimate and malicious firmware alterations? In addition, the article conclusively fulfilled all predefined research objectives, which are as follows:

• Assess the potential risks and real-world impact of firmware downgrades;
• Characterize the structural and behavioral symmetries exploited by firmware downgrade attacks;
• Design a solution that mitigates these implications while considering the OT domain-specific characteristics and limitations;
• Evaluate the solution’s efficiency in both a controlled test environment and a real production network.

2. Materials and Methods

2.1. Firmware Change Detected D4IoT Alert Overview

The “Firmware Change Detected” alert is one of twelve scenarios generated by the Policy Violation detection engine under the Firmware Change category in Microsoft Defender for IoT (D4IoT) [11]. This alert is classified with medium severity and aligns with the “T0857: System Firmware” technique, associated with the “Inhibit Response Function” and “Persistence” tactics as defined by the Industrial Control Systems (ICS) MITRE ATT&CK framework [12]. T0857, as described in the framework, outlines the possibility of threat actors exploiting the firmware update function to upload malicious or outdated firmware, potentially granting them root access to the device. The list of targeted assets includes Data Gateways, Human–Machine Interfaces (HMIs), Intelligent Electronic Devices (IEDs), and various types of controllers [13]. This technique has been observed in two pivotal ICS security incidents: the 2015 Ukraine Electric Power Attack [14] and the 2017 Saudi Arabia Triton Attack [15].

In late December 2015, threat actors used the Black Energy malware to target three Ukrainian power companies. By remotely manipulating and opening breakers, they induced widespread outages that affected approximately 225,000 customers. Almost two years later, in August 2017, the sophisticated Triton malware targeted the Safety Instrumented System (SIS) at a Saudi Arabian petrochemical facility. This unprecedented, at the time, cyber attack, specifically engineered to compromise an industrial safety controller, represents a significant acceleration in OT/ICS threats. Fortunately, although the threat actors succeeded in deploying malicious code, the incident was discovered and halted before any physical harm occurred.

The SYNful Knock and the two cases from 2015 and 2017 illustrate how potential firmware compromises create severe security implications beyond conventional cyber threats. These examples demonstrate the importance of contrasting legitimate firmware updates with malicious downgrades, which is crucial for effective security monitoring.

The four primary methods for detecting T0857 are as follows:

• DS0015—Monitoring application logs for firmware changes (it should be noted that not all devices generate such logs);
• DS0001—Tracking firmware modifications and comparing them to a database of known-good versions and expected patching behavior;
• DS0029—Analyzing ICS/file transfer protocols for activities that might indicate firmware changes;
• DS0040—Monitoring operational alarms that could alert firmware changes.

The proposed detection mechanism leverages DS0029 as its foundation.

D4IoT supports the detection of “Firmware Change Detected” alert across 40 ICS and standard well-known protocols, including the following:

• OPAC (Open Protocol Atlas Copco)—a communication protocol designed for the remote control of Atlas Copco controllers. It supports both Ethernet (TCP port 4545) and serial (Serial ASCII or Serial ASCII with 3964R handshake) connections [16].
• MODBUS—an application-layer communication protocol for establishing connections between devices from different vendors. It operates on a client–server model, utilizing various function codes for request/response messages. The protocol uses TCP port 502 [17].
• Profinet—an industrial Ethernet-based communication protocol for real-time data transfers between controllers (PLCs) and field devices (sensors, actuators, and robots). The protocol operates on TCP port 102 (configuration) and UDP 34962-34964 (communication) [18].
• Rockwell CSP2—a Layer 7 protocol designed by Rockwell Automation for communication between Allen–Bradley PLCs and Rockwell software applications. The default port is TCP 2222 [19].
• MMS (Manufacturing Message Specification)—an Ethernet-based client-server communication protocol used for data exchange between IEDs (Intelligent Electronic Devices) and higher-level systems, such as Supervisory Control and Data Acquisition (SCADA). The protocol typically operates over TCP port 102 [20].
• CDP (Cisco Discovery Protocol)—a proprietary Layer 2 protocol designed for directly connected network devices (such as routers, switches, and bridges). It enables network management applications to discover Cisco devices, providing at least their IP address and device type [21].

D4IoT generates a “Firmware Change Detected” alert when deviations from the established baseline are identified. Upon installation, a D4IoT network sensor begins monitoring the environment by analyzing mirrored traffic forwarded to its monitoring interface(s). The sensor detects devices and their properties (e.g., hostname, IP address, MAC address, and OS/firmware) and records them in the device inventory. Once the sensor has gathered complete information about the devices in the environment, it triggers a “Firmware Change Detected” alert if any device is found with a firmware version different from the one stored in the database. The alert includes a “Learn” capability, allowing the newly discovered firmware to be validated and the device entry to be updated accordingly. However, if the alert is just closed (i.e., the firmware is not learned), it will reappear the next time the device is detected.

The “Firmware Change Detected” alert is presented in Figure 1. It contains information about the device with changed firmware, the previous and current versions, and the detection time.

In addition to tracking “Firmware Change Detected” alerts, users can explore the detected firmware version of a monitored device by checking the “Backplane” device inventory page or creating a data mining report with the category “Modules and Firmware Versions”. The report can be granular (specific device/time period) or generic (reveals all results for the selected category). The two options are presented in Figure 2 and Figure 3.

2.2. D4IoT Setup Prerequisites

The proposed detection mechanism for firmware downgrades requires cloud-connected D4IoT sensor(s) and Microsoft Sentinel integration. For air-gapped environments, the solution can be implemented using an on-premises SIEM product, such as Splunk Enterprise [22].

During the onboarding process, the “Cloud Connected” option must be selected, and the sensor requires access to specific Azure secure endpoints on port 443 [23]. The configuration is presented in Figure 4. The other two options (Automatic Threat Intelligence updates/Automatic Sensor updates) do not impact the implementation.

Once the sensor(s) begins streaming data to the Azure portal, D4IoT alerts can be ingested into Microsoft Sentinel. This is achieved by enabling the “Microsoft Defender for IoT” data connector [24]. The connector configuration page is presented in Figure 5.

To confirm that the integration between Azure D4IoT and Microsoft Sentinel was successful, we can run a Kusto Query Language (KQL) that searches D4IoT alerts in the “Security Alert” table. The query is presented in Figure 6.

2.3. Implementation of a Detection Mechanism for Firmware Downgrade

The implementation of a detection mechanism for firmware downgrades involves the creation of a custom Sentinel Analytics rule and requires the introduction of several variables. These variables are utilized within the KQL query to parse the raw data and compare previous and current firmware versions.

The process begins by retrieving firmware versions from the “Updated To” and “Updated From” properties within “ExtendedProperties”, as illustrated in Figure 7.

The next step applies a regular expression (Regex) to extract the numerical digits of the firmware version. The original format begins with “Software Revision:”, followed by three or four digits, and ends with a semicolon—“Software Revision: x.x.x.x;”. This is presented in Figure 8.

The subsequent phase involves splitting the three or four digits into separate variables to facilitate comparison. This process is illustrated in Figure 9.

The final operation involves comparing the previous and current firmware versions digit by digit and displaying the result, which can be one of the following: “NewVersion is newer”, “OldVersion is newer”, or “Versions are equal”. The comparison utilizes “case()” KQL function [25] and is presented in Figure 10.

The implemented detection mechanism for the firmware downgrade described above was developed and validated as part of this study. In alignment with the best practices for research transparency and reproducibility, relevant detection logic and queries can be made available under the conditions below.

The KQL queries and Regex parsing logic developed for this article can be made available upon request. Due to internal security policies, raw device data and network captures are not publicly shared.

No generative AI tools were used in the design, implementation, data collection, analysis, or interpretation phases of this work.

2.4. Selected Methods’ Rationale

The proposed solution relies on KQL queries and Regex for parsing raw data and comparison logic to optimize both performance and operational efficiency. The detection mechanism leverages Sentinel’s real-time evaluation of D4IoT alert ingestion, enabling the discovery of a potentially malicious firmware downgrade and incident creation in approximately one minute. Alternative implementation strategies, such as utilizing Azure Functions or Python scripts, introduce latency and unnecessary operational complexity through additional code maintenance and/or scaling considerations. Sentinel’s native capabilities, including parse_json(), extract(), and split(), enable the processing of ExtendedProperties within a single atomic query execution, eliminating external dependencies and maintaining rapid response capabilities.

The selected Regex is based on a thorough analysis of D4IoT’s firmware version annotation conventions—typically present as human-readable strings, such as “Software Revision: 2.6.6.6”. Our solution demonstrates exceptional versatility by reliably capturing three or four digit versions, regardless of potential formatting inconsistencies.

Finally, implementing all logic within a Sentinel Analytics rule significantly enhances operational sustainability. The method eliminates the need to synchronize external libraries or manage version compatibility. Additionally, the solution provides complete transparency to SOC teams, as Microsoft Sentinel is currently one of the SIEM solutions with the largest market share.

3. Results

3.1. Setting Up the Test Bed

The test environment set to evaluate and assess the performance of the designed detection mechanism consisted of the following components:

• Atlas Copco Power Focus 6000—a single, centralized tightening controller, typically connected to one or more screwing machines, and presented in Figure 11;
• Moxa AWK-3131A—industrial wireless AP/bridge/client that supports IEEE 802.11 a/b/g/n and is utilized to connect the “Atlas Copco Power Focus 6000” and “Beckhoff CP2916-0000” to the wireless network, presented in Figure 12;
• Beckhoff CP2916-0000—industrial panel PC (processor + HMI) that runs Windows 10 IoT. Utilized for direct monitoring and process control, presented in Figure 13.

Scheme 1 presents the network topology of the Test Bed implemented to evaluate the proposed detection mechanism. The configuration accurately simulated a real production environment with all necessary components for comprehensive testing. Notably, the “Wireless Access Point” and “Screwing Machine(s)” components are included to represent a complete screwing production line typical for a manufacturing facility and provide contextual accuracy to the simulation environment.

Table 1. IP configuration settings.

Device	IP Address	Subnet Mask
Moxa AWK-3131A	10.10.10.10	255.255.255.240
Beckhoff CP2916-0000	10.10.10.1	255.255.255.240
Atlas Copco Power Focus 6000	10.10.10.2	255.255.255.240

presents the IP configuration settings for the Atlas Copco Power Focus 6000, Moxa AWK-3131A, and Beckhoff CP2916-0000 devices utilized in the test environment. It is important to highlight that in actual production manufacturing environments, firmware alterations and/or configuration changes to Atlas Copco screw joint machines are typically deployed from a centralized location (e.g., an application server) rather than from the local control device (i.e., Beckhoff CP2916-0000). This approach enables enterprise-scale management and centralized control across hundreds or even thousands of screwing controllers deployed throughout manufacturing operations.

Table 2. Testing scenarios.

#	Operation	Description	Expected Results	Actual Results
1	Asset Discovery	D4IoT detects the Atlas Copco device	D4IoT identifies the device’s firmware version	Firmware Version Identified: 2.6.6.6
2	Firmware Downgrade	The Atlas Copco device is downgraded	“Firmware Change Detected” alert	Alert Generated Indicating Firmware Version: 2.5.7.2
3	Incident Generation	Trigger a Sentinel incident for a firmware downgrade	“D4IoT—Firmware Downgrade Detected” incident	Incident Generated
4	Firmware Upgrade	The Atlas Copco device is upgraded	Second “Firmware Change Detected” alert	Alert Generated Indicating Firmware Version: 2.6.6.6
5	Incident Suppression	The designed detection mechanism supresses the activity	The second “Firmware Change Detected” alert does not trigger an incident	No Incident Generated

presents the comprehensive testing scenarios formulated to evaluate both the functional capabilities and operational effectiveness of the developed detection mechanism. Each scenario is systematically documented with three key components: a procedural description, the anticipated outcome based on the design specifications, and the actual observed results from execution. Exhaustive details of all performed simulations are presented in Section 3.2, which provides substantial evidence demonstrating the successful implementation and operational effectiveness of the proposed solution, which is illustrated in Figure 14, Figure 15, Figure 16 and Figure 17.

3.2. Testing the Implemented Solution

The proposed solution for the detection of firmware downgrades was tested by intentionally downgrading an Atlas Copco screw joint machine (model: Power Focus 6000) in a controlled environment (testing segment of a manufacturing facility). Subsequently, the controller was restored to its original firmware version (upgraded), triggering a second “Firmware Change Detected” alert in D4IoT. However, this alert did not generate an additional Sentinel incident. Figure 14 presents the alert generated by the firmware downgrade, which involved changing the Atlas Copco device’s firmware from version 2.6.6.6 to 2.5.7.2.

Figure 14. “Firmware Change Detected” alert generated by the downgrade.

Figure 14. “Firmware Change Detected” alert generated by the downgrade.

Approximately one minute after D4IoT detected the activity and generated an alert, the Sentinel rule “D4IoT—Firmware Downgrade Detected” triggered an incident. This incident indicated that a monitored device was reverting from a newer firmware version to an older one based on the variable “CompareResult”. The incident is presented in Figure 15.

Figure 15. “D4IoT—Firmware Downgrade Detected” incident in Sentinel.

Figure 15. “D4IoT—Firmware Downgrade Detected” incident in Sentinel.

The second phase of the test involved learning the alert, which updated the device record. Subsequently, we restored the Atlas Copco controller to its original firmware version (2.6.6.6). This action was detected by D4IoT, which then triggered a second “Firmware Change Detected” alert, indicating the transition from version 2.5.7.2 to 2.6.6.6. The alert is presented in Figure 16.

Figure 16. “Firmware Change Detected” alert generated by the upgrade.

Figure 16. “Firmware Change Detected” alert generated by the upgrade.

Unlike the initial detection, the second alert did not trigger a new Sentinel incident, as the new firmware version was newer than the previously installed one. A look-up for incidents generated by the Sentinel rule confirmed that only the initial detection, related to the controller’s firmware downgrade, was recorded. Figure 17 illustrates the results.

Figure 17. Available “D4IoT—Firmware Downgrade Detected” incidents.

Figure 17. Available “D4IoT—Firmware Downgrade Detected” incidents.

3.3. Implementation of Automation for Weekly Reports of Firmware Change Detected D4IoT Alerts

Once the proposed detection mechanism for firmware downgrades is successfully implemented, we recommend that the remaining “Firmware Change Detected” D4IoT alerts (i.e., firmware upgrades) not be completely ignored. Instead of generating Sentinel incidents and acting immediately upon detection, these alerts can be reviewed on a weekly basis through reports.

This approach can help to identify another suspicious scenario: a significant surge (e.g., 5 or 10 times) in the number of upgraded devices within a week. For instance, a bad actor might attempt to migrate as many devices as possible to a specific vulnerable firmware version, followed by a subsequent phase of vulnerability exploitation.

Another potential use case for the report on upgraded devices is regulatory and compliance requirements. Depending on the industry, some organizations may be required to maintain an up-to-date inventory of all assets, their properties, and a change log of modifications.

To facilitate this, this article proposes implementing Azure Logic Apps [26], which automates the collection of “Firmware Change Detected” D4IoT alerts and generates a CSV file. This file is then automatically sent via email to the on-site operations team responsible for device maintenance.

A best practice is to “Learn” all alerts after completing the report review. Otherwise, the same detections will appear in next week’s report, as D4IoT retains the previous firmware records.

Logic Apps incorporate several operations designed to be executed in a cyclic manner. The structure is as follows, and it is presented in Figure 18.

• Recurrence—defines the execution interval (e.g., once a week) and the starting point (e.g., specific date). This operation triggers the Logic Apps and initiates the following steps.
• Run query and list results—executes a KQL query that searches the “Firmware Change Detected” D4IoT alerts for the pre-defined period (e.g., last 7 days). The query is presented in Figure 19.
• Condition—validates whether the KQL query has produced any results (i.e., found “Firmware Change Detected” D4IoT alerts in the specified period).
• Create CSV table—collects the query results and stores them in a CSV file.
• Send an email (V2)—sends the created CSV file containing the “Firmware Change Detected” D4IoT alerts to a pre-defined list of recipients.

Figure 18. Logic Apps for the “Firmware Change Detected” weekly report.

Figure 18. Logic Apps for the “Firmware Change Detected” weekly report.

Figure 19. KQL query for “Firmware Change Detected” D4IoT alerts.

Figure 19. KQL query for “Firmware Change Detected” D4IoT alerts.

The successful implementation of the Logic Apps for “Firmware Change Detected” weekly reports ensures the delivery of an email with an attached CSV file containing all detections for the pre-defined time period. Figure 20 illustrates the results.

Figure 20. Email containing the “Firmware Change Detected” weekly report.

Figure 20. Email containing the “Firmware Change Detected” weekly report.

4. Discussion

4.1. Discussion of Results

Adversaries often exploit the symmetry between business-justified OS/firmware updates and downgrades to evade detection by imitating benign behavior. This article explores potential cyber threats to OT/ICS environments, with a particular focus on intentional firmware downgrades designed to exploit known vulnerabilities in older, less secure versions. This attack method, classified as tactic T0857 in the MITRE ATT&CK framework, has been observed in real-world adversary operations, including the 2015 Ukraine Electric Power Attack and the 2017 Saudi Arabia Triton Attack, as well as in security research efforts, such as the case of Alon Leviev. While prior research and incident analyses have emphasized the impacts and potential consequences (i.e., unavailability of essential services, environmental harm, injuries to people, or even loss of life) of firmware manipulation in OT/ICS environments, few practical detection mechanisms have been demonstrated in production-like environments. Neither are offered as standard features in existing commercial solutions.

This study builds on those insights by emphasizing the importance of proactive security monitoring in OT/ICS environments and proposing a tailored and innovative detection mechanism for firmware downgrades. The designed solution was successfully implemented in a cloud-friendly manufacturing organization and is based on standard product capabilities, which were enhanced to meet the specific objectives of this research. The presented novel custom solution leverages the passive, agentless monitoring capabilities of Microsoft Defender for IoT, which, when combined with the advanced analytic strengths of Microsoft Sentinel, creates a robust detection mechanism. This cutting-edge solution, engineered by the authors, represents a substantial advancement in firmware downgrade attack detection and supports bolstering the overall cybersecurity posture of OT/ICS environments.

The developed detection mechanism was tested by intentionally downgrading an Atlas Copco screw joint machine (model: Power Focus 6000) in a pre-commissioning (non-production) environment and subsequently restoring it to its original firmware version. The results confirmed that the implementation functions as intended, generated a single Sentinel incident exclusively for the downgrade event. This selective behavior minimizes alert fatigue and ensures that only activities suggesting potential exploitation of reintroduced known vulnerabilities are escalated in alignment with best practices for threat prioritization.

In addition to detecting downgrades, the article introduces an automated reporting mechanism for handling remaining “Firmware Change Detected” alerts—typically generated by legitimate firmware upgrades. These reports can be used to detect suspicious firmware migration patterns (e.g., coordinated upgrade to a vulnerable version) or to fulfill regulatory and compliance requirements. This secondary implementation was also successfully validated and shown to support operational and governance objectives without overwhelming the Security Operations Center (SOC) incident response teams.

The presence of symmetry in firmware updates and downgrades denotes an architectural balance that can be strategically preserved or disrupted depending on the intentions. In state-of-the-art cybersecurity frameworks, especially within the OT/ICS or IoT domain, this balance becomes a double-edged sword—providing functional consistency while also introducing potentially exploitable paths for threat actors. Identifying and leveraging this symmetry enriches firmware lifecycle management and strengthens wide-ranging information security by recognizing atypical processes and deviations from the expected behavior.

4.2. Evaluation and Discussion of Impacts

The developed detection mechanism demonstrated a tangible operational impact by generating a single, high-fidelity Sentinel incident only for firmware downgrades while suppressing alerts for potentially benign upgrades. The implementation within the manufacturing organization yielded a substantial reduction in SOC workload. It enabled the analysts to focus solely on possibly malicious downgrades rather than investigating all firmware alternation activities. After three months of deployment, the solution achieved an estimated 93% reduction in weekly “Firmware Change Detected” alerts. Additionally, it substantially accelerated the incident response capabilities and improved Mean Time to Detect (MTTD) through the effective mitigation of false positives.

From a risk mitigation standpoint, the solution effectively identifies downgrade attempts as distinct security incidents, preventing threat actors from covertly reintroducing legacy vulnerabilities. By dissecting the symmetry between a legitimate upgrade and malicious downgrade patterns, the solution intercepts adversarial actions that would otherwise remain camouflaged within the regular traffic. Although our controlled tests—intentional downgrade of an Atlas Copco screw joint machine—did not involve a follow-up firmware-based exploit, the substantial reduction in firmware-based security blind spots directly correlates with a decreased probability of successful post-downgrade compromise. In operational OT/ICS environments, organizations can expect a significant decrease in exposure windows caused by stealthy rollbacks, potentially reducing MTTD from days or even weeks to minutes.

Finally, the regulatory and compliance benefits are also substantial. The automated weekly report ensures that maintenance teams possess up-to-date asset change log and meet regulatory audit requirements without manual review processes. These reports enhance both governance and operational transparency. Furthermore, organizations achieve measurable cost savings through two primary mechanisms: (A) early detection of rollback-induced vulnerabilities, which significantly reduces unplanned downtime, and (B) optimized SOC resource allocation minimizes remediation overhead and the potential impacts of firmware-driven operational disruptions.

4.3. Limitations and Future Implications

Despite the promising results, our research had several constraints that limited its immediate general rollout implementation. The tests were confined to a single device model, Atlas Copco Power Focus 6000. Therefore, considering that firmware alternation behaviors vary significantly across diverse PLCs, controllers, and vendor-specific implementations, the detection accuracy of the solution can be detrimentally impacted. In addition, the developed detection mechanism currently supports only OPAC, leaving the other OT/ICS—covered by “Firmware Change Detected”—protocols unexamined.

Advancing the solution further, future developments plan to address these challenges on multiple fronts. To broaden applicability, we will explore additional PLC/controller vendors (e.g., Siemens, Schneider, and Rockwell) and familiarize ourselves with the internal processes involved during firmware alternations. Furthermore, to extend the coverage of the developed detection mechanism, we will need to research the corresponding OT/ICS protocols (e.g., Siemens S7 protocol within Siemens PLC) and obtain an in-depth understanding of them. The next step would involve creating additional custom parsers and Regex to extract the necessary—for the solution—information from the underlying “Firmware Change Detected” alerts.

This would enable us to expand beyond the initial manufacturing use case and extend the detection mechanism to other OT/ICS sectors where firmware integrity is critical, such as the energy, water, and food and beverage industries. Its passive architecture makes it particularly suitable for environments where active scanning is undesirable, and its agentless design broadens compatibility across diverse device types and vendors.

Lastly, we plan to develop a second automation: immediate automatic email notifications to OT personnel, enabling the instant validation of whether a detected firmware change is expected and business-justified. The primary objective is to eliminate or significantly reduce delays inherent in manual SOC investigation processes.

All these enhancements will evolve our detection mechanism into a resilient, universally applicable solution for safeguarding firmware integrity across the full spectrum of OT/ICS industries.