25 Common IoT Security Mistakes

25.1 Start With The First Security Review

Match the Installed Build to the Security Claim

Picture a device labeled patched while its update record names no installed version. Firmware means the software stored on a device that controls its operation.

Name the claim, expected build, installed build, update proof, owner, and retest trigger. Check a current device, an older device, a failed update, and a record that lacks identity.

Keep version evidence, verification result, correction, time, and follow-up rule. This proves one update claim, not total security; the deeper sections turn common credential, boundary, update, debug, and logging mistakes into testable evidence gaps.

Imagine reviewing a device that has a strong security label on the box but no proof behind the label. The password was never rotated, the management page is reachable from the sensor network, or the update record says “patched” without showing the build that actually installed. The mistake is the gap between the claim and the evidence.

This chapter treats common mistakes as reviewable gaps rather than blame. For each mistake, ask what claim the team is making, what evidence should exist, what correction narrows the gap, and what retest keeps it from returning. In everyday IoT work, that means checking credentials, boundaries, update paths, debug access, logs, and test records before trusting the release story. Start simple by turning one vague concern into a claim, evidence, gap, correction, and retest trigger.

25.2 Overview: Mistakes Are Evidence Gaps

Most IoT security mistakes are not exotic. They are ordinary gaps between a security claim and the evidence that should support it. A device may claim to be protected while still sharing credentials, accepting management traffic from the wrong place, running unverified firmware, recording secrets in logs, or depending on a security label that was never tested.

The practical review question is simple: what claim is being made, what evidence proves it, and what correction closes the gap? Writing a mistake as an evidence gap, rather than as "weak security," makes it possible to fix and to retest.

This framing also avoids overcorrection. If the evidence gap is shared credentials, the fix is identity provisioning and revocation evidence, not a vague rewrite of the whole security plan. If the gap is exposed management access, the fix is a management boundary and denied-path proof, not a claim that every network path is now safe.

Think of a "Beware of Dog" sign on a gate with no dog behind it. The sign is the claim; the dog, the lock, the camera, or the fence is the evidence. An attacker tests the evidence, not the sign. Many IoT mistakes are signs with nothing behind them: "encrypted," "segmented," "hardened," with no record that the control is actually present.

The decision in Overview: Mistakes Are Evidence Gaps becomes concrete only when the review flow: a claim is checked against evidence, classified as a gap when evidence is missing, corrected, and retested. Pause at Figure 25.1: its labels turn that requirement into something the reader can test.

In Figure 25.1, begin with protected, check Retest next, and finish at useful, not secret. Those named elements make the claim concrete rather than merely directional. Their relationship shows the review flow: a claim is checked against evidence, classified as a gap when evidence is missing, corrected, and retested; that evidence is what Overview: Mistakes Are Evidence Gaps contributes to the chapter’s running decision.

The One-Minute View

Beginner Examples

Overview Knowledge Check

If you can frame a mistake as an evidence gap, you can stop here. Continue to Practitioner for the recurring mistakes and their corrections.

25.3 Practitioner: Six Recurring Mistakes and Their Corrections

Each recurring mistake is easiest to fix when written with the same pattern: the claim, the evidence observed, the gap, the scoped correction, and the trigger that makes the evidence stale.

Use that pattern before choosing a control, because the same symptom can have different causes in provisioning, routing, update, logging, or ownership.

Walkthrough: Correcting Without Overclaiming

Begin with one testable claim, such as “devices have distinct identities,” and collect the configuration, traffic, update, access-policy, or log evidence that bears on it. Name the gap between that claim and the observation before selecting a correction. Then record both the event that should trigger a retest and the boundary of what the new evidence proves. This order keeps a local repair from becoming an unsupported statement about the whole system.

Figure 25.2 matters here because it turns that review method into five concrete claim-to-evidence pairs. Use it to check whether a proposed correction produces evidence for the particular mistake, rather than merely adding a control whose name sounds reassuring.

Across the top of Figure 25.2, the Review record fixes the reasoning order as claim, evidence, gap, correction. Now move down the pairs: Shared credentials must yield Identity ownership records, while Flat reachability calls for Flow policy evidence. The later rows keep the same discipline—Exposed management is tested with Admin boundary logs, and Sensitive logging with Redaction and access. Those mappings prepare the six-mistake ledger below: each correction must leave observable evidence and a defensible retest boundary.

The Six Mistakes

Worked Review Record

An environmental monitoring deployment has sensors, a gateway, an application service, and an operations console. The design record says devices are hardened.

Practitioner Knowledge Check

If you can correct each mistake as a scoped evidence gap, you can stop here. Continue to Under the Hood for why these mistakes recur and the hardware paths often missed.

25.4 Under the Hood: Why These Mistakes Recur

The deeper layer explains the mechanism behind each recurring mistake, including the hardware-access path that purely network-focused reviews tend to miss.

Default Credentials and Identity

A shared or default secret is the clearest evidence gap because it breaks three claims at once: accountability (you cannot tell which device or operator acted), containment (you cannot revoke one identity without affecting the others), and rotation (one change ripples across unrelated devices). The correction is not "use better passwords"; it is distinct identities per device, service, and operator path, first-use setup that replaces factory defaults before operation, and authentication logs that name the actor rather than a shared account.

The Mirai botnet is the practical warning behind this rule. Devices that were reachable on the network with unchanged factory credentials became easy recruits for large-scale distributed denial-of-service traffic. The review lesson is concrete: prove default credentials are removed, remote access is constrained, and failed login or scanning behavior leaves evidence before the device joins a real network.

Once a credential exists, its strength is also a claim that needs evidence, not an assumption. A weak or reused secret is exploitable through offline methods that need no further network access at all: brute-force guessing across the keyspace, a dictionary attack against known or previously leaked words and phrases, and, if a password hash is ever exposed through a log, backup, or extracted storage, a lookup against a precomputed table of hash-to-plaintext pairs. None of that matters if credential storage and policy are reviewed with real evidence: hashes stored with a slow, salted algorithm rather than a fast general-purpose hash or plaintext; a length policy that favors long passphrases over forced complexity rules; a lockout or rate limit on repeated failures; and, where the device or app class supports it, a second factor beyond something the user knows. A policy that states only "strong passwords required," with none of this evidence, is an unverified claim in the same sense as an unproven "encrypted" label further down this chapter.

Unencrypted Transport and Untested "Encrypted" Claims

"Traffic is encrypted" is a claim that needs session or configuration evidence. Many IoT protocols can run in a plaintext mode by default, so a design that assumes encryption without checking the negotiated session may be sending telemetry or credentials in the clear. The review should confirm which protocol mode is actually in use, whether peers are authenticated as part of the session, and whether fallback to an unprotected mode is possible. An "encrypted" label without this evidence is an unverified claim.

No Real Update Mechanism

"Update supported" is not the same as a reviewable update claim. The system must be able to prove which software or firmware state is installed, verify the package before installation, define rollback or recovery for a failed install, and run post-update checks. If the method cannot prove which state is installed, it cannot support a security claim about that state, which quietly undermines every later patch.

The failure mode is not only an unpatched device. A bad update can also brick equipment if rollout targeting, model compatibility, and recovery are not checked. The LockState smart-lock incident is a useful review example: an update path that sends the wrong build to the wrong lock model turns "patching" into an availability failure, so the update evidence must include targeting, staged rollout, health checks, and a recovery path.

Exposed Debug Interfaces

Hardware debug interfaces are a frequent blind spot for reviews that only look at the network. A serial console (UART) or a chip debug and boundary-scan interface (JTAG) left enabled on a shipped device can give someone with local access a console, memory access, or the ability to read firmware and secrets, bypassing network controls entirely. The defensive review records whether these interfaces are disabled, locked, or protected for the shipped build, whether manufacturing-test access is removed, and what the design assumes about who can physically touch the device. State the assumption and the control; do not publish extraction procedures.

The surrounding explanation becomes actionable when its components can be followed. Figure 25.3 provides that route for Exposed Debug Interfaces, showing how a JTAG probe connects directly to a target board’s debug header, as this AVR setup shows. The same legitimate engineering path becomes a shipped-device exposure when the interface remains enabled and unprotected. Photo: Martin Guy, CC BY-SA 3.0.

In Figure 25.3, the black AVR programmer is connected by a grey ribbon cable to the board debug header. That physical chain is the point: a tool intended for legitimate programming reaches the target below the network stack. The image therefore returns Exposed Debug Interfaces to its production question—whether that same header is disabled, authenticated, or otherwise proven inaccessible on shipped hardware.

Sensitive Logging and Denied Events

Logs are evidence, but they become a mistake when they record credentials, tokens, keys, or sensitive payloads, usually introduced during debugging and left in place. Good logging names the event, identity, device, boundary, decision, and result, avoids secrets, and has access controls and retention appropriate to its content. It should also include denied logins, blocked flows, failed verification, and rejected commands, because denied events are positive evidence that a control is enforcing its boundary.

Common Review Mistakes

Under-the-Hood Knowledge Check

At this depth, common mistakes are recurring evidence gaps with known mechanisms: shared identity, unverified encryption, unprovable update state, exposed debug access, and unsafe logging. Each is corrected by a scoped control change, proven by evidence including denied events, and reopened by a named retest trigger.