Originally published in Hakin9 / Pentestmag
In today's hyperconnected world, the Internet of Things and embedded systems are at the heart of a technological revolution. From smart homes and wearable tech to industrial automation and autonomous vehicles, billions of devices collect, process, and transmit data every second, fueling innovation but simultaneously expanding the attack surface at a pace that security governance has not kept up with. As attackers exploit vulnerabilities in sensors, actuators, firmware, and communication protocols, securing IoT ecosystems has become a critical concern for consumers, enterprises, and governments alike.
Understanding IoT and Embedded Systems
IoT refers to a vast network of devices connected to the internet that collect and share data. Embedded systems are purpose-built computing systems within larger mechanical or electrical systems. While IoT can exist without embedded systems, most IoT devices are embedded systems, found in everything from smart thermostats to medical implants. Understanding the distinction matters because the security constraints are baked in at the design level, not added later.
Key characteristics of embedded IoT systems include limited computational and memory resources, real-time data processing requirements, specialized operating systems, and deployment in remote or physically inaccessible locations. These are not incidental traits. They are fundamental design constraints that shape every security decision downstream, and frequently eliminate the controls that enterprise security teams take for granted.
Most IoT devices are not bad at security by accident. They are constrained by architecture, then optimized for cost and speed to market.
High-risk deployment sectors clarify why these constraints carry serious consequence:
Healthcare. Connected medical devices, insulin pumps, pacemakers, remote patient monitoring systems, have life-critical roles. Breaches can result in direct patient harm. The consequences of compromise are not recoverable in the way a credential rotation or a contained data breach can be remediated.
Automotive. Modern vehicles host over 100 electronic control units and run millions of lines of code. Vulnerabilities in infotainment or telematics systems can enable remote control of vehicle functions, a risk demonstrated in practice, not just theory. ISO/SAE 21434 now mandates cybersecurity engineering across the full vehicle lifecycle, but adoption varies widely across OEMs and their supplier chains.
Industrial IoT (IIoT). Smart factories rely on OT, PLCs, SCADA, DCS, for automation and physical process control. IIoT is the networked layer that connects those OT systems to IT infrastructure and, increasingly, the internet. Attacks on IIoT can cause operational disruptions, financial loss, or direct physical harm. The convergence of IT and OT networks , previously air-gapped by design, has introduced attack paths that industrial control system designers never anticipated and most OT hardware was never built to resist.
Smart Homes and Cities. From smart locks to traffic control systems, vulnerabilities here can lead to privacy breaches or infrastructure sabotage at municipal scale. The attack surface is distributed, fragmented across vendors, and governed by no single entity with operational accountability.
Core Security Challenges
The massive proliferation of embedded IoT devices, expected to surpass 25 billion by 2030, has vastly increased the global attack surface. These devices often prioritize low cost and rapid deployment over security, producing a consistent set of structural vulnerabilities:
Hardcoded credentials and weak authentication. Devices ship with default usernames and passwords that users rarely change. Mirai demonstrated this at scale: the botnet did not need sophisticated exploitation, it needed only to try admin/admin at enough addresses. The problem persists because default credentials reduce support burden and most users never encounter a breach before the device is discarded.
Insecure communication protocols. Many devices use unencrypted HTTP or poorly configured MQTT, exposing data in transit across networks that may be partially controlled by adversaries. MQTT in particular, lightweight and publish-subscribe oriented, was designed for constrained environments and lacks built-in authentication in its base specification.
Unpatched open-source components. The 2020 Amnesia:33 vulnerability cluster revealed how embedded TCP/IP stacks, including uIP, FNET, and Nut/Net, carried flaws including buffer overflows and DNS poisoning risks affecting millions of devices. These vulnerabilities were not novel; they existed in stacks that had been shipping for years without meaningful review.
Testing embedded systems compounds these challenges in ways that standard enterprise security practices do not resolve. Hardware-software co-dependencies mean bugs may appear only under specific hardware conditions, making software-only unit testing insufficient. Real-time systems require deterministic execution validation under worst-case scenarios. The scale of deployment , millions of devices across dozens of firmware versions, makes comprehensive manual testing structurally infeasible. Practices like Hardware-in-the-Loop testing and fuzzing over embedded interfaces (UART, SPI, CAN) are being adopted, but they require deep expertise and lack standardization across the industry.
IoT Breaches in Recent Times
The following cases from 2024–2025 illustrate the range of vulnerabilities actively exploited in production IoT environments. They are not exceptional. They are representative.
Matrix Botnet, November 2024. A threat actor known as “Matrix” orchestrated a large-scale campaign targeting IoT devices with known vulnerabilities. By deploying Mirai botnet malware, Matrix transformed compromised devices into a global botnet used to execute distributed denial-of-service attacks. The campaign primarily affected devices in China and Japan, exploiting unpatched vulnerabilities and misconfigurations in connected devices that had been publicly documented for months before exploitation.
Raptor Train Botnet, September 2024. Security researchers uncovered a botnet that had compromised over 200,000 IoT devices globally. Operated by the Chinese nation-state threat actor Flax Typhoon, the botnet leveraged a three-tiered architecture with Tier 1 consisting of compromised IoT devices including routers, IP cameras, and network-attached storage systems. Attackers exploited a combination of known and zero-day vulnerabilities to infiltrate devices, many of which owners had no mechanism to patch.
AVTECH IP Cameras, August 2024. Researchers discovered that unpatched vulnerabilities in AVTECH IP cameras were being exploited to disseminate Mirai malware. These cameras, commonly deployed in critical infrastructure sectors including finance, healthcare, and transportation, carried a known vulnerability from 2019 that was only assigned a CVE identifier in 2024. The lag between vulnerability existence and formal acknowledgment is not rare; it is the norm for the long tail of IoT products deployed in critical sectors.
TP-Link Tapo Smart Devices, July 2024. Research revealed that TP-Link's Tapo series, including smart bulbs, smart plugs, and cameras, contained vulnerabilities that could be exploited to extract Tapo account credentials and the SSID and password of the local network. These vulnerabilities stemmed from insecure communication protocols and inadequate encryption mechanisms: a smart bulb as a credential harvesting device.
Roku, April 2024. Roku reported 576,000 user accounts compromised through credential stuffing attacks using previously leaked username and password combinations. In response, Roku implemented mandatory multi-factor authentication for all users, a control that was available before the incident and not required.
ADT, August 2024. ADT disclosed a breach in which hackers accessed databases containing customer order information, exposing email addresses, phone numbers, and postal addresses for over 30,000 customers. A home security company experiencing a data breach is not ironic; it is illustrative of how IoT platform infrastructure and device security are managed separately.
Mars Hydro, February 2025. A breach linked to Mars Hydro, a China-based grow light manufacturer, and LG-LED Solutions Limited exposed 2.7 billion records. The compromised data included Wi-Fi network names, passwords, IP addresses, and device identifiers, a dataset with significant downstream utility for any attacker attempting lateral movement from IoT devices into home or enterprise networks.
The cases differ in sector, scale, and sophistication. The structural cause repeats: capability shipped ahead of the controls that would constrain its misuse.
Smart Home IoT: Security Risks and Testing
The consumer IoT explosion, smart thermostats, locks, lights, and cameras, has brought convenience alongside a decentralized cybersecurity problem that is structurally difficult to govern at scale. Default credentials are still present on over 50% of shipped smart home products. Several smart doorbell and camera brands have been found exposing RTSP streams through unauthenticated APIs. Voice assistants can be hijacked via ultrasound injection (DolphinAttack) to trigger commands silently. And most home networks are flat: once one device is compromised, lateral movement to NAS devices or personal computers is trivial.
In 2022, researchers exploited over 1 million smart plugs and thermostats through a single MQTT broker that lacked authentication, enabling remote switching and data harvesting at scale.
Standard testing practices for consumer IoT include Static Application Security Testing on firmware and application source code for buffer overflows and hardcoded credentials; Dynamic Application Security Testing for runtime behavior including insecure APIs and command injections; network penetration testing through home routers for open ports, Telnet exposure, and misconfigured MQTT brokers; and interoperability testing across hubs including Amazon Alexa, Apple HomeKit, and Samsung SmartThings.
Emerging techniques include fuzzing over embedded protocols, Zigbee, Z-Wave, and BLE, to detect crashes, authentication bypasses, and overflows; firmware emulation with tools like QEMU or FirmAE to extract and inspect firmware for hidden backdoors or unsigned update mechanisms; and cloud API security audits probing mobile applications and cloud platforms for exposed tokens or unauthenticated endpoints. In 2023, researchers used Firmwalker and Binwalk to extract credentials and AWS keys from a baby monitor firmware image, exposing user data and video streams.
Industrial IoT: Emerging Threats and Testing
The terminology matters before the threats do. OT (Operational Technology) is the control-systems layer: PLCs, SCADA, DCS, and HMIs that directly monitor and manipulate physical processes. OT predates the internet and was originally designed for isolation, often air-gapped, communicating over serial buses, with no IP stack in sight. IIoT (Industrial Internet of Things) is what happens when those OT devices get networked. A PLC running Modbus RTU over an RS-485 cable is OT. That same PLC with an Ethernet module doing Modbus TCP over a corporate LAN is IIoT. The security risks in industrial environments arise specifically at that junction: OT hardware that was never designed for adversarial networks, now exposed to them.
The flat-network problem is the most consequential expression of that gap. Many industrial environments lack segmentation between OT and IT: the SCADA console and the corporate laptop share the same network, and a ransomware payload that lands in IT can pivot directly to production systems without crossing a security boundary. Industrial protocols , Modbus, PROFINET, EtherNet/IP, were designed for reliability in closed environments, not for adversarial IP networks, and carry no built-in encryption or authentication. Remote maintenance tools like TeamViewer and VNC are routinely deployed across OT systems without MFA or network isolation, creating persistent external access paths that are rarely reviewed or rotated.
In the 2023 Cencora manufacturing attack, advanced persistent threats used outdated VPN credentials to access IIoT-connected HVAC systems and exfiltrate production metrics and SCADA configuration data.
Standard IIoT testing practices include industrial protocol fuzzing of Modbus, OPC UA, and BACnet using tools like Sulley or Boofuzz to detect malformed packet crashes or unexpected responses; Hardware-in-the-Loop testing to simulate control loops with real-world actuator and sensor feedback under fault conditions; asset inventory and mapping with tools like Tenable.ot or Nozomi Guardian to detect rogue devices and insecure configurations; and network segmentation testing to evaluate corporate-to-OT separation and lateral movement paths.
Emerging IIoT techniques include firmware static and binary analysis of PLCs and RTUs using Binwalk and Ghidra for credential leaks and undocumented logic paths; ICS honeynets to capture real-world payloads and study attacker behavior against industrial targets; behavioral anomaly detection using ML-based platforms such as Claroty and Dragos to monitor deviations in traffic frequency, packet timing, or payload structure; and digital twin cyber ranges for testing resilience and patch validation without production risk.
In 2024, a honeynet mimicking Schneider Electric PLCs was targeted by the BAUXITE APT group using Modbus write coil flooding, a zero-day technique that later appeared in live attacks across Europe's energy grid.
Smart Cities: Emerging Threats and Testing
Smart city infrastructure presents a distinct governance challenge: systems are built by different vendors, maintained by different municipal departments, and often operate on separate stacks with no unified visibility. Traffic lights, waste management systems, and surveillance networks run in fragmented architectures that create patching gaps and delayed update cycles across city-wide deployments.
Edge infrastructure like smart meters and environmental sensors relies on LPWANs that can be spoofed or subjected to denial-of-service attacks. Default credentials on smart poles and kiosks have led to city-wide signage compromises and public information tampering. Poor IAM and cloud storage misconfigurations expose real-time citizen data including foot traffic patterns and license plate records to unauthorized access.
In 2024, the Matrix Botnet hijacked vulnerable smart light poles in Tokyo using LoRa-based firmware injections to execute mass denial-of-service attacks and lateral pivot operations across urban infrastructure. In a 2025 red team exercise in Helsinki, testers exposed unauthenticated BLE broadcasts from smart benches that allowed attackers to query device identifiers and modify power usage logs , falsifying sustainability reporting data at the city level.
Testing for smart city infrastructure spans API penetration testing against RESTful urban services for injection and authentication flaws; vulnerability scanning across VLANs covering city Wi-Fi, utility, and emergency systems; standards compliance assessment for ISO 30182 and ISO 22301 for interoperability and resilience; mobile device compatibility and privacy testing for citizen applications; sensor spoofing validation to test filtering logic and anomaly detection; and red teaming across infrastructure layers to simulate supply chain compromise or rogue sensor installation.
Best Practices for Securing IoT
Defense-in-depth for IoT spans physical, network, application, and device layers. The following tables organize controls by deployment context. None of these controls is novel. Most are not implemented. The gap is not knowledge, it is prioritization and accountability.
Consumer IoT
| Category | Best Practice |
|---|---|
| Authentication | Change default passwords; use strong, unique credentials per device |
| Firmware Updates | Enable automatic OTA updates; buy from vendors with transparent update policies and defined end-of-support dates |
| Network Segmentation | Isolate IoT devices on a separate VLAN or SSID from personal computers and phones |
| Data Privacy | Review privacy policies; disable data-sharing features that are unnecessary for the device's function |
| Physical Security | Disable unused ports (USB, Ethernet); restrict physical access to smart hubs |
| Protocol Use | Prefer devices using encrypted communication, TLS for HTTPS, WPA3 for Wi-Fi |
| Disable Unused Features | Turn off voice assistants, location tracking, or remote control features if not in active use |
| Monitor Logs | Use applications that offer activity logging and alerting for unusual device behavior |
Industrial IoT (IIoT)
| Category | Best Practice |
|---|---|
| Zero Trust Architecture | Treat all IIoT nodes as untrusted by default; enforce strict access controls at every segment boundary |
| Asset Inventory | Maintain real-time inventory of all connected IIoT assets with software versions and firmware signatures |
| Network Segmentation | Use DMZs, VLANs, and firewalls to isolate OT/IIoT systems from IT and cloud platforms |
| Patching & Updates | Apply security patches through validated maintenance windows; test on digital twins before deploying to production |
| Protocol Hardening | Secure Modbus, DNP3, and OPC-UA with authentication, encryption, and session validation where the protocol supports it |
| Monitoring & Detection | Deploy anomaly-based IDS/IPS for OT traffic (e.g., Dragos, Nozomi Networks) with baselines tuned to known-good operational profiles |
| Access Control | Enforce least privilege via role-based access; remove unused accounts from PLCs and SCADA consoles on a defined cycle |
Smart City IoT
| Category | Best Practice |
|---|---|
| Data Governance | Implement centralized data classification, encryption-at-rest and in-transit, and audit logging across city systems |
| Open API Security | Secure public APIs with OAuth2, rate limiting, input validation, and token expiration |
| Vendor Management | Enforce third-party risk assessments and compliance with ISO 27001 or NIST CSF 2.0 for all smart city suppliers |
| Resilience Planning | Design for redundancy across smart traffic and public services; use edge gateways with failover capabilities |
| Patch Management | Coordinate patch cycles across city departments; automate testing via staging environments before city-wide deployment |
| Monitoring & Telemetry | Implement unified observability (SIEM, SOAR) across smart grid, water, traffic, and energy platforms |
| Incident Response | Maintain a smart city IR plan with multi-agency coordination, regular drills, and real-time dashboards |
| Public Trust & Ethics | Use consent-based surveillance policies; conduct algorithmic and privacy impact assessments per IEEE 7010 |
The pattern across all three contexts is the same: controls that look obvious in retrospect were not in place when cost, schedule, and commercial urgency still carried the argument. Security embedded by design requires early commitment, to architecture choices, procurement standards, and vendor accountability, that cannot be substituted by post-deployment remediation at the scale IoT operates.
The future of the connected world hinges not just on innovation, but on our ability to secure every byte of it.
As the digital mesh of smart homes, critical infrastructure, and autonomous systems deepens, IoT and embedded system security can no longer be an afterthought. Each connected device represents not just convenience, but a potential entry point for malicious actors. The escalating threat landscape demands a defense-in-depth approach that spans physical, network, application, and device layers. Regulatory alignment, threat-informed testing, robust patch management, and stakeholder collaboration are critical pillars in ensuring resilient IoT ecosystems. Governments, manufacturers, security professionals, and end-users must move in concert, transforming fragmented security efforts into a coordinated, adaptive, and proactive defense.