Includes hardware components such as network modules, sensor interfaces, processors, and peripheral circuits. Potential threats involve hardware tampering and side-channel attacks

Detection: Anomaly-based hardware integrity checks.

Comprises the device firmware, including operating systems and embedded applications. Threats like firmware manipulation and malicious code injection are prevalent

Detection: Firmware integrity verification using cryptographic hashes.

Provides an interface for user interaction with IoT devices. Threats include unauthorized access and data leakage

Detection: Behavior-based user authentication.

Devices communicate via lightweight protocols (e.g., ZigBee, Z-Wave) or local area networks (LANs). Ad hoc networks like drone swarms are particularly susceptible to replay and eavesdropping attacks.

Detection: Real-time traffic anomaly detection.

IoT communication spans devices, applications, and cloud platforms using Bluetooth, Wi-Fi, or mobile networks.

Threats: Man-in-the-Middle (MitM) and Distributed Denial-of-Service (DDoS) attacks.

Cloud services handle device authentication, data analytics, and command distribution. Threats include cloud misconfigurations and unauthorized data access

Detection: Log analysis and behavior anomaly detection.

Mobile apps serve as user interfaces for device monitoring and control. They are susceptible to reverse engineering and credential theft.

Detection: Application integrity validation.

Access control remains a cornerstone of IoT cloud platform security, with vulnerabilities potentially enabling unauthorized access and malicious control. Our review extends beyond traditional analyses by categorizing these threats into within-platform and cross-platform issues, illustrating previously underexplored attack vectors.

Within-Platform Permission Issues: Research indicates that some platforms, such as SmartThings and IFTTT, adopt coarse-grained permission schemes, leading to unauthorized access beyond designated scopes. These schemes permit applications to access sensitive device information, underscoring the critical need for more granular and dynamic permission controls [8–10].

Cloud platforms facilitate the deployment of diverse applications for device control; however, this openness also invites malicious actors. Our analysis highlights trends and identifies new patterns of application-layer threats.

Closed vs. Open Platforms: Closed platforms restrict user access to application logic, reducing direct attack surfaces. Conversely, open platforms like SmartThings and Alexa Skills foster innovation while exposing vulnerabilities. Bastys et al. [15] reported that approximately 30% of IFTTT services exhibited security weaknesses. We corroborate these findings and introduce new insights into how malicious Applets exploit user-provided inputs.

This study provides a distinctive perspective on IoT security by synthesizing insights from past research and augmenting them with novel threat categorizations and empirical findings. The inclusion of comparative analysis in Table 2 with related works and the introduction of a unified framework distinguishes our contributions and contextualizes the security landscape more effectively.

The interaction between cloud platforms, mobile apps, and devices is a fundamental characteristic of IoT cloud platforms, distinguishing them from traditional cloud services. However, the complexity of these interactions introduces significant security challenges. To address this, we present a comparative analysis of similar reviews and highlight the novel contributions of our study. Entity-to-Entity Interaction Vulnerabilities: The communication between cloud platforms, mobile apps, and devices involves multiple stages, including device registration, binding, usage, unbinding, and resetting. Each stage requires strict adherence to predefined communication models to maintain system integrity, as illustrated in Fig. 3. Zhou et al. [18] and Chen et al. [19] conducted similar reviews, identifying widespread non-compliance with these models. Our study extends its findings by categorizing these deviations based on device states and proposing detection mechanisms for unauthorized state transitions. For example, devices that fail to revert to their initial state after unbinding remain susceptible to remote hijacking.

Application-to-Application Interaction Vulnerabilities: Cloud platforms often support diverse applications interacting in two primary scenarios:

Device Overlap: Multiple applications control the same device, creating potential conflicts.

Previous studies [20] identified these vulnerabilities but lacked a structured framework for detection. Our research introduces a dependency graph model to predict and mitigate conflicts proactively. For instance, in a smart home environment:

Rule 1: “If smoke is detected, open the water valve.”

These rules can cause conflict during a fire, rendering the fire suppression system ineffective. The system prioritizes critical actions by applying our dependency graph, ensuring fire suppression mechanisms remain operational.

IoT systems rely on traditional and IoT-specific communication protocols, each with unique vulnerabilities. This section compares existing findings with our contributions. Common IoT Protocols: MQTT, CoAP, ZigBee, and Bluetooth Low Energy (BLE) are popular for their efficiency in low-power, low-bandwidth environments. However, these protocols were not initially designed with security as a priority.

MQTT: While Jia et al. [21] identified vulnerabilities enabling DDoS attacks and data theft, our study further categorizes these vulnerabilities by attack vector and proposes enhanced broker-side validation.

By conducting a comparative analysis with existing literature, this study consolidates current knowledge and presents novel detection and mitigation strategies, thereby enhancing the understanding and security of IoT cloud platforms. Proprietary protocols are custom-designed by manufacturers and typically restricted to their platforms. These protocols are often not publicly documented. However, attackers can reverse engineer them to uncover communication details. If proprietary protocols contain design flaws, attackers can exploit them for malicious purposes. Studies [25–27] have revealed vulnerabilities in proprietary protocols from multiple leading IoT vendors. Once these protocols are successfully reverse-engineered, flaws in device authentication and authorization checks become immediately exploitable by attackers.

The extensive volume and diversity of network traffic in IoT systems create opportunities for side-channel attacks. IoT communication patterns exhibit distinct characteristics, including device-specific tasks, limited-service requests, and standardized protocols with predictable transmission patterns. These features make IoT traffic susceptible to inference-based attacks even when encrypted. To quantify the impact of these vulnerabilities, we analyzed five representative side-channel attack methods, as summarized in Table 2.

Key observations from this analysis include:

Protocol Header Features: Easily extracted and useful for confirming device types, but limited in scope.

This quantitative comparison highlights the varying complexity and potential impact of different side-channel attack methods, emphasizing the need for adaptive detection mechanisms.

Firmware serves as the operational core of IoT devices, managing hardware interfaces and implementing functional capabilities. However, firmware development often lacks systematic vulnerability detection processes, increasing susceptibility to exploitation. Quantitative insights into common firmware vulnerabilities, obtained from analyzing 500 firmware samples across multiple IoT vendors, are presented in Table 3.

Memory Vulnerabilities Memory vulnerabilities often result from coding errors that allow unauthorized access or control flow hijacking. Our analysis identified that 35% of devices exhibited exploitable buffer overflow flaws, primarily due to inefficient memory management in C-based firmware.

Logic Vulnerabilities Logic vulnerabilities stem from flawed authentication or authorization mechanisms. The observed 48% exploitation rate for authentication bypass vulnerabilities underscores the need for rigorous testing during firmware development. By integrating these quantitative findings, this section provides a more comprehensive understanding of the potential risks and highlights the importance of proactive detection measures in Table 4.

Voice assistant devices (e.g., smart speakers) are central in IoT systems, acting as control hubs for other devices. Attacks targeting voice devices threaten all connected devices under their control.

Hidden Voice Commands: Some attack techniques embed inaudible but machine-recognizable voice commands within the voice channel.

Research Findings:

In Reference [28], authors demonstrated methods to craft voice commands that are imperceptible to humans but interpretable by voice recognition systems. These commands can surreptitiously invade user privacy or open phishing websites.

These attacks share a common trait: while voice devices can process and interpret such signals, humans remain unaware of the interaction.

Overcoming Distance and Noise Challenges: Hidden voice signals face challenges such as transmission distance and noise interference. However, these issues can be mitigated:

Literature [29] extended the attack range significantly by using multiple speakers to separate voice signal frequency bands.

The large scale and sheer number of devices in IoT systems make them prime targets for malware such as viruses and trojans. Once compromised, these devices can form powerful botnets. Besides being rendered unusable, hijacked devices in a botnet serve as “stepping stones” for attackers to launch further malicious activities, such as large-scale distributed denial-of-service (DDoS) attacks or distributing spam.

Notably, the Mirai virus and its numerous variants remain significant threats to industrial control system devices. For example:

MadIoT Attacks: A novel type of attack targeting power grid systems, MadIoT exploits high-power IoT devices to form botnets. These botnets manipulate electricity demand, disrupting power grids and causing localized or widespread blackouts.

This section summarizes the key characteristics and shortcomings of research into IoT security threats, highlighting the following aspects in Table 5:

Cloud Platform Threats: Cloud platform vulnerabilities have severe consequences, yet current research focuses on a limited range of platform types. IoT cloud platforms have grown significantly recently, with related security research increasing accordingly. However, over the past five years, much of this research has relied on the “open” nature of platforms like SmartThings and IFTTT, which allow access to internal application logic. Many modern cloud platforms, however, do not expose their internal logic. Threats identified in open platforms may also exist in closed platforms, which require further exploration.

Neglect of Integrity and Availability: Most cloud platforms prioritize confidentiality through encryption, hiding application, and protocol implementations as their primary security mechanism. However, they often overlook other security aspects, such as identity and permission checks or interaction model maintenance. Studies show that encryption alone can be insufficient in adversarial IoT environments, as attackers may exploit security flaws in authorization, protocol applications, and interactions. A compromised cloud platform jeopardizes all connected devices.

Interaction Logic Vulnerabilities: Interaction logic vulnerabilities are a notable emerging threat in IoT systems. IoT systems involve interactions among users, cloud platforms, and devices. These systems increasingly offer rich automated control services, with various services interacting within the same application environment. Identifying design flaws during initial implementation is challenging, potentially introducing security risks [31,32]. As IoT functionalities and interaction complexities grow, logical vulnerabilities in these processes warrant deeper investigation.

Device Firmware Vulnerabilities: Firmware vulnerabilities remain a primary threat to IoT devices. Due to the vast number of devices, exploited firmware vulnerabilities can spread rapidly, causing large-scale damage [33,35]. As device hardware becomes more powerful and firmware functionalities more complex, memory vulnerabilities continue to pose significant security risks [36–39]. However, logic vulnerabilities are even harder to detect. Attackers leveraging such flaws can carry out more covert and damaging attacks [40]. Improving the detection of logic vulnerabilities is a critical area for future research.

Voice Device Attacks: Attacks targeting voice devices are unique to IoT systems. While voice channels enhance user interaction efficiency, they also introduce new threats:

Malicious applications on voice platforms [41].

Given voice assistant devices’ central role and expanding functionalities, addressing these threats remains a priority for researchers.

The primary approach to detecting malicious cloud applications is to develop methods independent of platform review mechanisms. These methods assess whether applications published in marketplaces exhibit threatening behavior or produce unintended outcomes outside their declared functionality.

SmartThings and IFTTT Platforms: Privacy leakage is a typical consequence of malicious applications or services on these platforms. Since these platforms provide access to application code or API permissions, detection schemes often rely on data flow analysis. This involves tracing the flow of sensitive data within an application to determine whether it sends unauthorized sensitive information to untrusted external targets [45].

In the SmartThings platform, authors [46] proposed a method to automatically trace data flows from functions generating sensitive data to network interface functions, identifying whether sensitive data is transmitted externally.

For Voice Platforms: Since the details of the implementation of voice assistant skills are inaccessible, current research primarily adopts black-box testing. This involves constructing various Skill voice command inputs to identify deviations from normal behavior.

A key challenge is automating the generation of voice command inputs. In this author’s illustration [48–50], they converted Skill names into spoken forms and compared phonetic similarities to detect malicious Skills capable of voice hijacking.

Most detection methods for interaction vulnerabilities rely on model checking, which involves modeling the interaction process of entities or applications and comparing the normal model with the actual runtime state to identify anomalies.

Detection of Entity Interaction Vulnerabilities: This approach uses finite state machines (FSMs) to model the interaction process. Reverse analysis of interactions is performed to establish the normal state transition processes and their corresponding triplet state sets, forming a standard interaction model.

Attacks cause abnormal state transitions or introduce anomalous triplet sets. Anomalies can be detected by comparing the standard interaction model with real-time states.

Detection of Application or Service Interaction Vulnerabilities: Applications and services on cloud platforms are implemented in various ways, so their models differ. Table 4 compares modeling approaches and detection outcomes for different methods.

Static firmware analysis involves examining the code structure or logical relationships in binary files without executing the firmware. Symbolic execution and taint analysis are commonly employed to detect memory or logical vulnerabilities.

Symbolic Execution: This method substitutes program inputs with symbols. By the end of execution, it generates symbolic expressions and constraints for each execution path. Solving these constraints identifies input values that fulfill the path conditions. For example, Subramanyan et al. [56] described confidentiality and integrity properties in firmware and used symbolic execution to verify whether execution paths violated these properties.

Taint Analysis: This approach establishes a data dependency graph within the program and uses taint propagation algorithms to track the paths from sensitive data sources to aggregation points, identifying potential security issues along these paths [57,58]. For instance, Eschweiler et al. [59] performed cross-file taint analysis by tracing data propagation through a limited set of inter-process communication patterns commonly found in binary files.

Binary Similarity Detection: This technique involves extracting features of known vulnerabilities from binaries and matching them against new binaries to locate vulnerabilities [59]. Feng et al. [60] applied concepts from computer vision, converting program control flow graphs into numerical feature vectors to improve the efficiency of matching algorithms by reducing feature dimensionality.

Dynamic analysis detects vulnerabilities by observing the real-time behavior of firmware during execution. Many studies achieve this by loading firmware into emulation software like QEMU, simulating firmware functionality without hardware, and combining this with techniques like fuzz testing.

Applicability to Linux-Based Firmware: Dynamic analysis works well for firmware based on the Linux kernel, which supports full operating system functionality. Tools like FIRMADYNE [83] and FIRM-AFL [84] simulate the entire system for Linux-based firmware. However, this approach faces challenges for the real-time operating system (RTOS)-based or bare-metal firmware (direct hardware interaction without an OS). Issues include non-standard file formats, encrypted firmware, and difficulty retrieving hardware input/output data.

Partial Firmware Emulation: Some studies address these challenges by isolating code execution paths relevant to the detection target and simulating only those paths. For example, FIoT [85,86] traced paths from data input sources to memory overflow-prone aggregation functions using reverse program slicing. Combining symbolic execution and fuzz testing, it identified memory vulnerabilities along these paths.

Full Firmware Emulation: Other studies overcome hardware-firmware coupling and architectural differences to achieve full-system firmware emulation [87–90]. uEmu [90] leveraged symbolic execution to deduce expected inputs during firmware execution, forming a peripheral feedback knowledge base. This knowledge dynamically guided the program execution process, enabling full-system emulation without prior knowledge or original hardware.

Some IoT manufacturers provide mobile apps as control terminals for their devices. These apps often contain logic and data related to device communication and functionality. By exploiting the correlation between apps and devices, researchers can detect firmware vulnerabilities without analyzing the firmware directly.

Using Apps as Input Interfaces: Since full-system IoT device emulation is challenging and direct data input from devices is difficult to locate, tools like IoTFuzzer [91]and DIANE [92] reframe the problem. These tools treat mobile apps as input interfaces and request parameters as mutable seed data. They:

Automatically locate parameter data sources or processing functions within the app.

Bluetooth Exploitation via Apps:

In the literature [93], the author found that apps could reveal device UUIDs (universally unique identifiers), which are identifiable in Bluetooth broadcasts and the Bluetooth authentication mode used. Attackers could exploit app behavior to attack nearby devices.

Component Reuse and Similarity Analysis:

Manufacturers often reuse development components across devices, meaning vulnerabilities in one component can appear in multiple devices. By comparing similarities between different devices’ apps, researchers can infer shared vulnerabilities [94].

Devices under attack often exhibit anomalies in their external side-channel characteristics, in addition to internal functional disruptions. These side-channel features can be leveraged for anomaly detection.

Traffic-Based Anomaly Detection: The traffic generated during a device’s network interactions reflects its internal behavior, making it a valuable source for detecting anomalies.

Unencrypted Header Features: Extracting header information from unencrypted traffic can help identify anomalous devices [95–97]. For instance, Yu et al. [97] used the common broadcast and multicast protocols in device communication to represent the device’s overall characteristics as a “view.” They then applied a multi-view learning algorithm to create device signatures, effectively identifying anomalous or spoofed devices in complex environments with numerous devices.

Physical Characteristic-Based Anomaly Detection: External physical characteristics such as power consumption, voltage, speed, gravity, and orientation can reflect the operational state of a device. Some studies utilize these characteristics for anomaly detection [98–100]. For example, Choi et al. [101] used control parameters, physical motion data, and low-level control algorithms from drones and ground detectors as baselines for normal operation. Even minor deviations from these baselines were flagged as anomalies, detecting physical and network-based attacks.

Context Consistency Detection Using Nearby Devices: Activities in an environment often exhibit contextual consistency among nearby devices or sensors. This characteristic can be exploited for malicious behavior detection [101–102]. For instance, Birnbach et al. [102] collected sensor data from multiple devices in a smart home environment. By aggregating these data into a unified signature, they detected spoofing incidents caused by sensor faults or attackers.

Key findings and limitations in threat detection research discussed in Section 3.2 are summarized as follows:

Limitations of Malicious App Detection in Cloud Platforms:

Most detection approaches focus on SmartThings and IFTTT, achieving good results but relying heavily on these platforms’ specific application development characteristics. Such methods are less applicable to other platforms where application logic is not openly accessible.

Challenges in Interaction Logic Vulnerability Detection:

Research on interaction logic vulnerabilities has explored black-box platform detection methods with promising results. However, these methods rely on significant manual analysis during modeling.

Firmware Analysis Challenges:

Obtaining and loading firmware are persistent obstacles. Existing methods to acquire firmware include downloading from websites, intercepting OTA updates, extracting from apps, or using device hardware debugging interfaces. However, manufacturers are enhancing firmware protection, removing public download links, encrypting firmware, or eliminating debugging interfaces, making firmware acquisition increasingly difficult.

Limitations of Firmware Vulnerability Detection Methods:

Static Analysis: Techniques like symbolic execution and taint analysis face path explosion and over-tainting challenges, respectively. Reducing the solution space before analysis is crucial. Binary similarity-based methods depend heavily on the compiler environment, where optimizations and obfuscations can reduce detection accuracy.

Strengths and Weaknesses of Side-Channel Detection:

Strengths: ∘

Side-channel detection is a non-intrusive method that identifies device anomalies through external observations, making it effective in scenarios where direct system access is not possible.

The primary cause of access control issues in IoT cloud platforms is the failure to adhere to the principle of least privilege during platform functionality implementation. Current research leverages platform characteristics to design fine-grained access control mechanisms.

For the SmartThings platform, researchers extract real-time contextual information from SmartApps during operation to provide detailed references for access control decisions: ∘

ContextIoT [61] captures execution paths, data dependencies, real-time variable values, and environmental parameters from within SmartApps. It uses this information to represent contextual details of actions and proactively seeks user authorization before executing operations. Only authorized actions are permitted to proceed.

Robust security mechanisms must be integrated into commonly used IoT protocols to ensure secure communication in IoT systems. However, protocol development and improvement involve multiple stakeholders and are long-term processes. Consequently, protocol implementers must enforce strict checks on entity identities and permissions within the business logic.

Improving Existing Protocols: For the MQTT protocol, missing security attributes can be addressed by introducing session management mechanisms, message-based access controls, and limitations on wildcard usage. The inherent weaknesses of the ZigBee protocol necessitate enhanced encryption levels during network joining and regular communication phases [66].

Header feature concealment involves obfuscating protocol header information without affecting data integrity or traffic forwarding capabilities. These methods are adaptable across IoT platforms that use DNS and VPN protocols:

DNS Encryption: Encrypts domain name requests to obscure network request targets, as demonstrated by prior research [72].

Statistical feature concealment techniques alter traffic patterns to prevent inference of device activities. These techniques are applicable across various IoT environments:

Decoy Traffic Injection: Injects random packets into communication streams, confusing eavesdroppers about real activities.

Across Device Architectures Given the resource constraints of IoT devices, firmware protection mechanisms must be lightweight and universally applicable. Generalized techniques include:

Component Isolation: Segregates memory and program components to contain potential exploits, with tools like EPOXY [75] and ACES [76] applicable across various embedded systems.

Voice-based attack defenses must address the growing diversity of voice-controlled IoT devices for Diverse Applications. Generalizable solutions include:

Interactive Safeguards: Adds security prompts for sensitive operations, balancing usability and security.

Ensuring the real-world feasibility of traffic feature concealment strategies requires evaluating their impact on system performance, resource consumption, and deployment costs. This section discusses critical trade-offs that influence the adoption of these defense mechanisms across diverse IoT environments. 1.

Computational Overhead and Hardware Constraints

Many IoT devices operate under strict resource constraints, limiting their ability to implement complex security measures. To address this, traffic feature concealment techniques should:

Towards Generalized IoT Security Mechanisms: This section summarizes the characteristics, limitations, and generalization strategies of the discussed defense mechanisms:

Cross-Platform Access Control: Innovative models like the transfer learning-based permission management framework [81] can adapt access control policies across different cloud platforms.

By emphasizing techniques with broad applicability, this study enhances the practical relevance of the proposed defenses, providing actionable insights for securing heterogeneous IoT ecosystems.

IoT devices are deeply integrated into daily life, collecting data that can reveal personal habits and behavioral patterns [18]. Various attacks in IoT systems can lead to the theft of this sensitive information. As shown in Table 1, most threats in IoT systems result in privacy breaches. Another key issue contributing to insufficient privacy protection is the lack of understanding of privacy-related information [82]. Users often do not fully grasp how devices collect and use their data, and existing privacy regulations fail to meet practical needs.

IoT cloud platforms offer numerous and diverse applications and services, yet current security auditing mechanisms struggle to address their security needs. Research shows an imbalance between developing new applications and maintaining their security. Static analysis alone often misses dynamic security issues, and while manual reviews are somewhat effective, they are time-consuming, labor-intensive, and prone to oversight. With the rapid expansion of IoT ecosystems, efficient, accurate, and automated security auditing mechanisms are urgently needed to support the release of large volumes of applications.

As IoT systems evolve, interaction models are becoming increasingly complex. Interactions occur not only between applications and devices but also across platforms. Security protections must extend beyond individual entities to address risks introduced during interactions.

A common issue is that even if individual entities are secure when operating independently, their protection mechanisms may fail during interactions with others. Current detection and defense strategies often use interaction behavior modeling to identify threats. However, due to variations in interaction models, these solutions are typically tailored to specific platforms or scenarios and are not reusable across different contexts.

Most existing threat detection and defense mechanisms are designed for specific application types, scenarios, device structures, or systems.

In cloud platforms, solutions for detecting malicious applications and interaction logic vulnerabilities are typically developed around platform-specific characteristics.

These limitations mean current solutions are often domain-specific, lack portability or modularity, and fail to address new challenges effectively.

IoT communication networks are highly heterogeneous, encompassing diverse network types and structures. The absence of standardized protocols and authorization frameworks leads to inconsistent network security practices. IoT devices’ limited resources and real-time performance requirements make lightweight communication protocols more suitable. However, most widely used lightweight protocols lack built-in security mechanisms. Device manufacturers often neglect to implement security features, introducing additional vulnerabilities.

Privacy and security have always been a key focus of IoT research. On the one hand, there is the issue of detecting and protecting privacy information leakage in IoT application scenarios. On the other hand, research on privacy understanding is also essential, such as surveying users’ awareness and understanding of privacy policies [105] and assessing the rationality of privacy protection measures from different stakeholders in the IoT ecosystem [106]. This research is crucial for advancing privacy protection mechanisms in IoT systems.

The application environment of IoT systems is highly complex, and security vulnerabilities due to identity authentication and authorization management flaws manifest in many ways. Current research on enhanced access control schemes has limitations. Therefore, designing access control mechanisms that meet the security needs of IoT systems and accommodate low energy consumption and high real-time requirements while being scalable is a practical need for the future development of IoT.

Artificial intelligence (AI) technology can enable in-depth learning and understanding of the information collected by devices, helping to address the automation shortcomings of existing detection and defense technologies. For instance, combining deep learning with fuzz testing can automatically detect malicious applications or identify vulnerabilities. Transfer learning can also integrate detection knowledge across different platforms. As IoT applications diversify and interaction scenarios become more complex, utilizing AI to enhance threat detection and defense solutions is a promising direction for further research.

Given the widespread security vulnerabilities in device firmware, more effective methods are needed to detect and prevent threats from escalating during usage. For example, in firmware dynamic analysis, achieving a more comprehensive simulation and combining it with other tools for vulnerability detection requires further research. Additionally, due to IoT devices’ limited hardware and software conditions, most traditional security mechanisms cannot be directly applied. Another key research challenge is overcoming these limitations and implementing more trusted defense architectures in firmware.

Communication protocols are at the core of the IoT transport layer. On the one hand, manufacturers often overlook security considerations when implementing lightweight protocols that lack built-in security features, necessitating efficient and automated security analysis solutions. On the other hand, leveraging the unique characteristics of IoT, such as interactions between three types of entities or device proximity, can help design IoT-specific secure communication protocols tailored to application scenarios.