Which areas does a "secure IoT" curriculum have to cover, and why is security only one of them?

Architectures, devices, connectivity, protocols, programming, security, intelligence and applications — eight areas, because securing an IoT system requires understanding the system you are securing.

* The eight areas form a design checklist: security depends on the architecture, hardware, protocols and applications around it. *

The eight areas usually drawn as a ring around the subject:

1. IoT system architectures — systems and software architectures.
2. IoT devices, boards, sensors — the latest devices, platforms, development boards, sensors and IDEs.
3. IoT connectivity and networking — connectivity and interoperability.
4. IoT protocols and interfaces — protocols and cloud-based interfaces.
5. IoT flow-based programming — visual programming environments for wiring IoT together, and data visualisation.
6. IoT security — end-to-end: device ↔ gateway ↔ cloud.
7. IoT intelligence — intelligent techniques for data fusion and IoT data analysis.
8. IoT apps and services — real-world applications and services.

Security is item 6 of 8, and that placement is the lesson rather than a slight. Most IoT vulnerabilities are not failures of cryptography — they are consequences of the other seven areas: a protocol chosen for cheapness that has no authentication (3, 4), a development board shipped with a default password (2), an architecture that puts a trusted gateway where an untrusted one is (1), an analytics pipeline that aggregates data into something far more sensitive than any single reading (7).

The corresponding practical objectives are to build secure IoT systems, to conduct end-to-end attacks and assessments that demonstrate the vulnerabilities, to work within resource-constrained settings, and to recommend threat-mitigation measures that reduce the risk.

Tip: the ring is a useful audit checklist for a real deployment — walk it once and ask which of the eight areas your design has actually thought about. The unexamined one is usually where the incident comes from.

Go deeper:

• RFC 7452 — Architectural considerations — connects deployment lifetime, interoperability, protocol reuse and privacy decisions.