Embedded IoT Security, Safety and Governance

Introduction

The Internet of Things (IoT) connects sensors, actuators, embedded controllers, communication networks, cloud platforms and human users. This connectivity creates value, but it also enlarges the attack surface. A compromised smart meter can falsify measurements, an insecure medical device can endanger a patient, and a poorly governed industrial controller can interrupt production or cause physical damage. Security in embedded IoT is therefore not limited to protecting confidential information. It also concerns integrity, availability, safety, privacy, accountability, resilience and lawful use.

Embedded devices present distinctive challenges. They often have limited memory and processing capacity, long operational lifetimes, intermittent connectivity, physical exposure, constrained power supplies and difficult maintenance conditions. Many devices are deployed in large numbers and cannot be individually visited for repair. Security must consequently be designed into hardware, firmware, communication protocols, manufacturing, deployment, operation, maintenance and retirement.

This chapter presents a practical security and governance approach for diploma-level IoT engineering. It explains secure boot, cryptography, authentication, authorization, key management, hardware roots of trust, secure updates, threat modelling, risk assessment, functional safety, privacy, ethics, standards and device governance.

Learning Objectives

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

1. Explain the security, safety and governance requirements of embedded IoT systems.
2. Distinguish confidentiality, integrity, availability, authenticity, accountability and safety.
3. Describe secure boot, encryption, authentication, authorization, key management and hardware roots of trust.
4. Design a secure firmware-update process and explain rollback protection.
5. Apply a basic threat-modelling and risk-assessment method.
6. Recognize the relationship between cybersecurity and functional safety.
7. Identify privacy, ethical, regulatory and lifecycle-governance responsibilities.
8. Recommend practical controls for an IoT product or deployment.

1. Security, Safety and Governance as a System Property

Security is the protection of assets against unauthorized access, alteration, destruction or disruption. In IoT, assets include firmware, cryptographic keys, sensor data, actuator commands, identities, user information, network services and physical processes.

The classic security objectives are commonly summarized as follows:

• Confidentiality: information is disclosed only to authorized parties.
• Integrity: information and software remain accurate and unaltered.
• Availability: authorized users and processes can access required functions.
• Authenticity: an entity, message or software image is genuine.
• Accountability: actions can be attributed to an identity or system component.
• Non-repudiation: evidence supports the claim that a party performed an action, where legally and technically appropriate.

IoT adds two particularly important dimensions. Safety concerns preventing unacceptable physical harm, even when failures are accidental or caused by environmental conditions. Resilience concerns the ability to continue safe operation, recover and adapt during faults or attacks.

Security and safety overlap but are not identical. A malicious command to open a valve is a security incident with a potential safety consequence. A failed temperature sensor may be a safety failure without being a cyberattack. A secure system must therefore address both intentional threats and accidental failures.

Governance is the set of policies, roles, decisions, controls and evidence through which an organization directs and supervises the IoT lifecycle. It answers questions such as:

• Who owns the device and its data?
• Who may approve firmware releases?
• How long will security updates be provided?
• Which events must be logged and reported?
• What happens when a device reaches end of life?
• Which laws, contracts and standards apply?

2. A Layered Security Architecture

A useful architecture separates controls into layers:

Layering is important because no individual control is sufficient. Encryption does not prevent an attacker from installing altered firmware. Secure boot does not protect a stolen cloud password. Access control does not compensate for an exposed private key. Defence in depth combines independent controls so that failure of one control does not automatically compromise the entire system.

3. Threat Modelling and Risk Assessment

Threat modelling is a structured examination of what can go wrong, how an attacker or fault could cause it, and which controls reduce the risk. It should begin during requirements analysis rather than after implementation.

3.1 Identify assets and boundaries

Create an asset inventory covering devices, firmware, keys, data, cloud services, users, physical processes and update infrastructure. Draw trust boundaries wherever data or authority crosses between components. Examples include the boundary between a sensor and gateway, gateway and cloud, vendor update server and device, or technician and maintenance interface.

3.2 Identify actors and threats

Actors may include legitimate users, administrators, installers, service providers, malicious insiders, remote attackers, counterfeit manufacturers and opportunistic attackers. Threats include:

• Firmware replacement or downgrade
• Theft or extraction of keys
• Credential guessing and account takeover
• Eavesdropping and traffic modification
• Replay of previously valid commands
• Denial of service or battery exhaustion
• Malicious sensor data or actuator commands
• Supply-chain compromise
• Abuse of personal data
• Physical tampering and unauthorized debugging

A compact model is STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. STRIDE is a classification aid, not a substitute for engineering judgement.

3.3 Estimate and treat risk

Risk is often represented qualitatively as a combination of likelihood and impact. A simple risk-priority model is:

Here, R is a risk score, L is the likelihood score and I is the impact score. The scales must be defined by the organization, for example 1 to 5. This multiplication is a prioritization convention, not a universal law of probability. It is applicable when the organization accepts ordinal scoring and documents how scores are interpreted.

For a likelihood of 4 and an impact of 5:

A score of 20 might be classified as high, but the threshold must be established by policy. A low-likelihood event with catastrophic safety impact may require treatment even if its numerical score is not the highest.

Risk treatment options are to avoid, reduce, transfer or accept risk. Controls should be linked to specific threats and verified through testing. Residual risk—the risk remaining after controls—must be documented and accepted by an appropriately authorized person.

3.4 Security requirements and assurance

Threat modelling should produce testable requirements, such as:

• The device shall reject firmware without a valid vendor signature.
• Private keys shall not be exportable through the debug interface.
• Safety-critical commands shall require authenticated and authorized sessions.
• Failed updates shall recover to a known-good image.
• Personal data shall be retained only for an approved period.

Evidence may include design reviews, source-code analysis, penetration tests, fuzz testing, update tests, manufacturing records, vulnerability scans and incident exercises.

4. Cryptographic Foundations for IoT

Cryptography protects data and establishes trust, but it must be correctly implemented and managed.

4.1 Symmetric and asymmetric cryptography

Symmetric cryptography uses the same secret key for encryption and decryption. It is efficient and suitable for sensor data, firmware storage and authenticated sessions. Examples include AES and authenticated-encryption modes such as AES-GCM or ChaCha20-Poly1305, when implemented by a properly reviewed library.

Asymmetric cryptography uses a private key and a corresponding public key. The private key is kept secret; the public key may be distributed. Digital signatures allow a verifier to check that a message or firmware image was produced by the holder of the private key. Public-key techniques are also useful for establishing session keys and device identities, though they generally require more computation than symmetric operations.

Encryption alone does not guarantee integrity. A system should use authenticated encryption or a separate, correctly designed message-authentication mechanism. Nonces and initialization vectors must follow the algorithm's requirements; accidental nonce reuse can seriously weaken security.

4.2 Hashes and digital signatures

A cryptographic hash maps input data to a fixed-length digest. A small change in the input should produce a different digest, but a hash is not a secret and does not prove who created the data. A digital signature combines a private key with a message or digest. Verification uses the public key and establishes authenticity and integrity under the assumptions of the algorithm and key-management system.

For firmware, the usual process is:

1. Build and test the image.
2. Compute its cryptographic digest.
3. Sign the image or a manifest containing the digest, version and device constraints.
4. Distribute the image and signature through an authenticated channel.
5. Verify the signature and policy on the device before installation.

The signing private key requires stronger protection than an ordinary application credential. Access should be restricted, logged and preferably protected by a hardware security module or equivalent controlled service.

5. Secure Boot and Hardware Roots of Trust

Secure boot is a chain of verification beginning with an immutable or highly protected first-stage component. Each stage verifies the next stage before execution. A typical chain is read-only boot ROM → first-stage bootloader → second-stage bootloader → operating system or application firmware.

The first verification key, hash or verification mechanism is called a root of trust. If the root can be replaced silently, the chain is not trustworthy. Hardware roots of trust may include secure elements, trusted platform modules, protected key storage, one-time programmable memory, hardware random-number generators and isolated execution environments.

Secure boot should address more than signature validity. It should also enforce:

• Correct device or product type
• Approved firmware version
• Compatibility of configuration and hardware
• Revocation of compromised signing keys
• Rollback prevention
• Recovery from interrupted updates

Measured boot records measurements of software components for later inspection or remote attestation. Unlike secure boot, which prevents unauthorized code from running, measured boot primarily provides evidence of what was loaded. The two can be used together.

Physical security remains relevant. Debug ports such as JTAG or SWD should be disabled, authenticated or restricted in production. However, development access must be preserved in a controlled way for manufacturing and service. A documented service mode is safer than an undocumented backdoor.

6. Identity, Authentication and Authorization

A device identity should be unique, protected and lifecycle-managed. Reusing one universal password or private key across thousands of devices creates a catastrophic single point of compromise. Better designs provision a unique key or certificate per device, ideally during a controlled manufacturing process.

Authentication establishes who or what is communicating. It may use:

• A password, although passwords are weak for unattended devices.
• A pre-shared key, suitable for constrained environments only when securely provisioned and rotated.
• Public-key certificates and mutual TLS.
• Hardware-backed device keys.
• Short-lived tokens issued by an identity service.

Authorization determines what an authenticated identity may do. It should follow least privilege: an identity receives only the permissions required for its task. A temperature sensor may publish readings but should not issue actuator commands. A technician may retrieve diagnostics but not alter safety limits without additional approval.

Role-based access control assigns permissions to roles, while attribute-based access control evaluates attributes such as device type, location, time and operational state. Safety-critical operations may need separation of duties, dual approval or a local physical action in addition to remote authorization.

Authentication does not make commands safe. The receiving system must validate range, timing, state and physical consequences. For example, a command to increase motor speed may be authenticated but still invalid when a guard is open.

7. Key Management

Key management includes generation, provisioning, distribution, storage, use, rotation, backup, revocation and destruction. In practice, weak key management is more frequently responsible for failure than the choice of cryptographic algorithm.

A lifecycle may include:

1. Generate keys using an approved cryptographic random source.
2. Bind each key to a device identity and intended purpose.
3. Provision keys through a controlled and auditable process.
4. Store private keys in protected hardware when feasible.
5. Use separate keys for distinct purposes, such as device authentication, firmware signing and data encryption.
6. Rotate or replace keys according to risk and lifecycle events.
7. Revoke credentials when devices are stolen, decommissioned or compromised.
8. Erase secrets securely at retirement.

Key derivation can create purpose-specific keys from a protected root, but derived keys must not be confused with independent trust domains. A compromise of the root may expose all derived keys. Backups must be encrypted and access-controlled, and recovery procedures must be tested.

8. Secure Communication and Secure Updates

Communication security should provide confidentiality, integrity, peer authentication and replay resistance where required. TLS is commonly used over reliable transport, while DTLS supports datagram transport. Protocol selection must consider the device's memory, power, latency and network conditions. Application messages may still require their own sequence numbers, timestamps or counters.

A secure update mechanism is a central IoT security capability. It should include:

• Authenticated distribution and encrypted transport where confidentiality is needed
• Signed images and verified manifests
• Version and compatibility checks
• Atomic installation or a recovery partition
• Watchdog-assisted rollback after failed boot
• Anti-rollback counters or protected version metadata
• Staged deployment and monitoring
• Revocation and emergency response procedures
• A documented end-of-support policy

Encryption of an update channel does not replace signing. A compromised update server could otherwise distribute an authentic but maliciously altered image to devices that trust the channel. Conversely, signing does not necessarily hide proprietary code or sensitive configuration.

Updates should be tested on representative hardware and deployed gradually. A fleet-wide update without health monitoring can create a common-mode failure. Devices should report update status without exposing sensitive information.

9. Functional Safety and Resilience

Functional safety addresses risks arising from malfunctioning systems. Safety engineering commonly uses hazard identification, risk reduction, safety requirements, verification, validation and controlled change. The exact process depends on the industry; automotive, industrial, medical, railway and aviation sectors have different standards and assurance expectations.

A safety function should define:

• The hazardous condition
• The safe state
• Detection mechanisms
• Response time
• Independence or diversity of protective controls
• Diagnostic coverage
• Recovery and maintenance procedures

Cybersecurity controls must not undermine safety. For example, aggressive authentication retries could delay an emergency shutdown, while encryption processing could consume power needed for a safety sensor. Conversely, safety mechanisms should not become an unauthenticated bypass into the system.

A robust design often uses fail-safe or fail-operational behaviour depending on the application. A heating controller may shut down when its sensor is invalid; an autonomous vehicle may need controlled degraded operation rather than immediate shutdown. The appropriate response follows hazard analysis, not a general rule.

Resilience includes graceful degradation, local control during cloud outage, watchdogs, redundant sensing, rate limiting, backup configurations and incident recovery. Cloud connectivity should not be treated as the sole source of safety authority for a time-critical local process.

10. Privacy and Ethical Governance

IoT devices can collect location, voice, health, occupancy, behavioural and industrial information. Privacy protection begins with data minimization: collect only what is necessary for a stated purpose. Other principles include purpose limitation, transparency, accuracy, retention limitation, access control, user rights and secure disposal.

A privacy impact assessment should identify:

• What data is collected and whether it is personal or sensitive
• Why it is collected and who receives it
• Whether consent or another lawful basis is required
• How long it is retained
• Whether data leaves the jurisdiction
• What could happen if it is exposed or misused
• How individuals can access, correct or delete data where applicable

Anonymization is difficult when multiple datasets can be combined. Pseudonymized data may still be personal data if re-identification remains possible. Aggregation, edge processing and selective transmission can reduce exposure, but they do not eliminate the need for governance.

Ethical design requires more than legal compliance. Engineers should consider surveillance, discrimination, unequal access, manipulative defaults, environmental effects and the consequences of inaccurate automated decisions. Users should receive understandable information and meaningful control. Security telemetry should be proportionate and should not become an excuse for unlimited monitoring.

11. Standards, Compliance and Device Governance

Standards provide vocabulary, controls and assurance practices, but compliance with a standard is not identical to being secure. Relevant references may include:

• ISO/IEC 27001 for information-security management systems
• ISO/IEC 27005 for information-security risk management
• ISO/IEC 27400 for IoT security and privacy principles
• NIST Cybersecurity Framework and NIST guidance for IoT device capabilities
• IEC 62443 for industrial automation and control-system security
• IEC 61508 for functional safety of electrical, electronic and programmable systems
• Sector-specific medical, automotive or railway regulations
• National privacy, cybersecurity, product-safety and breach-notification laws

The applicable requirements depend on jurisdiction, sector, device function and data type. A product team should maintain a compliance matrix linking each requirement to an owner, implementation evidence and verification method.

Device governance should cover the complete lifecycle:

An accurate asset inventory is foundational. Each device should have an owner, location or logical scope, firmware version, support status, identity record and risk classification. Software bills of materials can help identify vulnerable components and support supply-chain response.

12. Applied Case: Illustrative Smart Irrigation Controller

Background

A municipal water authority deploys 8,000 IoT irrigation controllers. Each controller measures soil moisture and weather conditions and operates valves through a cloud dashboard. Maintenance contractors access the system remotely.

Problem

The original design uses a shared administrator password, unsigned firmware, an exposed maintenance port and unrestricted cloud commands. A compromised contractor account could open valves continuously, waste water and damage public landscaping. A malicious update could also alter firmware across the fleet.

Analysis

Assets include valve commands, device credentials, firmware, location data, water-use records and the physical irrigation system. Threats include credential theft, firmware replacement, replayed commands, denial of service and contractor misuse. Safety consequences are moderate, but availability, financial cost, environmental impact and public trust are significant.

Using a 1–5 qualitative scale, the team gives remote unauthorized valve operation likelihood 4 and impact 4, producing R = 4 × 4 = 16. The organization classifies this as high priority. The score is used for comparison; it does not replace judgement about environmental or legal consequences.

Approach and solution

The authority assigns each controller a unique device certificate and stores its private key in a secure element. Mutual TLS authenticates controllers and the cloud. Contractor access uses named accounts, multifactor authentication and role-based permissions. Operators can issue commands only to assigned zones, and high-volume or unusual commands require approval.

The bootloader verifies signed firmware and rejects versions below a protected minimum version. Updates are staged to a small pilot group before wider deployment. A watchdog and inactive fallback partition support recovery. Debug access is disabled in production. The controller validates command rate, valve duration and local soil or pressure conditions, so an authenticated but unreasonable command is rejected.

The cloud records command identity, time, target zone and result. Logs are protected from ordinary operators and reviewed for anomalies. Location and usage data are minimized, retained according to policy and separated from unnecessary personal information. A documented incident process can revoke certificates, isolate zones and restore known-good firmware.

Outcome

The redesign removes the universal password, limits contractor authority, prevents unsigned and downgraded firmware, and provides evidence for investigations. The system continues local irrigation schedules during temporary cloud outages, while safety and environmental limits remain enforced locally.

Learning points

1. Device identity must be individual, not shared across a fleet.
2. Authentication must be combined with authorization and command validation.
3. Secure boot and signed updates protect the firmware supply chain.
4. Local controls improve resilience when cloud services fail.
5. Governance—ownership, logs, retention and incident response—is part of engineering, not paperwork added afterward.

13. Challenges and Contemporary Developments

IoT security is constrained by cost, legacy protocols, battery life, limited memory, long support periods and fragmented ownership. Retrofitting a hardware root of trust may be impossible on an existing device. Stronger algorithms do not solve insecure defaults or unmaintained software.

Emerging practices include remote attestation, confidential computing, automated vulnerability monitoring, reproducible builds, software bills of materials, zero-trust architectures and post-quantum cryptography research. These technologies should be adopted according to threat and lifecycle needs. For example, remote attestation can provide evidence of device state, but it requires trustworthy measurement, reliable verification and a response policy. Artificial intelligence can help detect unusual device behaviour, but false positives, biased models, privacy concerns and adversarial manipulation must be evaluated.

Sustainable security requires support commitments. Manufacturers should publish vulnerability-reporting channels, define update periods, communicate end of support and avoid forcing users to replace functioning hardware unnecessarily. Security-by-design is both a technical and organizational commitment.

Best-Practice Checklist

Before deployment, confirm that:

• Assets, trust boundaries, threats and hazards are documented.
• Each device has a unique identity and protected credentials.
• Secure boot verifies authorized and non-rolled-back firmware.
• Debug and maintenance interfaces are controlled.
• Communications provide authentication and integrity.
• Authorization follows least privilege and separation of duties.
• Keys can be rotated, revoked, backed up and destroyed appropriately.
• Updates are signed, tested, staged and recoverable.
• Local safe behaviour exists during network or cloud failure.
• Logs support accountability without excessive data collection.
• Privacy, legal and sector requirements are mapped to evidence.
• Vulnerability response, support duration and retirement are defined.

Chapter Summary

Embedded IoT security is a lifecycle and system property involving hardware, firmware, communications, cloud services, people and governance. Confidentiality, integrity, availability, authenticity and accountability must be considered together with safety and resilience. Threat modelling identifies assets, trust boundaries, threats, hazards and controls; risk scoring supports prioritization but does not replace expert judgement.

Secure boot creates a verification chain rooted in protected hardware or immutable code. Encryption protects confidentiality, while signatures and authenticated protocols protect integrity and authenticity. Unique device identities, least-privilege authorization and disciplined key management are essential. Secure updates require signed images, version control, rollback protection, recovery and staged deployment.

Cybersecurity and functional safety must be coordinated so that security controls do not obstruct emergency behaviour and safety mechanisms do not create unauthorized access. Privacy requires minimization, purpose limitation, retention control and transparency. Standards and regulations provide structured expectations, while governance assigns ownership across design, manufacture, operation, maintenance, incident response and retirement. Effective IoT engineering therefore combines technical controls with ethical, legal and organizational responsibility.

Key Terms

Authentication: Verification of the identity of a user, device or service.

Authorization: Determination of actions an authenticated identity is permitted to perform.

Availability: Ability of an authorized system or service to function when required.

Confidentiality: Protection of information from unauthorized disclosure.

Digital signature: Cryptographic evidence used to verify origin and integrity of data or software.

Firmware: Software stored in or closely associated with embedded hardware.

Functional safety: Prevention of unacceptable risk caused by malfunctioning systems.

Hardware root of trust: Protected hardware or immutable code used as a foundation for security decisions.

Integrity: Assurance that data or software has not been improperly altered.

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

Least privilege: Practice of granting only the permissions necessary for a task.

Measured boot: Recording measurements of loaded software for later verification or attestation.

Nonce: A value intended for one-time use in a cryptographic operation.

Privacy by design: Incorporation of privacy protection into system architecture and lifecycle processes.

Risk assessment: Evaluation of threats, likelihood, impact and required treatments.

Secure boot: Verification of each software stage before it is allowed to execute.

Secure update: Authenticated and controlled replacement of device software.

Threat modelling: Systematic analysis of assets, attackers, threats, vulnerabilities and controls.

Trust boundary: A point where data, authority or assumptions change between components.

Vulnerability: A weakness that can be exploited to compromise a system or cause harm.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization in an IoT system.
2. Why is a digital signature required for firmware updates even when the update channel uses encryption?
3. State two differences between secure boot and measured boot.
4. What is meant by least-privilege access control?
5. Name four activities included in cryptographic key management.

Long Answer Questions

1. Explain a complete secure-boot chain for an embedded IoT controller, including the role of a hardware root of trust.
2. Describe how a secure firmware-update process should handle signing, version control, staged deployment and failure recovery.
3. Explain how threat modelling and qualitative risk assessment can guide IoT security requirements.
4. Discuss the relationship between cybersecurity, functional safety and resilience in a remotely controlled device.
5. Explain the major privacy and governance responsibilities across the IoT device lifecycle.

Analytical / Application Questions

1. A fleet uses one shared password and unsigned firmware. Analyse the principal threats and propose a prioritized redesign.
2. A safety controller must continue operating during cloud outages, but operators also require secure remote commands. Design an architecture that balances local safety, authentication, authorization and resilience.
3. A device collects household occupancy, temperature and location data. Develop a privacy and governance plan covering minimization, retention, access, incident response and retirement.

Multiple Choice Questions with Answers

Question 1

Which control primarily prevents unauthorized firmware from executing during startup?

A. Secure boot

B. Data minimization

C. Role-based billing

D. Network compression

Correct Answer: A. Secure boot

Question 2

What is the main purpose of a digital signature on a firmware image?

A. To increase battery capacity

B. To verify origin and integrity

C. To hide all network traffic

D. To assign physical location

Correct Answer: B. To verify origin and integrity

Question 3

A sensor is allowed to publish readings but not operate a valve. Which principle is illustrated?

A. Least privilege

B. Data replication

C. Rollback

D. Anonymization

Correct Answer: A. Least privilege

Question 4

If likelihood is scored as 4 and impact as 5 using R = L × I, what is the risk score?

A. 9

B. 16

C. 20

D. 25

Correct Answer: C. 20

Question 5

Which feature most directly supports recovery from an interrupted firmware update?

A. A fallback or recovery image

B. A longer device name

C. A larger display

D. Unencrypted logging

Correct Answer: A. A fallback or recovery image

Question 6

What is a hardware root of trust?

A. A public social-media account

B. A protected foundation for security verification

C. A temporary network address

D. A user-interface theme

Correct Answer: B. A protected foundation for security verification

Question 7

Which statement best describes authorization?

A. It verifies that a device is powered on

B. It determines what an authenticated identity may do

C. It compresses sensor readings

D. It generates weather forecasts

Correct Answer: B. It determines what an authenticated identity may do

Question 8

Why should a device fleet avoid one universal private key?

A. It makes displays brighter

B. Compromise of one key could affect the entire fleet

C. It prevents all encryption

D. It eliminates the need for updates

Correct Answer: B. Compromise of one key could affect the entire fleet

Question 9

Which practice best reflects data minimization?

A. Collecting every available sensor value indefinitely

B. Collecting only data necessary for a stated purpose

C. Sharing all data with contractors by default

D. Disabling access controls after deployment

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

Question 10

Which statement about safety and security is correct?

A. They are identical and require no separate analysis

B. Safety concerns only confidentiality

C. A security attack can create a safety consequence, but accidental safety failures also exist

D. Safety eliminates the need for authentication

Correct Answer: C. A security attack can create a safety consequence, but accidental safety failures also exist