Embedded and IoT Security

Introduction

Embedded systems increasingly control vehicles, medical devices, industrial machinery, energy infrastructure, consumer products, and connected buildings. Their security therefore affects not only data confidentiality but also physical safety, operational continuity, public trust, and national infrastructure. An Internet of Things (IoT) device is rarely an isolated computer: it is a component in a larger ecosystem containing sensors, actuators, gateways, cloud services, mobile applications, update servers, manufacturing facilities, and human operators.

Security engineering for embedded and IoT systems must consequently address the complete lifecycle—from silicon selection and manufacturing to deployment, maintenance, decommissioning, and disposal. The central security objectives remain confidentiality, integrity, availability, authenticity, and accountability, but their relative importance depends on context. For a connected insulin pump, integrity and availability may dominate; for a smart speaker, privacy may be the primary concern; for an industrial controller, unauthorized command execution may create physical hazards.

This chapter presents a systematic approach to threat modeling and to implementing secure boot, hardware roots of trust, cryptography, authentication, authorization, secure storage, firmware updates, vulnerability management, privacy protection, and supply-chain assurance.

Learning Objectives

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

1. Model threats across the embedded-device and IoT ecosystem.

2. Explain the role of hardware roots of trust and secure boot.

3. Select appropriate cryptographic primitives and key-management methods.

4. Design authentication, authorization, secure-storage, and update mechanisms.

5. Establish vulnerability-management and product-lifecycle processes.

6. Evaluate privacy, governance, and supply-chain risks.

7. Critically assess security trade-offs in realistic deployments.

1. Security Context and Terminology

An embedded asset is any hardware, software, data, credential, interface, or service requiring protection. A trust boundary separates components with different security assumptions. A threat actor may be a remote attacker, malicious user, criminal group, compromised supplier, insider, or state-sponsored organization. A vulnerability is a weakness that can be exploited; a threat is a potential cause of harm; and risk combines likelihood and impact.

The attack surface includes every interface through which an adversary may influence or observe the system: network protocols, debug ports, bootloaders, update channels, wireless radios, removable media, cloud APIs, mobile applications, physical enclosures, and manufacturing processes. Security controls reduce the probability or consequence of exploitation, but no control is absolute.

Important distinctions include:

• Safety protects people and equipment from accidental or hazardous behavior; security protects against intentional misuse, although the two overlap in cyber-physical systems.
• Authentication establishes who or what is communicating.
• Authorization determines what an authenticated entity may do.
• Confidentiality prevents unauthorized disclosure.
• Integrity prevents unauthorized alteration.
• Availability preserves reliable service.
• Non-repudiation provides evidence supporting the origin of an action, although it depends on key protection and trusted records.

The principle of least privilege grants only the permissions required for a task. Defense in depth uses multiple independent controls, while fail-safe design places the system in a safer state when security checks fail. These principles are especially important because embedded devices often have limited memory, energy, processing capacity, and maintenance access.

2. Threat Modeling for Embedded and IoT Systems

Threat modeling is a structured process for identifying assets, adversaries, attack paths, consequences, and mitigations. It should begin during requirements engineering rather than after implementation.

2.1 System decomposition

A useful model identifies:

• physical devices, microcontrollers, sensors, actuators, and buses;
• operating systems, bootloaders, firmware, libraries, and configuration data;
• local interfaces such as UART, JTAG, USB, Bluetooth, and NFC;
• networks, gateways, brokers, cloud platforms, and APIs;
• users, administrators, service technicians, manufacturers, and suppliers; and
• data flows, trust boundaries, and security-relevant state transitions.

Data-flow diagrams help reveal where credentials, commands, telemetry, and update packages cross trust boundaries. A threat model should distinguish development, manufacturing, deployment, maintenance, and retirement environments because an attack feasible in one phase may not be feasible in another.

2.2 Threat categories and attack trees

The STRIDE mnemonic is useful for classifying threats: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It is not a complete risk model, but it provides a repeatable starting point. Attack trees express how an attacker can achieve a goal. For example, “install unauthorized firmware” may be achieved by stealing a signing key, exploiting an update parser, bypassing signature verification, or obtaining physical access to an unprotected debug port.

Risk analysis should consider at least:

• asset value and safety impact;
• attacker capability, access, motivation, and persistence;
• exploit preconditions and exposure duration;
• likelihood and severity of consequences;
• detectability and recovery capability; and
• dependencies on cloud, supplier, or external identity services.

A qualitative matrix may classify risk as low, medium, high, or critical. Quantitative scoring can support prioritization, but numerical scores are not objective measurements unless their scales and evidence are clearly defined. A critical safety function should not be accepted merely because a numerical score appears moderate.

2.3 Security requirements derived from threats

Threat modeling must produce testable requirements. Examples include:

• The device shall reject firmware lacking a valid signature from an authorized release key.
• Production debug access shall be disabled or strongly authenticated.
• A cloud command shall be accepted only from an authenticated and authorized service.
• A failed update shall permit recovery to a known-good image.
• Personal data shall be collected only for specified purposes and retained for a defined period.

Security requirements should include verification methods, such as inspection, static analysis, penetration testing, fault injection, protocol testing, or formal analysis.

3. Hardware Roots of Trust and Secure Boot

A hardware root of trust is a small, protected foundation on which higher-level security decisions depend. It may include immutable boot ROM, one-time programmable memory, physically unclonable-function support, secure fuses, a cryptographic accelerator, a secure element, or a trusted platform module. The root must protect secrets and establish an authentic starting point even when external flash or operating-system software is untrusted.

3.1 Chain of trust

Secure boot establishes a chain of trust. A typical sequence is:

1. Immutable ROM code executes after reset.

2. ROM verifies the first mutable bootloader using a public key or key hash stored in protected hardware.

3. The bootloader verifies the operating system or application image.

4. The operating system verifies privileged modules and configuration.

5. The application starts only after required checks succeed.

If an image is signed, verification generally checks a digital signature over a defined manifest and image digest. Encryption is not a substitute for authenticity: encrypted but unsigned firmware may still be replaced by an attacker who can generate or replay a valid ciphertext. Conversely, signed firmware may be public while remaining authentic.

3.2 Key hierarchy and anti-rollback

Production systems should separate root keys, release-signing keys, device-identity keys, and session keys. A manufacturer may keep a root key offline and use delegated intermediate keys for routine signing. Compromise of a delegated key should not require replacing the immutable root in every device.

Secure boot must address rollback. An attacker may install an authentically signed but vulnerable older image. Anti-rollback protection can use a monotonic version counter, secure nonvolatile storage, or a signed security-version field. The device accepts an image only if its security version is not lower than the protected minimum. Recovery procedures must be designed carefully because an overly aggressive counter can permanently disable legitimate repair.

3.3 Physical attacks and limitations

Hardware roots of trust reduce risk but do not eliminate side-channel analysis, fault injection, invasive extraction, supply-chain substitution, or malicious authorized firmware. Debug-lock mechanisms, tamper detection, voltage and clock monitoring, key zeroization, and secure packaging can increase resistance. Their effectiveness depends on the attacker model and cost of attack. A low-cost consumer device and a military controller should not be assigned identical protection requirements.

4. Cryptography and Key Management

Cryptography should be selected by security requirement, lifecycle, performance, and interoperability—not by algorithm names alone.

4.1 Symmetric cryptography

Symmetric encryption uses the same secret key for encryption and decryption. Authenticated encryption with associated data (AEAD), such as AES-GCM or ChaCha20-Poly1305, provides confidentiality and integrity for a message and can authenticate unencrypted metadata. A nonce must be unique for each key; accidental nonce reuse can seriously compromise security, particularly for GCM. Nonces need not always be secret, but their uniqueness must be guaranteed by design.

Associated data may include a device identifier, protocol version, or message type. It is authenticated but not encrypted. Applications must verify the authentication tag before using decrypted plaintext.

4.2 Hashes and digital signatures

Cryptographic hash functions produce fixed-length digests used for integrity checks, content addressing, and signature inputs. A hash alone does not authenticate data against an active attacker because the attacker can recompute it. A message-authentication code (MAC) provides authenticity to parties sharing a secret. Digital signatures use a private key to sign and a public key to verify, making them suitable for firmware distribution and multi-party verification.

Modern deployments commonly use elliptic-curve signatures such as Ed25519 or ECDSA, subject to platform and standardization constraints. RSA remains present in legacy and enterprise systems. Algorithm selection must account for secure implementations, certificate support, hardware acceleration, long-term maintenance, and cryptographic-agility requirements.

4.3 Key lifecycle

Key management is often more difficult than algorithm selection. A complete process covers generation, provisioning, storage, use, rotation, backup, revocation, recovery, and destruction. Device-unique keys reduce the effect of compromise compared with one global device key. Keys should be generated in an approved secure environment or within the device’s protected hardware when feasible.

Static credentials embedded in firmware are dangerous because extraction from one device may compromise every unit. Manufacturing systems should authenticate provisioning operations, restrict access, maintain audit records, and prevent test credentials from reaching production.

5. Authentication, Authorization, and Secure Communication

Mutual authentication is generally preferable for device-to-cloud communication: the device authenticates the server and the server authenticates the device. Transport Layer Security (TLS) or Datagram TLS (DTLS) can provide authenticated, confidential channels, but correct certificate validation, hostname or identity checking, time handling, and trust-store management are essential. A device that accepts any certificate is not securely using TLS.

Device credentials may use certificates, raw public keys, or managed symmetric secrets. Certificate-based identity scales well when a public-key infrastructure is available. Credentials should be revocable or replaceable, and provisioning should bind identity to a specific device rather than merely to a product model.

Authorization should be explicit and context-aware. Role-based access control assigns permissions to roles; attribute-based access control evaluates attributes such as device state, location, time, tenant, and command risk. A gateway administrator might read telemetry but not issue safety-critical commands. Commands should also be validated against safe operating ranges and current state; authentication alone does not make an unsafe command acceptable.

Replay protection requires a nonce, sequence number, timestamp with reliable time assumptions, challenge-response protocol, or a combination. Sequence numbers should be stored or otherwise managed so that reboot does not silently reopen an old message window.

6. Secure Storage and Trusted Execution

Sensitive material includes private keys, tokens, telemetry, configuration, proprietary algorithms, and safety parameters. Protection options range from encrypted filesystems to secure elements and trusted execution environments (TEEs). Encryption at rest is useful only when key access is itself protected. Storing the encryption key beside the ciphertext in ordinary flash offers limited protection against device extraction.

Secure storage should provide confidentiality, integrity, rollback resistance where required, access control, and safe deletion. Keys may be sealed to a device state so that they are released only after verified boot. However, recovery design is essential: loss of a device key, corrupted metadata, or a failed update must not create an unacceptable operational or safety condition.

TEEs isolate selected code and data from a normal operating system. They can protect key operations, biometric templates, payment functions, and attestation services. Isolation boundaries must be narrow, interfaces minimized, and trusted code kept small. A TEE cannot compensate for insecure inputs, vulnerable trusted code, or a compromised authorization policy.

7. Secure Firmware Updates

Connected devices require a safe and sustainable update mechanism. An update protocol should provide authenticated packages, encrypted transport where appropriate, version control, authorization, atomic installation, power-loss recovery, status reporting, and rollback or recovery.

A signed manifest should specify the target hardware, image digest, version, dependencies, security version, validity constraints, and signing authority. The device must verify the manifest before installation and verify the image after transfer. A/B partitions or a recovery image can allow installation into an inactive slot, followed by a controlled boot trial. The system should mark the new image healthy only after successful startup and health checks.

Updates must be resilient to interrupted power, unreliable networks, insufficient storage, and partial fleet deployment. Differential updates reduce bandwidth but increase implementation complexity and may create patching errors if the base image differs. Emergency recovery should not rely exclusively on the same cloud service that may be unavailable during an incident.

Signing authority requires strong governance. Multi-person approval, offline root keys, hardware security modules, reproducible builds, release provenance, and rapid key revocation reduce the impact of a compromised build or signing environment.

8. Lifecycle Vulnerability Management

Security continues after product release. A professional vulnerability-management program includes:

1. an inventory of products, components, versions, and dependencies;

2. a security contact and vulnerability disclosure process;

3. monitoring of advisories and upstream projects;

4. triage based on exploitability, exposure, safety, and impact;

5. patch development, testing, signing, and distribution;

6. customer notification and mitigation guidance; and

7. verification that vulnerable versions are removed or isolated.

Software bills of materials (SBOMs) improve visibility into open-source and commercial components. They do not by themselves prove security: an SBOM may be incomplete, and the presence of a vulnerable component does not establish exploitability. Conversely, absence from an SBOM does not demonstrate absence from the product.

End-of-support dates should be declared before deployment. Long-lived industrial and medical devices may require compensating controls, extended maintenance contracts, or architectural isolation. Secure decommissioning should revoke credentials, erase personal data, remove device ownership, and prevent discarded equipment from becoming a source of compromise.

9. Privacy, Governance, and Supply-Chain Security

IoT devices can collect location, behavior, voice, health, and household information. Privacy engineering begins with data minimization: collect only what is necessary, process locally where practical, separate identity from telemetry, define retention periods, and provide meaningful user control. Encryption does not eliminate privacy risk because authorized parties may still infer sensitive behavior from metadata.

Organizations should document purposes, lawful bases where applicable, access rights, breach response, retention, and cross-border data handling. Regulatory obligations vary by jurisdiction and sector; relevant frameworks may include data-protection laws, sectoral medical or payment rules, product-cybersecurity requirements, and national critical-infrastructure guidance. Compliance is a baseline rather than proof of good security.

Supply-chain threats include counterfeit components, malicious modifications, compromised development tools, vulnerable libraries, exposed manufacturing credentials, and opaque subcontractors. Controls include supplier assessment, contractual security requirements, provenance records, controlled build environments, reproducible builds, component verification, secure provisioning, incoming inspection, and separation of duties. Hardware authenticity may require trusted serialization or attestation, but attestation only reports measured state; it does not guarantee that the measured software is desirable.

10. Illustrative Case Study: Connected Industrial Pump Controller

Background

Consider a fictional manufacturer deploying network-connected pump controllers in a municipal water facility. Each controller measures pressure, operates a motor, reports telemetry to a cloud service, and receives remote firmware updates. Controllers are installed for fifteen years, and temporary maintenance laptops are used on site.

Problem

An initial design uses a shared administrator password, unsigned firmware updates, an exposed UART header, and a cloud API that authorizes commands only by device identifier. A compromised laptop could therefore issue commands, extract firmware, or install modified code. A failed update could also stop pumping.

Analysis

The critical assets are motor-control integrity, continuous availability, maintenance credentials, and operational telemetry. Threat actors include a remote attacker, a malicious contractor, and an attacker with temporary physical access. The most severe attack paths are credential reuse, API impersonation, debug-port access, and malicious or interrupted updates.

Approach and solution

The manufacturer establishes device-unique identities using certificates provisioned in a secure manufacturing station. Mutual TLS authenticates controllers and the cloud. The API checks certificate identity, tenant, command authorization, device state, and permitted operating range. High-risk commands require a second authorized approval and are logged.

An immutable bootloader verifies signed firmware using a delegated release key whose root is protected offline. A security-version counter blocks rollback. Firmware is installed into an inactive partition and activated only after health checks. A recovery image maintains local safe operation if cloud connectivity is lost.

The UART is disabled in production; authorized service access requires a physical service token, authenticated challenge-response, time-limited privilege, and audit logging. Secrets are held in a secure element. Telemetry is minimized, encrypted in transit, access-controlled, and retained only as long as operationally necessary. The supplier provides an SBOM and vulnerability-notification commitment.

Outcome

The revised architecture does not make compromise impossible, but it changes the attack from a reusable-password event into a substantially more difficult, detectable, and recoverable operation. Availability is improved through local control and update recovery, while accountability improves through identity-bound logs.

Learning points

Security controls must be selected as a system. Secure boot without secure updates is incomplete; authenticated devices without authorization are dangerous; encryption without key management is superficial; and cloud dependence without local safety behavior creates an availability risk.

11. Validation, Testing, and Advanced Practice

Security validation should combine code review, static and dynamic analysis, fuzzing of parsers and protocols, penetration testing, fault injection, side-channel assessment, configuration review, and operational exercises. Threat models should be revisited when hardware, suppliers, protocols, or business processes change.

Formal methods can verify selected properties such as access-control invariants or protocol behavior, but their scope depends on the model and assumptions. Secure development frameworks should include security requirements, code review, dependency control, build integrity, test evidence, and incident learning.

Artificial intelligence can assist vulnerability triage, anomaly detection, log analysis, and code review. It may also generate insecure code, produce false positives, leak sensitive artifacts, or be manipulated by poisoned data. AI outputs therefore require expert validation, controlled data handling, and traceability. AI should augment—not replace—threat modeling, secure design, and accountability.

Challenges and Limitations

Embedded security faces persistent trade-offs. Strong cryptography consumes energy and memory; secure hardware increases bill of materials and manufacturing complexity; frequent updates may disrupt safety certification; and long device lifetimes outlast many software ecosystems. Physical protection is costly and depends on attacker capability. Privacy controls may reduce analytic value, while excessive logging may create new sensitive data.

Security mechanisms can also fail through operational error: lost signing keys, incorrect certificate expiration, bad time synchronization, incomplete inventories, unsafe recovery procedures, or update servers that cannot serve the installed fleet. Resilience requires tested fallback modes, documented ownership, and realistic assumptions about maintenance personnel and connectivity.

Best-Practice Checklist

• Define assets, trust boundaries, safety consequences, and lifecycle assumptions.
• Use hardware-backed identity and protect production secrets.
• Establish a verified boot chain and prevent unauthorized rollback.
• Prefer authenticated encryption and guarantee nonce uniqueness.
• Separate authentication from authorization and enforce least privilege.
• Design updates for interruption, recovery, revocation, and long-term support.
• Maintain an accurate component inventory and SBOM.
• Provide coordinated vulnerability disclosure and incident response.
• Minimize personal data and define retention and deletion rules.
• Secure suppliers, build systems, provisioning stations, and signing keys.
• Test physical, network, cloud, firmware, and operational attack paths.
• Plan secure decommissioning before the product is deployed.

Chapter Summary

Embedded and IoT security is a lifecycle discipline spanning hardware, firmware, networks, cloud services, people, suppliers, and governance. Threat modeling identifies assets, trust boundaries, adversaries, attack paths, consequences, and verifiable requirements. Hardware roots of trust and secure boot establish a basis for authentic execution, while key hierarchies and anti-rollback controls protect the update process. Cryptography must be paired with disciplined key management, and secure communication must combine authentication with explicit authorization and replay protection.

Secure storage, trusted execution, resilient firmware updates, vulnerability management, SBOMs, privacy engineering, and supply-chain assurance address risks that cannot be solved by a single algorithm. Effective architectures also preserve safe local operation, support recovery, record accountable actions, and remain maintainable throughout long product lifetimes. The strategic objective is not merely to prevent intrusion but to ensure trustworthy, recoverable, privacy-respecting, and governable system behavior.

Key Terms

Authenticated encryption: Encryption that also verifies message integrity and authenticity.

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

Hardware root of trust: Protected hardware or immutable code forming the foundation for security decisions.

Secure boot: Verification of software authenticity before execution.

Trust boundary: A boundary across which security assumptions or privileges change.

Threat modeling: Structured identification and analysis of threats, assets, and mitigations.

Attack surface: The set of interfaces exposed to possible attack.

Anti-rollback: Protection preventing installation of an older, vulnerable software version.

Secure element: Dedicated hardware for protected key storage and cryptographic operations.

Trusted execution environment: An isolated execution area for security-sensitive code and data.

Digital signature: Public-key evidence that data was approved by the holder of a private key.

Message-authentication code: Secret-key mechanism providing message authenticity and integrity.

Replay attack: Reuse of a previously valid message to cause an unauthorized action.

SBOM: Structured inventory of software components and dependencies.

Vulnerability disclosure: Process for reporting, assessing, and remediating security weaknesses.

Least privilege: Granting only the permissions necessary for a task.

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

Supply-chain security: Protection of design, development, manufacturing, distribution, and maintenance processes.

Review Questions

Short Answer Questions

1. What is the purpose of a hardware root of trust?

2. Distinguish authentication from authorization.

3. Why is encryption alone insufficient for secure firmware updates?

4. What is anti-rollback protection?

5. State two privacy risks associated with IoT telemetry.

Long Answer Questions

1. Explain how a secure-boot chain is established from immutable ROM to application software.

2. Discuss the complete lifecycle of cryptographic keys in an embedded product.

3. Describe the security requirements of a resilient firmware-update architecture.

4. Compare role-based and attribute-based authorization for IoT systems.

5. Explain how SBOMs, vulnerability disclosure, and supplier governance support lifecycle security.

Analytical / Application Questions

1. Design a threat model for a connected medical sensor, identifying assets, trust boundaries, attack paths, and prioritized mitigations.

2. An IoT gateway accepts signed firmware but permits installation of any lower version. Analyze the risk and propose a secure correction without eliminating emergency recovery.

3. A factory uses one shared secret in every device. Evaluate the consequences of compromise and design a replacement provisioning and identity architecture.

Multiple Choice Questions with Answers

Question 1

Which security property does a digital signature primarily provide for firmware?

A. Authenticity and integrity

B. Guaranteed confidentiality

C. Unlimited availability

D. Physical tamper resistance

Correct Answer: A. Authenticity and integrity

Question 2

What is the main purpose of anti-rollback protection?

A. To reduce firmware size

B. To prevent installation of an older vulnerable image

C. To encrypt network traffic

D. To disable all recovery functions

Correct Answer: B. To prevent installation of an older vulnerable image

Question 3

Which statement about AEAD associated data is correct?

A. It is encrypted but not authenticated

B. It is authenticated but normally not encrypted

C. It must always be secret

D. It replaces key management

Correct Answer: B. It is authenticated but normally not encrypted

Question 4

Which practice best limits the impact of compromise of one IoT device?

A. Use one global device password

B. Embed the same private key in all devices

C. Use device-unique credentials

D. Disable all authentication

Correct Answer: C. Use device-unique credentials

Question 5

What does mutual authentication establish?

A. Only that the network is available

B. That both communicating parties verify each other

C. That all commands are authorized

D. That firmware is free of defects

Correct Answer: B. That both communicating parties verify each other

Question 6

Why is nonce uniqueness important in AES-GCM?

A. Nonce reuse can seriously compromise security

B. It makes keys unnecessary

C. It guarantees physical security

D. It prevents all denial-of-service attacks

Correct Answer: A. Nonce reuse can seriously compromise security

Question 7

Which control is most directly associated with supply-chain visibility?

A. Software bill of materials

B. Screen brightness control

C. Packet fragmentation

D. Motor speed calibration

Correct Answer: A. Software bill of materials

Question 8

A device installs an update into an inactive partition and activates it after health checks. What benefit does this provide?

A. It eliminates the need for signatures

B. It improves recovery from interrupted or faulty updates

C. It guarantees that the cloud cannot be compromised

D. It prevents all physical attacks

Correct Answer: B. It improves recovery from interrupted or faulty updates

Question 9

Which authorization approach can evaluate location, time, device state, and user role?

A. Attribute-based access control

B. Unauthenticated access

C. Static hashing

D. Physical-layer encryption only

Correct Answer: A. Attribute-based access control

Question 10

Which statement best describes an SBOM?

A. A guarantee that software contains no vulnerabilities

B. An inventory of software components and dependencies

C. A replacement for secure boot

D. A method for encrypting telemetry

Correct Answer: B. An inventory of software components and dependencies