OWASP IoT Top 10 for Product Teams: Real-World Application

The OWASP IoT Top 10 is a useful starting frame, but its language sits one level too abstract for most product teams. “Insecure ecosystem interfaces” is a category, not an action item. Here is each one translated into what you actually do, build, or test.

I1 — Weak, Guessable, or Hardcoded Passwords

The abstract version: default credentials, hardcoded admin accounts, predictable initial passwords.

What to do:

• No shared default credentials across devices. Per-device passwords generated at manufacturing, printed on a sticker or QR code with the device.
• No hardcoded admin or service accounts in firmware. If you need a debug account, it is removed in the production build, not “documented internally.”
• No reachable network services with default passwords. Disable or password-protect every service on day one.
• Force password change on first login if the device exposes any web or shell interface.

What to test: scan the device with nmap and try the default credentials for every service that responds. Check the firmware binary for hardcoded strings that look like credentials (strings firmware.bin | grep -iE 'pass|admin|root').

I2 — Insecure Network Services

The abstract version: services running on the device that should not be reachable, or that have known vulnerabilities.

What to do:

• Disable or remove every network service that is not strictly required. No telnet, no FTP, no unauthenticated MQTT broker, no debug console.
• For services you do need, bind to specific interfaces (loopback, BLE only) and not 0.0.0.0.
• Disable unused features at compile time, not runtime — fewer attack surface even on compromised devices.

What to test: full port scan from outside the device, then from inside the device’s local network. Anything you didn’t expect to be open is a finding.

I3 — Insecure Ecosystem Interfaces

The abstract version: APIs, web admin, and cloud interfaces that aren’t hardened.

What to do:

• Mutual TLS between device and cloud — see our IoT security baseline
• API rate limiting per device certificate, not per IP
• Authenticated admin dashboards with MFA, role-based access control, and audit logging
• Input validation at every API boundary, not just at the front-end
• No undocumented endpoints — if it exists in code, it’s documented and threat-modeled

What to test: walk the OWASP API Security Top 10 against your cloud APIs. Try common API attacks — broken object-level auth, mass assignment, excessive data exposure.

I4 — Lack of Secure Update Mechanism

The abstract version: OTA updates that are unsigned, unverified, or impossible to roll back from.

What to do: the whole our OTA post — A/B partitions, signed images, rollback on failure, staged rollouts, kill switch. Sign with a key in an HSM, verify on device against a fuse-stored public key. Resume from interrupted downloads. Test power-cut during write.

What to test: try to push an unsigned image. Try to push a corrupted image. Cut power mid-update. Push a known-bad image and verify rollback. Push an image with a wrong-but-valid signature (signed by a different key).

I5 — Use of Insecure or Outdated Components

The abstract version: shipping firmware with known-vulnerable libraries.

What to do:

• Maintain an SBOM (Software Bill of Materials) for every release
• Subscribe to CVE feeds for every component you ship
• CI fails the build on critical CVEs in production dependencies
• Plan dependency upgrades quarterly, not “when something happens”

What to test: run dependency-check, npm audit, pip-audit, or equivalent. For C/C++ firmware, scan with tools like Black Duck, Snyk, or the open-source CVE Binary Tool.

I6 — Insufficient Privacy Protection

The abstract version: collecting more user data than needed, storing it indefinitely, or exposing it.

What to do:

• Data minimisation: collect only what the feature actually requires. Audit telemetry quarterly.
• Default retention period of 90 days; longer requires explicit business justification.
• No PII in logs. Hash or pseudonymise at the edge.
• Privacy-respecting analytics that don’t require cookies or fingerprinting.
• Clear opt-out for any data collection beyond what is strictly needed for the product to function.

What to test: walk a fresh-install device for an hour with a network proxy. Read every byte that leaves the device. Anything you didn’t intend is a finding.

I7 — Insecure Data Transfer and Storage

The abstract version: plaintext network traffic, unencrypted storage of sensitive data on the device.

What to do:

• TLS 1.3 (or 1.2 with modern ciphers) for every network connection. Pin certificates against a known root.
• Flash encryption enabled for any device that stores credentials or PII at rest.
• BLE LE Secure Connections, not legacy pairing.
• Encrypt PII even within the cloud database; database encryption-at-rest is necessary but not sufficient.

What to test: capture network traffic with Wireshark; verify nothing is plaintext. Pull the SPI flash off a device; verify content is encrypted. Decompile the firmware; verify no embedded keys.

I8 — Lack of Device Management

The abstract version: no way to monitor, update, decommission, or audit fleet devices in production.

What to do: full fleet observability — see our fleet observability post. Per-device certificates with rotation, revocation list, end-of-life decommissioning flow, telemetry on health and security signals.

What to test: simulate a compromised device. How long until you detect it? How quickly can you isolate it? Walk the incident playbook end-to-end at least once a year.

I9 — Insecure Default Settings

The abstract version: shipping with insecure-by-default configurations, expecting users to harden them.

What to do:

• Secure by default. Insecure options exist but require explicit opt-in.
• Network ports closed by default; services disabled by default.
• Strong cipher suites only; legacy options removed entirely.
• HTTPS-only on any web interface; HTTP redirects to HTTPS.

What to test: a fresh install with default settings should pass a basic security audit without any user configuration.

I10 — Lack of Physical Hardening

The abstract version: a device on a bench can give up its secrets to an attacker with physical tools.

What to do:

• JTAG / SWD disabled in production fuses (one-time programmable)
• Secure boot enabled
• Flash encryption enabled with per-device key
• Tamper-evident enclosures for high-value products
• See our hardware security guide for the spectrum

What to test: put a production device on a bench. Try to extract firmware. Try to read keys. Try to inject your own firmware. The bar is “expert-level effort with specialised equipment” — not “five minutes with a laptop and a clip.”

What goes in the deliverable

For every connected product engagement we ship a one-page OWASP IoT Top 10 compliance summary: each item, current status, evidence, residual risks. The document is reviewed at sign-off and again at every major release. Auditors love it. Customers’ security teams love it. Engineers don’t get asked the same question twice.

If you want a second pair of eyes on your OWASP coverage — or a focused security review before launch — we run these as fixed-scope engagements.