10 The IoT Threat Landscape
Vocabulary, Surfaces, and Evidence-Bound Threat Statements
IoT threats introduction, threat review, IoT assets, attack surface, vulnerability evidence, mitigation review, residual risk
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.
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
- “The gateway could be attacked” is too broad to review: no asset, path, weakness, or evidence is named.
- “The gateway command path may accept configuration changes without action-level authorization for the operator role” is reviewable.
- A threat is not the same as the actor: naming “an attacker” does not identify a local weakness or a control to inspect.
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
- Name the asset. The data, command, identity, function, or record being protected.
- State the threat condition. What could go wrong for that asset, in defensive terms.
- Identify the path. The interface, route, or workflow that can reach the asset.
- Name the weakness. The local missing evidence or control, not a generic label.
- Select a control. A measure that fits the path and the named weakness.
- Attach evidence. For both accepted and denied behavior, not just the allowed case.
- Record residual risk and the retest trigger. What remains, and the change that reopens the review.
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.
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
- Starting with a control list. Controls are easier to choose after the asset, path, and weakness are clear.
- Treating actor labels as findings. “An attacker” is not a local weakness; the review still needs asset, path, control, and evidence.
- Confusing vulnerability and threat. The vulnerability is the weakness; the threat condition is what could go wrong because of it.
- Accepting diagrams as enforcement evidence. Policies, logs, tests, and state records show whether a boundary is enforced.
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
- An IoT threat is a condition that could harm an asset; a useful threat statement names the asset, path, weakness, control, and evidence.
- Keep threat, vulnerability, and mitigation distinct: the condition, the local weakness, and the measure plus its evidence.
- Trace each note with the review lens: asset, condition, path, weakness, control, evidence, residual risk, retest trigger.
- Threat surfaces span device, network and gateway, application and data, and operations.
- Attack categories and vulnerability classes are prompts for where to look, not finished findings.
- A note without residual risk and a retest trigger silently expires when the system changes.
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.