IoT devices are everywhere now - in logistics systems, warehouses, offices, homes, hospitals, factories, and connected products of all kinds. That also means they create a broad and often messy attack surface. When these devices are weakly protected, attackers can use them to steal data, disrupt operations, join botnets, or pivot deeper into a network. NIST treats IoT risk as a distinct management problem because IoT devices often have different constraints than traditional IT assets.
IoT security is difficult because many devices are built for convenience, low cost, and fast deployment first. In practice, that can lead to weak defaults, poor update support, limited logging, insecure interfaces, and unclear ownership.
The real IoT challenge is lifecycle control. Organizations often know how to secure a laptop or server, but they may not know who owns a camera, sensor, gateway, or controller after it has been installed.
This article explains what IoT device vulnerabilities are, where the risks usually live, which weaknesses appear most often, how to assess IoT security, and which controls actually reduce exposure.
IoT Device Vulnerabilities Explained
IoT device vulnerabilities are weaknesses in the device, firmware, communication channel, cloud service, API, mobile app, or deployment process that attackers can exploit to gain control, steal data, disrupt operations, or move deeper into a network. This can be anything, including weak access credentials, outdated firmware, or insecure ecosystem interfaces (such as APIs).
These vulnerabilities provide an entry point for attackers to take control of the IoT device. Let’s say an IP camera retains the default password from the vendor. An attacker can easily figure out the password and gain control of this device.
Once they have control, they can either:
- Use it to view live feeds or access what is in the camera’s local storage.
- Use it to recruit other devices within the network to form a botnet. Then use this network of compromised devices to launch a DDoS attack.
- Use this access as a stepping stone to break into the network the camera is connected to.
A similar pattern appeared in 2016, when attackers used Mirai malware to infect IoT devices such as routers, IP cameras, and DVRs. This was done to create a massive botnet (the Mirai botnet, which was later associated with large DDoS attacks against targets including OVH, KrebsOnSecurity, and Dyn).
This is why IoT risk is not limited to the device itself. A weak device can become a path into the wider network. Securing these devices isn’t easy. One reason is that IoT devices are often deployed at scale, with different vendors, firmware versions, interfaces, and ownership models. That makes it difficult to know which devices are exposed, supported, patched, and properly configured.
Why IoT Devices Are Often Vulnerable
Many IoT devices are resource-constrained. They may have limited CPU power, memory, storage, or local security functionality, which makes it harder to support strong logging, modern update workflows, robust authentication options, or other protective features that are common on laptops and servers. NIST SP 800-213A exists specifically because organizations need to define which cybersecurity capabilities an IoT device should have before adopting it.
That is only part of the problem. The other part is operational. Some vendors do not provide updates for long enough. Some devices ship with default credentials. Some are deployed quickly without proper inventory or ownership records. CISA notes that default passwords remain a basic but persistent IoT security problem, and NIST guidance emphasizes that organizations should think about device cybersecurity requirements before purchase and deployment.
So it is not really correct to say that every IoT device is insecure by default. The better point is that many IoT devices are deployed in ways that create predictable risk, and many organizations still do not manage that risk well enough.
IoT Security Before Purchase
IoT security should start before procurement, not after deployment. Before buying or adopting a device, teams should ask whether the vendor supports security updates, unique credentials, secure configuration, logging, vulnerability disclosure, data protection, and secure decommissioning.
NIST SP 800-213A provides a catalog of IoT device cybersecurity capabilities and supporting capabilities that organizations can use to define these requirements before adoption.
Where IoT Security Risk Lives
IoT device risks live everywhere the IoT device touches. This includes the IoT device itself, communication channels, and the ecosystem interfaces.
| Layer | Common weakness | What to check first |
|---|---|---|
| Device hardware | Exposed debug ports, removable storage, physical tampering | Physical access, tamper evidence, debug interfaces |
| Firmware | Outdated components, hardcoded secrets, insecure boot | Update support, firmware source, known CVEs |
| Network | Weak Wi-Fi, exposed services, poor segmentation | Network isolation, encryption, open ports |
| Cloud and APIs | Broken access control, weak tokens, insecure storage | Auth, authorization, rate limiting, API exposure |
| Mobile or web app | Insecure local storage, weak session handling | Token storage, TLS, input validation |
| Operations | No owner, no update process, no logs | Inventory, ownership, lifecycle plan |
Risks in the IoT device itself
Security risks in IoT devices themselves stem from their design limitations, as mentioned earlier. The firmware could be using outdated components because the device lacks the memory needed to download a new patch. Or the vendor simply doesn’t provide patches anymore.
Patchable vulnerabilities will go unremediated. Because of this, an attacker can find them and use them to compromise the IoT device. Physical access can create additional risk. With IoT devices, there are physical security risks, for instance, easily accessible flash memory chips that an attacker can use to extract sensitive data from the device.
Risks in the IoT device network and communication channels
Another set of risks lies in the network connecting the devices to each other and to the internet. Wireless protocols such as Wi-Fi, Bluetooth, Zigbee, Z-Wave, and LoRaWAN each have their own security model and failure modes.
The practical question is whether the protocol is configured securely, whether encryption is used correctly, and whether the device can be reached by unauthorized users nearby or over the network. Alternatively, networks without encryption (like open Wi-Fi) can allow attackers to intercept traffic.
Risks in the ecosystem interfaces (cloud/backend APIs and apps)
Cloud services and APIs that collect, process, or store IoT data can also introduce risk. If any of them lack strong authentication or fail to filter input properly, they can be entry points for attackers to get to the IoT devices.
We use mobile apps to set up and control IoT devices. Like any other mobile app, these apps can have security flaws, for instance, if they don’t encrypt data stored or in transit. This means the data sent by the device can be intercepted.
The bottom line is that security risks can exist anywhere in the IoT ecosystem. Any one of the components we’ve covered can have vulnerabilities. Because of this, there are so many vulnerabilities to think about when dealing with IoT security.
Common IoT Device Vulnerabilities
Despite there being so many varieties of vulnerabilities, some are more common and persist more than others. Let’s go over the most common IoT device vulnerabilities.
Weak, guessable, or hardcoded credentials
Some devices still ship with default, weak, or shared credentials, and many deployments fail to replace them with unique credentials. CISA warns that default passwords are easy to find online and should be changed as part of basic IoT security. Attackers often start by trying default or commonly used credentials, especially when devices are exposed to the internet.
Why does this keep happening? Some IoT manufacturers prioritize convenience and fast setup over stronger default security. They want customers to be able to set them up so they don’t get frustrated easily. In short, manufacturers continue to ship IoT devices with weak credentials, and customers often fail to update these passwords.
Unpatched or outdated firmware
Many IoT devices run old firmware versions that never get updated. This may be down to the device not having enough resources to support regular updates or the manufacturer failing to release patches for older firmware. As a result, known flaws may remain unpatched for months or years. As a result, attackers always have an open door to the device.
Insecure data transfer and storage
Sensitive data, like keys or Wi-Fi credentials, may be stored unencrypted in an IoT device’s flash memory. Or the data collected by a device, let’s say an IP camera, can be sent to your cloud storage over HTTP instead of HTTPS.
This happens because many of these devices lack secure storage chips or encryption modules due to their resource constraints. The few resources available are maximized for performance.
Insecure ecosystem interfaces
Vulnerabilities don’t have to necessarily be in the IoT device itself to affect it. They can be in the services and applications outside the device, but the device needs them to work. For instance:
- The backend APIs - API security is complex, and developers may fail to implement things like rate limiting or authentication tokens properly. This causes the APIs to be susceptible to SQLi, XSS attacks, etc.
- The web interfaces - local web portals may have common security flaws. For instance, a web portal that doesn’t verify the origin of a request is prone to cross-site request forgery (CSRF).
The IoT ecosystem is complex (device → gateway → cloud → mobile app), and flaws in one of these interdependent components affect the entire system.
Many IoT incidents are ecosystem failures rather than single-device failures. A secure device can still create risk if the API, cloud storage, mobile app, or access model around it is weak.
Physical access vulnerabilities
Physical access can also create risk when devices have exposed USB ports, accessible debug interfaces, or unprotected memory chips. If attackers can access your IoT devices easily, they can install malware or manipulate hardware components.
There are many more vulnerabilities, but these are the most common ones. These vulnerabilities have led to several real-world security incidents.
Real-World IoT Security Incidents
The Mirai Botnet Attack in 2016 is the most infamous IoT security incident because of its scale and how it directly impacted the internet. But it’s not the only one. There have been others, such as:
St. Jude Medical’s hackable cardiac devices
In 2016, a security research firm, MedSec, discovered vulnerabilities in St. Jude Medical’s defibrillators and pacemakers. This was later confirmed by the FDA in 2017. The issue was that these devices had vulnerabilities in their transmitters (the part that sends patient data to doctors).
The reported vulnerabilities could allow unauthorized access to the transmitter and, in some scenarios, affect connected implantable cardiac devices. Luckily, St. Jude Medical (later acquired by Abbott Laboratories) released a patch to fix this before attackers could take advantage.
Jeep Cherokee remote hacking (2015)
A group of security researchers demonstrated that they could hack the Jeep Cherokee and take control of it remotely. There was a software vulnerability in the Uconnect system that allowed remote access. The Uconnect system provides a touch screen interface for entertainment, communication, etc.
Because it wasn’t properly isolated from the vehicle’s critical control systems, the researchers demonstrated that you could go as far as cutting the transmission. Fortunately, Jeep recalled the affected vehicles (1.4 million) and fixed this issue.
Infrastructure IoT risks in medical devices and ATMs (2022)
Researchers from CyberMDX (acquired by the IoT security firm Forescout) found 7 easily exploitable vulnerabilities in PTC Axeda, dubbed Access:7. PTC Axeda is a remote connectivity tool for industrial IoT. The platform is popular in medical equipment, but some companies have used it in ATMs and vending machines.
The vulnerabilities could allow attackers to execute code, access sensitive data, or alter configurations on affected devices. Since then, the researchers have worked with PTC to help them release patches to remediate this issue.
Apart from the Mirai Botnet incident, most of these were solved before attackers used them to cause significant damage. Does this mean that all IoT devices today are free from vulnerabilities? Quite the contrary. New vulnerabilities continue to appear regularly. This is why it’s important to assess your IoT network vulnerabilities.
Assessing IoT Security
IoT security assessments aren’t just about testing the IoT device itself. You’ll need to examine the entire ecosystem, including the device, the app/API controlling it, and the cloud infrastructure where data is stored or processed.
TopScan helps address the external and cloud-facing part of this problem, not the entire IoT security lifecycle. It can continuously scan internet-exposed web control panels, APIs, and related cloud services, correlate findings with CVE and CVSS data, and help teams prioritize remediation. Device procurement, physical security, firmware assurance, and secure decommissioning still need internal process controls.
Device security assessment
Start by first discovering all your IoT devices, then assessing their hardware and firmware. With hardware, you assess mainly for physical tampering.
Check the debug ports. Have the tamper seals or stickers been removed? Are there any scratched pads or fresh solder marks? This is a great first step if you want to find out if the firmware has been extracted.
With firmware, on the other hand, there’s a bit more to check.
- Check if the bootloader’s messages have been modified. This could be a sign that the debug port has been tampered with.
- Most organizations do not need to reverse engineer firmware themselves during a standard assessment. Basic checks include identifying the device model, firmware version, update status, exposed services, default credentials, network segment, and vendor support status. Advanced firmware analysis, binary review, and hardware debugging should be handled by specialists when the device is high-risk or business-critical.
- For high-risk devices, specialists may also extract or obtain firmware images, unpack them, and review components for known vulnerabilities.
Application and API assessment
Use tools such as Burp Suite or OWASP ZAP to intercept and analyze the traffic between the device, application, and the cloud. Here, you can check if the data in transit is encrypted. Then check if sensitive data stored (passwords and session tokens) is unencrypted in the app’s local storage.
Test the API endpoints for weaknesses such as broken access control. This way, you can confirm that users can only access their devices, plus data, and not those of others. Finally, perform an input validation in the app’s input fields (for example, by attempting to inject XSS code) to see if it sanitizes user input.
Cloud and infrastructure assessment
Here’s what you check in the cloud where the IoT’s data is stored and processed:
- Are roles and permissions defined correctly for not just users alone but also for devices and services?
- Is data in storage buckets encrypted? How is it backed up and disposed of when not needed? Dive deeper into this in our Cloud Data Security guide.
- Are the storage buckets configured to prevent exposing them to the public?
- Are events monitored for anomalies or unauthorized access?
- And more.
| Assessment area | What is assessed |
|---|---|
| IoT Device | Port tampering, firmware extraction or modification. |
| Application and API | Broken access control, input validation, and other OWASP Top 10 risks. |
| Cloud and infrastructure | Access permissions and privileges, encryption for data at rest, storage bucket configuration, and related security controls. |
By assessing your IoT ecosystem, you’ll understand where the risks live. The next natural step is to strengthen your defenses. Let’s look at how to do this by mitigating vulnerabilities.
Mitigating IoT Vulnerabilities
Hardening reduces IoT risk by removing unnecessary exposure and strengthening the controls that remain. It involves putting security controls in place that make it tougher for the IoT device or network to be compromised.
A practical mitigation plan:
- Find all IoT devices and assign owners.
- Remove default credentials and unnecessary services.
- Segment IoT devices from workstations and critical systems.
- Update firmware or retire unsupported devices.
- Review API, cloud, and mobile app security.
- Monitor device behavior and external exposure.
- Document how devices are retired.
Here are some of the things you can do to harden your IoT device.
Keep firmware up-to-date
Outdated firmware is one of the leading causes of IoT exploits. These versions usually have vulnerabilities that attackers can target. It’s important to keep firmware up-to-date because vendors release patches that fix known vulnerabilities.
- Enable automatic updates where possible; otherwise, conduct them manually. It’s best to do this automatically because with manual updates, you risk falling behind.
- Only install firmware from trusted vendor sources and not anywhere else.
What if the vendor no longer supports or patches the IoT device? Consider retiring it.
Retirement should be planned, not improvised. Before decommissioning an IoT device, teams should remove it from cloud accounts, revoke tokens and certificates, wipe stored data where possible, update asset inventory, and remove firewall or network rules that were created for it.
Your manufacturer should allow you to retire devices either physically or via the mobile app.
Strengthen authentication
Authentication should protect device access, admin interfaces, cloud accounts, and supporting services. Start by changing the default credentials the devices ship with.
- Make the password as long and complex as the system allows you to.
- Since you won’t be able to type it in from memory all the time, store passwords in a password vault.
- If supported, enable multi-factor authentication.
Rotate credentials when there is a suspected compromise, staff or vendor access changes, or the device lifecycle requires it. For IoT, unique credentials, secure storage, access control, and removal of default passwords usually matter more than arbitrary calendar-based rotation.
Encrypt data where it matters
Encrypted data prevents attackers from making sense of it if they intercept it. Use modern encrypted transport for communication between devices, applications, and cloud services, and follow vendor and regulatory requirements for the environment. For many systems, this means TLS 1.2 or higher, but exact requirements may depend on device constraints, protocol, and industry. Also, encrypt data stored in the app or in the cloud.
Apply least privilege
This means disabling any unnecessary functions that widen the attack surface. In other words, ensuring only the right resources have access and are turned on. Here’s an example.
For example, if a device does not need remote administration from the internet, that feature should be disabled or restricted. Probably not. But, if you grant it, understand that you’ve created an extra attack surface. If you aren’t getting enough value from a feature, it would be best to turn it off.
Segment and isolate the IoT network
There’s a limit to what you can do to secure the IoT device due to its design limitations. Fortunately, segmentation can limit the damage if one device is compromised. One way to do this is to segment and isolate the IoT network.
When a device cannot be hardened enough, the network has to carry more of the security burden. Segmentation, allowlisting, monitoring, and strict outbound rules can reduce the blast radius if the device is compromised.
Place IoT devices in a dedicated VLAN or isolated subnet. Place IoT devices on a dedicated VLAN or isolated subnet, separate from workstations and servers. The separate network will still be behind a firewall, but if a device gets compromised, an attacker can’t reach other entities in the network.
Monitor and respond continuously
Even the most secure devices can fail, but if you monitor them, you can catch these issues and fix them early.
- Enable centralized logging and alerting across all IoT devices and connected systems.
- Use intrusion detection systems to detect anomalies in the IoT ecosystem.
Then have an incident response plan, which you’ll implement if you detect anomalies.
Some IoT devices (or those from specific manufacturers) may lack the resources that allow you to implement these security controls. Before adding an IoT device, check if they have these capabilities. NIST SP 800-213A is a requirement catalog that you can refer to as you decide what to look for in an IoT device.
Retire Unsupported Devices Safely
Unsupported IoT devices should not remain in the environment without a clear risk decision. If a vendor no longer provides firmware updates, security patches, documentation, or support, the device becomes harder to protect over time. Even if it still works, known vulnerabilities may remain open, and new weaknesses may never be fixed.
The safest option is usually replacement or planned retirement. Before removing the device, teams should identify what it connects to, which accounts or cloud services it uses, what data it stores, and whether any business process still depends on it. This prevents accidental outages and helps avoid leaving behind forgotten access paths.
A safe retirement process should include several steps: remove the device from cloud accounts, revoke tokens and certificates, wipe local data where possible, delete unused firewall rules, update the asset inventory, and confirm that monitoring no longer expects traffic from that device. If the device cannot be removed immediately, restrict its network access, disable unnecessary services, and assign an owner with a replacement deadline.
Retirement is part of IoT security because unsupported devices often become invisible risk. A device that was safe enough five years ago may no longer match current security expectations, especially if it is exposed to the internet, connected to sensitive systems, or controlled through outdated software.
