Connected devices keep failing in the same ten ways, and the OWASP IoT Top 10 is still the shortest shared list for naming them. The current edition is the 2018 list from the OWASP Internet of Things Project, which OWASP still lists as active with no newer edition announced as of November 2026. Its age matters less than it seems: the same issues sit at the heart of the UK PSTI regime, ETSI EN 303 645 and the EU Cyber Resilience Act. This page takes each item, I1 to I10, and splits the fix into what the manufacturer does in firmware and what the operator does across the fleet. It is for product security teams, firmware engineers and the people who buy and run IoT estates. For the full IoT programme, protocols and segmentation, see the IoT Security Guide.
The Top 10 at a glance
| ID | OWASP name | Fix in firmware (manufacturer) | Fix in the fleet (operator) |
|---|---|---|---|
| I1 | Weak, Guessable, or Hardcoded Passwords | Unique per-device credentials, no backdoor accounts | Change or rotate on enrolment; scan for defaults |
| I2 | Insecure Network Services | Ship with unneeded services off | Port scans, segmentation, no direct internet exposure |
| I3 | Insecure Ecosystem Interfaces | Authenticated, authorised cloud APIs and apps | MFA on the management portal; review API tokens |
| I4 | Lack of Secure Update Mechanism | Signed, verified updates with anti-rollback | Track update status per device; set update windows |
| I5 | Use of Insecure or Outdated Components | SBOM, component patching, supplier checks | Ask for SBOMs; retire devices at end of support |
| I6 | Insufficient Privacy Protection | Minimise collected personal data; consent | Data protection impact assessment before deployment |
| I7 | Insecure Data Transfer and Storage | TLS, encrypted secrets storage | Verify encryption; protect gateways and backends |
| I8 | Lack of Device Management | Support remote management and telemetry | Inventory, monitoring, decommissioning process |
| I9 | Insecure Default Settings | Secure by default; hardening options available | Baseline configuration applied at onboarding |
| I10 | Lack of Physical Hardening | Disable debug ports; secure boot; protected key storage | Physical placement and tamper checks |
Names are exactly as OWASP publishes them. The fix columns are NHI Mgmt Group's summary, not OWASP text.
1. Weak, Guessable, or Hardcoded Passwords
OWASP describes I1 as easily brute-forced, publicly available or unchangeable credentials, including backdoors in firmware or client software. This is the Mirai lesson: default credentials on internet-facing devices built botnets at scale (see the Mirai and IoT Botnet Families Guide).
- Firmware: the UK PSTI regime, in force since 29 April 2024, requires passwords to be unique per product or set by the user, and not based on incremental counters, public information or product identifiers such as serial numbers (unless generated with an accepted encryption method or keyed hashing algorithm), or be otherwise easily guessable. ETSI EN 303 645 provision 5.1 is "No universal default passwords". Remove maintenance and debug accounts from production builds.
- Fleet: treat each device credential as a non-human identity: owner, purpose, rotation date. Prefer certificate-based device identity over passwords. See the Identity for IoT Fleets Guide.
2. Insecure Network Services
Unneeded or insecure services on the device, especially those exposed to the internet, that compromise confidentiality, integrity or availability or allow unauthorised remote control.
- Firmware: ship Telnet, UPnP, debug HTTP servers and unused protocols off; ETSI provision 5.6 is "Minimize exposed attack surfaces".
- Fleet: scan device subnets for open ports at onboarding and regularly; put devices in their own segment and block inbound internet access.
3. Insecure Ecosystem Interfaces
Insecure web, backend API, cloud or mobile interfaces outside the device. An attacker who controls the cloud account or API controls every device behind it.
- Firmware and cloud: enforce object-level authorisation on device APIs so one account cannot read another customer's devices; apply the OWASP API Security Top 10 to the backend.
- Fleet: enforce MFA and single sign-on on the vendor management portal, and inventory API tokens and integrations that can command devices. See Securing the IoT device management platform itself.
4. Lack of Secure Update Mechanism
OWASP lists missing firmware validation, unencrypted delivery, missing anti-rollback and missing notification of security changes.
- Firmware: sign images, verify signatures in the bootloader, enforce anti-rollback and protect signing keys in an HSM. See the IoT Secure Firmware Update Guide (SUIT, signed OTA).
- Fleet: report firmware version per device, set a target time to patch, and alert on devices that stop checking in. PSTI requires manufacturers to publish a minimum security update support period with an end date; record it at purchase.
5. Use of Insecure or Outdated Components
Deprecated or insecure software components and libraries, insecure operating system customisations, and third-party hardware or software from a compromised supply chain.
- Firmware: maintain an SBOM and hardware bill of materials, and track vulnerabilities in the embedded OS, libraries and modules. See the Hardware and Firmware SBOM Guide.
- Fleet: make an SBOM and a support end date procurement requirements; plan replacement before end of support.
6. Insufficient Privacy Protection
Personal information stored on the device or in the ecosystem used insecurely, improperly or without permission.
- Firmware: collect only what the function needs and give users a way to delete their data (ETSI provision 5.11).
- Fleet: run a data protection impact assessment before deploying cameras, wearables or occupancy sensors, and set retention for device data.
7. Insecure Data Transfer and Storage
Lack of encryption or access control for sensitive data anywhere in the ecosystem: at rest, in transit or during processing.
- Firmware: TLS with certificate validation to the backend; store keys and credentials in a secure element or TPM rather than flash. See the IoT Device Identity with TPM and DICE Guide.
- Fleet: verify on a sample device that traffic is encrypted and that gateways and brokers (for example MQTT) require authentication.
8. Lack of Device Management
No security support for devices in production: asset management, update management, secure decommissioning, systems monitoring and response.
- Firmware: expose device identity, configuration and security state to management tools. NIST IR 8259A lists device identification and cybersecurity state awareness among its core baseline capabilities. See the NIST IR 8259 IoT Device Cybersecurity Baseline Guide.
- Fleet: keep an inventory with owner, location, firmware and support date; send device logs to monitoring; wipe and revoke credentials at decommissioning.
9. Insecure Default Settings
Devices shipped with insecure defaults, or operators unable to make the system more secure by restricting configuration.
- Firmware: secure by default (remote access off, encryption on) and document the hardening options.
- Fleet: apply a written configuration baseline at onboarding and check for drift. See the IoT Device Onboarding Guide.
10. Lack of Physical Hardening
Lack of physical hardening that lets attackers extract sensitive information useful in a later remote attack, or take local control of the device.
- Firmware and hardware: disable or lock JTAG and UART in production, enable secure boot and flash encryption, and keep per-device secrets so one opened device does not expose the fleet.
- Fleet: place devices out of reach where possible, use tamper-evident enclosures in public areas, and revoke the credential of any device found tampered with.
Mapping to frameworks
| OWASP IoT | ETSI EN 303 645 provision | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| I1 | 5.1 No universal default passwords | PR.AA-01 | IA-5 Authenticator Management |
| I2 | 5.6 Minimize exposed attack surfaces | PR.PS-01 | CM-7 Least Functionality |
| I3 | 5.5 Communicate securely | PR.AA-03 | SC-8 Transmission Confidentiality and Integrity |
| I4 | 5.3 Keep software updated; 5.7 Ensure software integrity | PR.PS-02 | SI-2 Flaw Remediation; SI-7 Software, Firmware, and Information Integrity |
| I5 | 5.3 Keep software updated | ID.RA-01 | SA-22 Unsupported System Components; SR-11 Component Authenticity |
| I6 | 5.8 Ensure that personal data is secure; 5.11 deletion | PR.DS-01 | PT-2 Authority to Process PII |
| I7 | 5.4 Securely store sensitive security parameters; 5.5 | PR.DS-01, PR.DS-02 | SC-8; SC-28 Protection of Information at Rest |
| I8 | 5.10 Examine system telemetry data | ID.AM-08, PR.PS-04 | CM-8 System Component Inventory |
| I9 | 5.12 Make installation and maintenance easy | PR.PS-01 | CM-6 Configuration Settings |
| I10 | 5.4 Securely store sensitive security parameters | PR.PS-03 | PE-3 Physical Access Control |
ETSI provision titles are from EN 303 645 V3.1.3 (2024-09). The mapping is ours, at a judgement level. For the EU regime see the EU Cyber Resilience Act Guide, and for UK law the UK PSTI Act Product Security Guide.
Where to start
- Manufacturers: close I1 and I4 first. Unique credentials and signed updates are legal requirements or close to it in the UK and EU, and they decide whether every other fix can be delivered.
- Operators: build the inventory (I8) before anything else; you cannot rotate credentials or patch devices you have not found.
- Both: segment and scan (I2, I9), then make SBOMs and support dates procurement conditions (I5). The IoT Device Procurement Security Checklist turns this into buying questions.
- Measure: track devices with default or shared credentials (target zero), devices on supported firmware, median days to deploy a security update, devices with exposed management services, and inventory coverage against network discovery.
Standards and references
- OWASP: Internet of Things Project and IoT Top 10 2018
- ETSI: EN 303 645 V3.1.3 Cyber Security for Consumer Internet of Things
- GOV.UK: The UK Product Security and Telecommunications Infrastructure (Product Security) regime
- NIST: IR 8259A IoT Device Cybersecurity Capability Core Baseline
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: IoT Security Guide · ETSI EN 303 645 Consumer IoT Guide · Device and IoT Identity Guide · IoT Product Security Maturity Model