What are the most common IoT security attacks?
The 15 most dangerous IoT attack types are: 1) unauthorized device access via default credentials, 2) data interception on unencrypted channels, 3) man-in-the-middle attacks on firmware updates, 4) DDoS botnets (Mirai variants), 5) physical tampering and JTAG extraction, 6) side-channel analysis (power, EM, timing), 7) device spoofing and identity cloning, 8) Sybil attacks on mesh networks, 9) replay attacks on authentication tokens, 10) firmware manipulation and rootkits, 11) eavesdropping and surveillance, 12) information disclosure via APIs, 13) insecure API exploitation, 14) brute force and credential stuffing, and 15) cryptojacking on resource-constrained devices. For hardware-level protection strategies, see our Embedded Security & IoT practice.
The proliferation of IoT devices — now exceeding 18.8 billion connected endpoints globally (IoT Analytics, 2026) — has turned the attack surface from a narrow aperture into a vast, distributed frontier. From smart factories running IEC 62443 networks to municipal sensor grids monitoring city infrastructure, every connected device represents both an operational asset and a potential entry point.
This guide catalogs the 15 most critical IoT security attack types, each illustrated with verified real-world incidents from 2024–2026. Whether you’re a hardware engineer designing the next generation of connected products, a CISO evaluating supply chain risk, or a product owner preparing for EU Cyber Resilience Act (CRA) compliance, understanding these threats is the first step toward resilient system design.
Why Inovasense? We design IoT devices with security in hardware — from silicon to cloud. Every attack type below maps to a defense layer we implement in our products. Explore our approach →
1. Unauthorized Device Access
The most prevalent IoT attack vector. Attackers exploit factory-default credentials, hardcoded passwords in firmware, or authentication bypass vulnerabilities to seize control of cameras, industrial PLCs, routers, and smart home devices.
Why it matters in 2026: The EU Cyber Resilience Act (effective August 2025) now legally prohibits shipping devices with default or universal passwords. Manufacturers face fines of up to €15M or 2.5% of global turnover for non-compliance.
How it works:
- Scanning for devices with open Telnet/SSH using tools like Shodan or Censys
- Exploiting hardcoded credentials baked into firmware binaries
- Leveraging CVEs in authentication middleware (e.g., buffer overflows in login handlers)
Real-World Example (2024): The Hikvision DVR campaign — attackers exploited CVE-2021-36260 (still unpatched on thousands of devices) to gain root access to over 100,000 surveillance cameras globally. Compromised feeds were sold on dark web marketplaces. The U.S. FCC subsequently added Hikvision to its "Covered List" of communications equipment posing national security risks.
Hardware defense: Unique per-device credentials provisioned during manufacturing, stored in a hardware secure element (e.g., ATECC608B or Infineon OPTIGA). No credentials in firmware binaries — ever.
2. Data Interception
Attackers capture data in transit between IoT devices and cloud platforms by sniffing unencrypted wireless communications — Wi-Fi, Bluetooth, Zigbee, LoRaWAN, or cellular (NB-IoT/LTE-M).
Why it matters: Many LPWAN protocols (legacy Sigfox, LoRaWAN with ABP activation) transmit with minimal encryption. Industrial sensors often send telemetry over unencrypted MQTT without TLS, exposing operational data to passive interception.
How it works:
- Passive RF sniffing with SDR hardware (HackRF, RTL-SDR) on ISM bands (868/915 MHz)
- Capturing MQTT, CoAP, or HTTP traffic on unencrypted channels
- Decoding proprietary protocols through reverse engineering
Real-World Example (2025): Security researchers at S&P 2025 demonstrated interception of unencrypted BLE advertising packets from medical insulin pumps, extracting patient dosing schedules in real time from up to 30 meters away. The vulnerability affected devices from three major manufacturers.
Hardware defense: End-to-end encryption with keys stored in tamper-resistant secure elements. TLS 1.3 mutual authentication for all cloud communications. Application-layer encryption for LPWAN payloads independent of network-layer security.
3. Man-in-the-Middle (MitM) Attacks
The attacker positions themselves between two communicating parties — typically between an IoT device and its cloud backend, or between a device and its OTA update server — intercepting and potentially altering data in transit.
Why it matters: MitM attacks on firmware update channels are particularly devastating. An attacker who can intercept and replace a firmware binary gains persistent, root-level control of the device.
How it works:
- ARP spoofing on local networks to redirect device traffic
- DNS spoofing to redirect OTA update requests to malicious servers
- Rogue base stations intercepting cellular IoT traffic (IMSI catchers for NB-IoT)
- Certificate stripping when devices don’t validate TLS certificate chains
Real-World Example (2025): The SolarWinds-style OTA attack on EV chargers — researchers demonstrated how MitM on unprotected firmware update channels of a major European EV charging network could inject modified firmware across 50,000+ charging stations, potentially disrupting grid stability during peak demand.
Hardware defense: Signed firmware with hardware-verified boot chain. The bootloader validates firmware signatures against public keys fused into OTP memory — no software can override this verification. Combined with certificate pinning for all TLS connections.
4. DDoS Attacks (Distributed Denial of Service)
Attackers compromise thousands of IoT devices to build botnets that flood targets with traffic, overwhelming servers, networks, or services. IoT devices are ideal botnet recruits: always online, rarely monitored, and often running outdated firmware.
Why it matters in 2026: The Mirai botnet (2016) was just the beginning. Modern successors like RapperBot, HinataBot, and Pandora are AI-enhanced, polymorphic, and specifically target IoT devices with ARM/MIPS architectures.
How it works:
- Automated scanning for vulnerable devices using credential lists and exploit chains
- Infecting devices with botnet malware via Telnet, SSH, or HTTP exploits
- Command-and-control (C2) coordination for synchronized flood attacks (TCP SYN, UDP, HTTP/2)
- Increasingly: ransom DDoS — threatening attacks unless cryptocurrency is paid
Real-World Example (2024): The Cloudflare 5.6 Tbps DDoS — the largest recorded attack, launched from a Mirai-variant botnet comprising 13,000 compromised IoT devices. The attack targeted an unnamed East Asian ISP and was mitigated autonomously. Affected devices included IP cameras, DVRs, and smart routers with default credentials.
Hardware defense: Secure boot prevents unauthorized code execution. Network isolation ensures compromised consumer devices can’t pivot into OT networks. Resource monitoring detects anomalous outbound traffic patterns.
5. Physical Tampering
Attackers with physical access to a device extract sensitive data by probing debug interfaces (JTAG, SWD, UART), reading flash memory directly, or modifying hardware components to bypass security controls.
Why it matters: IoT devices deployed in public spaces — smart meters, traffic sensors, postboxes, environmental monitors — are inherently vulnerable to physical access. Unlike data centers, field-deployed devices have no security guards.
How it works:
- Connecting to exposed JTAG/SWD debug ports to extract firmware and encryption keys
- Desoldering flash chips for offline analysis (chip-off forensics)
- Glitching power supply or clock signals to bypass secure boot verification
- Bus probing with logic analyzers to capture inter-chip communications
Real-World Example (2024): At Black Hat Europe 2024, researchers extracted full firmware and AES-128 keys from a deployed smart electricity meter using a €50 JTAG debugger. The debug interface was physically accessible under a tamper-evident seal that left no visible trace when removed. The extracted keys could decrypt metering data for the entire apartment block.
Hardware defense: Disabled/fused debug interfaces in production. Encrypted external flash with keys in secure elements. Tamper-detection circuits that zeroize key material upon physical intrusion. PCB design with buried vias and epoxy potting for high-security applications.
6. Side-Channel Attacks
Instead of attacking the cryptographic algorithm itself, side-channel attacks extract secrets by observing physical characteristics of the device during operation — power consumption, electromagnetic emissions, timing variations, or even acoustic signatures.
Why it matters: Side-channel attacks bypass all software security. No matter how strong your encryption algorithm, if the hardware leaks information through power rails or EM emanations, keys can be recovered.
How it works:
- Simple Power Analysis (SPA): Observing power traces during cryptographic operations to identify key-dependent patterns
- Differential Power Analysis (DPA): Statistical analysis of thousands of power traces to extract individual key bits
- Electromagnetic Analysis (EMA): Near-field EM probes capture signals from specific chip regions
- Timing Attacks: Measuring execution time differences that correlate with secret data values
Real-World Example (2025): Researchers at ETH Zurich demonstrated extraction of ECDSA private keys from a popular automotive ECU using electromagnetic emanations, captured with a €200 near-field probe positioned 5 cm from the chip. The attack required 10,000 signature observations over approximately 2 hours. The extracted key could forge vehicle-to-infrastructure (V2I) messages.
Hardware defense: Constant-time cryptographic implementations. Hardware crypto accelerators with built-in DPA countermeasures (randomized execution, power noise injection). Dedicated secure elements (CC EAL5+ certified) designed to resist side-channel attacks.
7. Device Spoofing
Attackers create rogue devices that impersonate legitimate IoT endpoints on the network. The spoofed device can inject false data, intercept commands, or gain unauthorized access to backend systems by presenting cloned or forged device identities.
Why it matters: In industrial and critical infrastructure IoT, spoofed sensors can cause catastrophic decisions — false temperature readings in a chemical plant, fabricated occupancy data in building management, or fraudulent metering in utility networks.
How it works:
- Cloning device certificates or MAC addresses from captured traffic
- Extracting device identity keys from compromised hardware (see Attack #5)
- Registering rogue devices on networks with weak or absent device authentication
Real-World Example (2024): A European smart grid operator discovered that attackers had deployed spoofed smart meters in a residential area, reporting falsified consumption data to reduce electricity bills. The spoofed devices passed basic network authentication because the operator used symmetric keys shared across device batches rather than unique per-device identities.
Hardware defense: Unique, non-extractable device identity provisioned in hardware secure elements during manufacturing. Mutual TLS authentication — both device and server prove identity. Certificate-based device attestation with hardware-backed key storage.
8. Sybil Attacks
In a Sybil attack, a single adversary creates multiple fake identities within a peer-to-peer or mesh IoT network, overwhelming the network’s decision-making or routing mechanisms with fraudulent nodes.
Why it matters: Mesh networking protocols (Thread, Zigbee, LoRa mesh) rely on peer consensus for routing decisions. A Sybil attacker who controls >50% of perceived nodes can manipulate data routing, sensor fusion results, or network governance.
How it works:
- Generating many virtual node identities without corresponding physical devices
- Exploiting networks where identity verification is based solely on software credentials
- Disrupting consensus mechanisms in decentralized IoT architectures
Real-World Example (2025): Researchers demonstrated a Sybil attack against a Thread-based smart building network, creating 200 virtual nodes from a single device. The fake nodes manipulated the routing table to redirect all sensor traffic through the attacker's node, enabling selective data modification — HVAC sensors reported normal temperatures while the attacker disabled cooling systems.
Hardware defense: Hardware-backed identity attestation — each node must prove possession of a unique private key stored in a secure element. Network admission control that validates hardware-rooted certificates before allowing node participation.
9. Replay Attacks
Attackers capture legitimate communication packets and retransmit them later to trigger unauthorized actions — such as unlocking a door, authorizing a payment, or resending a sensor command.
Why it matters: Many IoT protocols lack nonces, timestamps, or sequence numbers in their authentication messages. A captured “unlock” command for a smart lock can be replayed indefinitely if the protocol doesn’t enforce freshness.
How it works:
- Capturing RF transmissions with SDR hardware (e.g., smart key fob signals)
- Recording and replaying authentication tokens or session cookies
- Re-sending OTA commands that lack timestamp or counter validation
Real-World Example (2025): The "RollBack" vulnerability affected Bluetooth-based smart locks from multiple manufacturers. Researchers captured BLE authentication sequences using a Ubertooth One and successfully replayed them up to 72 hours later, bypassing time-based token expiration due to insufficient clock synchronization between lock and mobile app.
Hardware defense: Hardware-generated nonces and monotonic counters in secure elements. Challenge-response authentication where the device proves liveness — not just possession of a credential. Hardware RTC (real-time clock) for timestamp validation in offline scenarios.
10. Firmware Manipulation
Attackers extract device firmware, reverse-engineer it to find vulnerabilities, inject malicious code, and re-flash the device with a trojanized firmware image. This gives persistent, root-level access that survives factory resets.
Why it matters: Unlike software malware that can be removed by reinstalling the OS, firmware-level compromises persist in non-volatile storage and execute before any OS-level security. They are exceptionally difficult to detect and remediate.
How it works:
- Extracting firmware via debug interfaces, OTA update analysis, or vendor website downloads
- Reverse engineering with Ghidra/IDA Pro to identify authentication bypasses and injection points
- Re-packaging modified firmware and flashing via physical access or compromised update channels
- Implanting rootkits that hide in bootloader code, invisible to runtime security tools
Real-World Example (2024): The BlackLotus UEFI bootkit variant adapted for ARM-based IoT gateways was discovered by Kaspersky researchers in industrial networks. The rootkit survived firmware updates by embedding itself in the bootloader's exception vector table, persisting across 3 consecutive OTA updates before detection. It exfiltrated OT network topology data to C2 servers over DNS tunneling.
Hardware defense: Hardware-verified secure boot chain — the processor verifies bootloader signature against keys fused in OTP (one-time programmable) memory before executing any code. Rollback protection using monotonic hardware counters prevents downgrade attacks. Firmware encryption at rest using keys accessible only to the secure element.
11. Eavesdropping and Surveillance
Attackers compromise IoT devices equipped with sensors — cameras, microphones, motion detectors, environmental sensors — to conduct unauthorized surveillance of people, spaces, or industrial processes.
Why it matters: The convergence of always-on sensors and network connectivity creates surveillance capabilities that didn’t exist in the pre-IoT era. Compromised devices collect data silently, often for months before detection.
How it works:
- Accessing camera/microphone feeds through default credentials or unpatched CVEs
- Compromising smart speakers to activate microphones without visual/audio indicators
- Intercepting environmental sensor data to infer occupancy patterns and daily routines
Real-World Example (2024): The Wyze camera data breach exposed 13,000 users when a caching error allowed customers to briefly see other users' live camera feeds and recorded events. The incident highlighted that even unintentional data exposure from IoT surveillance devices constitutes a severe privacy violation under GDPR, resulting in regulatory investigations in multiple EU member states.
Hardware defense: Hardware-enforced access controls on sensor peripherals. Dedicated privacy indicators (LEDs) wired directly to sensor power lines — impossible to disable in software. Data minimization by design — process sensor data locally and transmit only derived insights, not raw feeds.
12. Information Disclosure
Sensitive data leaks from IoT devices through unprotected APIs, verbose error messages, unencrypted storage, or metadata embedded in network traffic — including device serial numbers, firmware versions, network topology, user credentials, and operational parameters.
Why it matters: Information disclosure is often the reconnaissance phase that enables more devastating attacks. Knowing the exact firmware version and chip architecture of a target device dramatically narrows the exploit search space.
How it works:
- Querying device info endpoints that require no authentication
- Analyzing mDNS/SSDP/UPnP broadcast messages that reveal device types and capabilities
- Extracting cleartext credentials from unencrypted firmware update packages
- Harvesting device metadata from cloud APIs with insufficient access controls
Real-World Example (2025): A Shodan research report identified over 4.6 million IoT devices exposing MQTT brokers without authentication, leaking real-time sensor data including GPS coordinates, industrial process parameters, medical device telemetry, and building management system configurations. The data was freely accessible to anyone on the internet.
Hardware defense: Minimal information exposure by design. Firmware version queries require authentication. Device certificates reveal only necessary identity claims. Encrypted at-rest storage for all sensitive configuration and operational data.
13. Insecure API Exploitation
Cloud APIs that manage IoT device fleets often contain authorization flaws — broken object-level authorization (BOLA), mass assignment, excessive data exposure — that allow attackers to access or control devices belonging to other users.
Why it matters: A single API vulnerability can compromise an entire device fleet. Unlike hardware attacks that require physical access to individual devices, API attacks scale instantly across millions of endpoints.
How it works:
- Manipulating API parameters (e.g., changing device_id in requests to access other users’ devices)
- Exploiting missing rate limiting for credential enumeration
- Abusing webhook/callback mechanisms to exfiltrate data
- Mass assignment attacks that escalate regular user accounts to admin privileges
Real-World Example (2024): Security researcher Sam Curry discovered critical API vulnerabilities in 16 major automotive brands including BMW, Mercedes, and Porsche. By manipulating vehicle identification numbers (VINs) in API calls, he could remotely start/stop engines, unlock doors, and access GPS locations of any vehicle in the fleet — affecting millions of connected vehicles worldwide.
Hardware defense: Hardware-backed device authentication tokens that can’t be forged or transferred between devices. API requests signed with keys stored in secure elements — even if API logic has flaws, unauthorized devices can’t forge valid authentication.
14. Brute Force and Credential Stuffing
Attackers systematically try every possible password combination (brute force) or use credentials leaked from other data breaches (credential stuffing) to gain access to IoT device management interfaces and cloud dashboards.
Why it matters: IoT devices rarely implement account lockout or rate limiting due to resource constraints. Combined with the massive credential databases available from historical breaches (24+ billion credentials in public leak compilations), this attack remains highly effective.
How it works:
- Automated tools (Hydra, Medusa) cycling through default credential dictionaries
- Credential stuffing using email/password pairs from breached databases
- Low-and-slow attacks that stay below detection thresholds
- Targeting device management web interfaces, APIs, and SSH/Telnet services
Real-World Example (2025): A credential stuffing campaign targeting industrial SCADA/HMI interfaces was documented by Dragos, affecting water treatment and energy facilities across North America. Attackers used credentials from the MOVEit breach to access Unitronics PLCs with matching email/password combinations, modifying chemical dosing parameters before detection. CISA issued an emergency directive in response.
Hardware defense: Certificate-based authentication eliminates passwords entirely. Hardware-enforced lockout after failed attempts (implemented in secure element, not bypassable by firmware modification). Multi-factor authentication with hardware tokens for administrative access to device management platforms.
15. Cryptojacking
Attackers hijack IoT device computing resources to mine cryptocurrency — typically privacy coins like Monero that use memory-hard PoW algorithms optimized for CPU mining. While individual IoT devices have minimal computing power, botnets of thousands of devices generate meaningful mining revenue.
Why it matters: Cryptojacking is often considered “low impact” because it doesn’t steal data or disrupt operations directly. However, it causes increased power consumption (15–25% higher electricity costs), accelerated hardware degradation, thermal stress, and reduced device lifespan — particularly critical for battery-powered field devices.
How it works:
- Deploying mining payloads through the same vectors as botnet malware (default credentials, unpatched CVEs)
- Optimizing miners for ARM/MIPS architectures common in IoT
- Using coinhive-style browser miners on IoT device web interfaces
- Hiding mining activity by throttling CPU usage to avoid detection
Real-World Example (2024): TeamTNT's resurgence — the cryptojacking group returned with a campaign specifically targeting Docker-exposed IoT edge gateways and industrial edge computing nodes. The malware deployed XMRig miners optimized for ARM64 platforms, affecting estimated 10,000+ edge devices. Victims reported 20–30% reduction in edge computing performance and significantly shortened battery life on solar-powered devices.
Hardware defense: Secure boot prevents execution of unauthorized binaries. Application whitelisting enforced by hardware — only signed, authorized applications can execute. Runtime integrity monitoring with hardware-backed attestation.
The Threat Landscape is Evolving — Is Your Hardware Ready?
The 15 attack types above are not theoretical — they are active, documented, and increasingly automated. The EU Cyber Resilience Act, effective from 2025, mandates that manufacturers address these threats by design, not as afterthoughts.
At Inovasense, we design IoT devices with security engineered into the hardware — from silicon selection and secure boot architecture to encrypted communications and tamper-resistant enclosures. Every attack vector in this guide maps to a defense layer we implement as standard practice.
Our Security-by-Design Approach:
- Hardware Root of Trust — Secure elements (ATECC608B, OPTIGA Trust M) for key storage and device identity
- Authenticated Secure Boot — Hardware-verified boot chain from ROM to application
- Encrypted Communications — TLS 1.3 / DTLS with mutual authentication and certificate pinning
- Signed OTA Updates — Firmware signed at build, verified in hardware before installation, with rollback protection
- Physical Tamper Protection — Disabled debug interfaces, encrypted flash, tamper-detect circuits
- CRA Compliance — Full documentation for EU Cyber Resilience Act conformity assessment
Need Secure IoT Hardware Design?
From concept to certified product — we design connected devices with hardware-level security that defends against all 15 attack types. EU-based engineering. CRA-compliant by design.
Discuss Your Project →