Security, Privacy and Safety

Introduction

The Internet of Things (IoT) connects sensors, actuators, embedded controllers, communication networks, cloud platforms and user applications. This connectivity creates useful services—such as smart energy management, industrial monitoring, healthcare assistance and connected transport—but it also creates security, privacy and safety risks. A weakness in a small device can provide an attacker with access to a home network, production system or sensitive database.

IoT security is concerned with protecting devices, communications, software, data and services from unauthorized access, alteration, disruption and misuse. Privacy focuses on the proper collection, use, sharing, retention and deletion of information about people. Safety focuses on preventing physical injury, environmental damage or unsafe operation, including failures caused by cyberattacks.

These concerns overlap but are not identical. A stolen password is primarily a security problem; excessive collection of location data is a privacy problem; a compromised industrial actuator that opens a valve incorrectly is a safety problem. Professional IoT development therefore treats security, privacy and safety as lifecycle requirements rather than features added at the end.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Identify threats at the device, network, platform and application layers.
2. Explain secure boot, device identity, authentication, authorization and encryption.
3. Describe practical key-management and signed-update processes.
4. Apply network segmentation and defense-in-depth principles.
5. Conduct a basic IoT risk assessment and privacy assessment.
6. Distinguish security incidents from privacy incidents and safety hazards.
7. Recommend appropriate controls for a small IoT deployment.

1. The IoT Security Problem

A conventional computer is usually a relatively powerful device with a user interface, regular patching and a stable power supply. IoT devices may be inexpensive, physically exposed, battery powered, difficult to update and deployed for ten or more years. They may also use proprietary protocols, have limited memory and be managed remotely at large scale.

An IoT system commonly contains four interacting layers:

The layers are dependent. Strong cloud authentication cannot compensate for a device that accepts unsigned firmware. Encrypted communication cannot prevent an authorized but malicious application from sending an unsafe command. Security must therefore be considered end to end.

Security objectives

The traditional security objectives are confidentiality, integrity and availability, often called the CIA triad.

• Confidentiality means that information is available only to authorized parties.
• Integrity means that data, commands and software are not altered improperly.
• Availability means that authorized users and systems can access services when required.

IoT systems also require authenticity, accountability, resilience and safety. Authenticity establishes that a device, server, message or user is genuine. Accountability provides records that allow actions to be traced. Resilience is the ability to continue or safely degrade during failures or attacks. Safety requires that the system avoid unacceptable physical consequences.

2. Threats Across the IoT Architecture

2.1 Device-layer threats

Devices can be attacked through software, hardware or their physical environment. Common threats include:

• Default, shared or hard-coded passwords.
• Debug ports such as JTAG or UART left enabled.
• Unencrypted credentials stored in flash memory.
• Insecure firmware-update mechanisms.
• Buffer overflows, command injection and unsafe input handling.
• Malicious replacement of firmware or boot components.
• Sensor spoofing, in which false physical measurements are introduced.
• Physical theft, probing or extraction of cryptographic keys.
• Battery exhaustion caused by repeated connection requests.

A device should not automatically be trusted merely because it is inside a building. Physical access may be possible to meters, cameras, gateways or environmental sensors, especially in public or industrial locations.

2.2 Network-layer threats

Network attacks target communication links and the routing infrastructure. Eavesdropping exposes sensitive data. Man-in-the-middle attacks intercept and potentially alter traffic between a device and its service. Replay attacks resend a previously valid command, such as an old unlock instruction. Spoofing occurs when an attacker pretends to be a legitimate device or server. Denial-of-service attacks consume bandwidth, processing capacity or battery power.

Controls include mutual authentication, encryption in transit, message freshness mechanisms, secure routing, rate limiting and network segmentation. Encryption alone does not establish who is communicating; identity verification is also required.

2.3 Platform-layer threats

IoT platforms often contain device registries, telemetry stores, dashboards, message brokers and administration APIs. Important threats include exposed management interfaces, insecure APIs, excessive administrator privileges, weak tenant isolation, vulnerable dependencies and poorly protected backups. A platform compromise can affect thousands of devices simultaneously.

Cloud security is a shared responsibility. The service provider may secure the underlying infrastructure, while the IoT operator remains responsible for identities, configurations, application code, data access and device credentials.

2.4 Application-layer threats

Applications may expose web dashboards, mobile applications and APIs. Typical weaknesses include broken access control, insecure direct object references, injection, cross-site scripting, weak session management and inadequate validation of commands. An application should verify not only whether a user is authenticated, but also whether that user is authorized to perform a particular operation on a particular device.

A temperature-monitoring user may be allowed to read data but not change calibration. A maintenance engineer may be permitted to restart a device but not modify its identity or firmware policy. Authorization must reflect least privilege and business context.

3. Threat Modelling and Risk Assessment

Threat modelling is a structured process for identifying what must be protected, how it may be attacked and which controls are justified. A basic process is:

1. Define system boundaries and information flows.
2. Identify assets and their owners.
3. Identify threats, vulnerabilities and possible consequences.
4. Estimate likelihood and impact.
5. Select controls and assign responsibilities.
6. Test controls and review residual risk.

Useful asset categories include personal data, device credentials, firmware, operational commands, safety functions, service availability and audit records. A data-flow diagram should show devices, gateways, networks, cloud services, users and external interfaces.

A simple qualitative risk model is:

Likelihood and impact may be assigned ordinal values such as 1 to 5. This multiplication is a prioritization aid, not a scientifically precise probability calculation. It assumes that the chosen scales are defined consistently and that the organization accepts the limitations of combining ordinal scores numerically. For example, a likelihood score of 4 and an impact score of 5 produce a priority score of 20. The result does not mean a 20 percent probability.

A risk register should record the asset, threat, vulnerability, likelihood, impact, existing controls, proposed treatment, owner and review date. Risk treatment may involve reducing, transferring, avoiding or accepting risk. Safety-related risks normally require stricter treatment than minor confidentiality risks because physical consequences may be severe.

STRIDE as a threat-modelling aid

STRIDE categorizes threats as:

• Spoofing identity.
• Tampering with data or software.
• Repudiation of actions.
• Information disclosure.
• Denial of service.
• Elevation of privilege.

STRIDE is useful for discovering threats, but it does not replace detailed safety analysis, privacy analysis or penetration testing.

4. Essential Security Controls

4.1 Secure boot and trusted execution

Secure boot creates a chain of trust from an immutable or protected hardware root to the bootloader, operating system and application firmware. Each stage verifies the digital signature or cryptographic measurement of the next stage before execution. If verification fails, the device should refuse to run the untrusted image or enter a controlled recovery mode.

A digital signature provides authenticity and integrity: the producer signs a firmware image with a private key, and the device verifies it using a trusted public key. Encryption of firmware is a separate matter. It may protect intellectual property or confidentiality, but encrypted firmware that is not authenticated can still be maliciously modified unless integrity protection is provided.

Secure boot is not a complete solution. The trusted key must be protected, rollback to vulnerable firmware should be prevented where appropriate, recovery procedures must be safe, and vulnerabilities in signed software can still be exploited.

4.2 Identity, authentication and authorization

A device identity is a unique, manageable representation of a device. It may be based on a certificate, a hardware-protected key, a secure element or another cryptographic credential. Factory-wide shared passwords are weak because compromise of one device can compromise every device.

• Identification claims an identity, such as a device identifier.
• Authentication verifies that claim.
• Authorization decides what the authenticated entity may do.
• Accounting records relevant actions.

Authentication factors include something known, something possessed and something inherent. For devices, possession of a private cryptographic key is commonly used. Mutual TLS, for example, allows both client and server to authenticate certificates and then establish an encrypted session.

Authorization should follow least privilege, deny by default and separate duties. A sensor should not possess administrative rights. A gateway should have only the permissions needed to forward approved messages. Administrative accounts should use multi-factor authentication where practical.

4.3 Encryption and integrity protection

Encryption in transit protects data moving across networks. Encryption at rest protects stored data in devices, gateways, databases and backups. Authenticated encryption provides confidentiality together with detection of unauthorized modification. Transport protocols such as TLS should be configured with current, secure versions and validated certificates.

Passwords and long-term secrets must not be stored as plain text. User passwords should be processed with a deliberately slow, salted password-hashing function. Cryptographic keys should not be reused for unrelated purposes. Random numbers used for keys, nonces or tokens must come from an appropriate cryptographic random-number source.

Encryption has operational requirements: certificate renewal, key rotation, clock management, failure handling and recovery. An expired certificate can interrupt a service; an incorrectly implemented exception can lead to insecure fallback behavior.

4.4 Key management

Key management includes generation, provisioning, storage, distribution, rotation, revocation, backup and destruction. A sound process separates duties and limits access to private keys. Device-specific keys are preferable to one shared fleet key. Hardware security modules or secure elements can make extraction more difficult.

A practical lifecycle is:

1. Generate a unique device key in a controlled manufacturing or provisioning process.
2. Bind the public identity to an approved device record.
3. Store the private key in protected hardware when feasible.
4. Use the key only for defined operations.
5. Monitor certificate or credential status.
6. Rotate or revoke credentials when compromise, replacement or end of life occurs.
7. Erase secrets securely during decommissioning.

Key recovery must be designed carefully. A universal recovery key may simplify operations but creates a high-value target. Emergency access should be logged, restricted and tested.

4.5 Signed updates and vulnerability management

IoT products need a supported update mechanism throughout their expected life. Update packages should be digitally signed, verified before installation and delivered through authenticated channels. The system should check version numbers to prevent unauthorized rollback to a vulnerable version. Updates should be atomic or use a fallback partition so that power loss does not permanently disable a device.

Organizations should maintain an asset inventory, monitor vulnerability advisories, define patch timelines and communicate end-of-support dates. If a device cannot be patched, compensating controls such as isolation, restricted access or replacement may be required.

4.6 Network segmentation

Segmentation limits the movement of an attacker. An organization might place consumer devices, industrial controllers, administrative workstations, guest devices and databases in separate network segments. Firewalls and access-control lists should allow only necessary flows.

Segmentation is not the same as simply using different IP ranges. Effective segmentation requires enforced policy, monitoring and protection against bypass paths such as unmanaged wireless bridges. A gateway can mediate communication between a constrained device network and a cloud service, reducing direct exposure.

5. Privacy in IoT Systems

IoT devices can collect location, audio, video, health, occupancy, behavioral and operational data. Even data that appears harmless may become sensitive when combined with other sources. Privacy protection begins with purpose specification and data minimization.

Important privacy principles include:

• Collect only data necessary for a defined purpose.
• Inform people clearly about collection and use.
• Obtain consent where required and provide lawful alternatives where applicable.
• Restrict secondary use and sharing.
• Keep data accurate and allow correction where appropriate.
• Retain data only as long as justified.
• Protect data throughout its lifecycle.
• Support access, deletion or other rights required by applicable law.
• Assess risks to individuals, not merely risks to databases.

A privacy impact assessment should identify data subjects, data elements, collection points, purposes, recipients, international transfers, retention periods and possible harms. It should also document controls such as access restrictions, aggregation, pseudonymization, encryption and deletion processes.

Pseudonymization replaces direct identifiers but does not make data anonymous if re-identification remains reasonably possible. Anonymization is a stronger claim and must be evaluated against the available data and realistic re-identification methods.

Privacy notices should be understandable. A camera system in a college should explain what is recorded, why it is recorded, how long it is retained and who may access it. Covert or excessive monitoring can damage trust even where technically lawful.

Applicable legal requirements vary by jurisdiction and sector. Examples include data-protection, consumer-protection, telecommunications, health, workplace-monitoring and critical-infrastructure rules. Organizations should obtain appropriate legal and regulatory advice rather than assuming that one framework applies everywhere.

6. Safety and Secure Operation

Cybersecurity and functional safety must be coordinated. A malicious command, corrupted sensor value or unavailable network can create a hazardous condition. Safety engineering commonly uses hazard identification, risk reduction, fail-safe design, independent protective functions and testing.

Examples of safety controls include:

• Local limits that prevent an actuator from exceeding safe values.
• Manual emergency stops independent of cloud connectivity.
• Watchdogs that place equipment in a safe state after software failure.
• Sensor plausibility checks and redundant measurements.
• Safe defaults during loss of communication.
• Separation between safety-critical and non-critical networks.
• Human confirmation for high-consequence commands.

A system should not assume that a cloud service will always be available. If a connected door lock loses communication, its failure behavior must be defined. If a medical monitor loses connectivity, it may need to continue local alarms rather than silently stop reporting.

Security controls can also create safety risks. For example, an overly aggressive lockout policy may prevent authorized emergency access. Security and safety teams should test these interactions through failure scenarios and exercises.

7. Incident Response and Monitoring

An IoT incident-response plan should define preparation, detection, analysis, containment, eradication, recovery and lessons learned. Preparation includes asset inventories, contact lists, backups, logging and playbooks. Detection may use unusual login alerts, abnormal traffic, repeated failed updates or implausible sensor readings.

Logs should record time, device identity, action, result and relevant network or user context while avoiding unnecessary personal data. Time synchronization is important for correlating events, but systems should handle inaccurate clocks safely.

Containment may involve revoking a certificate, isolating a device group, blocking a command path or switching equipment to manual control. Recovery should include validation that firmware, credentials and configurations are trustworthy. Organizations must also consider notification duties when personal data or regulated systems are affected.

8. Illustrative Case: Connected Cold-Storage Facility

Background

A food distributor installs wireless temperature sensors, gateway computers and a cloud dashboard across a cold-storage facility. Supervisors receive alerts when temperatures exceed limits, while maintenance staff can update gateway software remotely.

Problem

An assessment discovers that all sensors use the same factory password, the gateway accepts commands from the general office network and updates are downloaded without signature verification. Temperature data is retained indefinitely and the dashboard gives every employee access to all facilities.

Analysis

The shared password creates device impersonation risk. Network access allows a compromised office computer to reach the gateway. Unsigned updates permit malicious firmware. Excessive dashboard access violates least privilege and increases privacy and operational exposure. A false temperature reading could cause food spoilage, financial loss and health consequences.

Using a qualitative scale, the organization rates unauthorized gateway control as likelihood 4 and impact 5, giving a prioritization score of 20 under the stated risk model. The number is used to compare risks; it is not a probability.

Approach and solution

The organization replaces shared credentials with unique device identities and certificates. Gateways verify sensor identities and use authenticated encrypted communication. Secure boot is enabled, and firmware updates require valid signatures, version checks and an automatic safe rollback mechanism. The sensor network is separated from the office network by a firewall that permits only required gateway flows.

Dashboard roles are redesigned: operators can view assigned facilities, maintenance staff can update approved gateways, and security administrators manage identities. Temperature data is retained only for the documented operational and regulatory period. Alerts are generated for implausible readings, repeated authentication failures and unexpected firmware changes. Local gateway rules continue to monitor temperature if cloud connectivity fails.

Outcome

The facility reduces the chance that a stolen office credential can control refrigeration equipment, improves accountability and limits unnecessary data retention. The organization also documents a replacement plan for sensors that cannot support secure updates.

Learning points

1. IoT risk is distributed across all layers.
2. Authentication, authorization and segmentation solve different problems.
3. Signed updates and secure boot must be supported by key management.
4. Local safety behavior is essential when cloud services fail.
5. Privacy assessment should address retention and access, not only encryption.

9. Implementation Checklist for a Diploma-Level Project

For a small IoT prototype or deployment, the following sequence is practical:

1. Draw the architecture and identify trust boundaries.
2. List devices, data, commands and safety functions as assets.
3. Change default credentials and remove unnecessary services.
4. Assign unique device identities.
5. Use authenticated encryption for network communication.
6. Apply least-privilege roles to users, services and devices.
7. Segment the IoT network from ordinary user networks.
8. Protect secrets and avoid placing them in source code.
9. Verify signed firmware updates and test recovery.
10. Record logs without collecting unnecessary personal data.
11. Define retention, deletion and access procedures.
12. Test failure, offline and emergency conditions.
13. Maintain an inventory and vulnerability-response process.
14. Review the design whenever devices, suppliers or purposes change.

10. Challenges and Contemporary Developments

Legacy devices may lack secure hardware, update capability or adequate processing power. Supply chains may contain counterfeit components, vulnerable libraries or uncertain support commitments. Large fleets create operational challenges: certificate renewal, inventory accuracy and coordinated patching become difficult at scale.

Edge computing can reduce the amount of personal data sent to the cloud, but it moves security responsibility to local gateways. Artificial intelligence can assist anomaly detection, yet models may generate false alarms, be manipulated by adversarial inputs or process sensitive data. AI does not replace authentication, authorization or secure design.

Current good practice increasingly emphasizes security by design, secure-by-default configuration, software bills of materials, coordinated vulnerability disclosure, hardware-backed identity, zero-trust principles and measurable product support periods. Standards and regulations continue to evolve, so professionals should consult current national requirements and recognized technical standards before deployment.

Chapter Summary

IoT security, privacy and safety are lifecycle responsibilities spanning devices, networks, platforms and applications. Threats include physical tampering, weak credentials, interception, spoofing, insecure APIs, excessive privilege, malicious updates and denial of service. The CIA triad provides a foundation, while authenticity, accountability, resilience and safety extend the analysis.

Secure boot establishes a chain of trust; device identity and authentication verify participants; authorization applies least privilege; encryption protects confidentiality and integrity; key management protects credentials throughout their lifecycle; signed updates support trustworthy maintenance; and network segmentation limits attack propagation. Risk assessment prioritizes threats using defined likelihood and impact scales, while privacy assessment examines purpose, minimization, transparency, retention and individual harm. Safety requires fail-safe behavior, local controls and careful analysis of cyber-physical consequences. Effective IoT practice combines technical controls with governance, monitoring, incident response and responsible lifecycle management.

Key Terms

Authentication: Verification of a claimed identity.

Authorization: A decision about what an authenticated entity may do.

Availability: The ability of an authorized user or system to access a service when required.

Confidentiality: Protection of information from unauthorized disclosure.

Defense in depth: Use of multiple independent or complementary protective controls.

Device identity: A unique, manageable representation of an IoT device.

Encryption: Transformation of data so that only authorized parties can understand it.

Integrity: Assurance that data, commands or software have not been improperly altered.

Key management: Generation, storage, distribution, rotation, revocation and destruction of cryptographic keys.

Least privilege: Giving an entity only the permissions required for its legitimate function.

Mutual authentication: Authentication in which both communicating parties verify each other.

Network segmentation: Separation of systems into controlled network zones.

Privacy impact assessment: A structured examination of how processing may affect individuals’ privacy.

Risk register: A record of identified risks, ratings, controls, owners and review information.

Secure boot: Verification of boot software before it is executed.

Secure element: Hardware designed to protect cryptographic keys and operations.

Signed update: A software update whose authenticity and integrity are verified with a digital signature.

Threat modelling: Systematic identification and analysis of threats to a system.

Vulnerability: A weakness that can be exploited to cause harm.

Zero trust: A security approach that does not grant implicit trust based only on network location.

Review Questions

Short Answer Questions

1. What are the four principal layers of an IoT architecture, and give one security concern for each?
2. Distinguish authentication from authorization.
3. What security purpose does secure boot serve?
4. Why is network segmentation useful in an IoT deployment?
5. State two important principles of IoT privacy.

Long Answer Questions

1. Explain how device identity, authentication, authorization and key management work together in a secure IoT system.
2. Discuss the role of digitally signed updates, rollback protection and recovery procedures in IoT maintenance.
3. Compare device-layer, network-layer, platform-layer and application-layer threats.
4. Explain how security and functional safety can conflict and how they should be coordinated.
5. Describe a complete basic risk and privacy assessment for a connected building system.

Analytical / Application Questions

1. A factory sensor network uses shared passwords, communicates through the office LAN and sends unencrypted data to a cloud dashboard. Identify at least five risks and propose controls in priority order.
2. A smart door lock loses cloud connectivity during a building emergency. Analyze the security, privacy and safety requirements for its failure behavior.
3. Design a simple risk register for a connected healthcare-monitoring prototype containing three assets, three threats, likelihood and impact ratings, proposed controls and responsible owners.

Multiple Choice Questions with Answers

Question 1

Which control verifies that firmware has not been altered and originated from an approved producer?

A. Network segmentation

B. Digital signature verification

C. Data retention

D. Password expiration

Correct Answer: B. Digital signature verification

Question 2

What is the primary purpose of authorization?

A. To assign an IP address

B. To encrypt a message

C. To decide what an authenticated entity may do

D. To detect a failed sensor

Correct Answer: C. To decide what an authenticated entity may do

Question 3

A risk is rated with likelihood 4 and impact 5 using Risk = Likelihood × Impact. What is the prioritization score?

A. 9

B. 20

C. 25

D. 45

Correct Answer: B. 20

Question 4

Which action best limits movement from a compromised office computer to industrial IoT devices?

A. Increasing data retention

B. Network segmentation with controlled firewall rules

C. Disabling audit logs

D. Using a shared administrator password

Correct Answer: B. Network segmentation with controlled firewall rules

Question 5

Which statement about encryption is correct?

A. Encryption automatically proves that the sender is authorized

B. Encryption removes the need for key management

C. Encryption can protect confidentiality, but identity and authorization are separate concerns

D. Encryption prevents all denial-of-service attacks

Correct Answer: C. Encryption can protect confidentiality, but identity and authorization are separate concerns

Question 6

What is a major weakness of a single shared password across an entire device fleet?

A. It improves individual accountability

B. Compromise of one credential can affect the whole fleet

C. It prevents device impersonation

D. It guarantees least privilege

Correct Answer: B. Compromise of one credential can affect the whole fleet

Question 7

Which privacy practice is most consistent with data minimization?

A. Collecting all available data indefinitely

B. Collecting only data necessary for a defined purpose

C. Sharing data with all employees by default

D. Avoiding deletion procedures

Correct Answer: B. Collecting only data necessary for a defined purpose

Question 8

What does secure boot primarily do?

A. It verifies boot components before execution

B. It increases wireless range

C. It anonymizes users

D. It replaces network firewalls

Correct Answer: A. It verifies boot components before execution

Question 9

Which measure is most appropriate for a safety-critical actuator during loss of cloud connectivity?

A. Allowing unlimited remote commands

B. Entering a defined safe local state

C. Deleting all device logs

D. Disabling all authentication

Correct Answer: B. Entering a defined safe local state

Question 10

Why should IoT devices have unique identities rather than fleet-wide credentials?

A. Unique identities improve accountability and allow individual revocation

B. Unique identities eliminate the need for updates

C. Unique identities make encryption unnecessary

D. Unique identities guarantee physical safety

Correct Answer: A. Unique identities improve accountability and allow individual revocation