IoT vulnerabilities: the common weak points

IoT vulnerabilities are weaknesses in a connected device, or in the app, cloud service and network around it, that an attacker can use to log in, take control, read data or knock the device offline. The common ones have been known for years: default and hardcoded passwords, network services left open, no secure way to update the firmware, and old software components that nobody patches. This guide walks through the OWASP IoT Top 10 list in plain words, explains why connected devices end up exposed, follows the Mirai botnet through the weaknesses it used, and shows how to look up the known vulnerabilities of a device you own. It is part of the IoT security guides, next to IoT device security basics, the owner’s checklist for fixing these weaknesses, and the guide to firmware updates, signing and rollback.

What counts as an IoT vulnerability

NIST’s glossary defines a vulnerability as a “weakness in an information system, system security procedures, internal controls, or implementation that could be exploited”. A threat is “any circumstance or event with the potential to adversely impact” an organization’s operations. Put simply, the vulnerability is the open window, and the threat is the person or the malware that might climb through it.

For a connected device, the weakness can sit in three places:

• On the device: its firmware, its passwords, the services it runs and its physical ports.
• On the network: what the device exposes to your home network and, through the router, to the internet.
• In the ecosystem: the phone app, the maker’s cloud service and the update server the device talks to.

Owners cannot fix a bug in a camera’s code, but they can remove many of the conditions that let an attacker reach it, such as a default password or an open port. Builders can fix the cause.

The OWASP IoT Top 10 (2018)

OWASP’s Internet of Things Project publishes the IoT Top 10, which it describes as the “top ten things to avoid when building, deploying or managing IoT systems”. The edition on the project page is from 2018 and replaced an earlier 2014 list. Here are the ten items under their exact names, with what each looks like on a real device and what to check.

1. I1 Weak, Guessable, or Hardcoded Passwords. OWASP means credentials that are easy to brute-force, publicly available or impossible to change, “including backdoors in firmware”. On a real device this is a camera whose admin password is printed in a manual anyone can download, or a hidden support account the owner cannot remove. Owners change every password and look for extra accounts; builders give each unit its own password or make the user set one.
2. I2 Insecure Network Services. Unneeded or insecure services running on the device, “especially those exposed to the internet”. A telnet server left on from development, or a web admin page that answers from outside the home, fits here. Owners can port-scan the device, as the security basics guide describes, and check the router for port forwards and UPnP mappings. Builders ship with unused services off.
3. I3 Insecure Ecosystem Interfaces. Weak web, backend API, cloud or mobile interfaces outside the device. OWASP names missing authentication or authorization, weak or missing encryption, and no filtering of input and output. An example would be a cloud API that hands over a device’s data to any account that asks for it. Owners cannot audit the maker’s cloud; they can turn on two-factor sign-in and prefer devices that keep working without a cloud account. Builders check, on every request, that the caller owns the device.
4. I4 Lack of Secure Update Mechanism. No firmware validation on the device, no secure delivery, no anti-rollback protection and no notice of security changes in an update. In practice: firmware fetched over plain HTTP and installed without a signature check, or no update path at all. Owners look up the model’s update history; builders sign images and verify them on the device, as the firmware update guide explains.
5. I5 Use of Insecure or Outdated Components. Deprecated or insecure libraries, insecure customization of the operating system, and third-party parts “from a compromised supply chain”. Think of an old web server library inside the firmware. Owners cannot see inside the firmware, so the useful signal is how often updates arrive. Builders keep an inventory of components and versions and check it against known vulnerability databases.
6. I6 Insufficient Privacy Protection. Personal information on the device or in the ecosystem “used insecurely, improperly, or without permission”. A camera that uploads clips to the cloud by default is the familiar case. Owners read the privacy settings and delete stored data; builders collect less.
7. I7 Insecure Data Transfer and Storage. No encryption or access control for sensitive data at rest, in transit or during processing. A Wi-Fi password stored in plain text in flash memory is one example: factory reset a device before you sell it, and give IoT devices their own Wi-Fi password on a separate VLAN.
8. I8 Lack of Device Management. No asset management, update management, secure decommissioning, monitoring or response for devices in use. A small office with a dozen cameras and nobody who knows their firmware versions has this problem. Owners keep a device list; builders make firmware versions visible and support a full reset.
9. I9 Insecure Default Settings. Insecure settings out of the box, or no way for the owner to make them stricter. Remote access switched on by default, with no option to turn it off, is the typical form. Owners go through every settings page after setup.
10. I10 Lack of Physical Hardening. Nothing stops someone with the device in hand from pulling information that helps a later remote attack, or from taking local control. An exposed debug header on the circuit board is the usual route. Owners mount outdoor devices where they are hard to open; builders disable or lock debug interfaces.

Why IoT devices are exposed

Four things make these weaknesses common.

Default credentials. The European consumer IoT standard, ETSI EN 303 645, notes that many consumer devices are sold with universal default usernames and passwords such as “admin, admin”, and that their continued use “has been the source of many security issues in IoT”.

Long service lives with short support. NIST’s guidance for manufacturers, IR 8259 Rev. 1, says IoT products “may remain in service much longer than software or other digital components are supported”, and that homes and small businesses collect such legacy products, which are much more likely to carry vulnerabilities. The FBI made the same point about routers in a May 2025 public service announcement: routers dated 2010 or earlier likely no longer receive updates, and the TheMoon malware infects them without a password by scanning for open ports.

Shared components. OWASP’s I5 covers outdated or insecure components, including third-party software and hardware from a compromised supply chain. When one of those components has a flaw, every product that reuses it carries the flaw until its maker ships an update, which is why NIST IR 8259 Rev. 1 asks manufacturers what checks they make on the third-party software inside their products.

Exposed services and cloud dependence. Services left running (I2) and the apps and cloud APIs around a device (I3) give attackers routes that do not touch the device’s own login at all.

Mirai: how a botnet used these weaknesses

The clearest worked example is Mirai. CISA’s alert TA16-288A, “Heightened DDoS Threat Posed by Mirai and Other Botnets”, first released October 14, 2016, describes botnets as “networks of devices infected with self-propagating malware” that can carry out distributed denial-of-service (DDoS) attacks.

According to the alert, Mirai “continuously scans the Internet for vulnerable IoT devices” and uses “a short list of 62 common default usernames and passwords” to log in, over telnet on ports 23 and 2323. The devices affected were primarily home routers, network-enabled cameras and digital video recorders. On September 20, 2016 it was used against the security blog krebsonsecurity.com in an attack exceeding 620 gigabits per second, and the alert reports a claim that over 380,000 devices had been infected.

In OWASP terms, Mirai needed I2 (an exposed telnet service), I1 (passwords from a short list of common defaults) and I9 (insecure defaults that owners had left in place). It also showed the cost of weak device management: the malware lived in memory, so a reboot cleared it, but CISA warned that a device reconnected before its password was changed “could be quickly reinfected”. NIST IR 8259 Rev. 1 cites the Mirai botnet as one reason the US government issued Executive Order 13800.

CISA’s own advice in the alert matches the right-hand column: change default passwords to strong ones, install security patches as soon as they are available, and disable Universal Plug and Play on routers “unless absolutely necessary”. The IoT device security basics guide turns that into a checklist.

How vulnerabilities are tracked: CVE, NVD and KEV

Three public catalogs matter to anyone checking a device.

CVE. The CVE Program exists “to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities”, with one CVE Record for each. Records are assigned and published by partner organizations around the world, and each has an ID that lets people refer to the same flaw without confusion.

NVD. NIST maintains the National Vulnerability Database, “a repository of information on software and hardware flaws that can compromise computer security”, built on CVE records. On April 15, 2026, NIST changed how it handles entries. It now prioritizes adding details (“enrichment”) for CVEs in CISA’s catalog of exploited vulnerabilities, CVEs for software used in the federal government, and critical software as defined by Executive Order 14028. Every other CVE is still listed, marked lowest priority, and NIST no longer routinely adds its own severity score where the reporting organization already gave one, so a consumer device’s entry may carry only the details its reporter supplied.

KEV. CISA’s Known Exploited Vulnerabilities catalog is, in CISA’s words, “the authoritative source of vulnerabilities that have been exploited in the wild”. CISA says organizations should use it as an input to how they prioritize fixes. It can be searched by keyword, filtered by vendor, and downloaded as CSV or JSON.

Each vulnerability moves through the same steps, and each depends on someone different.

How to look up your own device

Repeat these steps for each device you own; they show whether a known hole is waiting to be closed.

1. Note the exact model and firmware version. They are on the label, in the app or on the device’s admin page. Vulnerabilities are usually listed against specific firmware versions, so the model name alone is not enough.
2. Check the maker’s security page. Look for security advisories, a firmware changelog with dates, and a vulnerability disclosure policy.
3. Search the KEV catalog by vendor and model. A match means attackers are already using that flaw. Install the fix now, or if there is none, take the device off the network or isolate it until you can replace it.
4. Search the NVD by vendor and model, open each entry, and compare the affected versions with yours.
5. Act on what you find. If a fix exists, install it. If the model is past its support period, follow the steps for devices that stop getting updates: contain it on the IoT network, block its internet access, or replace it.

An empty search does not prove a device is safe. The CVE Program catalogs publicly disclosed vulnerabilities, so a flaw nobody has reported is not in it, and the habits in the security basics guide still apply.

What builders should do

Two baselines describe what is expected of a device maker; the IoT security standards guide covers where they apply. ETSI EN 303 645 (version 3.1.3, September 2024) sets out its security provisions in thirteen sections, 5.1 to 5.13, after a reporting provision (5.0), with data protection in a separate clause (6). NIST IR 8259A (May 2020) defines a core baseline of six device capabilities: device identification, device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness.

The provisions that answer the OWASP items most directly:

• No universal default passwords. ETSI provision 5.1-1 requires every password, outside the factory default state, to be “unique per device or defined by the user”.
• Signed, verified updates. ETSI provision 5.3-10 requires a device that receives updates over a network to verify the authenticity and integrity of each one. NIST’s software update capability includes “the ability to verify and authenticate any update before installing it” and limits updating to authorized entities. The firmware update guide linked above explains signing and rollback.
• Secure boot. ETSI provision 5.7-1 recommends that the device “verify its software using secure boot mechanisms”.
• A vulnerability disclosure policy. ETSI provision 5.2-1 requires the manufacturer to publish one, with contact details for reporting issues and timelines for acknowledging a report and giving status updates. NIST IR 8259 Rev. 1 asks manufacturers how they accept and respond to reports of possible vulnerabilities, giving bug bounties and coordinated disclosure as examples.
• A stated support period. ETSI provision 5.3-13 requires the manufacturer to publish the defined support period in a way that is clear to the user.
• Fewer open doors. ETSI provision 5.6-1 requires unused network interfaces, and unused logical interfaces that are reachable over the network, to be disabled, and 5.6-4A requires debug interfaces to be disabled or protected by access control.

The table pairs OWASP items with the ETSI sections that address them. The pairing is this guide’s reading of the two documents; neither OWASP nor ETSI publishes it.

I3, I5, I8 and I9 touch several ETSI sections each, so they have no single row.

For the fixes on the owner’s side, work through IoT device security basics; the rest of the IoT security guides cover updates, UPnP and network separation in detail.