Connected Systems, Cybersecurity and Governance

Introduction

A microcontroller rarely operates in isolation. A motor controller may report temperature to a supervisory system, a wearable device may synchronize with a cloud service, and an industrial sensor may influence a safety-related decision. Connectivity increases capability, but it also creates pathways through which systems can be observed, manipulated, interrupted, or used to collect information without appropriate consent.

A connected embedded system must therefore be designed as both a control system and a security-relevant information system. Security mechanisms such as authentication, encryption, secure boot, access control, and governed updates must be integrated with timing, power, memory, safety, reliability, and maintainability requirements. Security is not a feature added after hardware and firmware are complete; it is a lifecycle property.

This chapter develops a practical framework for designing secure IoT and industrial edge nodes using wired and wireless networks. It also examines privacy, functional safety, ethics, standards, supply-chain risk, and responsible data management.

Learning objectives

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

1. Describe the architecture and threat surface of a connected microcontroller system.
2. Select suitable wired or wireless connectivity for a stated application.
3. Explain authentication, encryption, integrity protection, secure boot, and access control.
4. Design a defensible firmware-update and key-management process.
5. Apply threat modelling and risk-based security decisions.
6. Relate cybersecurity to safety, privacy, ethics, standards, and supply-chain governance.
7. Evaluate a connected-node design using technical and organizational criteria.

1. Connected embedded-system architecture

A connected node usually contains five interacting planes:

• Sensing and actuation plane: sensors, ADCs, timers, motors, relays, and safety interlocks.
• Compute plane: microcontroller, memory, cryptographic accelerator, watchdog, and secure storage.
• Communication plane: UART, SPI, I²C, CAN, Ethernet, Wi-Fi, Bluetooth Low Energy, cellular, or industrial protocols.
• Management plane: identity provisioning, configuration, diagnostics, logging, update, and recovery.
• Human and organizational plane: operators, maintainers, administrators, suppliers, policies, and legal obligations.

A useful distinction is between an edge node, which performs local sensing or control, and a gateway, which aggregates nodes and commonly provides protocol conversion, stronger computation, or access to enterprise systems. Cloud services may provide long-term storage and analytics, but a safety-critical control loop should not depend on an unreliable wide-area connection unless that dependency has been explicitly engineered and validated.

Figure: A connected edge-node architecture with cross-cutting security controls.

2. Connectivity choices and protocol boundaries

Connectivity should be selected from requirements rather than popularity. Relevant criteria include range, data rate, latency, determinism, power consumption, electromagnetic environment, installation cost, network ownership, physical exposure, and security support.

A protocol boundary is a security boundary only when it is deliberately protected. For example, a CAN bus may be physically inaccessible inside a cabinet, but a compromised maintenance laptop connected to the cabinet can still inject frames. Similarly, a private Wi-Fi network is not a substitute for device authentication and authorization.

Application protocols should define message types, lengths, units, timestamps, sequence numbers, error handling, and permissible ranges. Parsers should reject malformed, oversized, stale, duplicated, or out-of-order messages. A message that is authentic but outside a safe operating range must still be rejected by the control application.

3. Threat modelling for microcontroller systems

Threat modelling is a structured way to ask what can go wrong, who may cause it, and what controls are proportionate. A practical process is:

1. Establish scope and assets. Identify firmware, keys, calibration data, personal data, process parameters, availability, and physical safety.
2. Map trust boundaries and data flows. Mark radio links, debug ports, gateways, cloud APIs, supplier tools, and removable media.
3. Identify adversaries. Consider opportunistic attackers, remote criminals, malicious insiders, competitors, nation-state actors, and accidental operators.
4. Enumerate threats. Spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege are useful categories.
5. Estimate risk. Consider likelihood, impact, exposure, detectability, and existing controls.
6. Choose treatments. Avoid, reduce, transfer, or accept risk with documented authority.
7. Verify residual risk. Test both preventive and recovery controls.

Assets include more than confidential information. A machine’s availability and integrity may be more important than secrecy. A false temperature reading can cause unsafe heating; a denial-of-service attack can stop production; a stolen device identity can permit fraudulent commands.

A basic qualitative risk register can use low, medium, and high ratings. Numerical scores can be useful for prioritization, but they should not create false precision. If a quantitative model is used, a common simplified representation is:

Here, likelihood and impact are defined ordinal or numerical ratings under the organization’s stated scale. The multiplication is a prioritization convention, not a probability law; it is meaningful only when the scales and decision thresholds are defined consistently.

4. Identity, authentication, and authorization

Identification claims an identity; authentication verifies that claim; authorization determines what an authenticated entity may do. These are distinct decisions.

A robust device identity is normally unique per device. Shared factory passwords and copied symmetric keys create catastrophic common-mode risk. Better approaches include a hardware-protected private key, a device certificate signed by an organizational certificate authority, and a controlled provisioning record. The private key should be generated in or imported into protected storage and should not be readable through ordinary firmware interfaces.

Authentication factors may include:

• something the device has, such as a private key or hardware token;
• something a user knows, such as a password or PIN;
• something a user is, such as a biometric characteristic;
• contextual evidence, such as a network or physical location.

For machine-to-machine communication, certificate-based mutual TLS is often appropriate. The server authenticates the device and the device authenticates the server. Constrained devices may use OSCORE, DTLS, or a carefully designed application-layer protocol, depending on available libraries and lifecycle support.

Authorization should follow least privilege. A temperature sensor should not possess permission to update firmware; a maintenance technician may calibrate a device but not change production safety limits; an analytics service may read aggregated data but not issue actuator commands. Roles, capabilities, scopes, and time-limited maintenance credentials are practical mechanisms.

Credentials require lifecycle management: issuance, activation, rotation, revocation, expiry, backup, and secure destruction. A certificate that cannot be revoked or replaced is a long-term operational liability.

5. Encryption, integrity, and replay protection

Encryption protects confidentiality, while a message authentication code or authenticated-encryption mode protects integrity and authenticity. Modern designs should prefer authenticated encryption, such as AES-GCM or ChaCha20-Poly1305, through a well-maintained implementation. Encryption does not by itself prove who sent a message, and authentication does not hide its content.

A secure session normally negotiates keys using an authenticated key-establishment protocol, then uses fresh nonces and session keys. Nonces must not be reused with the same key in modes such as AES-GCM. Random numbers must come from a cryptographically secure random-number source; predictable pseudo-random values can undermine otherwise correct cryptography.

Replay protection requires freshness. A protocol may use a monotonically increasing counter, a nonce, a timestamp within an accepted window, or a challenge-response exchange. Counters must survive reset or be designed so that rollback cannot cause acceptance of old commands. Time-based protection requires a trustworthy clock source and careful handling of loss of synchronization.

Sensitive data should be minimized before transmission. Encryption in transit does not protect data after it reaches an authorized but compromised service, nor does it justify collecting information that is unnecessary for the stated purpose.

6. Secure boot and the firmware trust chain

Secure boot establishes that the processor executes only approved firmware. A typical chain is:

1. immutable ROM code verifies a first-stage bootloader;
2. the bootloader verifies the operating firmware signature;
3. the firmware verifies selected configuration or application components;
4. hardware security features prevent unauthorized rollback or key extraction.

Digital signatures provide authenticity of the firmware publisher. A cryptographic hash provides a compact integrity measurement, but a hash alone does not identify who approved the image. Verification must occur before execution, and failure must lead to a defined safe state rather than silently executing unverified code.

Keys should be separated by purpose: signing, encryption, device identity, and debugging should not all use one key. Signing keys require especially strong protection, controlled access, audit trails, offline or hardware-backed storage, and documented compromise response. Debug interfaces such as JTAG and SWD should be disabled, authenticated, or physically controlled in production, while preserving an authorized recovery method.

Secure boot does not guarantee secure software. It can ensure that the approved image runs, but the approved image may contain vulnerabilities, excessive privileges, unsafe parsers, or insecure default settings.

7. Secure updates and update governance

Connected products need updates because vulnerabilities, certificates, dependencies, and operational requirements change. An update system should provide:

• authenticated and integrity-protected images;
• version and anti-rollback policy;
• compatibility checks for hardware and configuration;
• power-loss tolerance, commonly through A/B images or an atomic swap;
• staged deployment, monitoring, and a tested rollback plan;
• signed release metadata and an auditable approval process;
• recovery procedures when connectivity fails.

An update package should not be accepted merely because it is newer. It must be intended for the device model, have a valid signature, satisfy policy, and pass post-installation health checks. Update servers and signing infrastructure are high-value assets and must be protected as carefully as devices.

Governance assigns responsibility: who approves a release, who tests it, who can pause deployment, how vulnerabilities are reported, how long products are supported, and how customers are informed. A software bill of materials (SBOM) helps identify vulnerable open-source and commercial components. Vulnerability disclosure and incident-response procedures should exist before deployment, not after an incident.

8. Safety, reliability, and cybersecurity together

Cybersecurity and functional safety overlap but are not identical. Safety asks how to prevent unacceptable harm from faults and hazards; cybersecurity asks how to resist intentional or accidental misuse. A security control that increases latency may affect a control loop. A fail-safe state that stops a motor may protect people but cause process damage if invoked too readily. These trade-offs require hazard analysis, timing analysis, testing, and engineering authority.

Important design patterns include:

• independent emergency-stop and protective circuits where required;
• bounded command ranges and rate limits;
• watchdog timers and brownout handling;
• local safe operation when the network is unavailable;
• separation of safety functions from non-safety communications;
• event logging that does not endanger real-time performance;
• deterministic recovery after reset.

A network command should be treated as an input to a safety-validated state machine, not as an unquestionable instruction. Safety standards and sector regulations may require formal evidence, independence, traceability, and validation beyond ordinary cybersecurity practice.

9. Privacy and responsible data management

Even industrial data can reveal individuals, working patterns, production capacity, or commercially sensitive information. Responsible data management follows purpose limitation, data minimization, accuracy, retention limitation, access control, transparency, and secure disposal. These principles appear in different forms across privacy laws and organizational policies.

Designers should ask:

• What data is actually necessary?
• Is the device collecting identifiable or inferential information?
• Who owns, controls, and may access the data?
• Where is it stored and transferred?
• How long is it retained?
• Can a person or organization exercise applicable rights?
• What happens when a device is sold, repaired, decommissioned, or recycled?

Edge processing can reduce transmission and exposure by converting raw data into local summaries. However, it is not automatically private: a supposedly anonymous time series may permit re-identification when combined with other data. Privacy impact assessments, documented data flows, access reviews, and deletion procedures are therefore technical and governance tasks, not merely legal paperwork.

10. Standards, governance, and supply-chain risk

Standards provide vocabulary, controls, and evidence expectations. Relevant families may include ISO/IEC 27001 for information-security management, IEC 62443 for industrial automation and control-system security, NIST Cybersecurity Framework and NIST SP 800-系列 guidance, ISO/IEC 27400 for IoT security and privacy concepts, and sector-specific functional-safety standards such as IEC 61508. Product-security legislation and privacy law vary by jurisdiction; engineers must verify current requirements rather than assume that a standard is legally sufficient.

Standards do not replace engineering judgment. A compliance checklist may miss an undocumented maintenance port, a weak supplier process, or an unsafe recovery design. Governance should connect requirements to architecture, tests, ownership, evidence, and review dates.

Supply-chain risks include malicious or vulnerable components, counterfeit chips, compromised build tools, leaked signing keys, unmaintained libraries, opaque cloud dependencies, and supplier access that remains active after commissioning. Controls include:

• approved-vendor and component inventories;
• reproducible or controlled builds;
• signed source and artifact provenance;
• SBOMs and vulnerability monitoring;
• supplier security requirements and notification duties;
• incoming inspection and hardware authenticity checks;
• separation of development, test, and production credentials;
• secure disposal and revocation at end of service.

11. Illustrative case: secure condition-monitoring nodes

Background

A manufacturer deploys 600 wireless vibration and temperature nodes on motors. Nodes report measurements to an industrial gateway. Maintenance staff use a tablet to configure sampling intervals and update firmware.

Problem

The first prototype uses one shared password, accepts configuration commands over an unencrypted connection, leaves the debug port enabled, and overwrites its only firmware image during updates. A malicious or careless user could alter thresholds, obtain measurements, or disable nodes during a power interruption.

Analysis

Assets include motor availability, measurement integrity, firmware, maintenance credentials, and worker-related information in maintenance logs. Trust boundaries exist at the radio link, tablet, gateway, firmware-update service, and physical enclosure. The most serious consequences are false maintenance decisions, loss of monitoring, and unsafe operation if a control function later relies on the data.

Approach and solution

Each node receives a unique device identity and certificate during controlled provisioning. The tablet authenticates to the gateway using an organizational account with multifactor authentication, while the gateway authenticates nodes using mutual TLS. Configuration commands are authorized by role and limited to permitted ranges.

The firmware uses signed images, secure boot, disabled production debug access, encrypted storage for sensitive credentials, and an A/B update design. A monotonic firmware version prevents unauthorized rollback. Nodes buffer a bounded amount of data locally and enter a defined monitoring-only mode when the gateway is unavailable. The gateway validates message freshness and rejects duplicate commands.

The organization maintains an asset inventory, SBOM, release approvals, vulnerability-reporting channel, and incident procedure. Data retention is limited to the period needed for maintenance analysis. Security tests include malformed-message tests, credential-revocation tests, radio attack assessment, power-loss update tests, and recovery drills.

Outcome

The redesign costs more than the prototype, but it prevents a single shared credential from compromising the whole fleet, makes updates recoverable, and gives operators a controlled response when communications fail. Residual risks remain, including physical tampering and gateway compromise, so monitoring and periodic review continue.

Learning points

Security architecture must include operators, gateways, update services, and suppliers. Strong cryptography cannot compensate for poor authorization or unsafe recovery. Availability and safety requirements must be tested together with confidentiality and integrity.

12. Practical engineering workflow

A disciplined project workflow is:

1. Define safety, privacy, performance, power, lifecycle, and regulatory requirements.
2. Draw data-flow and trust-boundary diagrams.
3. Create an asset and threat register.
4. Select protocols with maintained security libraries and suitable update support.
5. Design identity provisioning, key storage, authorization, logging, and recovery before coding.
6. Implement secure boot, protected debug access, input validation, and fail-safe behavior.
7. Test firmware, hardware, communications, update interruption, and physical interfaces.
8. Conduct independent review and penetration testing appropriate to risk.
9. Deploy gradually with monitoring and rollback capability.
10. Maintain inventories, SBOMs, patches, incident response, and end-of-life plans.

Useful evidence includes requirements traceability, threat-model decisions, code-review records, test results, cryptographic-key custody records, update logs, and recovery-test reports.

13. Challenges and contemporary developments

Small microcontrollers face limited memory, energy, processing capacity, and secure-storage options. Security libraries may be difficult to update, and legacy industrial equipment may lack modern identity mechanisms. Wireless availability can be intermittent, while cloud dependence introduces jurisdictional and availability concerns.

Hardware security modules, trusted execution environments, remote attestation, confidential computing at gateways, zero-trust architectures, and machine-readable SBOMs are increasingly important. Artificial intelligence can help detect unusual traffic or device behavior, but an AI detector is not a replacement for authentication, authorization, secure updates, or human incident response. AI systems also create concerns about false alarms, opaque decisions, training-data leakage, and adversarial manipulation.

The central professional principle is proportional, evidence-based security: protect the most consequential assets, make assumptions explicit, test controls under realistic conditions, and ensure that people remain accountable for safety and governance decisions.

Chapter Summary

Connected microcontroller systems combine sensing, actuation, computation, communications, management, and human responsibility. Their attack surface includes physical interfaces, protocols, firmware, credentials, gateways, cloud services, suppliers, and maintenance processes. Threat modelling identifies assets, trust boundaries, adversaries, consequences, and appropriate treatments.

Authentication establishes identity, authorization limits actions, encryption protects confidentiality, and integrity mechanisms detect alteration. Secure boot creates a firmware trust chain, while governed updates provide vulnerability remediation and recoverability. Unique device credentials, least privilege, protected keys, replay resistance, input validation, disabled production debug access, and tested recovery are foundational practices.

Cybersecurity must be integrated with functional safety, reliability, privacy, ethical data use, standards, supply-chain assurance, and lifecycle governance. Secure connected products require not only sound cryptography but also accountable ownership, evidence, monitoring, incident response, and end-of-life planning.

Key Terms

Access control: Rules determining which authenticated subjects may perform which actions.

Authenticated encryption: Encryption that also provides integrity and authenticity protection.

Authentication: Verification of a claimed identity.

Authorization: Decision about permitted actions after authentication.

Edge node: A local connected device that senses, computes, or actuates near the physical process.

Firmware: Software stored in a device to control its hardware functions.

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

Mutual TLS: A TLS arrangement in which both communicating endpoints authenticate one another.

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

Replay attack: Reuse of a previously valid message to produce an unauthorized effect.

Secure boot: A startup process that verifies approved firmware before execution.

SBOM: Software bill of materials listing software components and dependencies.

Supply-chain risk: Security or integrity risk introduced by suppliers, components, tools, or services.

Threat model: A structured description of assets, adversaries, attack paths, and controls.

Trust boundary: A location where data or authority crosses between different trust assumptions.

Vulnerability: A weakness that can be exploited to violate a security property.

Zero trust: An approach that continuously verifies access rather than inherently trusting network location.

Firmware rollback: Reversion to an earlier software version, which may be dangerous if it restores a known vulnerability.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, and authorization.
2. Why is a hash alone insufficient for authenticating firmware?
3. State two reasons why replay protection is needed in an actuator-command protocol.
4. What is the purpose of an SBOM?
5. Give two examples of how cybersecurity and functional safety can interact.

Long Answer Questions

1. Explain how secure boot, protected key storage, and signed updates form a firmware trust and maintenance process.
2. Compare CAN, Ethernet, Wi-Fi, and Bluetooth LE for a connected industrial sensing application.
3. Describe a complete threat-modelling process for an edge node connected to a cloud gateway.
4. Explain how privacy-by-design principles apply to an industrial monitoring system.
5. Discuss why supply-chain governance is part of embedded-system security.

Analytical / Application Questions

1. Design an identity, authorization, and update architecture for 1,000 battery-powered environmental nodes. Justify your choices and identify residual risks.
2. A remote motor controller loses network connectivity while receiving a command to increase speed. Propose a safe and secure state-machine response, including freshness, limits, logging, and recovery.
3. A supplier reports that the private signing key for a deployed product may have been exposed. Develop an incident-response and fleet-remediation plan, including technical and governance actions.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication encrypts data, while authorization compresses it.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication assigns an IP address, while authorization selects a protocol.

D. Authentication disables debug ports, while authorization updates firmware.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 2

What is the main purpose of secure boot?

A. To increase wireless range

B. To reduce sensor noise

C. To verify approved firmware before execution

D. To replace all access-control policies

Correct Answer: C. To verify approved firmware before execution

Question 3

Why is a unique device identity preferable to a shared factory password?

A. It eliminates the need for software updates.

B. It limits compromise to identifiable credentials and supports lifecycle management.

C. It guarantees that the device cannot be physically attacked.

D. It makes encryption unnecessary.

Correct Answer: B. It limits compromise to identifiable credentials and supports lifecycle management.

Question 4

Which control most directly helps prevent replay of an old actuator command?

A. A freshness counter or challenge-response mechanism

B. A larger display

C. A lower sensor sampling rate

D. An unconnected debug port

Correct Answer: A. A freshness counter or challenge-response mechanism

Question 5

What does authenticated encryption provide?

A. Confidentiality without integrity

B. Integrity and authenticity without confidentiality

C. Confidentiality together with integrity and authenticity protection

D. Physical protection from component counterfeiting

Correct Answer: C. Confidentiality together with integrity and authenticity protection

Question 6

Which update feature is most important when power may fail during installation?

A. A single image overwritten in place

B. An A/B image or atomic update strategy

C. A shared administrator password

D. Disabling version checks

Correct Answer: B. An A/B image or atomic update strategy

Question 7

Which example follows least-privilege design?

A. Every sensor can update every device in the fleet.

B. A read-only analytics service can issue actuator commands.

C. A maintenance role can calibrate assigned devices but cannot alter safety limits.

D. All operators share the signing-key password.

Correct Answer: C. A maintenance role can calibrate assigned devices but cannot alter safety limits.

Question 8

Why is a cryptographic hash alone insufficient to establish firmware publisher authenticity?

A. A hash cannot represent binary data.

B. A hash does not prove who approved or produced the image.

C. A hash always requires a wireless connection.

D. A hash prevents rollback automatically.

Correct Answer: B. A hash does not prove who approved or produced the image.

Question 9

Which statement about cybersecurity and functional safety is most accurate?

A. They are identical disciplines with identical evidence requirements.

B. Cybersecurity is relevant only when personal data is collected.

C. They address different concerns but can interact through availability, integrity, and unsafe commands.

D. Safety systems should always depend on cloud connectivity.

Correct Answer: C. They address different concerns but can interact through availability, integrity, and unsafe commands.

Question 10

Which practice best addresses software supply-chain visibility?

A. Using undocumented third-party libraries

B. Maintaining an SBOM and monitoring component vulnerabilities

C. Allowing suppliers to share production credentials

D. Removing release approval records

Correct Answer: B. Maintaining an SBOM and monitoring component vulnerabilities