IoT Security and Privacy

Introduction

The Internet of Things (IoT) connects sensors, actuators, gateways, cloud services, mobile applications and business systems. This connectivity creates value, but it also enlarges the attack surface. An insecure temperature sensor may provide an entry point into an industrial network; a poorly protected camera may expose private conversations; a compromised medical device may threaten human safety. IoT security is therefore not limited to protecting data in transit. It includes the entire lifecycle of devices, software, identities, networks, data and people.

Security-by-design means that security requirements are identified before implementation and are maintained throughout commissioning, operation, maintenance and retirement. Privacy-by-design applies the same discipline to personal information: collect only what is necessary, use it for legitimate purposes, protect it, retain it for an appropriate period and provide accountability.

This chapter presents practical foundations for threat modelling, identity, authentication, authorization, encryption, key management, secure boot, firmware signing, network segmentation and secure over-the-air updates. It also examines privacy risks and common IoT attacks.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Identify IoT assets, trust boundaries, threats and security requirements.
2. Distinguish identification, authentication, authorization and accounting.
3. Select suitable controls for confidentiality, integrity, availability and safety.
4. Explain encryption, certificates, keys, secure boot and signed firmware.
5. Design basic network segmentation and secure update processes.
6. Recognize privacy risks and apply data-minimization principles.
7. Evaluate an IoT security design using a lifecycle and defence-in-depth approach.

1. The IoT Security Problem

IoT systems differ from conventional IT systems in several important ways:

• Devices may be physically accessible to attackers.
• Many devices have limited memory, processing power and energy.
• Devices can remain deployed for ten years or more.
• A device may be safety-critical or difficult to patch.
• Hardware and software may come from many suppliers.
• Devices often communicate automatically and at large scale.
• Security failures can affect the physical world, not merely information.

A useful security model considers four closely related properties:

Safety and privacy should be considered alongside these properties. For example, integrity of a motor-control command may be more important than confidentiality, while confidentiality is dominant for a wearable health record.

Security objectives and risk

Risk is commonly understood as a function of the likelihood of an adverse event and its impact. This is a planning concept rather than a precise universal equation. A simple qualitative model is:

Likelihood describes how probable exploitation or failure is; impact describes the resulting harm, such as financial loss, injury, privacy violation or service interruption. The model assumes that the two factors can be assessed on comparable ordinal scales. It should not be interpreted as an exact probability calculation.

Security controls reduce likelihood, impact, or both. For example, segmentation may reduce the likelihood that a compromised sensor can reach a billing server, while a safe actuator state may reduce impact.

2. Threat Modelling and Security-by-Design

Threat modelling is a structured method for asking what can go wrong, how it could happen and how the design should respond. It should begin with the system architecture rather than with a list of products.

A practical process is:

1. Define scope and assets. Identify devices, credentials, firmware, data, cloud services, network links, physical processes and safety functions.
2. Draw data flows. Show communication paths and trust boundaries between devices, gateways, cloud services and users.
3. Identify actors. Include ordinary users, administrators, suppliers, malicious outsiders, insiders and physically present attackers.
4. Enumerate threats. Consider spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.
5. Assess risk. Estimate likelihood and impact using an agreed scale.
6. Select controls. Prefer prevention, but also include detection, response and recovery.
7. Verify assumptions. Test whether the controls work under realistic operating conditions.

A threat model is a living document. A new communication protocol, supplier, firmware version or cloud integration can change the threat environment.

Figure: Security-by-design is a lifecycle rather than a one-time configuration task.

Trust boundaries

A trust boundary is a point where assumptions about identity, control or data protection change. Examples include a sensor-to-gateway wireless link, a gateway-to-cloud connection, a supplier update server and an administrator interface. Every boundary should have explicit authentication, authorization and validation requirements. “Internal” does not automatically mean trusted.

3. Identity, Authentication and Authorization

Identity is the claimed or assigned representation of an entity. An entity may be a device, user, service or organization. Identification is the act of stating that identity. Authentication verifies the claim. Authorization determines what an authenticated entity may do. Accounting or auditing records relevant actions.

Device identity

Each device should have a unique, lifecycle-managed identity. Shared default passwords and duplicated certificates make attribution and revocation difficult. Suitable identity mechanisms include:

• unique asymmetric key pairs stored in a protected hardware element;
• device certificates issued by a trusted certificate authority;
• hardware-backed device identifiers, where their use does not create unnecessary privacy risks;
• short-lived service tokens for cloud access.

A serial number alone is an identifier, not proof of identity. It must not be treated as a secret.

Authentication factors

Authentication can use something the entity knows, possesses or is. IoT designs commonly use certificates or cryptographic keys because passwords are difficult to protect on unattended devices. Multifactor authentication is especially important for administrators and remote operators. A device should not automatically receive human administrative privileges.

Authorization models

Role-based access control assigns permissions to roles such as operator, technician and auditor. Attribute-based access control evaluates attributes such as device location, time, data sensitivity and action type. Least privilege means granting only the permissions required for an approved task. Separation of duties can require two authorized people for high-risk operations, such as changing a safety controller.

Authorization must be enforced at the resource, not merely in a user interface. A gateway should validate whether a command is permitted before forwarding it to an actuator.

4. Cryptography and Key Management

Cryptography provides mechanisms, not automatic security. Correct algorithms can still be defeated by exposed keys, weak randomness, incorrect certificate validation or insecure endpoints.

Encryption in transit and at rest

Encryption in transit protects data crossing a network, commonly through TLS or an appropriate equivalent. It provides confidentiality and, when correctly authenticated, integrity and endpoint authentication. Encryption at rest protects stored data in devices, gateways, databases and backups.

Authenticated encryption is generally preferred because it combines confidentiality with detection of unauthorized modification. Keys must be separated by purpose: a firmware-signing key should not also encrypt telemetry.

Public-key and symmetric cryptography

Symmetric cryptography uses one shared secret for encryption and decryption. It is computationally efficient but requires secure distribution of the secret. Public-key cryptography uses a private key and a corresponding public key. It supports scalable authentication and key establishment, but usually requires more computation and careful certificate management.

Cryptographic strength depends on the algorithm, key length, implementation, randomness and lifecycle. Organizations should follow current standards and obtain specialist advice rather than inventing algorithms or protocols.

Key lifecycle

A professional key-management process includes:

1. secure generation using an approved random source;
2. protected storage, preferably hardware-backed where appropriate;
3. controlled provisioning and association with a device identity;
4. rotation or replacement according to risk and lifetime;
5. revocation or blocking when compromise is suspected;
6. backup only when justified and protected;
7. destruction at retirement.

Certificate expiry and revocation must be planned for devices that may be offline. A device that cannot validate time reliably may require carefully designed validity handling, but this must not become an excuse to accept expired or untrusted credentials indefinitely.

5. Secure Boot and Firmware Integrity

Secure boot establishes a chain of trust from an immutable or strongly protected root of trust. At startup, a boot component verifies the digital signature or integrity of the next component before executing it. The chain may include boot ROM, first-stage bootloader, second-stage bootloader, operating system and application firmware.

A signature provides authenticity and integrity only if the verifying device already trusts the correct public key and if private signing keys remain protected. A hash alone detects accidental or known modification, but does not prove who produced the firmware. Signed firmware should also include version information to resist rollback attacks.

Important controls include:

• storing verification keys in protected memory;
• disabling or controlling debug interfaces in production;
• protecting signing keys with hardware security modules or equivalent controls;
• maintaining a revocation mechanism for compromised keys;
• using anti-rollback counters or trusted version metadata;
• failing safely if verification fails.

Secure boot does not prove that firmware is free of vulnerabilities. It proves that the device accepted firmware authorized by the signing process. The signing process and release pipeline must therefore be secured and independently reviewed.

6. Secure Over-the-Air Updates

Updates are essential because vulnerabilities are discovered after deployment. An update system should authenticate the source, verify integrity, prevent rollback, protect confidentiality when necessary and recover from interruption.

A robust update sequence is:

1. The device obtains update metadata through an authenticated channel.
2. It validates the signature, target model, version and compatibility.
3. It checks sufficient power and storage.
4. It downloads the image, often into an inactive partition.
5. It verifies the complete image before activation.
6. It switches to the new image and records status.
7. It automatically returns to the previous known-good image if startup validation fails.

Updates should be staged gradually, monitored and capable of emergency withdrawal. The update service must not accept an image merely because it is encrypted; authenticity and integrity are essential. Recovery planning is particularly important for battery devices, intermittent networks and safety-critical equipment.

7. Network Protection and Segmentation

Network segmentation limits movement after compromise. A practical IoT environment may separate:

• constrained sensors and actuators;
• gateways and device-management services;
• enterprise information systems;
• guest or consumer devices;
• administrative management networks.

Firewalls, virtual networks, access-control lists and application gateways can restrict traffic between zones. Rules should be deny-by-default where operationally feasible, with explicit exceptions for necessary protocols and destinations. Outbound traffic also requires control; a compromised device should not have unrestricted Internet access.

Segmentation is not a replacement for endpoint security. An attacker may exploit an allowed protocol, compromise a gateway or use stolen credentials. Monitoring should detect unusual volumes, destinations, command patterns and authentication failures. Network time, logs and alert ownership must be defined so that events can be investigated.

Common attacks include:

8. Privacy in IoT Systems

IoT devices can infer more than they directly measure. A smart meter may reveal occupancy patterns; a wearable may reveal health information; location data can expose routines. Privacy risk therefore includes inference, linkage, unauthorized secondary use and loss of control, not only direct disclosure.

Privacy-by-design principles include:

• Purpose limitation: define why data is collected and prevent unrelated use.
• Data minimization: collect the least data needed for the stated purpose.
• Transparency: explain collection, processing, sharing and retention in understandable language.
• User control: provide appropriate access, correction, deletion or objection mechanisms.
• Retention limitation: delete or anonymize data when it is no longer needed.
• Protection: secure data throughout collection, transmission, processing and disposal.
• Accountability: document decisions, suppliers, permissions and incidents.

Consent may be required in some contexts, but it is not a universal solution. Consent should be informed, specific and freely given where applicable; safety or contractual processing may have different legal bases. Organizations must consult relevant privacy law, sector regulation and contractual obligations. Privacy impact assessments are valuable when monitoring people, processing sensitive data or introducing large-scale analytics.

Anonymization is difficult when datasets can be linked with other sources. Pseudonymization reduces direct identification but does not necessarily remove personal-data obligations. Aggregation, local processing and edge analytics can reduce the amount of raw data sent to the cloud, but they do not eliminate the need for access control and governance.

9. A Defence-in-Depth Architecture

Consider a connected building with occupancy sensors, smart locks, HVAC controllers, a gateway and a cloud dashboard. A layered design could include:

1. Unique device credentials provisioned during manufacturing.
2. Secure boot and signed firmware on sensors and controllers.
3. Encrypted, mutually authenticated gateway communication.
4. Separate network zones for building controls, office IT and guest access.
5. Role-based administration with multifactor authentication.
6. Cloud authorization that limits each tenant to its own devices.
7. Local safety rules so HVAC and locks remain safe if cloud connectivity fails.
8. Signed, staged updates with automatic rollback.
9. Event logging, vulnerability handling and an incident-response plan.
10. Data minimization, retention schedules and clear notices to occupants.

This design demonstrates that no single control is sufficient. If a sensor is stolen, network access controls still limit its usefulness. If a cloud account is compromised, device authorization and safe operating limits reduce possible harm.

Applied Case: Illustrative Smart Irrigation Deployment

Background

A municipality deploys wireless soil-moisture sensors and remotely controlled irrigation valves across public parks. Readings are sent through gateways to a cloud service. Maintenance staff use a mobile application to schedule watering.

Problem

During a pilot, all sensors use the same default password, valves accept commands from any device on the local network, and firmware updates are performed manually with memory cards. Location and maintenance-worker data are retained indefinitely.

Analysis

The assets include water-control commands, device identities, firmware, network credentials, worker accounts and location data. Threats include credential guessing, replayed valve commands, malicious firmware, lateral movement from a gateway and privacy exposure. The impact includes water waste, damaged landscaping, service disruption and disclosure of worker routines.

Approach and solution

The municipality assigns each device a unique certificate and stores its private key in a secure element. Gateways mutually authenticate with the cloud using TLS. Controllers accept only signed commands containing a freshness value and a permitted action. Sensors, gateways and municipal office systems are placed in separate network zones. Staff use multifactor authentication and role-based permissions: a grounds worker may schedule watering, while only a small engineering group may change firmware.

Firmware is signed through a protected release process. Devices verify the signature and version, install updates into an inactive partition and roll back if health checks fail. The cloud retains aggregated moisture statistics for planning, while precise device and worker-location records are deleted according to a documented schedule. Alerts identify unusual command rates and repeated authentication failures.

Outcome

The revised architecture reduces the likelihood of unauthorized control, limits lateral movement and improves recovery from faulty updates. It also reduces privacy exposure by separating operational necessity from indefinite data collection. Residual risks remain: physical damage, supply-chain compromise and denial of wireless service require continuing monitoring and contingency procedures.

Learning points

Security controls must be matched to assets and consequences. Device identity, command authorization, update assurance, segmentation and privacy governance work together. A technically secure device can still create privacy harm if its data practices are excessive.

10. Governance, Operations and Professional Practice

Security is an operational responsibility, not merely a design feature. Organizations should maintain an inventory of devices, software versions, owners, locations, suppliers and support status. They should define vulnerability disclosure, patch timelines, incident escalation, backup, recovery and end-of-life procedures.

Procurement contracts should require security documentation, update support, vulnerability notification, secure deletion and evidence of testing. Interoperability should not be achieved by disabling certificate validation or accepting unauthenticated legacy protocols. When legacy equipment cannot meet the required security level, compensating controls may include isolation, monitoring, restricted physical access and replacement planning.

Testing may include code review, vulnerability scanning, protocol testing, penetration testing, update-failure testing and physical assessment. Testing must be authorized and should avoid disrupting safety or production systems. Artificial intelligence can assist anomaly detection and vulnerability triage, but it can also generate false positives, expose sensitive telemetry or be manipulated by adversarial inputs. Human oversight, explainable escalation and careful data governance remain necessary.

Challenges and Limitations

IoT security faces practical constraints. Battery life may limit continuous communication; legacy devices may lack secure boot; certificate revocation may be difficult during long offline periods; manufacturers may stop supporting products; and small organizations may lack specialist staff. Strong controls can also reduce usability or increase cost.

Risk-based prioritization is therefore necessary. Safety-critical commands, administrative identities, update infrastructure and systems containing sensitive personal information normally deserve the strongest controls. Standards and regulatory requirements provide useful baselines, but compliance alone does not prove that a system is secure. Security must be continuously reassessed as threats, suppliers, software and operating environments change.

Best-Practice Checklist

• Maintain an accurate device and software inventory.
• Assign unique identities; eliminate default shared credentials.
• Authenticate both endpoints where practical.
• Enforce least privilege and multifactor administration.
• Use authenticated encryption and protect keys throughout their lifecycle.
• Establish secure boot and signed, anti-rollback firmware.
• Design safe, monitored and recoverable OTA updates.
• Segment networks and restrict unnecessary inbound and outbound traffic.
• Log security-relevant events without collecting excessive personal data.
• Apply data minimization, retention and transparency principles.
• Plan vulnerability response, incident handling and end-of-life disposal.
• Test controls under realistic physical, network and operational conditions.

Chapter Summary

IoT security protects devices, communications, software, services and physical processes throughout their lifecycle. Security-by-design begins with assets, data flows, trust boundaries and threat modelling. Unique identities, strong authentication, least-privilege authorization and secure key management establish trustworthy interactions. Encryption protects confidentiality and integrity, while secure boot and signed firmware protect the software foundation. Secure OTA updates must authenticate images, prevent rollback and support recovery. Network segmentation and monitoring limit the consequences of compromise. Privacy-by-design requires purpose limitation, data minimization, transparency, retention control and accountability. Because no control is complete, defence in depth, governance, testing and continuous improvement are essential.

Key Terms

Asset: Anything valuable that requires protection, including data, devices, credentials or services.

Authentication: Verification that an entity is the one it claims to be.

Authorization: Determination of which actions an authenticated entity may perform.

Certificate: A signed data object binding an identity to a public key.

Confidentiality: Protection against unauthorized disclosure.

Defence in depth: Use of multiple independent or complementary security controls.

Digital signature: A cryptographic value used to verify origin and integrity.

Firmware: Software embedded in or closely associated with a device.

Integrity: Protection against unauthorized alteration.

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

Least privilege: Granting only the permissions necessary for an approved task.

Network segmentation: Dividing a network into controlled security zones.

Nonce: A value intended to be used once, often to provide message freshness.

Privacy by design: Integrating privacy protections into system design and lifecycle processes.

Secure boot: Startup verification that establishes a trusted software chain.

Threat modelling: Systematic identification and assessment of threats and mitigations.

Trust boundary: A point where security assumptions or control requirements change.

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

Review Questions

Short Answer Questions

1. Distinguish identification, authentication and authorization.
2. Why is a shared default password unsuitable for a fleet of IoT devices?
3. What is the purpose of secure boot?
4. State two principles of privacy-by-design.
5. How does network segmentation limit the effects of compromise?

Long Answer Questions

1. Explain a complete threat-modelling process for an IoT deployment.
2. Describe the lifecycle of a cryptographic key from generation to destruction.
3. Explain how signed firmware and secure OTA updates should work together.
4. Discuss defence in depth using a connected-building example.
5. Compare confidentiality, integrity, availability and authenticity in IoT systems.

Analytical / Application Questions

1. A water-treatment controller accepts commands from any device on its local network. Identify the main threats and propose layered controls.
2. A wearable application stores precise location and health data indefinitely. Analyze the privacy risks and design a more responsible data lifecycle.
3. A remote sensor is offline for six months and then reconnects. Design an update and certificate strategy that addresses expiry, rollback and compromised firmware keys.

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents unauthorized firmware from executing during device startup?

A. Network address translation

B. Secure boot with signature verification

C. Data retention policy

D. Rate limiting

Correct Answer: B. Secure boot with signature verification

Question 2

What is the primary purpose of authorization?

A. To assign an IP address

B. To encrypt a database

C. To determine permitted actions

D. To generate random numbers

Correct Answer: C. To determine permitted actions

Question 3

Which practice best supports unique device identity?

A. One password for all devices

B. A public serial number used as a secret

C. A unique certificate and protected private key

D. Disabling device authentication

Correct Answer: C. A unique certificate and protected private key

Question 4

Which measure is most directly associated with preventing replay attacks?

A. Nonces or sequence numbers

B. Longer device cables

C. Data aggregation only

D. Changing screen brightness

Correct Answer: A. Nonces or sequence numbers

Question 5

What is the main purpose of network segmentation?

A. To increase sensor temperature

B. To limit movement after compromise

C. To eliminate the need for authentication

D. To make all devices publicly reachable

Correct Answer: B. To limit movement after compromise

Question 6

Which statement about a cryptographic hash alone is correct?

A. It proves who produced the firmware

B. It detects modification but does not authenticate the producer

C. It replaces all access control

D. It guarantees confidentiality

Correct Answer: B. It detects modification but does not authenticate the producer

Question 7

Which is an example of data minimization?

A. Keeping all raw data forever

B. Collecting only the data needed for the stated purpose

C. Sharing telemetry with every supplier

D. Disabling deletion requests

Correct Answer: B. Collecting only the data needed for the stated purpose

Question 8

Why should an OTA update support rollback?

A. To recover when the new image fails health checks

B. To allow unsigned code to run

C. To bypass version verification

D. To expose the update key

Correct Answer: A. To recover when the new image fails health checks

Question 9

Which authentication approach is particularly appropriate for remote administrators?

A. Shared factory password

B. Multifactor authentication

C. Unauthenticated HTTP

D. A public device serial number

Correct Answer: B. Multifactor authentication

Question 10

A compromised sensor is on a zone that cannot reach enterprise databases because firewall rules deny that traffic. Which principle is illustrated?

A. Least privilege and segmentation

B. Purpose limitation only

C. Firmware compression

D. Anonymization

Correct Answer: A. Least privilege and segmentation