Identify Common IoT Security Threats and Privacy Risks
Before you can secure a system, you must understand what you are defending against. This lesson introduces the CIA triad, surveys the most common IoT attack types, provides a structured risk assessment method, and explains the privacy obligations that apply to IoT systems in Rwanda.
The CIA Triad — Foundational Security Framework
| Property | Meaning | IoT example |
|---|---|---|
| Confidentiality | Data is accessible only to authorised parties. Unauthorised parties cannot read or intercept it. | Encrypting sensor data in transit (TLS). Protecting access tokens. Patient health data visible only to clinicians. |
| Integrity | Data has not been tampered with or altered in transit or at rest. You can trust that it is authentic. | Message authentication codes on MQTT payloads. Verifying firmware signatures before OTA update. |
| Availability | The system is accessible and operational when needed. Denial of service attacks target availability. | Distributed MQTT brokers with failover. Rate limiting to prevent flood attacks. Watchdog timers on devices. |
OWASP IoT Top 10 Security Vulnerabilities
| Vulnerability | Description and examples |
|---|---|
| 1. Weak / default passwords | Shipping with ‘admin/admin’ or ‘root/root’ credentials. Millions of devices never have passwords changed. Exploited by Mirai and successor botnets. |
| 2. Insecure network services | Unnecessary open ports, Telnet access, or unencrypted management interfaces. Every open port is an attack surface. |
| 3. Insecure ecosystem interfaces | Cloud APIs with no authentication, web dashboards with weak session tokens, mobile backends that trust input without validation. |
| 4. Lack of secure update mechanism | Firmware updates delivered without signature verification. An attacker who intercepts an update can push malicious firmware. |
| 5. Insecure / outdated components | Libraries with known vulnerabilities, outdated TLS versions, or deprecated cipher suites. |
| 6. Insufficient privacy protection | Collecting more data than necessary, storing without encryption, retaining data indefinitely, no consent mechanism. |
| 7. Insecure data transfer and storage | Transmitting data over plain HTTP or MQTT (no TLS). Storing credentials in plaintext Flash memory. |
| 8. Lack of device management | No way to remotely disable a compromised device, no audit logs, no asset inventory. |
| 9. Insecure default settings | Debug interfaces enabled by default, logging verbose output including credentials, UART/JTAG accessible without authentication. |
| 10. Lack of physical hardening | Debug headers exposed, memory extractable, no tamper detection on physically accessible devices. |
IoT Threat Catalogue — Five Attack Types
Risk Assessment Matrix
Risk Score = Likelihood (1–5) × Impact (1–5) → Maximum risk = 25
Score 1–5
Low risk
Monitor but no immediate action required
Score 6–10
Medium risk
Address in next development cycle
Score 11–15
High risk
Prioritise and fix before deployment
Score 16–25
Critical risk
Must fix before any production deployment
Hospital patient monitoring node — example risk assessment:
| Threat | Likelihood (1–5) | Impact (1–5) | Risk Score | Mitigation priority |
|---|---|---|---|---|
| Credential theft (plain MQTT) | 4 | 5 | 20 | CRITICAL — implement TLS immediately |
| Man-in-the-Middle (no TLS) | 3 | 5 | 15 | HIGH — implement TLS before deployment |
| Firmware without OTA signing | 2 | 5 | 10 | HIGH — implement code signing |
| Physical device access | 2 | 4 | 8 | MEDIUM — secure enclosure |
| DoS / flood attack | 2 | 3 | 6 | MEDIUM — rate limiting on broker |
Privacy and Rwanda Law No. 058/2021 on Personal Data Protection
Rwanda’s Personal Data Protection and Privacy Law (2021) applies to any organisation processing personal data of Rwandan citizens, including IoT data. The eight core principles:
| Principle | Explanation for IoT |
|---|---|
| Lawfulness | Personal data may only be collected with a legal basis: consent, contractual necessity, legal obligation, or legitimate interest. |
| Purpose limitation | Data collected for one purpose may not be used for another. A smart meter for billing cannot share data with advertisers. |
| Data minimisation | Collect only data necessary for the stated purpose. A smart doorbell does not need facial recognition if a motion alert suffices. |
| Accuracy | Personal data must be kept accurate and up to date. Stale GPS coordinates or outdated health records can cause harm. |
| Storage limitation | Data must not be retained longer than necessary. Define a retention policy and automate deletion. |
| Security | Personal data must be protected with appropriate technical and organisational measures (encryption, access control, audit logs). |
| Accountability | Data controllers must be able to demonstrate compliance: records of what data is collected, why, and how it is protected. |
| Data subject rights | Right to access, correct, delete (‘right to be forgotten’), and object to processing of personal data. |
Privacy by Design in IoT
| Practice | Implementation |
|---|---|
| Collect minimum data | Only record what is needed. Do not log room occupancy every second if you only need daily averages. Do not collect age or gender for a temperature sensor. |
| Anonymise where possible | Replace identifiable information with pseudonyms or hashes. Store ‘device-7g3k’ not the owner’s name. |
| Define retention policy | Set automatic deletion of old telemetry. ThingsBoard and ThingSpeak both support data TTL (time-to-live) settings. |
| Notify data subjects | Inform users what data is collected, how it is used, and who it is shared with. Post a clear privacy notice. |
| Encrypt data at rest | Use server-side encryption on cloud storage. Hash and salt any authentication credentials stored in databases. |
Check Your Understanding — Lesson 8.1
You may also like
Nyereka Tech and Tumba College Explore Opportunities for Collaboration
September 25, 2026
The Launch of our IoT Innovation Hub
May 7, 2026
Partnership with MakerSpace Kigali
May 7, 2026
