A Survey of Cross-Layer Security for Resource-Constrained IoT Devices

Abstract

Low-power microcontrollers, wireless sensors, and embedded gateways form the backbone of many Internet of Things (IoT) deployments. However, their limited memory, constrained energy budgets, and lack of standardized firmware make them attractive targets for diverse attacks, including bootloader backdoors, hardcoded keys, unpatched CVE exploits, and code-reuse attacks, while traditional single-layer defenses are insufficient as they often assume abundant resources. This paper presents a Systematic Literature Review (SLR) conducted according to the PRISMA 2020 guidelines, covering 196 peer-reviewed studies on cross-layer security for resource-constrained IoT and Industrial IoT environments, and introduces a four-axis taxonomy—system level, algorithmic paradigm, data granularity, and hardware budget—to structure and compare prior work. At the firmware level, we analyze static analysis, symbolic execution, and machine learning-based binary similarity detection that operate without requiring source code or a full runtime; at the network and behavioral levels, we review lightweight and graph-based intrusion detection systems (IDS), including single-packet authorization, unsupervised anomaly detection, RF spectrum monitoring, and sensor–actuator anomaly analysis bridging cyber-physical security; and at the policy level, we survey identity management, micro-segmentation, and zero-trust enforcement mechanisms supported by blockchain-based authentication and programmable policy enforcement points (PEPs). Our review identifies current strengths, limitations, and open challenges—including scalable firmware reverse engineering, efficient cross-ISA symbolic learning, and practical spectrum anomaly detection under constrained computing environments—and by integrating diverse security layers within a unified taxonomy, this SLR highlights both the state-of-the-art and promising research directions for advancing IoT security.

1. Introduction

Securing IoT/IIoT at global scale requires a cross-layer lens that reconciles heterogeneous devices, tight memory and energy budgets, and adversaries who exploit interactions among firmware, networks, behavior, and trust controls. Accordingly, this review synthesizes mechanisms across layers and data granularities, evaluates accuracy/latency/deployability under resource constraints, and sets a research agenda oriented toward evidence-attached detection and zero-trust-aligned operation.

1.1. Motivation and Scope

The Internet of Things (IoT) is rapidly evolving into a global-scale ecosystem expected to encompass tens of billions of heterogeneous devices deployed across enterprise, industrial, and consumer domains. These devices range from simple sensors and actuators to complex embedded controllers and edge computing nodes, all of which must collaborate in real time across organizational and national boundaries [1,2,3]. The scale of this deployment enables data-driven optimization of production lines, logistics, healthcare services, and smart city infrastructures. However, it also significantly broadens the attack surface—extending from bootloader firmware and wireless protocols to cloud integration and even physical process control.

Recent security investigations have highlighted multiple attack vectors that undermine the integrity of IoT deployments: firmware backdoors intentionally inserted during the manufacturing supply chain, encrypted command-and-control channels designed to bypass perimeter defenses, and manipulation of sensor readings to evade traditional network monitoring tools [4]. These challenges are aggravated by the hardware limitations of microcontrollers and low-power system-on-chip (SoC) platforms typically found in IoT devices. Constrained in memory, energy, and bandwidth, such devices are often unable to support heavyweight cryptographic or intrusion detection solutions, leaving them particularly vulnerable.

Traditional single-layer defenses are insufficient in this context, as attackers can compromise different system layers simultaneously. Cloud-based security services, although powerful, introduce latency, bandwidth overhead, and additional risks related to data sovereignty and privacy. This creates a strong demand for a cross-layer security perspective, where vulnerabilities are addressed holistically across firmware, network, and behavioral layers. For instance, firmware-level analysis can expose insecure reused libraries or misconfigured bootloaders, while lightweight, deep learning, and graph-based intrusion detection can flag anomalies in constrained wireless traffic. Complementary research has also begun exploring behavior-based process-level anomaly detection models, continuous risk assessment using adaptive policy engines, and the adoption of zero trust architecture (ZTA) in distributed IoT environments [5,6].

Based on these insights, this study seeks to consolidate and advance state-of-the-art approaches by combining firmware-level vulnerability analysis with lightweight network-level anomaly detection, while ensuring computational efficiency suitable for resource-constrained environments.

1.2. Contributions and Article Organization

The contributions of this paper are threefold:

• Cross-layer taxonomy: We propose a systematic taxonomy that organizes IoT security mechanisms by system level, algorithmic paradigm, data granularity, and hardware budget. This classification not only clarifies the design trade-offs of existing solutions but also offers a practical framework for positioning emerging research.
• Focused benchmarking: We integrate state-of-the-art firmware security techniques (e.g., static analysis, symbolic execution, machine learning–based binary similarity) with representative network intrusion detection models. Their performance is empirically evaluated on real IoT hardware with respect to accuracy, latency, and deployability.
• Research agenda and exploration goals: Instead of posing open-ended questions, we outline concrete directions for exploration:
• Exploring compatibility challenges of binary analysis across diverse instruction set architectures (ISAs).
• Investigating strategies to minimize the footprint of intrusion detectors while maintaining high accuracy in anomaly detection.
• Advancing hybrid symbolic–learning procedures that combine the rigor of symbolic execution with the adaptability of machine learning.
• Extending cross-layer approaches to incorporate behavioral anomaly detection and zero-latency verification aligned with ZTA principles.

The rest of this document is structured as follows. Section 2 provides an overview of the IoT context and threat landscape, covering typical IoT architectures, resource constraints, multi-layer attack surfaces, and security requirements for edge-bound deployments. Section 3 describes the survey methodology, including the search strategy, inclusion/exclusion criteria, and the review workflow based on the PRISMA 2020 guidelines. Section 4 introduces a taxonomy for cross-layer IoT security, organized by security level, data granularity, deployment model, and algorithmic paradigm. Section 5 focuses on firmware-level security, detailing static, symbolic, and machine learning techniques for binary similarity analysis. Section 6 examines integrated security at the network, behavioral, and policy levels, focusing on lightweight intrusion detection, deep/graph-based models, sensor-actuator/RF spectrum analysis, and zero-trust implementation. Section 7 concludes the paper, summarizes the findings, and outlines future research directions for IoT security.

2. Background and Threat Landscape

To understand the challenges in securing IoT systems, it is first necessary to examine the underlying architecture, the typical resource limitations of devices, and the evolving multi-layer threats that adversaries exploit.

2.1. Typical IoT Architecture and Resource Constraints

Most academic and commercial roadmaps still state that the IoT consists of three layers: the perception layer (or sensor layer), the network layer, and the application/cloud layer [7]. The Industrial Internet of Things (IIoT) often includes an edge control layer, but the basic data path (physical signal → digital data packet → cloud analytics) remains the same [8].

At the perception layer, a single node can have up to 256 kB of RAM, a CPU running at less than 1 GHz, and milliwatt-level battery capacity. Encryption, secure boot logic, and real-time control operations are still required [9]. The number of these billions of diverse devices far exceeds the number of hardware, operating systems, and wireless protocols that security solutions must support [10].

2.2. Multi-Layer Attack Surface

In this section, we use the term multi-layer attack surface to refer to the combined vulnerabilities across firmware, network, and behavioral layers. A detailed taxonomy is provided in later sections, but here we briefly introduce the concept for consistency. The purpose of this section is to show how attacks span across different technical levels, making cross-layer defenses indispensable.

Table 1. Representative Multi-Layer Attack Surface in IoT Systems.

Layer	Representative Threats	Consequence	Exemplary Studies
Firmware	Code-reuse of vulnerable libraries; logic-bombs planted during manufacturing	Remote takeover of identical product lines, supply chain worms	ZigBee light-link chain reaction [11]
Network–Near-field (BLE/ZigBee)	Weak or “Just Works” pairing; static keys; link-layer spoofing	Device impersonation, data theft within radio range	FirmXRay BLE audit [12]
Network–Far-field (MQTT/CoAP/AMQP)	Token hijacking; malicious topic subscription; session fixation	Cloud-to-device command injection across domains	Burglars’ IoT Paradise [13]
Behavior	GPS, RF or ultrasonic spoofing; sensor saturation	False location/process readings; stealthy physical manipulation	GPS spoofing requirements [14]
Trust/Policy	Implicit device trust; coarse-grained ACLs; static segmentation	Lateral movement across tiers, privilege creep	IIoT zero-trust survey [15]

summarizes representative threats, consequences, and representative research at each layer of the IoT. This table provides a brief overview of vulnerabilities and illustrates the need for cross-layer security research. IoT systems face a variety of threats at multiple levels, including firmware vulnerabilities, weak network authentication, behavioral deception, and inadequate trust management. These attack surfaces collectively highlight the importance of a cross-layer security approach.

• Firmware level. The ZigBee Light-Link worm showed that a single unpatched binary could set off a chain reaction that affected all lights in an installation [11].
• Network level. More than 70% of tested BLE devices still default to “Just Works” pairing within local radio range. This makes it easier for attackers to forge connections and launch man-in-the-middle attacks [12]. In the backbone, common messaging protocols such as MQTT or AMQP make it easier for attackers to steal session tokens and send forged commands through the cloud [13].
• Behavioral level. Real-world spoofing can evade conventional (network-centric) intrusion detection systems (IDS) because it manipulates sensor inputs rather than packet semantics; for example, laboratory GPS spoofing has been shown to alter the course of a GPS-guided drone [10,14].
• Trust level. Zero Trust Architecture (ZTA) eliminates mutual trust between users, devices, and workloads, but most current pilots only consider user access to the cloud without checking the provenance of firmware or real-time sensor data [15].

2.3. Security Requirements for Edge-Bound Deployments

Strong IoT security requires more than just cloud-based cryptographic primitives or firewalls. Instead, each layer must have defense-in-depth built-in, especially for devices that operate offline or are occasionally connected.

• Lightweight, with both integrity and privacy. IoT devices typically do not have enough RAM or code space to use standard protocols such as TLS or DTLS. Therefore, security suites must use cryptographic algorithms with smaller memory footprints and simpler handshakes, while still being able to protect against active attackers on the wireless channel [7].
• Multi-layered, fine-grained access control. Security measures should be implemented not only at the cloud API level, but also in the firmware call graph, wireless MAC layer, and lightweight message brokers. If permissions are not enforced at each layer, there is a risk of lateral movement and escalation of the trust chain [8].
• Continuously audit and grant as few access permissions as possible. Modern designs must rethink the identification, localization, and context of each abnormal state change based on zero trust principles [15,16]. However, these checks are currently performed only at the cloud edge, not in embedded runtime environments.
• Local actionability and explainability are critical. Engineers need to understand the meaning of alerts without being able to view cloud logs or developer consoles. Compact on-device summaries (ideally using reduced or quantized language models) are still an emerging research topic [9], but can provide explainable diagnostic results without sacrificing latency or power consumption.

To meet these requirements, security measures must work together at multiple levels. Firmware-level risk assessment can support network-level traffic filtering, anomaly models can enable adaptive privilege reassignment, and policy enforcement points must consider all lower-level inputs. The next section explores how current work addresses (or fails to address) these requirements in both firmware and network contexts.

3. Survey Methodology

To ensure rigor and reproducibility, the survey follows a predefined protocol: broad database searches using a transparent query, explicit inclusion/exclusion criteria, and PRISMA-2020 screening and eligibility. The aim is to bound the corpus to resource-aware, cross-layer IoT security and make subsequent analyses traceable.

3.1. Search Strategy and Databases Queried

Systematic literature search queries were executed on eight digital libraries that jointly cover computer-security, embedded-systems and industrial-informatics research:

• IEEE Xplore and ACM Digital Library—core venues for networked-system security and embedded software;
• ScienceDirect and SpringerLink—major publishers of IoT-specific journals;
• Web of Science and Scopus—multidisciplinary indexing and citation tracing;
• Google Scholar—discovery of gray literature and early-view conference papers;
• arXiv (cs.CR, cs.NI, eess.SP)—access to pre-publication manuscripts.

The search string combined four concept groups with Boolean AND operators:

(“IoT” OR “IIoT” OR “cyber-physical”) AND (“cross-layer” OR firmware OR network OR behavio* OR “zero trust”) AND (security OR “intrusion detection” OR vulnerability OR “access control”) AND (“resource-constrained” OR edge OR embedded OR “low power”).

Results coincided with the rise in BLE (Bluetooth Low Energy)/ZigBee security work and the formalization of zero-trust architecture. Reference lists of selected papers were snow-balled to capture additional studies.

3.2. Inclusion and Exclusion Criteria

To ensure methodological rigor, we established explicit inclusion and exclusion criteria before screening the literature. These criteria are summarized in

Table 2. Inclusion and Exclusion Criteria for the Systematic Review.

Criterion Set	Details
Inclusion	Peer-reviewed journal articles or full conference papers (including accepted arXiv versions); explicit focus on at least one IoT layer (firmware, network, behavior, trust) and on resource-aware design (e.g., memory, latency, power); empirical evaluation on hardware, simulation or benchmark data, or a reproducible design framework; (iv) English language.
Exclusion	Short abstracts, posters, tutorials, patents; work limited to cloud or IT security without device component; papers that present cryptographic primitives in isolation; (iv) duplicate reports—only the most complete version retained.

, which outlines the types of studies that were retained or discarded during the review process.

3.3. Review Workflow

The systematic review followed the PRISMA 2020 guidelines [17] and was divided into three main stages:

• Article identification. A comprehensive keyword-based search of major academic databases and preprint servers retrieved a total of 1084 articles. After automatically removing 142 duplicates by matching DOI, title, and arXiv ID, 942 unique articles remained for further review.
• Screening. Titles and abstracts were evaluated according to the inclusion and exclusion criteria defined in Section 3.2. In this step, a total of 579 articles were excluded, including editorials, position papers, short abstracts, purely cloud-centric studies, and articles not related to IoT or resource-constrained environments. A total of 363 articles were reviewed in full text.
• Eligibility review. Afterwards, we reviewed the full text to ensure methodological soundness and direct relevance to firmware, lightweight network defense, behavioral modeling, zero trust implementation, or device-side explainability. Papers that did not conduct empirical evaluation, papers that were superseded by new versions, or papers that only focused on traditional IT systems were excluded.

After eliminating 160 papers, a total of 196 studies were finally available for inclusion. Screening and eligibility assessments were conducted in parallel by two reviewers. In nine instances of disagreement, consensus was reached through discussion, and in one borderline case a third reviewer mediated. This consensus procedure is consistent with PRISMA-2020 guidelines and helps ensure transparency and reproducibility.

4. Taxonomy of Cross-Layer IoT Security

Cross-layer security in the Internet of Things (IoT) requires a systematic overview of where defenses are deployed and how they combine across different layers.

Figure 1 visually illustrates the IoT trust chain, from the perception layer through the network layer to the application layer, listing representative components at each layer (e.g., sensor and device hardware and software, near-field and long-range communications, cloud applications, interfaces, and device connectivity). The right-hand pane captures a layer-by-layer analysis, including attack and solution summaries, culminating in the trust chain endpoints. These insights inform the overall protection layers (device, traffic, cloud, application, and interface security), ultimately enabling secure IoT access control.

Based on this layered approach, we organize prior research along four orthogonal axes used in this section: security layer (firmware/device, network/transport, behavior/application, trust/policy), data granularity (binary, packet/stream, telemetry, RF spectrum), deployment model (on-device, hybrid edge cloud, cloud/OTA), and algorithmic paradigm (rule-based/machine learning/deep learning/optimization).

This categorization clarifies scope and limitations, highlights integration points between layers, and provides a common foundation for comparing heterogeneous approaches.

4.1. Security-Layer Perspective

The system architecture level at which these methods are applied is a key element in understanding a cross-layer security strategy for the Internet of Things (IoT). We use four levels of abstraction: firmware/device, network/transport, behavior/application, and trust/policy. Each layer presents its own threats and limitations, and security solutions vary in terms of data availability, computational power, and risk models. As shown in Figure 1, the IoT trust chain covers the perception layer, network layer, and application layer, each of which includes different components such as sensors, communication interfaces, and cloud services. The figure illustrates how security issues, from device software integrity to interface protection, are addressed layer by layer, laying the foundation for secure IoT access control and trusted system behavior.

• Firmware/Device Layer. This layer includes security features that directly affect hardware peripherals, microcontroller instructions, or device firmware. This layer provides both active analysis (e.g., vulnerability detection) and runtime protection mechanisms (e.g., attestation and execution control). Many embedded systems lack memory protection or statically link binaries, making them vulnerable to attacks such as memory corruption, control flow hijacking, and binary reuse. Recent research has focused on finding parallels between symbolic execution [18], lightweight taint tracking [19], and semantic hashing [20] and firmware. Researchers have also explored shadow stack enforcement [21], TrustZone isolation [22], and secure boot [23] to ensure runtime security. These approaches are particularly important in mission-critical applications such as drones, industrial actuators, and medical sensors, where firmware compromise can have severe practical consequences.
• Network/Transport Layer. The network layer encompasses communications based on Bluetooth Low Energy (BLE), ZigBee, LoRa, Wi-Fi, and MQTT-based cloud protocols. Security at this layer includes device fingerprinting, traffic injection, spoofing, replay, and protocol degradation. Existing defenses include Bluetooth Low Energy fingerprinting [24], packet timing and channel hopping anomaly detection [25], and lightweight intrusion detection systems (IDS) using compressed CNNs or GNNs [26,27]. Additionally, there are numerous examples of attacks targeting specific protocols, such as ZigBee Touch Link Hijacking [28], MQTT Hijacking [29], and Bluetooth Address Randomization Failures [30]. Many embedded IDS engines use bitfield encoding or Bloom filters [31,32] and operate on systems with less than 100 kB of RAM.
• Behavioral/application layer. This layer monitors the consistency of higher-level application logic, actuator control, and sensor data. It provides both direct models of time-varying physical processes (e.g., the water level in a tank) and indirect models, such as policies for monitoring context-aware applications. Graph-based models, such as GAT-GRU [33], temporal sensor anomaly detectors [34], and hybrid context/state machine verifiers [35,36], are widely used in industry. To prevent privilege abuse, smart homes utilize tools such as ContexIoT [37] and Soteria [38] to record user interactions with devices. Modeling the overall behavior of a device is crucial for detecting hidden behaviors or policy violations that cannot be detected by firmware or packet filters.
• Trust/Policy Layer. This layer adds logical structure and architectural guidance to ensure reliable system operation across different domains. It includes zero-trust identity enforcement, continuous authentication, remote attestation chains, and federated policy control. Systems such as WAVE [39], XToken [40], and MPA [41] aim to achieve fine-grained authorization and feature propagation in resource-constrained multi-tenant systems. Trust layer approaches also include device access protocols [42] for protection against forged configuration attacks (e.g., ghost device attacks) and distributed ledger systems for trust traceability [43]. These approaches are particularly important when IoT devices are owned by multiple parties and policies need to be coordinated without a shared physical infrastructure.

4.2. Data Granularity

Cross-layer security solutions for the Internet of Things (IoT) process input data at different levels of detail. This affects how well they detect threats, their operational costs, and the difficulty of integration. There are four levels of data granularity: binary level, packet/stream level, time series telemetry level, and radio frequency spectrum (RF) level. Each level has its own advantages and disadvantages that affect the design and use of IoT security measures.

Binary-level analysis looks for static vulnerabilities, backdoors, and cryptographic errors in firmware images or executable code (usually in raw or disassembled format). The tool used in [44] uses a secure stream processing framework to inspect the firmware without executing it. This ensures that vulnerabilities can be found even when the device is not connected to the Internet. Ref. [45] also discusses trusted execution environments (TEEs), which can assist binary analysis by providing a secure code inspection setup that is independent of the rest of the system. These methods are ideal for detecting zero-day vulnerabilities, but lack runtime behavioral context, making it difficult to detect dynamic threats. For example, static analysis in a trusted execution environment (TEE) [45] can find firmware errors but not problems that occur during program execution.

Packet and flow-level inspection is a common feature of network intrusion detection systems (NIDS), which analyze PCAP files or network traffic in real time. Approaches include statistical feature extraction [46], protocol-specific filtering for protocols such as MQTT [47], and compressed stream embedding using advanced models such as graph neural networks (GNNs) [47]. These approaches strike a good balance between coverage and speed, making them well suited for detecting network-based issues. However, since they primarily analyze packet metadata, they may miss aspects of semantic intent or high-level device logic. For example, ref. [46] discusses edge computing frameworks that allow real-time traffic analysis. However, these approaches struggle with context-sensitive attacks and require more information about the application layer.

Time series telemetry analysis uses data such as actuator state changes, energy consumption, or sensor values to understand device functionality and identify issues. Increasingly, users are leveraging this level of detail for general modeling and predictive anomaly detection [48,49]. For example, ref. [48] discusses edge computing applications that analyze telemetry data to detect behavioral changes, providing it with rich semantic context. However, this approach requires longer observation windows and complex correlation models, which can be challenging for resource-limited IoT devices. Systems such as TEEs used to protect telemetry processing in [49] are often migrated to edge or cloud infrastructure due to their high computational power requirements.

Radio frequency (RF) spectrum analysis is critical for detecting problems in wireless networks, especially in the presence of denial of service (DoS) attacks, malicious base stations, or protocol spoofing [50]. These systems analyze raw I/Q signal data or spectrum fingerprints to detect unwanted transmissions or interference. RF detection is applicable to any protocol and can therefore detect threats that are not present in traditional protocol stacks such as ZigBee and LoRa. For example, ref. [50] describes a TEE-based framework for protecting wireless communications by analyzing RF signals. However, RF analysis is difficult to apply to low-power devices because it requires a lot of computational power and therefore typically requires specialized hardware.

When choosing the level of detail in the data, trade-offs must be made between latency, interpretability, and hardware feasibility. New hybrid approaches combine simple flow-level inspection with deeper binary or RF analysis to enable immediate action when suspicious events are discovered [50]. For example, a system could start with packet-level monitoring to detect threats and then leverage RF spectrum analysis to more precisely detect wireless attacks. This can improve both efficiency and accuracy.

4.3. Implementation Models and Algorithmic Paradigms

This section explores the practical aspects of how these security solutions are actually implemented, based on a layer-oriented approach and data granularity. We will therefore discuss deployment models, which define the placement of defensive measures within the IoT stack, and algorithmic paradigms, which determine how threats are detected and mitigated in practice.

To achieve practical integration of IoT security, it is important to consider not only where defensive measures are implemented but also how their algorithms operate. Deployment models determine the physical and architectural placement of defensive mechanisms within devices, edge nodes, and cloud infrastructure. Algorithmic paradigms define computational strategies for implementing intrusion detection, anomaly detection, and adaptive defenses within resource-constrained environments. Together, these two perspectives form the foundation for the practical implementation of cross-layer IoT security.

4.3.1. Deployment Models

IoT security solutions must adapt to the hardware and deployment environment of edge devices. There are three primary deployment models: on-device deployment, hybrid or collaborative deployment, and cloud-based over-the-air (OTA) delivery. Each type addresses specific operational and security requirements.

With on-device deployment, security logic is implemented directly on a microcontroller (MCU), system-on-chip (SoC), or edge gateway. This allows devices to be protected in real time and with very low latency. This model is best suited for IoT applications that need to run quickly but cannot offer many features due to low processing power and memory capacity. Firmware integrity checking [51] and lightweight intrusion detection systems (IDS) [47] are two examples of technologies that are often deployed on devices. For example, ref. [51] describes the trend among IoT developers to use ARM TrustZone to secure devices. On the other hand, ref. [47] describes a trusted execution environment for a lightweight IDS. Newer platforms can leverage advanced hardware such as ARM TrustZone [52] to separate critical tasks. These systems provide strong protection but must be optimized for specific hardware to run within limited resources.

Hybrid implementations distribute security tasks between cloud infrastructure and edge devices. We perform simple or real-time analysis on our own computers, but move computationally intensive activities (such as graph-based threat detection or advanced analytics) to the cloud. This approach strikes a balance between edge responsiveness and scalable analysis. For example, ref. [46] discusses an edge computing framework that supports local packet filtering, while a cloud-based system [48] performs more complex threat analysis. For centralized correlation, the system can upload PCAP files or extracted features, or local anomaly alerts can trigger cloud-based processing [47]. Hybrid implementations achieve scalability but require secure network connectivity and strong cloud security.

Cloud-based OTA implementations can implement vulnerability scanning, security updates, and anomaly detection through regular cloud updates. This model enables rapid response to new threats, but can be risky if the update channel is not secure. For example, ref. [53] discusses an open TEE framework that supports secure OTA updates. Digital signatures and encrypted sessions are essential to ensure the security of the update chain [50]. OTA technology can provide updated anomaly detection models for edge devices [49]. However, flaws in the update process may allow attackers to inject malicious code. Therefore, a strong authentication mechanism is required.

From a hardware perspective, the choice of deployment model is inevitably constrained by the available computational resources on the IoT platform. Consumer devices are typically based on microcontrollers (MCUs) such as ESP32 or STM32, while industrial IoT implementations often use more powerful edge accelerators such as TPUs or NVIDIA Jetson boards. These heterogeneous hardware configurations mean that security architectures cannot be applied uniformly but must be adapted to the device class. In practice, this adaptation often requires pruning, quantization, or simple optimization of anomaly and intrusion detection models to ensure feasibility within tight memory and power budgets. Frameworks such as TinyML and platforms such as EdgeImpulse [54] demonstrate how compressed inference runtimes can be efficiently executed on MCUs, enabling real-time anomaly detection directly at the edge. This hardware-centric perspective complements the previous discussion of deployment models by showing that practical feasibility depends not only on the location of the security logic (on-device, hybrid, or cloud-based), but also on how it fits within the computational constraints of the target device.

When choosing a deployment strategy, latency, update frequency, hardware capabilities, and operational considerations must be taken into account. Recent research has explored techniques for dynamically switching between models, including sending complex analytics to the cloud only when local monitoring detects suspicious conditions [50]. This flexible approach maximizes resource utilization while maintaining high security standards.

4.3.2. Algorithm Paradigms in Cyberspace Security Applications

Cybersecurity has already implemented significant qualitative leaps in the use of artificial intelligence (AI) algorithms toward the fulfillment of such core functions as intrusion detection, security posture assessment, and related dimensions of defense strategy enhancement. Types of algorithms discussed in this section that have proven useful toward the advancement of cybersecurity include machine learning (ML), deep learning (DL), and optimization algorithms.

• Machine Learning Paradigms

Most of the algorithms used in network security are machine learning because they are easy to implement and support good computer implementation. The methodologies that these methods embrace include supervised, unsupervised, semi-supervised, and reinforcement learning. These algorithms find their best application where there is a need for fast sorting as well as where the computers are not performing at a high level.

Supervised learning: K-nearest neighbor (K-NN), support vector machine (SVM), naive Bayes (NB), and decision tree (DT) are the most popular intrusion detection algorithms. For example, Al-Omari et al. [55] developed a DT-based intelligent intrusion detection model that achieved 98% accuracy on the UNSW-NB15 dataset by evaluating security variables using the Gini coefficient. This reduces computational time compared to typical machine learning methods. Sapavath et al. [56] also used NB to detect cyberattacks in virtualized wireless networks in real time. They achieved this by modeling an adaptive agent system and achieved 99.8% accuracy. Abuali et al. [57] developed a DT-based intelligent intrusion detection model that achieved 98% accuracy on the UNSW-NB15 dataset by evaluating security variables using the Gini coefficient. This reduces computational time compared to typical machine learning methods. Sapavath et al. [56,58] also used a black box model to detect cyberattacks in virtualized wireless networks in real time. They achieved this by modeling an adaptive agent system and achieved 99.8% accuracy [59] combined support vector machines (SVM) with deep learning for intrusion detection. They achieved 98.50% accuracy on the CSE-CIC-IDS2018 dataset, showing that this approach is well suited for detecting complex patterns. These models are good at ranking known attack patterns but struggle with high-dimensional data or novel attacks [57].

Unsupervised learning: To protect against distributed denial of service (DDoS) attacks, algorithms such as K-Means are used. Gu et al. [58] developed a semi-supervised K-Means algorithm based on hybrid feature selection (SKM-HFS), which achieved the lowest detection latency on datasets such as CICIDS2017. Unsupervised algorithms are well-suited for detecting unusual patterns in unlabeled data, but may not be as accurate in complex attack scenarios [60].

Semi-supervised learning: Nishiyama et al. [61] developed the SILU algorithm, which uses large amounts of unlabeled data to improve supervised classifiers such as SVMs and Random Forests (RFs). This approach improves detection accuracy and reduces the number of false positives, making it suitable for real-time applications with limited labeled data [62].

Reinforcement Learning (RL): Reinforcement learning is increasingly being used to develop defense methods. For example, Liu et al. [63] used a deep recurrent Q-network (DRQN) to make defense decisions in a stochastic game system. This approach reaches the optimal policy faster than standard methods. Reinforcement learning is well-suited to dynamic situations because it can adapt to changing threats, but it requires a lot of computational power [64].

Representative IoT evidence: Doshi et al. used classic machine learning traffic features to detect consumer IoT DDoS attacks and demonstrated high accuracy of a lightweight model.

• Deep Learning Paradigms

Deep learning algorithms, especially those using neural networks, are well-suited to processing high-dimensional, complex data. This makes them ideal for detecting sophisticated attacks and assessing security posture.

Convolutional Neural Networks (CNNs): CNNs are well suited to detecting cyberattacks in many different domains. Khaw et al. [65] developed a one-dimensional CNN with an autoencoder (AE) for protecting transmission line relays. They achieved 100% accuracy on the OPAL-RT HYPERSIM dataset. Ho et al. [66] developed a CNN-based multi-class classification model that achieved 99.78% accuracy on the CICIDS2017 dataset by fine-tuning hyperparameters through repeated testing. Nazir et al. [67] developed a hybrid CNN-LSTM architecture for IoT threat detection that achieved 99.20% accuracy on the IoTID20 dataset by capturing both spatial and temporal variables. CNNs perform well on structured data but require extensive parameter tuning [68].

Different types of recurrent neural networks (RNNs): Long short-term memory (LSTM) and gated recurrent unit (GRU) are examples of RNNs used to analyze sequential data. Hossain et al. [69] used LSTM to detect SSH and FTP brute force attacks, achieving 99.88% accuracy on CICIDS2017. Ma et al. [70] developed XBiLSTM-CRF for network security entity detection, achieving 90.54% accuracy on the open source NER dataset. Bukhari et al. [71] used a federated learning approach of sparse CNN and bidirectional LSTM (SCNN + Bi-LSTM) to improve defense strategies, achieving 97.80% accuracy on the WSN-DS dataset while maintaining training confidentiality. These models are well suited to capture temporal relationships but require a lot of computational power [72].

Autoencoders (AEs) address the data imbalance problem in attack detection. Kunang et al. [73,74] used AE for feature discovery and achieved 86.96% accuracy on NSL-KDD. Qazi et al. [75] developed a stacked asymmetric deep autoencoder (S-NDAE) and achieved 99.65% accuracy on the KDD CUP99 zero-day attack test. AEs are helpful for feature learning but may have difficulties with highly imbalanced datasets [76]. Generative adversarial networks (GANs) improve datasets by creating fake data. Ding et al. [77] developed a table-assisted classifier GAN (TACGAN) and achieved 95.86% accuracy on CICIDS 2017. GANs make models more robust but must be carefully tuned to avoid mode collapse [78].

Representative IoT evidence: Meidan et al.’s N-BaIoT uses deep autoencoders to flag botnet traffic from compromised IoT devices (Mirai/BASHLITE), achieving near-instant detection.

• Optimization Algorithm Paradigms

In the field of cybersecurity, optimization algorithms such as classical methods and swarm intelligence (SI) methods are very important for tuning parameters and selecting features.

Classical optimization methods such as genetic algorithms (GA) and simulated annealing are often used for feature selection. Seth and Chandra [79] combined KNN with modified gray wolf optimization (MGWO) and achieved 99.87% accuracy on the Solaris dataset. Anonymous et al. [74] combined SVM, KNN, RF, DT, LSTM, and ANN with fuzzy clustering to find intruders. They improved feature selection by using fuzzy clustering and achieved 99.10% accuracy on CICIDS2017. These strategies are well suited for simple problems but are not suitable for more complex non-convex problems [80].

Swarm intelligence methods: SI methods such as particle swarm optimization (PSO) and gray wolf optimization (GWO) can improve model performance and feature selection. Kan et al. [81] developed an adaptive PSO-CNN (APSO-CNN) for IoT intrusion detection with an accuracy of 96%. Chohra et al. [82] used the Chameleon model with ensemble learning and achieved an F-value of 97.3% on the IoT-Zeek dataset. SI techniques are well suited for solving multidimensional problems, but their convergence may take a long time [83].

Game theory and stochastic models: Game theory helps improve defense techniques by simulating the interactions between attackers and defenders. Hyder and Govindarasu [84] used game theory to protect smart grids from cyber attacks and reduce the probability of attacks. Bhuiyan et al. [85] developed a risk-free Stackelberg game model that reduced computational time by 71%. These models can help develop strategies, but they must make correct assumptions about the attacker’s behavior [86].

Benchmark IoT evidence: Benmalek et al. hybridize an enhanced PSO with deep models for real-time IoT cyber-attack detection on a benchmark IoT, shedding light on the place of metaheuristics in the constrained tuning/feature selection space.

Table 3. Performance Comparison of AI Algorithms in Cyberspace Security.

Reference	Algorithms	Application	Datasets	Accuracy	Advantages	Limitations
[55]	DT	Intrusion Detection	UNSW-NB15	98	High accuracy, reduced computation time	Limited to known attack patterns
[56]	NB	Intrusion Detection	Known/Novel Attacks	99.8	High precision, dynamic detection	Struggles with novel attacks
[57]	Improved K-means	Intrusion Detection	KDD CUP99	95.75	Reduced training time	Limited to specific attack types
[58]	SKM-HFS	DDoS Detection	CICIDS2017	-	Minimal detection delay	Lower accuracy in complex scenarios
[61]	SILU	Intrusion Detection	Unlabeled Logs	-	Low overhead, improved detection	Requires integration with supervised methods
[63]	DRQN	Defense Strategy	Stochastic Systems	-	Fast convergence	High computational cost
[65]	1D-CNN + AE	Intrusion Detection	OPAL-RT HYPERSIM	100	Perfect accuracy	Dataset-specific performance
[66]	CNN	Intrusion Detection	CICIDS2017	99.78	High multi-class accuracy	Complex parameter tuning
[69]	LSTM	Intrusion Detection	CICIDS2017	99.88	Effective for sequential data	Computationally intensive
[70]	XBiLSTM-CRF	Entity Recognition	Open-source NER	90.54 (Precision)	High precision for text analysis	Limited to specific entities
[73]	AE	Intrusion Detection	NSL-KDD	86.96	Effective feature extraction	Struggles with imbalanced data
[75]	S-NDAE	Intrusion Detection	KDD CUP99	99.65	High accuracy for zero-day attacks	Dataset-specific performance
[77]	TACGAN	Intrusion Detection	CICIDS2017	95.86	Robust data augmentation	Risk of mode collapse
[79]	MGWO + K-NN	Intrusion Detection	Solaris	99.87	High accuracy, effective feature selection	Slow convergence
[81]	APSO-CNN	Intrusion Detection	Public IoT	96	Adaptive parameter tuning	Local optima risk
[82]	Chameleon	Intrusion Detection	IoT-Zeek	97.30 (F score)	High F score, ensemble learning	Complex implementation
[84]	Game Theory	Defense Strategy	Smart Grid	-	Optimal policy allocation	Requires accurate attacker models
[85]	Stackelberg Game	Defense Strategy	Attack Graph	-	Reduced computation time	Assumption-dependent
[87]	FOA-SVM	Situation Assessment	-	81.2	Quantitative risk evaluation	Moderate accuracy
[88]	NB + CRQ-J48	Situation Assessment	Virtual Power Plants	82	Economic risk evaluation	Limited to specific contexts
[89]	SSC + MCS	Situation Assessment	RBTS Bus 2	-	High reliability	Computationally intensive
[90]	DAENDD (UOSW)	Situation Assessment	NSL-KDD	-	Improved recall for imbalanced data	Longer evaluation time
[91]	GA-PNN	Situation Assessment	KDD CUP99	98.46	High training speed	Dataset-specific performance
[92]	GRU-RNN	Situation Assessment	-	-	Robust for time-series data	High training time
[93]	EWM-IFAHP	Situation Assessment	KDD CUP99	90	High generalization	Moderate accuracy
[59]	SVM + DL	Intrusion Detection	CSE-CIC-IDS2018	98.5	Robust combination of SVM and DL for complex patterns	High computational resources needed
[67]	CNN + LSTM	Intrusion Detection	IoTID20	99.2	Captures spatial and temporal features effectively	High computational complexity
[71]	SCNN + Bi-LSTM (Federated Learning)	Defense Strategy Optimization	WSN-DS	97.8	Privacy-preserving, reliable detection	Requires robust network infrastructure
[74]	SVM, KNN, RF, DT, LSTM, ANN + Fuzzy Clustering	Intrusion Detection	CICIDS2017	99.1	Adaptive feature selection with fuzzy clustering	Increased preprocessing complexity

sums up disclosed performances by different algorithms in intrusion detection, security scenario assessment, and defense optimization. It also lists their datasets, accuracy, and main advantages.

As summarized in Table 3, three themes emerge: first, classical ML baselines provide very strong accuracy–latency tradeoffs on structured datasets, though they fail under conditions of concept drift and novel attack families; second, DL models discover spatial–temporal structure and frequently outperform ML on complex traffic and telemetry with higher compute and tuning effort—thus good for gateways and edge nodes rather than tiny MCUs; third, optimization and game-theoretic methods complement detection by feature selection, hyper-parameter tuning or defense allocation increasing robustness at the cost of increased design complexity. These lead us to propose hybrid pipelines motivated by lightweight on-device screening paired with deeper edge/cloud analytics.

Machine learning algorithms have gained attention in the attack detection community due to their simplicity and their ability to perform well in resource-constrained environments. SVM + DL [59] and other hybrid methods are more robust to complex datasets but require higher computational power. Deep learning algorithms such as CNN, LSTM, and hybrid models such as CNN + LSTM [67] and SCNN + Bi-LSTM [71] perform better on complex and imbalanced datasets. They can be used in IoT and wireless sensor networks but require high computational power and sophisticated parameter tuning [66,69]. Optimization methods such as SI and fuzzy clustering [74] can improve feature selection and strategic decision making. Models such as APSO-CNN and Stackelberg games show potential in IoT and smart grid applications [81,85]. The choice of algorithm depends on the specific security task, the specifics of the dataset, and the performance limitations of the computer. Future research should explore hybrid models that leverage the best parts of ML, DL, and optimization techniques to address emerging threats and data imbalance. This trend of adapting classical ML/DL paradigms to resource-constrained IoT devices has also been recognized in recent surveys, which emphasize that IoT-specific constraints—limited memory, energy, and heterogeneity—necessitate tailored versions of otherwise general algorithms.

Figure 2 brings together the entire pipeline across On-Device/MCU → Edge/Gateway → Cloud/Control Plane to make concrete the implementation view. The mechanisms are grouped by tiers so that the components represent where their most natural place of execution might be—running firmware analysis and lightweight IDS on constrained MCUs; deep/graph IDS, sensor–actuator consistency, and RF monitoring at the edge; trust evaluation, policy decision, and enforcement in the control plane. Solid arrows denote data flow (evidence-attached alerts, anomaly features, behavioral/RF signals); return path contains control/feedback from trust and policy back to enforcement (fine-grained tokens, rate limits, isolation) to devices as OTA patches or model updates. It will stack MCU-side and cloud-side blocks vertically to minimize horizontal span but keep signal collection left-to-right logic through to decision and action. The four design axes—data granularity, algorithmic paradigm, deployment, hardware budget—are called out with dotted boxes so that a reader can immediately relate methods to where they execute and why.

5. Firmware-Level Security

Academic and industrial circles have, in recent years, directed significant attention toward the security evaluation of embedded firmware. Techniques for vulnerability discovery in conventional computer systems typically prove inapplicable to firmware assessment owing to the considerable diversity among embedded devices, their specialized functionalities, and their constrained execution contexts. Static analysis and symbolic execution represent two principal methodologies for program examination that can identify security flaws by analyzing a program’s architecture and logic (without running the code). This renders them quite valuable for assessing the security of embedded firmware.

Figure 3 presents an organization of the typical approaches that would facilitate your understanding of the technical landscape about firmware similarity analysis techniques applied in vulnerability detection. They are usually organized by the type of analysis as static, dynamic, hybrid, and machine learning with accuracy versus coverage versus runtime applicability versus applicability to pure binary firmware paradigms.

Static analysis examines the structure and logic of firmware binary code to find potential security vulnerabilities, such as buffer overflows or hard-coded passwords. It does not require a runtime environment, making it well suited for embedded devices. However, it can produce false positives due to the lack of context. Recent research has found new algorithms and techniques to make it more efficient and accurate.

Symbolic execution checks for vulnerabilities by simulating all possible execution modes of a program. It is particularly suitable for finding complex logic errors. However, firmware analysis faces challenges due to path explosion and peripheral device interaction modeling. Recent research has improved performance through code slicing and domain-related knowledge.

Recent research has made firmware security analysis more automated and accurate. For example, a framework for detecting application privacy leaks uses static analysis to identify privacy issues in IoT applications. Hardware-based fuzz testing uses hybrid modeling to improve path exploration. Reverse engineering methods for smart home IoT firmware can discover network vulnerabilities, while tracing hardware information flows helps analyze the security of firmware-hardware collaboration. These improvements significantly promote the discovery of vulnerabilities in embedded device firmware and are both accurate and scalable.

5.1. Static and Symbolic Analysis Techniques

This section covers the ideas, applications, current research, and limitations of static and symbolic analysis methods. A comprehensive evaluation will be conducted in this section, focusing on their usefulness and associated challenges in analyzing the security of embedded firmware.

5.1.1. Static Analysis Techniques

Static analysis techniques examine the binary code or intermediate representation of a program to determine control flow, data flow, and semantic information. They can also discover potential security vulnerabilities such as buffer overflows, command injection, or hard-coded credential backdoors. Static analysis does not require the program to be running, so it is suitable for embedded devices with limited resources, especially when the firmware source code is not available or has limited documentation. The typical steps of firmware security analysis are as follows:

Deploy the firmware and make it available for use: Extract the executable code or application from the firmware image using tools such as Binwalk [94] or Binary Analysis Next Generation (BANG) [95]. These programs can identify file systems, compression schemes, or binary structures to extract the firmware into an analyzable binary.

Code conversion: Convert the binary code to assembly language or an intermediate representation such as VEX or LLVM-IR using reverse engineering tools such as IDA Pro [96] or Ghidra [97]. These tools are available for many different instruction set architectures (ISAs), such as ARM, MIPS, and x86. They can also find function call links, string references, and control flow graphs (CFGs).

Program analysis: Uses static analysis methods such as fuzzy hashing [98], taint analysis, or control flow analysis to identify program features and potential security vulnerabilities. For example, fuzzy hashing can find re-used third-party libraries or code snippets that are known to be vulnerable. On the other hand, taint analysis tracks the flow of data from user input to sensitive processes to identify instruction injection or buffer overflows.

Vulnerability detection: Uses special techniques to search for backdoors, memory corruption, or other security issues by analyzing program behavior.

Prior research and surveys have consistently demonstrated that static analysis is highly effective in detecting vulnerabilities in embedded device firmware, particularly in uncovering backdoors and taint-based attacks [99,100,101,102,103,104,105,106].

Here are some examples of research:

• Costin et al. [99] developed a method for analyzing large numbers of firmware files using fuzzy hashing. The method finds backdoor vulnerabilities such as weak keys and hardcoded credentials by finding similarities between firmware files. By examining 693 firmware images, 38 known vulnerable files were identified. However, the file-level granularity makes the method less precise, and the additional effort makes it unsuitable for large-scale firmware.
• Stringer [100] developed a method for comparing static data in commercial off-the-shelf (COTS) firmware to detect hardcoded credentials and undocumented functions. The method finds potential backdoors by comparing static strings in binary files. The method is well suited for large-scale analysis, but has a high false positive rate.
• HumIDIFy [101] proposed a semi-supervised learning method for finding binary functions in firmware and comparing them to predicted functions to detect hidden functions or backdoors. Tests show that the analysis of COTS firmware has a low false positive rate, although the method requires a high-quality training dataset.
• Firmlice [102]: Uses static analysis to build a program dependency graph (PDG), uses authentication slices from entry points to privileged operations, and combines symbolic execution to check fixed-value routing restrictions to find backdoors that bypass authentication. The method is very accurate, but only works for certain types of backdoors and is difficult to apply to other types of vulnerabilities.
• DTaint [103]: A method for vulnerability detection using taint analysis is proposed, which traces data from sensitive inputs (sources) to dangerous functions (sinks) by building data flow graphs of intra-procedural and inter-procedural data flows, and finds buffer overflows and instruction injections. DTaint’s bottom-up analysis can detect vulnerabilities more accurately, but takes longer for complex firmware.
• SainT [104]: In IoT applications, it monitors sensitive data (such as device status or user information) sent to external outputs and finds possible data leaks. SainT works well for type I firmware, but does not work well for type II and type III firmware because these formats are too complex.
• Zheng et al. [105]: They combined protocol parsing with static taint analysis to find protocol fields and key functions in firmware, thereby accelerating the search for taint-based vulnerabilities. This strategy reduces the amount of analysis by selecting appropriate keywords, thereby improving efficiency.
• Karonte [106] proposed a multi-binary static analysis method to simulate the communication between firmware components (such as web servers and background services) to discover insecure data transmission or logic vulnerabilities. Karonte solves some of the problems of single-component analysis, but needs to better handle more complex firmware.
• PrivacyGuard [107]: A framework has been developed for detecting privacy leaks in applications. It uses static analysis to check trigger condition-action rules in IoT applications to identify privacy risks such as location tracking and activity analysis vulnerabilities. The system is well suited for evaluating large IoT application datasets and significantly improves the level of privacy protection [107].
• Smart Home IoT Firmware Analysis and Exploitation Framework [108]: The framework supports reverse analysis of smart home IoT firmware to identify network weaknesses (such as unencrypted communication and weak authentication) and missing protection mechanisms (such as NX and Stack Canary). This helps in analyzing the security of smart home devices [108].
• Hardware Information Flow Tracing [109]: A simple path-based hardware information flow tracing method is proposed. It uses static analysis to examine firmware-hardware interactions and detect potential information leaks and dangerous operations. The method works well on low-resource devices and is fairly accurate [109].

One of the advantages of static analysis is that it does not require a runtime environment. This makes it suitable for embedded devices with limited resources and can find many types of vulnerabilities. However, it also brings some problems to firmware analysis:

High false positive rate: Static analysis often produces false positive results because firmware code is complex and diverse and lacks sufficient context information. For example, fuzzy hashing may mistakenly mark code that has the same functionality as the vulnerable code as vulnerable [99].

Not very helpful for Type II and Type III firmware: Type I firmware is usually based on standard file systems such as Squashfs, which are easy to decompress and analyze. On the other hand, Type II and Type III firmware lack a standard format or clear loading standards, which makes it difficult for static analysis tools to find code segments and data structures [110].

Insufficient analysis of the interactions between different parts of the firmware: Firmware is usually composed of many parts that work together, such as a web interface and background functions. Current static analysis methods only consider one component at a time, ignoring the interactions and data flows between components that may lead to logical vulnerabilities [106].

Computational complexity: Static analyses are difficult to perform at scale because they require processing complex control flow or data flow graphs and are therefore inefficient [103].

5.1.2. Symbolic Execution Techniques

Symbolic execution considers all different execution paths for a program input and represents them as symbolic values. Then, a constraint solver (such as Z3) is used to check for vulnerabilities by checking the path constraints. It is able to precisely analyze how a program runs, especially in detecting hard-to-find vulnerabilities such as memory corruption and authentication bypass backdoors. On the other hand, path explosion and environment dependencies make analysis of embedded firmware more difficult.

When analyzing firmware, the typical steps of symbolic execution are as follows:

• Firmware preprocessing: As with static analysis, the executable code is extracted from the firmware and converted into an intermediate representation, such as LLVM-IR or VEX.
• Input symbolization: The program input (e.g., user input or peripheral input) is converted into symbolic variables.
• Path analysis: All possible paths of the program are explored using a symbolic execution engine (e.g., KLEE [111] or angr [112]) and path constraints are imposed.
• Constraint solving: A constraint solver is used to check whether the input can trigger the vulnerability by checking the satisfiability of the path constraints.

When analyzing embedded firmware, symbolic execution is often used to investigate specific hardware types or vulnerabilities. Here are some research examples:

• Avatar [113]: A hybrid execution framework that leverages both symbolic execution and full-system simulation is proposed. It uses S2E [114] as a symbolic execution engine, dynamically intercepts simulation events (such as memory access or instruction execution), and selectively symbolizes important code segments to find vulnerabilities. This approach works for class I, II, and III firmware, but not for all peripherals.
• FIE [115]: Based on KLEE, a symbolic execution tool for MSP430 microcontrollers is developed that can simulate memory and interrupt operations to find security vulnerabilities. FIE only works for MSP430 and has many bugs due to path explosion.
• FirmUSB [103]: This is a USB controller firmware for the 8051/52 architecture that leverages domain knowledge and symbolic execution to create functional models and find BadUSB vulnerabilities. FirmUSB limits the scope of symbolic execution, making it seven times more efficient than conventional symbolic execution.
• Inception [116]: Created a symbolic virtual machine based on KLEE to transfer firmware code to LLVM-IR to find memory leaks in ARM Cortex-M3 firmware. Inception can analyze assembly and library functions, but it does not work well for complex firmware.
• Gerbil [117]: Searches for privilege separation vulnerabilities by using backward slicing to find potentially vulnerable code regions and combining symbolic execution to search deep paths. Gerbil avoids path explosion by skipping complex library functions, but requires rich domain knowledge.
• FIoT [118]: Uses static analysis and symbolic execution to build firmware control flow graphs to represent the paths of critical function inputs. Dynamic fuzzing is also used to find memory corruption vulnerabilities [119]. FIoT limits the scope of analysis but has difficulties in managing peripheral information.
• HD-FUZZ [120]: Proposes a hardware-based firmware fuzzing framework that combines hybrid MMIO modeling with symbolic execution to improve pathfinding efficiency. This significantly increases the number of vulnerabilities in the firmware of small embedded devices [120].

The strengths of symbolic execution lie in its high accuracy and ability to find complex logic errors. However, it is not suitable for all situations for the following reasons:

• Path explosion: Firmware code with complex control flows and loops can generate exponentially many paths, placing higher demands on computer performance [115].
• Peripheral dependencies: Embedded firmware often works with peripherals such as MMIO or interrupts, which are difficult for symbolic execution engines to model correctly. This can cause the analysis to abort or lead to incorrect conclusions [113].
• Complex environment setup: Symbolic execution requires complex tools such as disassemblers, instrumentation tools, and constraint solvers, which makes it difficult to use on resource-constrained embedded devices [117].
• Limitations of constraint solving: Constraints imposed by cryptographic algorithms or complex hash functions in firmware are sometimes difficult to solve, reducing its practicality [103].

5.1.3. Analysis and Evaluation

Static analysis and symbolic analysis each have their own advantages and disadvantages when analyzing embedded firmware security [121].

Table 4. Comparison of Static and Symbolic Analysis Techniques.

Technique	Target	Main Techs	Vulnerability Types	Advantages	Limitation	Representative Studies
Static Analysis	Type I Firmware, Apps	Fuzzy Hashing, Taint Analysis, CFG Analysis	Backdoors, Taint, Memory Corruption	No runtime environment needed, broad applicability	High false-positive rate, limited support for Type II/III firmware	[99,100,101,102,103,104,105,106,122,123,124]
Symbolic Execution	Type I/II/III Firmware, Specific Platforms	Path Exploration, Constraint Solving	Memory Corruption, Auth Bypass, Privilege Separation	High precision, suitable for complex logical flaws	Path explosion, peripheral dependencies, complex setup	[108,113,115,116,117,118,119]

summarizes their technical characteristics and some typical research results.

Applicability: Static analysis is well suited for analyzing large amounts of firmware, especially class I firmware, as it is independent of the runtime environment. However, it struggles with class II and class III firmware, which require more robust base address detection and file format analysis [110]. Symbolic execution works well on some platforms, such as MSP430 or 8051, but does not work well when very broad coverage is required.

Accuracy and false positives: Static analysis suffers from high false positives, especially when using coarse-grained methods such as fuzzy hashing [99]. Symbolic execution finds fewer false positives through detailed path analysis, but may miss vulnerabilities due to path explosion or peripheral emulation issues [115].

Efficiency: The computational complexity of static analysis increases significantly with the size of the firmware, so feature extraction and matching methods must be optimized [103]. The efficiency of symbolic execution is limited by the number of paths and the difficulty of considering constraints. Slicing or domain knowledge is required to simplify the analysis [117].

Scalability: Static analysis has made great progress in analyzing interactions between multiple binaries (e.g., Karonte [106]), but analyzing the complexity between components remains difficult. Hardware emulation and environment configuration limit the scalability of symbolic execution, thus requiring lightweight execution frameworks.

5.1.4. Future Improvements

Future improvements to firmware security analysis should focus on supporting non-standard formats (Type II and Type III) through robust base address detection and file format analysis techniques, simplifying the processing of diverse binaries. Static analysis frameworks can be extended to capture interactions between firmware components in real time, thereby detecting cross-module logic vulnerabilities [125]. Furthermore, the efficiency of symbolic execution must be improved through methods such as code slicing, selective symbolization, and domain-specific constraints to minimize the challenges posed by path explosion and peripheral emulation [126]. Finally, combining static and symbolic methods with dynamic testing methods such as fuzz testing is a promising direction, as runtime feedback can improve the accuracy of static analysis and guide symbolic path exploration to high-impact execution traces.

5.2. Machine Learning-Assisted Binary Similarity Analysis

Cui et al. [124] pointed out that many firmware updates contain third-party libraries that have known security vulnerabilities that persist for years. Their study found that 80.4% of vendor-provided firmware had known vulnerabilities. This poses a significant problem for embedded systems that control safety-critical infrastructure. The Mirai botnet [127] demonstrated that exploitation of such vulnerabilities could cause widespread disruption of public systems, such as a distributed denial of service (DDoS) attack against DNS servers.

Finding vulnerabilities in embedded systems is difficult because they use many different hardware platforms, have their own implementations, and run in limited environments. Dynamic testing tools are widely available on desktop computers, but embedded firmware often lacks easily discoverable source code, standardized instruction set architectures (ISAs), or consistent compilation parameters [122]. This renders traditional tools useless. Researchers have increasingly used binary similarity analysis to find known vulnerabilities in firmware and have made significant progress. However, binary similarity techniques are difficult to apply to embedded firmware due to the inaccessibility of source code, the presence of different instruction sets (ISAs), and the variability of compilation settings [128,129,130,131].

This section focuses on how to use machine learning to support binary similarity analysis to find firmware vulnerabilities. This paper introduces some of the most prominent methods proposed between 2015 and 2024. These methods were published in leading security and software development forums (such as CCS, NDSS, RAID, ASIACCS, DIMVA, FSE, ASE, ICSE, TSE, ESORICS, IEEE Access, and arXiv) and analyzed within a unified four-stage framework. This report covers the technical characteristics, datasets, CVE (Common Vulnerabilities and Exposures) search performance, and computational complexity of these methods. Finally, this paper proposes some open research issues.

5.2.1. Necessity of ML-Assisted Binary Similarity Analysis

• Why binary similarity is needed at the firmware level.

Firmware binaries are stripped, optimized, and compiled for diverse ISAs, so a single vulnerable routine appears in many surface forms; purely syntactic signatures and naïve graph matching therefore miss semantically equivalent functions compiled under different settings [123]. Graph-based embeddings over attributed control-flow graphs (ACFGs) are designed to preserve structural/relational semantics across such transformations, making similarity search viable when syntax diverges [130]. Hand-crafted statistical descriptors over ACFGs were the first step toward this robustness but remain sensitive to inlining and compiler idiosyncrasies, which motivates learning richer representations [113].

• Closing the gap between breadth and evidence.

Static analyzers scale but often lack behavioral evidence and thus inflate analyst workload; in contrast, symbolic execution yields precise witnesses but struggles with path explosion and incomplete models of peripherals [132]. Using learned similarity as a front-end turns the global hunt into a nearest-neighbor retrieval problem that can surface high-yield candidate functions quickly, after which targeted slicing or feasibility checks can attach concrete, auditable artifacts to each alert. PDG-driven authentication slicing exemplifies how post-retrieval evidence can be produced for security-critical flows [102].

• What makes ML similarity robust in practice.

ACFG embeddings trained on diversified builds learn invariants that survive ISA and optimization variance, enabling cross-architecture matching at scale [130]. Token/sequence models learn instruction-level semantics and can remain useful even when control-flow is distorted, complementing graph approaches in obfuscated or flattened binaries [133]. Self-attention over token streams further improves the model’s ability to focus on security-relevant motifs such as bounds checks and sanitizer calls [134]. Where syntax diverges dramatically, cross-ISA alignment at the basic-block level can be learned by treating translation as a sequence-to-sequence task, which keeps semantically equivalent blocks close even across architectures [135]. When static evidence is insufficient, micro-executions provide short semantic trajectories that help disambiguate look-alikes during retrieval and ranking [136].

• Supply chain reuse and fleet-wide recall.

When a CVE is disclosed, the operational question is where else the same or near-same code landed across vendor forks and backports; ML similarity helps enumerate these variants and makes large-fleet recall feasible [137]. Aligning a matched binary to its source repository and patch lineage turns findings into actionable SBOM updates and targeted remediation plans [138].

• How this complements traditional dynamic testing.

Emulation-based firmware testing remains indispensable but is often tied to specific device classes and requires extensive environment modeling, which limits throughput on large vendor corpora; similarity-guided triage can prioritize where emulation time is best spent [131]. Semi-emulation frameworks reduce modeling overhead but still constrain the set of peripherals and firmware families that can be covered quickly; again, learned retrieval provides high-probability targets to feed these pipelines [139]. Firmware migration techniques extend dynamic testing by transplanting code into instrumented environments, yet the migration effort remains significant; similarity search can narrow the set of functions whose migration yields maximal payoff [140].

5.2.2. ML-Assisted Binary Similarity Workflow

• Stage 1—Acquisition and normalization.

Firmware images are unpacked to recover file systems and binaries; functions are disassembled and, where possible, lifted to an IR to harmonize instruction semantics across toolchains. A multi-view artifact is built per function: token sequences, basic-block boundaries, and program graphs such as CFGs and PDGs. Because inlining erodes function boundaries, a pre-processing pass that detects or reconstructs inlined regions improves downstream matching and reduces systematic false negatives on utility routines [141].

• Stage 2—Feature extraction.

Build a multi-view representation per function by jointly harvesting (i) lightweight statistical descriptors over graphs—e.g., ACFG constant histograms, instruction counts, and degree profiles—as fast, interpretable pre-filters [113]; (ii) dynamic/semantic signals from partial emulation that yield short traces (library-call sequences, I/O pairs, value evolution) to stabilize against compiler/inliner variance and supply high-quality cues for later verification [142]; and (iii) learned representations that generalize across ISAs and builds, including GNN embeddings over ACFGs for structure-aware matching [130], distributional/token embeddings that retain instruction-level semantics under moderate CFG distortion [133], self-attention to emphasize vulnerability-relevant motifs such as bounds checks and sanitizers [134], cross-ISA basic-block alignment via neural machine translation when opcode vocabularies diverge strongly [135], and micro-execution–derived trajectories that disambiguate near-neighbors during ranking [136]. Fuse these views with early fusion (feature concatenation) or late fusion (calibrated ensembling) and train with diversified architectures/opt-levels plus hard-negative mining so the model collapses benign compiler drift while preserving differences between patched and vulnerable variants; in inline- or obfuscation-heavy firmware, bias the mix toward token/attention features and dynamic traces, optionally preceded by inline-recovery preprocessing, to maintain recall without sacrificing precision.

• Stage 3—Representation and retrieval.

Functions are embedded into a vector space or encoded as structured signatures; approximate nearest-neighbor indexes enable sub-linear retrieval on large corpora. During training, hard-negative mining—near-misses produced by different compilers or opt-levels for the same routine—forces the model to collapse benign compiler drift while preserving discriminative cues that separate patched from vulnerable variants [143]. Calibrating similarity scores stabilizes thresholds across firmware families so that ranking quality translates into predictable analyst effort [144].

• Stage 4—Triage, attribution, and verification.

Top-k candidates are clustered to remove near-duplicates and ranked under a budget-aware objective that maximizes time-to-first-vulnerability. PDG slicing from entry points to privileged operations can then attach concrete paths that indicate likely bypasses in authentication or authorization logic [102]. Targeted symbolic checks validate path feasibility on a small set of high-scoring functions, providing inputs or states that witness the issue without incurring whole-program path explosion. When provenance matters, source/patch alignment maps the binary hit to a repository and patch lineage for SBOM updates and coordinated remediation [138].

• Design choices that materially improve outcomes.

Training on mixed architectures and compiler/opt-level variants is necessary to achieve cross-variant robustness in graph embeddings; models trained narrowly tend to overfit to build idiosyncrasies and collapse out-of-domain [130]. Inline-heavy builds benefit from an inline-recovery step before representation learning; without it, token and graph models systematically miss small utility routines implicated in many bugs [141]. Discriminating patched from vulnerable near-duplicates requires exposing the learner to such pairs and backing retrieval with a verification gate that checks for the presence of the specific guard or sanitizer introduced by the fix, which reduces false positives during patch cycles [145]. Finally, leakage-safe evaluation must split by project/version rather than at the function level to avoid inflating scores through microscopic code duplication across train and test [143].

5.2.3. Technical Challenges (Root Causes, Symptoms, and Single-Source Mitigations)

There are several issues with using machine learning for binary similarity analysis, as listed below:

• C1—Information loss after compilation. Root cause: symbols and high-level structure are erased; inlining collapses call boundaries. Symptom: unstable matches and high analyst burden. Mitigation: rely on relational views such as ACFG/PDG to preserve structural semantics during retrieval, then attach PDG-based slices to produce auditable evidence for security-critical flows [102].
• C2—ISA diversity. Root cause: the same semantics map to different opcode vocabularies and calling conventions. Symptom: high same-ISA accuracy that degrades across architectures. Mitigation: learn ACFG embeddings explicitly trained to be stable across architectures so that semantically equivalent routines cluster together during retrieval [130].
• C3—Compiler/opt-level variance. Root cause: O-level changes, inlining decisions, and link-time optimization reshape CFGs. Symptom: hand-crafted graph features drift; recall collapses under O3 vs. O0. Mitigation: augment structural features with short semantic traces from partial emulation, which smooth compiler noise while preserving the cues needed for disambiguation [142].
• C4—Function inlining. Root cause: small helpers vanish as standalone functions; boundaries blur. Symptom: systematic false negatives for utility routines commonly implicated in bugs. Mitigation: detect and recover inlined regions before modeling so that both token and graph learners operate on function units that better reflect source semantics [141].
• C5—Obfuscation and CFG distortion. Root cause: control-flow flattening and bogus edges decouple CFG shape from behavior. Symptom: CFG-centric descriptors lose discriminative power. Mitigation: emphasize token/sequence embeddings with attention, which learn instruction-level semantics less sensitive to CFG distortion and retain discriminative power under moderate obfuscation [134].
• C6—Multi-block/function vulnerabilities. Root cause: end-to-end flaws span helpers, drivers, or inter-process boundaries. Symptom: function-only retrieval flags fragments without a triggerable path. Mitigation: perform multi-binary flow reasoning during verification so that candidate matches are elevated only when an inter-component data path to a dangerous sink exists [106].
• C7—Patch similarity and false positives. Root cause: patched and vulnerable variants remain structurally close. Symptom: alerts on already-fixed code waste patch windows. Mitigation: include patched/unpatched pairs during training and add a verification gate that checks for the specific guard or bounds fix introduced by the patch before escalating a finding [145].
• C8—Accuracy versus verifiability. Root cause: high cosine similarity does not imply exploitability. Symptom: strong ranking with weak artifacts slows engineering sign-off. Mitigation: attach PDG slices or targeted symbolic inputs to each high-rank match so that every alert is accompanied by concrete paths or inputs that are auditable by developers [102].
• C9—Throughput and indexing at scale. Root cause: naïve all-pairs comparison is quadratic in corpus size. Symptom: time budgets exhausted before useful recall is reached. Mitigation: use approximate nearest-neighbor indexing and batched inference so that retrieval time scales sub-linearly with corpus size; design ranking to maximize early discovery under fixed budget [146].
• C10—Sustained scalability under fleet growth. Root cause: the number of images and variants grows faster than analyst/compute budgets. Symptom: thresholds drift upward, recall declines, and backlogs accumulate. Mitigation: adopt two- or three-stage cascades—lightweight pre-filters, semantic enrichment, then targeted verification—so recall per unit compute remains stable as the fleet expands [147].

5.2.4. ML-Assisted Techniques and Tools

Machine learning (ML) has become a central driver of modern binary similarity analysis, enabling firmware vulnerability detection to go beyond rule-based or handcrafted approaches. Broadly, these techniques can be grouped into statistical, dynamic, and learning-based categories, each offering different balances between accuracy, scalability, and interpretability [148].

• Statistical Feature-Based Methods

Statistical approaches rely on manually extracted features such as instruction counts, control-flow graph (CFG) attributes, or text constants. These methods are lightweight and interpretable, but their effectiveness depends heavily on feature engineering. A representative example is Genius [113], which constructs attributed CFGs (ACFGs) using constants, instruction counts, and descendant nodes to compare binary functions. Building on this idea, Gemini [130] integrates ACFGs with graph neural networks (GNNs, e.g., Structure2Vec [149]) to generate embeddings, significantly improving scalability and robustness against compiler diversity. This transition from handcrafted to embedding-based statistical features marks a key inflection point: it reduces sensitivity to syntactic changes while retaining the structural cues essential for detecting reused or vulnerable code [150].

• Dynamic Feature-Based Methods

Dynamic methods execute or emulate candidate binaries to extract semantic behaviors, such as I/O values or library call patterns, thereby complementing static analysis. For example, VulSeeker-Pro [142] leverages VEX-IR emulation to extract semantic execution traces and improves vulnerability detection precision by combining these features with graph-based similarity. Similarly, BinGo-E [151] employs the Unicorn engine [152] to generate “fake” execution traces, creating richer behavioral profiles without requiring full device execution. These methods are especially effective for uncovering vulnerabilities that manifest only at runtime (e.g., hidden backdoors or protocol misuse), but they incur higher computational overhead and require careful sandboxing to scale to large firmware corpora. Compared with statistical approaches, dynamic methods provide deeper semantic insight but sacrifice efficiency [153,154,155].

• Learning-Based Methods

The most recent wave of research uses ML models to automate feature extraction and discover patterns beyond manual engineering. Within this category, graph-based learning methods have become dominant: VulSeeker [156] and IoTSeeker [157] extend Gemini by using GNNs to learn ACFG embeddings that encode both structure and semantics. αDiff [143] further combines convolutional networks for intra-function features with inter-function call-graph analysis, creating embeddings that capture multi-level context.

Another line applies natural language processing (NLP)–inspired embeddings to binary code. Asm2Vec [133] and SAFE [134] treat instructions as tokens, training Word2Vec [158], LSTM [159], or attention models [160] to derive semantic embeddings of instructions or basic blocks. Systems like MIRROR [135] push this further by using neural machine translation to align blocks across different ISAs, while Trex [136] introduces micro-executions [161] with BERT embeddings [162] to model instruction-level trajectories.

Finally, specialized tools tackle long-standing challenges: FSmell [141] improves inline function detection via control-flow analysis combined with CNN-based pattern recognition, while BinaryAI [138] accelerates software composition analysis by matching binary code against large source repositories using deep learning. These directions highlight the versatility of ML in addressing not only binary similarity but also firmware reverse engineering bottlenecks such as function boundary recovery and code provenance.

Taken together, these methods show a clear evolution: from feature-heavy statistical descriptors (Genius) to emulation-driven semantic enrichment (VulSeeker-Pro) and finally to automated, representation-learning approaches (Asm2Vec, IoTSeeker, BinaryAI) [163,164]. Statistical methods remain attractive for lightweight similarity checks, dynamic methods expose runtime behaviors otherwise invisible, and learning-based methods push scalability and robustness across ISAs and obfuscation [165,166]. This spectrum of approaches suggests that hybrid pipelines—statistical pre-filters, dynamic semantic enrichment, and deep representation learning—may provide the most effective balance for large-scale IoT firmware analysis.

5.2.5. Comparative Analysis

Table 5. Comparison of ML-Assisted Binary Similarity Tools.

Tool	Dataset	CVE Used	Precision (%)	Overhead (s)
Genius [113]	OpenSSL, BusyBox (x86, ARM, MIPS)	3 CVEs	85.2	12.5
Gemini [130]	Coreutils, OpenSSL (cross-architecture)	5 CVEs	90.1	8.7
VulSeeker [156]	IoT firmware (ARM, MIPS)	4 CVEs	88.6	10.2
VulSeeker-Pro [142]	IoT firmware, OpenSSL	6 CVEs	92.3	9.4
IoTSeeker [157]	IoT firmware (real-world)	5 CVEs	89.4	11.8
Asm2Vec [133]	Synthetic binaries (x86, ARM)	2 CVEs	87.5	7.9
SAFE [134]	OpenSSL, Coreutils (cross-ISA)	4 CVEs	91.8	8.2
FSmell [141]	OpenSSL, Coreutils (x86, ARM)	3 CVEs	90.5	9.1
BinaryAI [138]	IoT firmware, OpenSSL (cross-ISA)	5 CVEs	93.2	7.5

Notes: Datasets: come from open-source projects like OpenSSL, BusyBox, and Coreutils, or from real-world firmware images (via Binwalk).

shows the datasets, CVE usage, search accuracy, and computational cost of some ML-based binary similarity methods, focusing on their effectiveness in discovering firmware vulnerabilities. Existing evaluations of ML-assisted binary similarity analysis have largely focused on precision and average overhead (Table 5). While these indicators establish a baseline, they fail to capture operational realities in IoT firmware analysis, where vulnerabilities follow long-tail distributions, datasets are highly imbalanced, and devices operate under tight computational and energy budgets [167,168,169,170]. A richer evaluation framework is thus required, moving beyond simple accuracy to criteria that reflect robustness, scalability, and actionable utility.

Precision indicates the proportion of correctly identified vulnerable functions among all flagged functions; however, given the highly imbalanced nature of firmware datasets, precision alone provides a limited view of effectiveness, such as those in Table 5 (e.g., 85–93%) obscure the fact that vulnerabilities are rare compared to benign functions.

In such skewed settings, PR-AUC or F1-max provides a more faithful measure of utility. For instance, Gemini [130] reports higher precision than Genius [113], but without recall or PR-AUC it is unclear whether this improvement translates to more vulnerabilities being caught in practice.

Especially for IoT firmware images with thousands of benign routines, the operational impact of false positives (wasted analyst effort, unnecessary patches) is as critical as catching true positives.

The binary flags in

Table 6. Technical Characteristics of ML-Assisted Tools.

Tool	ISA Support	Compiler	Obfuscation	Inlining	Feature Type	ML Model
Genius [113]	x86, ARM, MIPS	gcc, clang	No	No	Statistical	None
Gemini [130]	x86, ARM, MIPS	gcc, clang	Yes	No	Learning-based	GNN (Structure2Vec)
VulSeeker [156]	ARM, MIPS	gcc	Yes	No	Learning-based	GNN
VulSeeker-Pro [142]	ARM, MIPS	gcc, clang	Yes	Yes	Hybrid	GNN + Emulation
IoTSeeker [157]	ARM, MIPS	gcc	Yes	No	Learning-based	GNN
Asm2Vec [133]	x86, ARM	gcc, clang	Yes	No	Learning-based	PV-DM
SAFE [134]	x86, ARM, MIPS	gcc, clang	Yes	Yes	Learning-based	Self-Attention
FSmell [141]	x86, ARM	gcc, clang	Yes	Yes	Learning-based	CNN + CFG Analysis
BinaryAI [138]	x86, ARM, MIPS	gcc, clang	Yes	Yes	Learning-based	Deep Learning

can be converted into a robustness score (e.g., weighted across ISA × compiler × optimization level × obfuscation). VulSeeker-Pro [142] achieves higher precision partly because it integrates dynamic emulation, making it more resilient to compiler optimizations and inline transformations. In contrast, Asm2Vec [133] has lightweight embeddings but degrades sharply when confronted with obfuscation. A metric such as Cross-Variant Robustness (CVR) would quantify this gap, allowing systematic comparison of how tools generalize across the heterogeneity of IoT ecosystems. Since the two studies used different datasets or CVE sets, it is difficult to compare them directly. BINKIT [171] provides a reproducible benchmark, but its performance is inferior due to its pre-semantic nature.

The overhead values in Table 5 can be reframed into functions per second per core and memory footprint, making comparisons more intuitive for large-scale firmware screening. For example, BinaryAI [138] achieves 7.5 s/function, equivalent to ~0.13 functions/s/core, which translates to ~21 h on a single core for 10,000 functions. However, if BinaryAI parallelizes near-linearly across 16 cores, its effective throughput surpasses tools with lower per-function overhead but weaker parallel scalability. Such throughput-aware evaluation is directly relevant to IoT vendors who must scan thousands of firmware images before scheduled updates.

In practice, analysts rarely need all vulnerabilities at once; rather, they seek time-to-first-vulnerability (TTFV) or recall under a fixed budget (e.g., 8 CPU-hours, 2 GB RAM). Tools with lightweight embeddings (e.g., Asm2Vec) may deliver early hits faster, even if ultimate precision is lower. By contrast, heavier models like SAFE [134] or VulSeeker-Pro [142] yield stronger precision at higher cost. Evaluating methods along the budget–recall curve would thus better inform hybrid pipelines (e.g., fast screening on-device, deeper semantic matching in the cloud).

Finally, tools like BinaryAI [138] go beyond vulnerability discovery into software composition analysis (SCA). For such systems, evaluation must include attribution quality—whether the binary is correctly linked to its source repository, patch version, or software bill of materials (SBOM). Reporting Top-k source hit rate or patch alignment accuracy adds practical value, especially for supply chain auditing where actionable traceability matters more than raw precision.

5.2.6. Open Research Challenges

Machine learning-based binary similarity analysis has made significant progress in detecting firmware vulnerabilities, but many challenges remain:

• Firmware reverse engineering: Accurate reverse engineering remains difficult and often requires expert knowledge [172].
• Efficient storage and retrieval: Large firmware corpora require better methods to store and query data that have not been fully studied.
• Vulnerability dataset construction: Most datasets only consider application-level CVEs, but not firmware-specific vulnerabilities [173].
• Cross-function/binary vulnerabilities: Currently, we can only consider vulnerabilities in a single function, while ignoring cross-process vulnerabilities [174].
• False positives/false negatives: Static analysis is difficult due to the large number of false positives and false negatives [175].
• Lack of common benchmarks: Comparative analysis is also difficult due to different datasets and evaluation criteria [15].

5.2.7. Future Directions

To address these issues, future research should focus on the following areas:

• Configuration robustness: Improve machine learning models to handle function inlining, obfuscation, and cross-project changes. Use the ideas in FSmell [141] as a starting point.
• Improve reverse engineering: Develop more advanced disassemblers to handle complex firmware binaries [172].
• Firmware-specific models: Use semi-supervised learning and reinforcement learning to find firmware-specific vulnerabilities [176].
• Generic vulnerability signatures: Create templates for vulnerability classes (e.g., buffer overflows) rather than targeting specific CVEs.
• Unified datasets: Establish standard datasets for training, testing, and CVE querying.
• Hybrid analysis models: Use frameworks such as BinaryAI [138] for scalable software composition analysis that combines static analysis, dynamic verification, and machine learning for complete firmware testing.

6. Integrated Network, Behavioral, and Policy-Layer Security

This section explores how to integrate network, behavioral, and policy security measures into the Industrial Internet of Things (IIoT) to further enhance Zero Trust Architecture (ZTA). We will then discuss lightweight intrusion detection systems (IDS), advanced deep learning and graph-based models, sensor-actuator and RF spectrum analysis, microsegmentation-based identity management, and Zero Trust implementation. All of these topics build on the fundamental ideas and techniques presented in the previous sections. We will also discuss limitations, gaps between the various layers, and future research directions.

6.1. Lightweight Intrusion Detection and Signature-Based Models

Lightweight intrusion detection systems (IDS) are important in resource-constrained Industrial Internet of Things (IIoT) environments, where sensors and controllers have limited computational power or memory capacity [177]. These solutions aim to ensure security without compromising real-time performance. Signature-based IDS models leverage a database of known threats to detect malicious behavior. These threats are captured as a set of patterns. For example, Buck et al. [178] discussed lightweight IDS solutions that leverage hash-based operations and XOR techniques to minimize computational power requirements while still detecting many known attack patterns. These models work well in areas where threats are easy to predict but difficult to defend against zero-day attacks because they rely on static signatures [179]. To cope with limited resources, the single packet authorization (SPA) approach proposed by Xu et al. [180] proposes filtering incoming packets based on cryptographic signatures. This allows for fast and efficient detection of issues. Shah et al. [180] discussed a single packet authorization (SPA) approach based on cryptographic signatures that proposes filtering incoming packets based on cryptographic signatures. Reference [179] also used lightweight time-varying linear or nonlinear functions to protect IIoT communication paths. This enables fast threat detection, which is critical for industrial real-time applications. Although signature-based models work well, they often miss new threats and therefore need to be combined with more flexible methods [181].

6.2. Deep/Graph-Based IDS with Behavioral Features

Deep learning and graph-based intrusion detection systems (IDS) exploit behavioral features to identify problems in Industrial Internet of Things (IIoT) networks that are hidden from signature-based models. These approaches exploit complex patterns in data and interactions that change over time to identify anomalous characteristics of a device or network. Wu et al. [182] proposed a deep learning-based intrusion detection system (IDS) that uses neural networks to detect human behavior. This approach is better suited to detecting complex attacks than traditional methods. Their approach uses unsupervised learning to discover hidden data structures to identify previously undetected risks [183].

Konduru et al. [184] studied graph-based intrusion detection system (IDS) models that represent Industrial Internet of Things networks as graphs with devices as nodes and communication lines as edges. These models identify problems caused by lateral movement or unauthorized access by examining the characteristics of the graph, including how nodes are connected and how traffic flows. For example, Ali et al. [185] added behavioral elements such as device connection frequency and data exchange protocol to graph-based models to improve discovery capabilities in edge computing environments. These approaches are good at finding things but require a lot of computing power, which is a problem for resource-constrained Industrial IoT devices [186].

6.3. Sensor-Actuator and RF-Spectrum Anomaly Analytics

Sensor-actuator systems and RF spectrum analysis are critical to the security of Industrial Internet of Things (IIoT) environments because they monitor physical and wireless interactions. The goal of sensor-actuator anomaly detection is to identify anomalous patterns in device behavior, including unpredictable actuator motion or sensor data that does not match expectations. Lei et al. [187] proposed a zero-trust (ZTA)-enhanced system that uses lightweight encryption and artificial noise precoding to protect wireless channels and detect problems in sensor-actuator communications. This approach can monitor the environment with low latency while ensuring security in high-risk industrial environments [188].

RF spectrum analysis addresses the issue of wireless IIoT connectivity, especially where proprietary protocols are used. Sedjelmaci et al. [16] proposed an AI-based RF spectrum analysis model for 6G networks that leverages zero-trust principles to detect anomalous patterns in signal strength and frequency. Their model reduces threats such as interference or spoofing by combining real-time spectrum monitoring with trust assessment. However, continuous spectrum analysis remains a challenge for low-resource devices due to its high computational cost [189].

6.4. Identity, Micro-Segmentation, and Zero-Trust Enforcement

Identity management, microsegmentation, and zero-trust implementations are key components of Industrial Internet of Things (IIoT) security. They ensure precise access control and continuous trust verification. Authentication in the IIoT requires a system that is powerful, flexible, and compatible with a wide range of devices [190]. Li et al. [191] proposed a blockchain-based multi-factor authentication (MFA) system that combines device attributes and cryptographic signatures to ensure secure authentication across different IIoT platforms. Zanasi et al. [192] added quantum-resistant digital certificates that contain access rights and metadata to make the system more flexible and secure.

Microsegmentation breaks down the IIoT network into smaller, independent areas to prevent lateral threats. Daah et al. [193] implement network-based microsegmentation using gateways to enforce access policies and assign trust levels to segments. Alagappan et al. [194] use local infrastructure-based microsegmentation in virtual power plants to protect devices from attacks based on their functionality and trust level. Zero-trust implementations combine these tools with continuous authentication. Shen et al. [181] used a policy enforcement point (PEP) to verify access requests in real time based on trust scores.

6.5. Limitations, Cross-Layer Gaps, and Future Work

Despite improvements, Zero Trust (ZTA) in the Industrial Internet of Things (IIoT) still faces many challenges. Michael et al. [195] pointed out that implicit trust in untested things such as policy decision points (PDPs) and trust algorithms may reduce the effectiveness of ZTA. Bertino [196] pointed out that high switching costs and legacy system issues are some of the challenges encountered during deployment. Swearingen et al. pointed out that implementing ZTA in critical infrastructure such as power grids may introduce latency, thus affecting real-time operations.

Vulnerabilities still exist at the network, behavioral, and policy levels. For example, lightweight intrusion detection system (IDS) models are vulnerable to zero-day attacks, while deep learning-based intrusion detection systems (IDS) consume too many resources [186]. Micro-segmentation technology does not work well with different types of protocols, and RF spectrum analysis requires a lot of computing power, which makes it difficult to scale [189]. To strike a balance between security and resource constraints, Gudala et al. [183] suggested that future research focus on lightweight AI algorithms. Zaid et al. studied the integration of quantum-resistant cryptography, while Hong et al. proposed improving cross-layer coordination through programmable APIs. Both approaches can help fill these gaps.

Table 7. IDS/Policy Approaches: Dataset, Accuracy, Latency, Trust Target.

Approach	Dataset	Accuracy	Latency	Trust Target
Lightweight IDS [178]	Network traffic logs	85–90%	Low (<10 ms)	Known threats
Deep Learning IDS [182]	Behavioral data	92–95%	Moderate (50–100 ms)	Zero-day attacks
Graph-Based IDS [184]	Device interaction graphs	90–93%	High (100–200 ms)	Lateral movement
RF-Spectrum Analytics [16]	Wireless signal data	88–92%	High (150–300 ms)	Wireless threats
Micro-Segmentation [193]	Trust-level policies	87–91%	Low (<20 ms)	Access control

provides a comparative overview of representative IDS and policy-layer mechanisms, highlighting their datasets, accuracy levels, latency characteristics, and specific trust targets.

The table makes clear the trade-offs among different families of approaches: lightweight IDSs provide low latency but limited scope, deep and graph-based IDSs achieve high accuracy but incur computational delays, while RF spectrum analytics and micro-segmentation serve specialized trust targets but suffer either from scalability or interoperability constraints. This comparative lens underscores that no single approach suffices across all IIoT conditions, reinforcing the need for layered integration.

In addition to cross-layer intrusion detection mechanisms, trust evaluation and policy-based access control play a central role in ensuring secure IoT and IIoT deployments. To illustrate this, Figure 4 shows the integrated control and data platform architecture that leverages a Trust Evaluation Module, Policy Engine (PE), and Policy Administration Point (PA). The framework connects threat sources, behavior logs, and access policies with enforcement points, enabling dynamic micro-segmentation and fine-grained authorization across industrial control environments.

Operational trade-offs in IDS and policy layers are contrasted in Table 7, while deployable cross-layer bundles appear in Appendix A (

Table A1. Representative Tools by Layer & Paradigm & Deployment. (Each row provides a one-line purpose, typical deployment target, and a minimal resource note. “Edge” denotes gateway/industrial PC-class devices).

Layer	Paradigm	Tool/System (Example)	One-Line Purpose	Typical Deployment	Minimal Resource Note
Firmware	Unpacking/preprocessing	Binwalk; BANG	Recover file systems/binaries from images for downstream analysis	Edge/Cloud	CPU-bound; tens of minutes for large images; RAM in GB-scale for batch runs
Firmware	Static (IR/graphs)	IDA Pro, Ghidra	Disassembly/CFG/IR to enable slicing and taint analysis	Edge/Cloud	Memory heavy on large firmware; plugin support for many ISAs
Firmware	Static + program slicing	Firmalice	PDG-guided authentication-bypass discovery via slicing + checks	Edge/Cloud	Hours per image on commodity CPUs; requires IR build
Firmware	Static taint analysis	DTaint	Tracks source → sink flows to surface memory/command-injection risks	Edge/Cloud	Sensitive to library modeling; multi-binary speedups advised
Firmware	Multi-binary reasoning	Karonte	Models inter-process/component flows to catch cross-binary flaws	Edge/Cloud	Requires per-service configuration; higher RAM
Firmware	Symbolic execution (hybrid)	Avatar, S2E	Hybrid SE with device/system emulation for deep path feasibility	Edge/Cloud	Solver/emu heavy; best under narrowed scopes
Firmware	Symbolic (platform-specific)	FIE (MSP430), FirmUSB (8051/USB)	Platform-tailored SE for microcontroller/USB firmware	Edge	Good precision; limited to supported MCUs/peripherals
Firmware	Symbolic (LLVM/KLEE)	Inception, Gerbil	SE with slicing/backward analysis for privilege/logic flaws	Edge/Cloud	Requires stubs for MMIO/crypto; mitigated by selective symb.
Firmware	Hybrid SE + fuzz	FIoT, HD-FUZZ	Combine selective SE with fuzzing and MMIO modeling	Edge	Better coverage on embedded paths; setup effort moderate
Firmware	ML similarity (graph)	Genius, Gemini, VulSeeker, VulSeeker-Pro, IoTSeeker	ACFG/GNN embeddings for cross-variant vulnerable-code retrieval	Edge/Cloud	CPU-centric; optional GPU; index fits in GBs; robustness per Table 6
Firmware	ML similarity (tokens/attention)	Asm2Vec, SAFE	Instruction/token embeddings (w/attention) robust to CFG noise	Edge/Cloud	Fast inference; sensitive to inlining unless preprocessed
Firmware	Inline recovery	FSmell	Detects/reconstructs inlined helpers to reduce false negatives	Edge/Cloud	Pre-pass; improves recall for similarity pipelines
Firmware	SCA/provenance	BinaryAI	Maps binaries to source/patch lineage for SBOM/attribution	Cloud/Edge	Embedding + ANN search; integrates with CI/SBOM
Network	Lightweight IDS	Hash/XOR-style IDS (e.g., Buck et al.)	Signature/bitfield/Bloom-style fast screening on constrained links	MCU/Edge	kB-scale RAM; sub-10 ms latency (see Table 7)
Network	SPA/admission	Single Packet Authorization (SPA)	Cryptographic single-packet gate before session setup	MCU/Edge	Minimal CPU; integrates with firewall/PEP
Network	Protocol-aware auditing	FirmXRay (BLE)	Audit BLE pairing/keys/mode use; flag weak defaults	Edge	Runs off-device; informs on-device filters
Behavior	Context policy	ContexIoT, Soteria	App-level context/policy checking to prevent privilege abuse	Edge/Cloud	Low runtime cost; upfront policy modeling
Behavior	Telemetry anomaly (DL)	N-BaIoT (DAEs)	Device-behavior anomaly detection from traffic/telemetry	Edge/Cloud	50–100 ms typical on edge; model fits in 10 s–100 s MB
RF/Wireless	Spectrum analytics	[16] RF-IDS (prototype)	RF fingerprint/DoS/spoofing detection from I/Q/spectrum	Edge	SDR required; 150–300 ms latency class (Table 7)
Trust/Policy	Fine-grained authZ	WAVE, XToken, MPA	Tokenized/chain-of-trust authorization and multi-party approval	Cloud/Edge	PEP/PDP integration; low per-decision latency (<20 ms)
Trust/Policy	Micro-segmentation	Gateway PEP/PA (industrial)	Segment device classes; enforce least privilege at gateways	Edge/Cloud	Policy design effort; low runtime cost (Table 7)
Trust/Policy	Blockchain-assisted MFA	Li et al. MFA	MFA + device attributes for heterogeneous fleets	Cloud/Edge	Added crypto overhead; offloads to cloud when possible

and

Table A2. Recommended Cross-Layer Combinations by Device Class & Budget (Condensed: highlights key defense choices, accuracy/latency ranges, and operational cost notes).

Device Class & Budget	Firmware Layer	Network Layer	Behavior Layer	Trust/Policy	Accuracy/Latency (Ref. Table 6 and Table 7)	Operational Notes
Tiny MCU (≤256 kB RAM)	Integrity checks; off-device batch screening; selective SE for top cases	Lightweight IDS; SPA gate	Rule-based sanity checks	Gateway/cloud PEP/PDP	IDS ~ 85–90% @<10 ms	Minimal runtime; main cost is safe OTA + CI pipeline
Mid-range MCU (512 kB–2 MB RAM)	Batch ML screening (SAFE/VulSeeker-Pro); micro-exec for top-K	Lightweight IDS + protocol filters	Edge-assisted telemetry	Micro-segmentation by role	IDS < 20 ms; precision per Table 6	Higher integration burden; modest telemetry labeling
Gateway-class Edge (2–8 GB RAM)	Continuous similarity (BinaryAI/SAFE); SE/fuzz for deep paths	Deep/Graph IDS	DAE/GRU models for device behavior	Local PEP + cloud PDP	Deep IDS ~ 92–95% @50–100 ms; Graph ~ 90–93% @100–200 ms	Moderate ops cost; GPU optional; strong zero-day defense
Hybrid Fleet (MCU + Edge + Cloud)	MCU integrity; Edge/Cloud similarity + provenance	MCU pre-filters + edge deep IDS	Edge-level temporal models	Fleet-wide attestation + micro-segmentation	Combined: low on-device latency, edge accuracy as Table 7	Highest coordination payoff; requires CI/CD for models + policy
Mission-critical IIoT (PLC/industrial PCs)	Conservative screening; evidence-attached verification	Layered guards + deep IDS at aggregation	Physical-process consistency; optional RF guard	Strong zero-trust enforcement	Link guards < 10 ms; deep IDS 50–200 ms; RF 150–300 ms

).

The integrated pipeline includes a lightweight IDS for fast signature-based detection, a deep/graph-based IDS for detecting behavioral anomalies, RF spectrum analysis for wireless security, and policy-driven micro-segmentation for access control. The Trust Assessment module processes data from network traffic and device logs. The module sends the data to the Policy Engine (PE) and Policy Administrator (PA). The PE uses behavioral, contextual, and policy data to determine the trust level, while the PA uses the PEP to enforce access decisions, ensuring that there are no trust issues at any level.

7. Conclusions

The evidence assembled across 207 rigorously screened studies paints a consistent picture: dependable IoT/IIoT security is achieved not by any single technique, but by composing methods across layers, data granularities, and deployment models under strict resource budgets. Organizing prior work along system level, algorithmic paradigm, data granularity, and hardware budget clarified where each family of defenses excels and where it fails. At the firmware layer, static analysis supplies breadth and explainability for large corpora, while symbolic execution provides path-level precision for memory safety and logic flaws; hybrid tactics (e.g., program-slice prechecks, selective MMIO modeling, and fuzzing-guided exploration) curb false positives and extend coverage into peripheral-heavy paths, yet remain bounded by Type-II/III packaging quirks, path explosion, and incomplete device models.

Learning-based binary similarity closes a complementary gap: by embedding attributed control-flow graphs and instruction tokens, it collapses compiler/ISA variance and turns global search into fast nearest-neighbor retrieval. Adding short semantic traces from partial execution raises robustness to inlining/optimization, and coupling similarity with composition analysis ties matches to provenance and patches for SBOM-grade attribution. Crucially, the most effective pipelines exhibit the same operational pattern: rapid retrieval to surface likely vulnerable functions or reused components; targeted verification to confirm triggerability with concrete paths/inputs; and evidence fusion and attribution to de-duplicate variants, stabilize scores, and drive coordinated remediation. Viewed through this lens, headline metrics like “precision” are insufficient on their own; what matters operationally is recall under a fixed compute/memory budget and time-to-first-vulnerability, supported by throughput-aware indexing (approximate nearest neighbors, batched inference) and calibration so that a rank threshold corresponds to predictable analyst effort across heterogeneous firmware families.

Beyond firmware, lightweight intrusion detection on constrained links delivers immediate safeguards at millisecond latencies, while deep/graph-based models at gateways capture higher-order traffic and device-behavior structure for zero-day detection. Sensor–actuator consistency checks and RF-spectrum analytics close cyber-physical blind spots that packet inspection cannot, and identity/micro-segmentation with continuous, device-centric authorization confines blast radius when latent defects persist. These layers are not substitutes but safety nets for one another: retrieval-driven firmware triage feeds dynamic testing; verified findings inform network and policy filters; and policy engines in turn prioritize where scarce device, edge, and cloud resources should be spent.

Notwithstanding the improvements synthesized in this review, several challenges remain. Nonstandard packaging and sparse metadata impede unpacking and cross-binary reasoning; symbolic engines continue to be constrained by peripheral interactions and cryptographic primitives; learning models must better tolerate obfuscation, aggressive inlining, and imperfect function boundaries; and end-to-end flaws that traverse helpers, drivers, and services are still easier to flag than to validate as triggerable chains. At higher layers, network- and behavior-centric detectors face enduring trade-offs between accuracy and footprint, RF analytics typically require specialized hardware, and policy-heavy controls are expensive to retrofit across legacy fleets.

Against this backdrop, operationally actionable advances follow directly from these limits and are best pursued through a set of priorities aligned with evidence needs and resource budgets. These priorities include adopting evidence-attached detection as standard practice so that high-rank firmware candidates are accompanied by slices, inputs, or harness hints that expedite engineering review and compliance; elevating cross-variant robustness to a primary objective by evaluating across ISA, compiler, optimization, and obfuscation diversity and reporting recall-at-budget and time-to-first-vulnerability alongside precision; preprocessing for embedded-code realities by recovering function boundaries in inline-heavy builds, de-noising distorted control-flow graphs, and employing short micro-executions when structural cues are unreliable; developing reusable, peripheral-aware symbolic scaffolds—selective symbolization, minimal MMIO models, and driver stubs—that permit deep checks to scale across device families; integrating vulnerability discovery with software composition analysis so that detection, attribution, SBOM maintenance, and fleet recall form a unified workflow; and investing in open, reproducible corpora and benchmarks that cover single-function, cross-function, and cross-binary flaws to enable comparable results and transferability.

Taken together, these directions point to a disciplined, resource-aware pipeline in which scalable similarity identifies what matters, precise program analysis substantiates it, and policy-grade attribution operationalizes remediation, with deployments tuned to the realities of tiny MCUs, modest gateways, and shared clouds. Systems built along these lines respect edge constraints, reduce analyst effort, and measurably raise the cost of exploitation across heterogeneous fleets, advancing the security of billions of connected devices toward resilience, auditability, and sustainability.