1. Default and Weak Credentials
Default credentials are the single most commonly exploited vulnerability in IoT environments.
Most IoT devices ship with factory-set usernames and passwords — often simple combinations like admin/admin or admin/password — that are publicly documented in manufacturer manuals and widely known to attackers. When these credentials are not changed during deployment, the device remains accessible to anyone with basic knowledge of the manufacturer’s defaults.
The problem is compounded by scale. Organizations may deploy hundreds or thousands of IoT devices across multiple sites, making systematic credential management operationally challenging. Devices installed by third-party contractors or facilities teams are particularly likely to retain default credentials, as security hardening is rarely part of the installation scope.
Attackers exploit default credentials using automated scanning tools that identify internet-exposed IoT devices and attempt login using known credential lists. The technique requires minimal skill and consistently yields results.
How attackers exploit it: Automated credential stuffing, brute-force attacks against management interfaces, exploitation of publicly documented default credentials.
Compensating controls: Change default credentials at deployment. Enforce unique credentials per device. Restrict administrative interface access to specific IP ranges or management networks.
2. Unpatched Firmware and Software Vulnerabilities
Firmware vulnerabilities are endemic to IoT environments.
IoT devices run embedded software that controls their function, communication, and management interfaces. This firmware frequently contains security vulnerabilities — buffer overflows, hardcoded credentials, insecure update mechanisms, and authentication bypasses — that can be exploited to gain unauthorized access or execute arbitrary code.
Unlike enterprise software, IoT firmware is not updated on a regular patch cycle. Updates may be infrequent, difficult to apply without taking the device offline, or dependent on the manufacturer releasing an update at all. In many cases, devices reach end-of-life while still deployed and actively connected to production networks — meaning vulnerabilities are never patched.
Publicly disclosed IoT vulnerabilities remain exploitable in production environments for far longer than comparable IT vulnerabilities. Attackers maintain curated lists of known vulnerable device models and firmware versions, actively targeting organizations that have not — or cannot — apply available patches.
How attackers exploit it: Exploitation of publicly disclosed CVEs, targeted attacks against known vulnerable firmware versions, exploitation of end-of-life devices with no available patches.
Compensating controls: Maintain a firmware inventory across the IoT estate. Apply updates where operationally feasible. For devices that cannot be patched, apply compensating controls — segmentation, access restriction, and enhanced monitoring.
3. Insecure Network Services and Open Ports
Many IoT devices expose network services that are unnecessary for their intended function — Telnet, FTP, SSH, HTTP management interfaces, and vendor-specific protocols — often enabled by default and accessible without authentication.
These exposed services expand the attack surface of the device significantly. An attacker who identifies an open Telnet port on an IoT device, for example, can attempt to connect directly and authenticate using default or brute-forced credentials — gaining command-line access to the device and, potentially, the network it sits on.
The problem is often compounded by internet exposure. IoT devices intended for local network use are frequently accessible from the internet — either because they were configured that way intentionally, or because network address translation (NAT) rules, cloud management platforms, or vendor remote-access features create unintended external pathways.
How attackers exploit it: Direct exploitation of exposed management interfaces, brute-force attacks against open services, exploitation of unauthenticated APIs and management portals.
Compensating controls: Disable all unnecessary network services and close unused ports during device hardening. Restrict management interface access to dedicated management networks. Audit internet-facing IoT devices regularly.
4. Lack of Encryption
Many IoT devices transmit data over unencrypted protocols — either because they predate modern encryption standards, because encryption adds computational overhead that resource-constrained devices cannot support, or because manufacturers deprioritized it during design.
This is particularly prevalent in operational technology environments, where legacy industrial protocols such as Modbus, DNP3, and BACnet were designed for reliability and speed in isolated networks — not for security in connected environments.
When IoT device communications are unencrypted, an attacker with access to the network segment can capture, read, and in some cases modify device traffic without detection. This enables both passive intelligence gathering and active manipulation of device commands — a particularly serious risk in environments where IoT devices control physical systems.
How attackers exploit it: Network sniffing and traffic interception, man-in-the-middle attacks, replay attacks against unencrypted command traffic.
Compensating controls: Enforce encrypted communication protocols where device capability allows. For legacy devices that cannot support encryption, apply strict network segmentation to limit exposure. Monitor for unexpected communication patterns on OT protocol traffic.
5. Insecure Update Mechanisms
Even where IoT manufacturers provide firmware updates, the update mechanism itself can introduce vulnerabilities.
Common weaknesses include:
Firmware updates delivered over unencrypted channels, allowing interception and substitution
No cryptographic verification of update integrity or authenticity, allowing malicious firmware to be installed
Update processes that expose the device to attack during the update window
Reliance on vendor-controlled cloud infrastructure for update delivery, creating a supply chain dependency
An attacker who can intercept or manipulate the firmware update process can install malicious code on the device — achieving persistent access that survives reboots and routine maintenance.
How attackers exploit it: Man-in-the-middle attacks against unencrypted update channels, distribution of malicious firmware through compromised vendor infrastructure, exploitation of unsigned update acceptance.
Compensating controls: Prefer devices that use cryptographically signed firmware updates delivered over encrypted channels. Monitor update processes and validate firmware integrity where tooling supports it.
6. Physical Security Weaknesses
IoT devices are frequently deployed in physically accessible locations — corridors, plant rooms, external walls, remote sites — where they can be physically tampered with by an attacker with physical access.
Physical attacks against IoT devices can include:
Connecting to exposed debug interfaces (UART, JTAG) to extract firmware or gain privileged access
Removing and cloning storage media to analyze firmware or extract credentials
Replacing legitimate devices with compromised hardware
Power cycling devices to trigger insecure boot sequences
Physical security is often overlooked in IoT security programs, particularly for devices in operational or facilities environments where access control is less rigorous than in data center settings.
How attackers exploit it: Direct hardware access via debug interfaces, firmware extraction from physical storage, device substitution, exploitation of insecure boot processes.
Compensating controls: Apply physical access controls to IoT device locations where feasible. Disable physical debug interfaces on deployed devices. Include physical device integrity in asset management processes.
7. Insufficient Authentication and Authorization
Beyond default credentials, many IoT devices implement authentication and authorization controls that are fundamentally inadequate — or absent entirely.
Common weaknesses include:
Single-factor authentication with no support for multi-factor mechanisms
No session management, allowing session tokens to be captured and reused
Overly permissive authorization models where all authenticated users have administrative access
API endpoints that accept commands without any authentication
Hard-coded credentials embedded in firmware that cannot be changed
These weaknesses mean that even when default credentials have been changed, the authentication model itself may be trivially bypassed.
How attackers exploit it: Session token theft and replay, exploitation of unauthenticated API endpoints, bypass of authentication via hard-coded credentials, privilege escalation through weak authorization models.
Compensating controls: Evaluate device authentication models as part of procurement. Restrict API access to authenticated and authorized systems only. Monitor for authentication anomalies across IoT management interfaces.
8. Inadequate Logging and Monitoring Support
Many IoT devices generate little or no security-relevant log data. Where logs exist, they may not be exportable to centralized monitoring platforms, may not capture the events most relevant to security investigations, or may be stored locally in a format that is overwritten frequently.
This creates a significant challenge for security operations teams. When an IoT device is compromised, the absence of log data can make it impossible to determine how the breach occurred, what the attacker did, or what other systems may have been affected.
The monitoring gap extends beyond individual devices. Because IoT devices often use proprietary or legacy protocols, traditional SIEM platforms may be unable to ingest and interpret their traffic without specialist integration work.
How attackers exploit it: Attackers exploit the monitoring gap directly — conducting activity on IoT devices with low risk of detection, using compromised devices as staging points for longer-term campaigns.
Compensating controls: Implement passive network monitoring to capture IoT device traffic at the network level, independent of device-level logging. Use OT and IoT-aware monitoring platforms capable of interpreting industrial and proprietary protocols. Integrate IoT network telemetry into broader security operations.
Learn more: What Is IoT Security? A Beginner’s Guide for Businesses
9. Supply Chain Vulnerabilities
IoT devices are complex products assembled from components, firmware, and software supplied by multiple vendors across global supply chains. Each element of that chain represents a potential point of compromise.
Supply chain attacks against IoT devices can take several forms:
- Malicious code inserted into firmware during manufacturing
- Compromised software libraries included in device firmware
- Backdoors introduced by third-party component suppliers
- Malicious updates distributed through compromised vendor infrastructure
Supply chain vulnerabilities are particularly difficult to detect because the compromise occurs before the device reaches the organization. Standard security assessments may not identify malicious code embedded at the firmware level without deep technical analysis.
How attackers exploit it: Pre-installed malware or backdoors activated after deployment, malicious firmware updates distributed through legitimate vendor channels, exploitation of compromised third-party components.
Compensating controls: Include security assessment as part of IoT device procurement. Monitor devices for unexpected communication with external infrastructure. Treat vendor update infrastructure as a potential attack vector and validate update integrity.
10. IT/OT Convergence Exposure
As IoT devices connect to corporate IT networks — either by design or as a consequence of digital transformation — the security boundaries that once isolated operational technology from IT systems erode.
This convergence creates a new class of vulnerability: pathways through which an attacker who has compromised an IT system can pivot into IoT and operational environments, or vice versa.
An attacker who gains access to a corporate network through a phishing email, for example, may be able to reach building management systems, industrial controllers, or connected operational devices — if those devices share network segments or have inadequate segmentation from corporate IT infrastructure.
How attackers exploit it: Lateral movement from IT networks into OT and IoT environments, exploitation of shared network segments, abuse of legitimate IT/OT integration pathways.
Compensating controls: Enforce strict network segmentation between IT, OT, and IoT domains. Monitor cross-boundary traffic for anomalous behavior. Apply the Purdue Model or equivalent segmentation framework as a reference architecture.
