Your smart thermostat, your baby monitor and the CCTV camera above your front door are all part of the same story. Every one of them is a small computer with a network connection, and most of them were built to be cheap and easy to set up, not secure. That trade-off is exactly what creates IoT device vulnerabilities: the specific weaknesses in hardware, software and network design that let attackers take over a device, steal the data flowing through it, or use it as a launchpad for something bigger.
In October 2025, a botnet built almost entirely from hijacked routers and DVRs pushed over 20 terabits of traffic in a single attack, and the devices involved were never designed with security as a priority. IoT vulnerabilities like these rarely start as one dramatic hack; they usually start with a password nobody bothered to change. This guide walks through the vulnerabilities in IoT devices that make attacks like this possible, the UK and EU laws now forcing manufacturers to close them, and the practical steps that work even when a device can never be patched.
Table of Contents
Understanding IoT Device Vulnerabilities: Why Connected Devices Break the Rules
Standard IT security assumes you can install an agent, run regular patches, and monitor a device from a central dashboard. Most IoT devices break every one of those assumptions, which is why the same vulnerabilities keep resurfacing across smart cameras, routers, industrial sensors, and connected medical equipment.
The Hardware and Software Constraints Behind Every Weak Device
Many IoT devices run on stripped-down operating systems such as embedded Linux or FreeRTOS, chosen because they fit onto cheap, low-power chips. That efficiency comes at a cost: there is often no spare memory for a dedicated security chip, no room for strong encryption libraries, and no support for the antivirus or endpoint detection software that protects a laptop. A security camera cannot run the same defences as a work PC, so it has to rely entirely on how well it was designed in the first place.
The Attack Surface Most Guides Ignore: APIs and the Cloud
Most articles on this topic focus on the physical gadget, but the device itself is rarely where the real damage happens. The mobile app, the cloud dashboard and the API that connects them are usually softer targets, and a flaw in any one of them can expose every device linked to that account. A broken authorisation check on a manufacturer’s cloud platform, for instance, can let one customer view or control another customer’s devices, without either device itself being compromised at all.
The Most Common IoT Device Vulnerabilities Right Now
Before looking at fixes, it helps to see where the real risk sits. The table below summarises the vulnerabilities covered in this guide, and the sections that follow explain how each one is actually exploited.
| Vulnerability | Typical Risk Level | Where It Usually Shows Up |
|---|---|---|
| Default or hardcoded passwords | Critical | Routers, IP cameras, DVRs |
| Insecure firmware updates | High | Smart hubs, industrial sensors |
| Exposed network services | High | Routers, NAS devices, printers |
| Insecure cloud and mobile APIs | High | Manufacturer apps and dashboards |
| Weak or missing encryption | Medium to High | Wearables, smart locks, trackers |
| Poor visibility and monitoring | Medium | Enterprise and industrial fleets |
Default and Hardcoded Passwords
This is still the single biggest reason IoT devices get compromised. Manufacturers ship thousands of units with the same username and password baked into the firmware, and attackers simply scan the internet for open device ports and try the known defaults. The Aisuru botnet, which drove some of the largest DDoS attacks ever recorded in late 2025, grew by exploiting exactly this weakness alongside an unpatched flaw in consumer DVRs, eventually compromising an estimated one to four million devices.
Once a device is hijacked this way, it can be folded into a botnet, used to pivot deeper into a home or business network, or simply left running as a quiet foothold. Changing the default password on setup and refusing to buy devices that cannot be given a unique one remains the single most effective fix available to any user.
Insecure Firmware and Update Mechanisms
A device that cannot be safely updated is a device that stays vulnerable forever, and this is one of the most persistent IoT device vulnerabilities in the entire product lifecycle. Some manufacturers skip cryptographic signing on firmware files entirely, which means an attacker who can intercept the update process can push a modified file straight onto the device. Others simply stop issuing updates a year or two after launch, leaving known flaws unpatched for the rest of the product’s working life. Anyone buying connected hardware should check how long the manufacturer commits to providing updates before the device is discontinued.
Exposed Network Services and Cleartext Protocols
Many devices ship with unnecessary ports left open, including old, unencrypted protocols such as Telnet or plain HTTP for remote administration. Combined with automatic port-forwarding features like UPnP, a device sitting quietly on a home network can end up directly reachable from the open internet without the owner ever realising it. Closing unused ports, disabling UPnP on the router, and insisting on encrypted management interfaces remove a huge share of this exposure in one move.
Insecure Cloud and Mobile APIs
The device itself might be well designed, and still get compromised through the systems that manage it. Broken authorisation on a cloud API, weak session handling in a mobile app, or a poorly secured message broker such as MQTT can all let an attacker reach devices without ever touching the hardware. This is the part of the guide most competitor content skips entirely, yet independent research consistently points to the API and cloud layer, not the physical chip, as the source of the majority of real-world IoT breaches.
Weak or Missing Encryption
Data moving between a device, an app, and the cloud is sometimes sent with weak encryption or none at all, and it is one of the quieter IoT device vulnerabilities because nothing about the device looks broken from the outside. That matters more than it sounds: location trackers, health wearables and smart locks all transmit information that reveals patterns about a person’s daily life, and unencrypted traffic can be intercepted by anyone on the same network. Confirming that a device uses properly implemented, modern encryption rather than a proprietary or outdated cipher is one of the easier checks a buyer can make before purchase.
Poor Visibility and Monitoring
Most organisations cannot install a security agent on a smart camera or industrial sensor, which means these devices are frequently invisible to standard monitoring tools. A compromised device can sit on a network for months, quietly exfiltrating data or waiting for instructions, without triggering a single alert. This is where machine learning-based network monitoring has become genuinely useful, since it can flag unusual traffic patterns from a device even when no traditional agent is available to report on it.
Insecure Physical Interfaces and Hardware Debug Ports
This one gets far less attention than it deserves. Many devices ship with exposed UART or JTAG debug ports on the internal circuit board, left over from the manufacturing and testing process. Anyone with brief physical access and a cheap logic analyser can use these ports to pull a root shell straight off the hardware, bypassing every software protection the device has.
This matters most in shared or semi-public settings, such as smart locks on rented properties or connected equipment in communal buildings, where physical access to the device itself cannot be ruled out. Manufacturers who disable or physically remove debug interfaces before shipping a consumer product close off this route entirely, and it is a fair question to ask a vendor before buying anything designed to sit somewhere you do not fully control.
The Legislative Shift: PSTI, the Cyber Resilience Act, and What Changes This Month
For years, closing IoT device vulnerabilities depended entirely on manufacturers choosing to do the right thing voluntarily. That has now changed on both sides of the Channel, and the timing could not be more relevant.
The UK’s Product Security and Telecommunications Infrastructure Act came into force on 29 April 2024, making the UK the first country in the world to ban default passwords on consumer smart devices by law. Manufacturers, importers and distributors must now provide unique passwords, publish a point of contact for reporting vulnerabilities, and disclose how long a device will keep receiving security updates. Non-compliance carries fines of up to ten million pounds or four per cent of global turnover.
A government-commissioned review of the market found that only 52% of manufacturers had removed default passwords from every product line, only 58% had published a public contact point for vulnerability reports, and just 27% had committed to a clear security update period across their whole range. Enforcement clearly still has real work to do. For the current requirements, see NCSC guidance on the PSTI Act.
The financial stakes behind all of this are considerable. IBM’s 2025 Cost of a Data Breach Report put the global average cost of a breach at 4.44 million US dollars, with the UK figure sitting close to 3.29 million pounds. A single hijacked IoT device rarely causes a breach of that scale on its own, but it is frequently the entry point that leads to one, which is exactly the scenario the PSTI Act and the wider push against ransomware attacks are designed to prevent.
The European Union’s Cyber Resilience Act is moving on a similar but later timeline, and one of its most demanding obligations lands on 11 September 2026, just days from now. From that date, any manufacturer placing a connected product on the EU market must report actively exploited vulnerabilities within twenty-four hours of becoming aware of them, submit a fuller notification within seventy-two hours, and file a final report once a fix exists. This applies even to products that shipped years before the law existed. Full conformity requirements, including CE marking, follow in December 2027, but the reporting clock starts now.
How to Secure IoT Devices You Cannot Patch
Consumer advice usually stops at “keep your firmware updated”, but that is close to useless for the industrial sensors, building systems and connected medical devices that cannot be patched without voiding a certification or causing downtime. A plan that works without patching matters just as much.
Passive Discovery and Network Segmentation
The first step in managing IoT device vulnerabilities at scale is knowing what is actually connected. Passive network scanning can identify every IoT device on a network without sending traffic that might crash a fragile industrial sensor, which active scanning sometimes does. Once every device is mapped, placing it on its own isolated network segment, separate from laptops, servers, and payment systems, limits the damage a single compromised device can cause. This is standard practice in healthcare IoT deployments, where connected infusion pumps and monitors frequently cannot be updated without re-certification, making isolation the only realistic defence.
Virtual Patching When the Vendor Has Moved On
When a manufacturer has stopped issuing updates entirely, a firewall or intrusion prevention system placed in front of the device can block known exploit attempts before they ever reach the vulnerable code. This approach, sometimes called virtual patching, will not fix the underlying flaw, but it closes the practical window an attacker needs. Restricting outbound traffic from IoT devices to only the destinations they genuinely need also limits what a compromised device can do even if it is eventually breached, and it is one of the most overlooked controls in home and small business networks alike.
Knowing What Is Inside the Device in the First Place
A growing number of IoT vulnerabilities do not sit in code the manufacturer wrote at all, but in older open-source components buried inside the firmware, sometimes carried over unchanged from one product generation to the next. A software bill of materials, essentially an ingredient list of every component inside a device, lets a security team check instantly whether a newly disclosed flaw such as a vulnerable TCP/IP stack affects any device on their network, rather than waiting weeks for the manufacturer to confirm it.
This kind of visibility is becoming a genuine differentiator between organisations that can respond to a new threat within hours and those still trying to work out which of their devices are even affected, months later. Anyone dealing with identity theft risk from a compromised smart device will recognise the pattern: the damage almost always traces back to a component nobody was tracking.
If you manage any connected devices, whether that is a single smart camera at home or an estate of industrial sensors at work, the next step is straightforward: check who still has a default password, confirm which devices have stopped receiving updates, and put the ones that can never be patched onto their own isolated network. Most IoT device vulnerabilities are closed by these few, unglamorous checks, long before any attacker gets the chance to exploit them.
Frequently Asked Questions
These are the questions people most often ask when researching IoT device vulnerabilities, answered directly.
What is considered an IoT device vulnerability?
It is any weakness in a connected device’s hardware, software, or communication protocol that allows unauthorised access, data theft, or control. This covers everything from a hardcoded password to a flaw in the cloud service that manages the device.
Which IoT devices are most vulnerable to hacking?
Consumer routers, unbranded IP cameras and DVRs top the list of IoT device vulnerabilities in practice, largely because they are cheap, widely deployed, and rarely updated after purchase. Smart building controllers and legacy medical devices are close behind, not because they are poorly designed, but because they often cannot be patched without formal re-certification.
Why are IoT devices different from a normal laptop or server in terms of security?
They usually have no room for antivirus or endpoint detection software, cannot run modern encryption efficiently, and are often left in service for ten to fifteen years without any vendor support, long after a laptop of the same age would have been retired.
Can a vulnerability be fixed if the manufacturer has stopped supporting the device?
Yes, though not by patching the device itself. Isolating it on its own network segment, blocking exploit attempts with a firewall or intrusion prevention system, and restricting what it can connect to outbound all reduce the risk substantially, even without a single line of firmware changing.
Does the UK PSTI Act apply to devices bought before 2024?
The security requirements apply to products sold in the UK from 29 April 2024 onwards, regardless of when they were originally manufactured. Older stock already in someone’s home is not retroactively covered, but anything sold new after that date must comply.
What role does a software bill of materials play in fixing IoT vulnerabilities?
It acts as an ingredient list for a device’s firmware, listing every third-party and open-source component used to build it. When a new flaw is disclosed in a widely used component, a software bill of materials lets a security team check within minutes whether any of their devices are affected, rather than waiting on the manufacturer to confirm it weeks later.