10 The IoT Threat Landscape
10.1 Start Simple: Protect One Doorway
Picture one device command doorway: a sensor can send readings, but only a maintainer should change a setting. A beginner-friendly threat statement names that protected command, the path that reaches it, the boundary between roles, and the evidence that proves the wrong role is denied.
Keep that doorway in mind while reading the chapter. Every term here has a job in the review record: asset says what matters, path says how it is reached, weakness says why the concern is credible, control says what should stop it, evidence says what was inspected, and residual risk says what remains outside the proof.
10.2 What an IoT Threat Statement Means
An IoT threat is a condition that could harm an asset through an unwanted action, fault, misuse path, or control gap. A useful threat statement is not a dramatic story and not a generic fear. It names what matters, how it could be affected, which boundary is involved, which control should reduce the risk, and what evidence supports the decision.
This chapter is the vocabulary entry point for the rest of the threats sequence. The stance is defensive: identify threat conditions, connect them to assets and paths, request evidence, select mitigations, and record when the decision must be retested.
For a smart-building gateway, the asset might be the configuration command that changes HVAC set points. A reviewable threat note would name the dashboard path, the operator role, the gateway boundary, and the missing proof that viewer accounts are denied change actions. The same note should name the evidence needed: an allowed maintainer action, a denied viewer action, and an audit record that records actor, action, target, and outcome.
If you only need the intuition, this layer is enough: threat review starts with an asset, describes what could go wrong for it, and stays narrow enough that another reviewer can ask for evidence and repeat the check.
The core distinction to learn first is between three terms that beginners often merge. "Unauthorized command" is a threat condition (what could go wrong). "Command authorization is only checked at login" is a vulnerability (the local weakness). "Action-level authorization with denied-command logs" is a mitigation and its evidence. Keeping these separate is what makes a threat note reviewable.
Figure 10.1 applies those words to one heating system. The asset is the command that changes the heating, ventilation, and air-conditioning (HVAC) set point. The threat is an unauthorized change. The weakness is checking a person’s role only when they log in. The control checks that role again for each change. The evidence includes one allowed change, one denied change, and a log of both results.
Read the figure from CONCRETE REVIEW · SMART-BUILDING GATEWAY to Authorize every change action. Then follow the path through the evidence and remaining risk. The final label, or authorization code changes, is a reason to test again. This ordered path keeps the asset, threat, weakness, control, evidence, remaining risk, and retest rule separate.
The Threat Vocabulary
Asset and path
The asset is the data, command, identity, function, update path, or record being protected. The path is the interface, route, or workflow that can reach it.
Condition and weakness
The threat condition is what could go wrong for the asset. The vulnerability is the local weakness that makes the condition credible.
Control and evidence
The control is the preventive, detective, corrective, or recovery measure. The evidence supports or weakens the control claim, with residual risk and a retest trigger.
Beginner Examples
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
Overview Knowledge Check
If you can tell a threat, a vulnerability, and a mitigation apart, you can stop here. Continue to Practitioner to write reviewable threat statements across IoT surfaces.
10.3 Write Reviewable Threat Statements
A threat introduction should help you ask reviewable questions. Start with the asset and trace outward using a repeatable lens, then write statements that another reviewer can check with evidence.
A practical statement has enough nouns to be assigned and retested. "Telemetry may be altered" is still too broad. "The gateway may forward temperature readings from an unenrolled sensor identity to the dispatch service" names the asset, path, identity condition, and affected decision. From there the reviewer can ask for enrollment records, route policy, accepted-message evidence, denied-message evidence, and the change that would reopen the check.
Walkthrough: The Review Lens
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
Common IoT Threat Surfaces
IoT threats cross device, network, application, and operations boundaries. Treat each surface as a place to ask evidence questions.
Work one surface at a time so the note does not collapse into a vague system warning. At the device surface, ask which identity and firmware state are accepted. At the gateway surface, ask which topic, route, or command path is allowed and which case is denied. At the application surface, ask which role can view, export, or change data. At the operations surface, ask which support, override, recovery, or update path can change the outcome.
Device surface
Which identity proves the device is expected? Which firmware or configuration state is accepted? Which local access paths are disabled, restricted, logged, or monitored?
Network and gateway surface
Which identity is checked at each boundary? Which route, topic, or API is allowed? Which publish or command attempt is denied, and which logs prove the decision?
Application and data surface
Which data is sensitive or personal? Which role can view, export, or change it? Which validation, retention, or access evidence supports the claim?
Operations surface
Who can enroll, revoke, update, restore, isolate, or retire a device? Which approval, monitoring, and recovery records support the action?
Weak Statement Versus Reviewable Statement
Weak
"The gateway could be attacked." No asset, path, weakness, control, or evidence. A reviewer has nothing to inspect.
Reviewable
"The gateway command path may accept configuration changes without evidence of action-level authorization for the operator role." Names path, action, missing evidence, and property.
The green “Reviewable” example names a missing authorization decision, but the claim still needs evidence categories. Inspect Figure 10.2 to connect that sentence to the records that would support or reject it.
Within Figure 10.2, Identity is evidenced by enroll and revoke records, while Authorization requires both allow and deny results. Monitoring needs a signal and owner, Recovery needs restored state, and Retest names the change proof that reopens the claim. That pairing turns the operator-role concern into a bounded evidence request instead of a generic security warning.
Worked Introductory Review
A building gateway forwards telemetry and accepts configuration changes from an operator dashboard.
Practitioner Knowledge Check
If you can turn a broad concern into a narrow, evidence-bound note, you can stop here. Continue to Under the Hood for attack categories and vulnerability classes.
10.4 Attack Categories and Vulnerability Classes
The deeper layer adds the category prompts and weakness classes that keep a review systematic. Use them to decide where to look for evidence, not as the final finding. A local asset, path, weakness, evidence source, and mitigation are still required.
A useful category-to-finding transition has three steps. First, use the category as a prompt: for example, tampering asks whether data, commands, firmware, configuration, or logs can be changed without approval. Second, bind the prompt to a local path, such as a gateway configuration API. Third, request evidence for that path: allowed role, denied role, signed or validated state, audit outcome, owner, and retest trigger.
Attack Categories
Attack categories name the security property at risk. They align with the STRIDE prompts used later in the sequence.
Different taxonomies slice the same review space in different ways. STRIDE starts from broken security properties. Open threat taxonomy style lists often group threats by source or mechanism, such as physical damage, resource failure, personnel action, and technical compromise. IoT-focused ENISA-style taxonomies make that list easier to navigate for connected devices by separating device, network, cloud, data, privacy, and operational impacts. Treat the taxonomy as a checklist prompt, then still write the local evidence-bound finding.
- Spoofing: an identity, device, service, or message source may not be trustworthy.
- Tampering: data, commands, firmware, configuration, or logs may be changed without approval.
- Repudiation: events may not be attributable to the right device, account, service, or process.
- Information disclosure: sensitive data may be exposed through transport, storage, logs, APIs, or physical access.
- Service disruption: devices, gateways, networks, or cloud workflows may become unavailable.
- Privilege escalation: a low-permission identity or component may gain a stronger role.
Vulnerability Classes
Vulnerability classes describe the local weakness that makes a threat condition credible. The same class can appear at different IoT layers; keep each finding tied to the local system and path.
Evidence quality matters here. Direct evidence comes from the reviewed system, such as an enrollment record, denied-command log, rejected-message trace, update verification result, or recovery drill record. Indirect evidence, such as an architecture diagram or policy statement, can explain intent but should not close the finding by itself. Missing direct evidence is often the finding, especially when the control claim depends on a boundary actually denying the unwanted case.
Identity and authorization
Shared credentials, unclear device identity, telemetry identities that can request actions, or roles that reach management paths outside their scope.
Exposure
Management, debug, broker, or API interfaces reachable outside their intended boundary.
Update and dependency
Update signing, install state, or rollback behavior that is untested, and components that lack ownership or version evidence.
Data handling and monitoring
Sensitive data over-collected, logged needlessly, or sent unprotected; relevant events not logged or alerts not reviewed.
Control and Evidence Map
Threat review should map findings to evidence, not only to control names. Each control class has a matching evidence requirement.
Residual Risk and Retest Discipline
Residual risk is what remains after the decision: what is still possible, why it is accepted for now, who owns it, and what change reopens the review. Retest triggers exist because identities, routes, commands, update paths, data handling, and monitoring rules all change over time. A threat note without a retest trigger silently expires.
Common Mistakes
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter's evidence-led review sequence.
Under-the-Hood Knowledge Check
At this depth, an introductory threat note is a small evidence record: asset, condition, path, weakness, control, evidence, residual risk, and retest trigger. The category and class prompts keep it systematic, but the finding is only as strong as the local evidence behind it.
10.5 Summary
Taken together, these checks make the section reviewable. That order prevents a control name from being treated as proof and connects the visual to the chapter’s evidence-led review sequence.
Threat introduction work teaches learners to ask what can go wrong, who or what can cause it, what the impact is, and which evidence supports the mitigation, kept narrow enough that another reviewer can repeat the check.
10.6 See Also
Threat Modelling and Mitigation
Expand introductory notes into full threat models with mitigation and evidence records.
Threats STRIDE Framework
Use category-based prompts to find threats systematically across each path.
Cyber Security Defense in Depth
See how independent controls support one another once threats are named.