Cybersecurity, Functional Safety, and Resilience

Introduction

Connected mechatronic systems combine sensors, actuators, embedded controllers, industrial networks, cloud services, and human interfaces. Connectivity improves observability and enables predictive maintenance, remote diagnosis, adaptive control, and coordinated production. It also creates paths through which an attacker, software defect, or component failure can affect physical motion, energy, product quality, or human safety.

Cybersecurity protects confidentiality, integrity, and availability of information and control functions. Functional safety reduces unacceptable risk arising from malfunctioning equipment or control systems. Resilience is the capability to continue safe operation, degrade gracefully, recover, and learn after disruption. These concerns overlap but are not identical. A system may be secure but unsafe, safe under accidental faults but vulnerable to deliberate manipulation, or operationally available while producing dangerous outputs.

For example, authentication may prevent an unauthorized user from issuing a command, but it does not by itself ensure that a correctly authenticated command is physically safe. Conversely, an emergency-stop circuit may place a machine in a safe state while an attacker has already caused production loss or stolen process data. Effective IoT engineering therefore treats safety and security as coordinated lifecycle disciplines.

Learning Objectives

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

1. Identify assets, trust boundaries, threats, vulnerabilities, and consequences in a connected mechatronic system.
2. Conduct a structured cybersecurity risk assessment.
3. Select appropriate identity, authentication, authorization, encryption, secure-boot, and key-management controls.
4. Design network segmentation, patching, monitoring, incident response, and resilient operating arrangements.
5. Explain the relationship between functional safety and cybersecurity.
6. Apply safety–security co-engineering to an industrial IoT case.
7. Evaluate ethical, regulatory, lifecycle, and practical limitations of proposed controls.

1. A System View of Cyber-Physical Risk

A useful analysis begins with the complete system rather than an individual device. A typical industrial IoT architecture contains:

• Field layer: sensors, drives, valves, robots, safety switches, and actuators.
• Control layer: programmable logic controllers (PLCs), safety PLCs, motion controllers, and embedded gateways.
• Supervisory layer: human–machine interfaces (HMIs), historians, engineering workstations, and manufacturing execution systems.
• Enterprise and service layer: databases, analytics, cloud platforms, maintenance portals, and mobile applications.
• Human and organizational layer: operators, technicians, suppliers, administrators, and emergency responders.

Each layer has different timing, availability, and safety requirements. A cloud dashboard can tolerate seconds of delay; a motion interlock may require a deterministic response. A confidentiality breach in a production report is serious, but unauthorized alteration of a robot-speed limit may directly create a hazard.

Important terminology includes:

• Asset: something requiring protection, such as a controller, safety function, recipe, credential, or production process.
• Threat: a circumstance or actor capable of causing harm.
• Vulnerability: a weakness that can be exploited or triggered.
• Attack surface: all reachable interfaces through which compromise may occur.
• Trust boundary: a point where information crosses between components with different assumptions about trust.
• Hazard: a potential source of physical harm.
• Risk: the combination of the likelihood of harm and its severity.
• Safety function: a function intended to prevent or reduce harm, such as guarded stop or overspeed protection.
• Security control: a technical, procedural, or physical measure that reduces security risk.
• Resilience: the ability to withstand, adapt to, recover from, and learn after disruption.

The central engineering question is not merely “Can this device be hacked?” It is “What could happen to the process if this component is compromised, unavailable, or misleading, and what independent barriers limit the consequence?”

2. Threat Modeling and Risk Assessment

2.1 Asset and data-flow analysis

Threat modeling is a structured examination of how a system can be misused or fail. Begin with a system context diagram and data-flow diagram. Identify data flows, protocols, users, external services, update channels, and trust boundaries. Record both cyber assets and physical consequences.

A practical asset inventory should include device identity, owner, location, firmware version, exposed services, network zone, safety role, dependencies, and recovery method. Unknown assets are a major risk because they cannot be patched, monitored, or included in response plans.

2.2 Threat sources and attack paths

Threat sources include external criminals, insiders, compromised suppliers, careless users, competitors, activists, and environmental or technical faults. Common attack paths include stolen credentials, exposed remote-access services, vulnerable web interfaces, malicious firmware, insecure removable media, supply-chain compromise, lateral movement from office IT, and manipulation of sensor data.

Threat modeling methods may use threat trees, attack trees, STRIDE, or structured industrial-control-system analysis. The method matters less than disciplined coverage of spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege, unsafe commands, and loss of sensor trustworthiness.

2.3 Risk estimation

For a preliminary qualitative assessment, risk can be represented as:

Here, R is a risk score, L is a likelihood rating, and C is a consequence or impact rating. The ratings must be defined by the organization—for example, ordinal values from 1 to 5. This is not a universal probability equation: multiplying ordinal scores does not produce a true probability or monetary loss. It is useful for prioritization only when rating definitions are consistent.

A quantitative expected-loss model may be used when credible data exist:

P(Event) is the probability of the event within a stated period, and Consequence is expressed in suitable units such as currency, downtime, or quantified harm. The model assumes that the event definition is clear and that the consequence estimate is meaningful. Rare catastrophic events are often poorly represented by simple averages; scenario analysis and independent safety assessment remain necessary.

Risk assessment should consider confidentiality, integrity, availability, safety, privacy, environmental impact, quality, regulatory compliance, and recovery time. A low-probability attack with fatal consequences may require stronger treatment than a frequent but low-impact nuisance.

2.4 Risk treatment

Risk can be reduced by avoidance, prevention, detection, response, recovery, or transfer. Examples include removing unnecessary remote access, enforcing least privilege, adding independent speed monitoring, segmenting networks, installing backups, rehearsing restoration, or transferring limited financial exposure through insurance. Risk cannot normally be eliminated completely; residual risk must be documented, accepted by an authorized person, and reviewed when the system changes.

3. Identity, Authentication, and Authorization

3.1 Identity and authentication

Identity answers “which entity is requesting access?” Authentication answers “what evidence supports that identity?” Authorization answers “what is that identity allowed to do?” These functions must not be conflated.

Device identities should be unique and cryptographically bound to hardware or protected storage where practical. Shared accounts such as “operator” or “admin” destroy accountability and make revocation difficult. Human authentication should use strong, unique credentials and, for high-impact functions, multi-factor authentication (MFA). Factors may be knowledge, possession, or inherence; two passwords are not genuinely two independent factors.

Machine-to-machine authentication commonly uses certificates and mutual Transport Layer Security (mTLS), in which both endpoints authenticate. Credentials should have defined validity periods, rotation procedures, and revocation or replacement mechanisms. Default passwords must be removed before deployment.

3.2 Authorization

Authorization should follow least privilege: an identity receives only the permissions required for its role and task. Role-based access control maps permissions to roles such as operator, maintenance technician, engineer, and auditor. Attribute-based policies can additionally consider location, device state, time, job assignment, or risk level.

Privileged actions deserve stronger controls: approval, dual authorization, command logging, change windows, and confirmation of physical state. Authorization must be enforced at the device or service that performs the action, not only at a dashboard that can be bypassed.

3.3 Encryption and integrity

Encryption in transit protects data from eavesdropping and manipulation when correctly configured. Encryption at rest protects stored credentials, recipes, logs, and personal information if storage is stolen. Integrity mechanisms, including authenticated encryption and digital signatures, help detect alteration.

Encryption does not solve endpoint compromise, unsafe authorization, poor key storage, or denial of service. Protocol versions, algorithms, certificate validation, time synchronization, and failure behavior must be specified. A controller should not silently accept an invalid certificate because “the network is trusted.”

4. Secure Boot, Firmware, and Key Management

Secure boot establishes a chain of trust from an immutable root of trust to bootloader, operating system, and application firmware. Each stage verifies the digital signature of the next stage before execution. If verification fails, the device should enter a defined recovery or safe state rather than execute untrusted code.

A secure update system verifies authenticity, integrity, version policy, and—where required—compatibility and authorization. It should resist rollback to a vulnerable version, while retaining a controlled recovery path for defective releases. Updates must be tested against real timing, safety, and communications behavior.

Key management is a lifecycle process, not merely an encryption setting. It includes generation, provisioning, storage, distribution, use, rotation, backup, revocation, archival, and destruction. Private keys should be protected in a hardware security module, trusted platform module, secure element, or equivalent protected mechanism when feasible. A lost key must not require replacing an entire production line, and a compromised key must be revocable.

A sound design separates keys by purpose and scope. For example, a device identity key, firmware-signing key, data-encryption key, and backup key should not be the same secret. Signing authority should be tightly controlled, logged, and preferably protected by multi-person approval.

5. Network Segmentation and Secure Operations

Segmentation limits lateral movement and reduces the blast radius of compromise. A common design separates corporate IT, industrial control, safety-related networks, contractor access, laboratory systems, and cloud connectivity. Firewalls and industrial demilitarized zones mediate necessary flows. “Flat” networks are convenient but allow a compromised office laptop to reach controllers directly.

Segmentation is not achieved merely by drawing zones on a diagram. Each permitted flow should specify source, destination, protocol, direction, business or operational purpose, and owner. Deny-by-default rules are preferable where operationally feasible. Safety networks may require deterministic, highly available communication and should not depend on a cloud service for immediate protective action.

Remote access should be disabled when unnecessary. When necessary, it should use a managed gateway, MFA, time-limited authorization, session recording, approved tools, and explicit operator awareness. Direct modem access, unmanaged vendor accounts, and permanent tunnels create substantial exposure.

Monitoring should collect authentication events, configuration changes, firmware changes, unusual commands, network anomalies, and safety-function status. Logs require accurate time, access control, retention, and protection against tampering. Monitoring is valuable only when someone is responsible for reviewing alerts and responding to them.

6. Patching and Vulnerability Management

Patching connected mechatronic equipment is more difficult than patching an office computer. A patch may alter timing, driver behavior, certification assumptions, or vendor support status. Nevertheless, “do not patch” is not a security strategy.

A lifecycle process should include:

1. Maintain an accurate asset and software bill of materials.
2. Obtain vulnerability information from vendors and trusted advisories.
3. Determine exploitability, exposure, safety consequence, and compensating controls.
4. Test patches in a representative environment.
5. Schedule controlled deployment and rollback.
6. Verify operation, logging, safety functions, and communications after deployment.
7. Record the result and reassess residual risk.

When immediate patching is impossible, compensating controls may include isolation, service disablement, application allow-listing, enhanced monitoring, restricted accounts, or physical access control. Unsupported equipment should be replaced or placed under a formally approved exception with an end date.

7. Functional Safety and Safety–Security Co-Engineering

Functional safety addresses risks caused by functional failure, systematic design error, or foreseeable misuse. It generally follows a lifecycle of hazard identification, risk reduction, safety requirements, design, verification, validation, operation, maintenance, and decommissioning. Common concepts include safety integrity, diagnostic coverage, safe failure behavior, independence, redundancy, and proof testing.

Cybersecurity introduces intentional and adaptive causes of failure. An attacker may disable a guard, falsify a sensor, alter a safety parameter, block a stop command, or force repeated trips. Therefore, a safety analysis that assumes random hardware faults only may be incomplete.

Safety and security engineering should exchange information:

Independence is especially important. If the same processor, power supply, network, or credential controls both normal operation and the protective function, a single compromise may defeat both. A security control should not be credited as a safety control unless its reliability, independence, response time, and failure behavior are demonstrated for the safety requirement.

Safety integrity is not equivalent to cybersecurity strength. A highly secure system can still contain a design error; a redundant safety system can still be vulnerable if all redundant channels share the same compromised software or network. Co-engineering therefore uses joint hazard–threat analysis, common-cause analysis, secure safety requirements, and coordinated verification.

8. Resilient Operation and Incident Response

Resilience begins before an incident. Design for graceful degradation: local control should continue if cloud analytics is unavailable; stale data should be detected; actuators should move to a defined safe or controlled state; and operators should receive clear information about degraded modes.

Useful resilience measures include redundant power, communication paths, controllers, sensors, and backups, but redundancy can increase complexity and common-cause risk. Backups must be offline or otherwise protected from ransomware, periodically restored in tests, and accompanied by configuration, certificates, firmware, and documented procedures. Recovery objectives should be explicit:

• Recovery time objective (RTO): maximum acceptable time to restore a service.
• Recovery point objective (RPO): maximum acceptable age of recovered data.

An incident-response plan normally includes preparation, detection and analysis, containment, eradication, recovery, and lessons learned. In an operational plant, immediate priorities are protection of people, stabilization of the process, preservation of evidence, and controlled communication. Disconnecting equipment impulsively may create a hazardous stop or destroy forensic evidence; response actions must be coordinated with process and safety personnel.

An incident playbook should identify decision authority, contact details, vendor escalation, law-enforcement and regulator interfaces, safe shutdown procedures, evidence handling, alternate communications, and restoration criteria. Exercises should include loss of a control server, compromised remote access, manipulated sensor data, ransomware, and simultaneous safety-system alarms.

9. Applied Case: Connected Robotic Cell

Background

The following is an illustrative case. A manufacturing cell contains a six-axis robot, conveyor, PLC, safety PLC, HMI, vision sensor, maintenance laptop, and cloud production dashboard. A vendor uses remote access for support. The robot is fenced, and a gate interlock and emergency-stop circuit are intended to prevent hazardous motion.

Problem

An assessment discovers that the HMI and engineering laptop share local administrator credentials. The vendor VPN is permanently enabled, the PLC and HMI occupy the same flat subnet, firmware updates are performed using removable media, and the vision sensor accepts commands without mutual authentication. The production dashboard can write selected recipes even though its business purpose is monitoring.

A plausible attack path is compromise of a vendor account, movement through the HMI, alteration of a robot-speed parameter, and manipulation of vision data. Even if the safety PLC stops motion when the gate opens, the altered configuration may increase exposure before an operator notices. A denial-of-service attack could also stop production, while a falsified “part present” signal could cause unexpected robot behavior.

Analysis

Assets include human life, robot motion, safety parameters, recipes, product quality, availability, credentials, and production data. Trust boundaries exist at the vendor VPN, HMI-to-PLC link, cloud gateway, removable media interface, and sensor interface. High-consequence threats concern unauthorized motion, defeat of interlocks, unsafe configuration, and loss of operator visibility.

The risk treatment prioritizes prevention of unauthorized commands, independent limitation of hazardous motion, and recoverability. The team does not assume that authentication alone makes a command safe.

Approach and solution

The plant disables permanent vendor access and introduces a brokered remote-access gateway with MFA, approval, time limits, and session recording. Individual accounts replace shared administrator credentials. The PLC, safety PLC, HMI, engineering station, and cloud gateway are placed in controlled zones with firewall rules allowing only documented flows.

The production dashboard becomes read-only. Recipe changes require an authorized local or supervised engineering action, signed configuration packages, and audit logging. Mutual authentication is added between the gateway and devices that support it; unsupported devices are isolated and monitored as a compensating measure.

The boot and update process is revised to require signed firmware, verified media, version control, and rollback procedures. A separate independent speed-monitoring function limits robot speed during maintenance and detects unsafe values. The gate interlock and emergency-stop function remain locally available and do not depend on cloud connectivity.

Backups include PLC logic, safety configuration, HMI project files, device certificates, network rules, and known-good firmware. Restoration is tested quarterly. The incident plan defines a safe shutdown, evidence preservation, vendor notification, and staged restoration procedure.

Outcome and learning points

The redesigned cell has a smaller attack surface, better accountability, and reduced lateral movement. Cloud loss no longer prevents local protective action. The plant still faces residual risks: vulnerable legacy devices, insider misuse, sensor failure, and supply-chain compromise. These are documented with owners and review dates.

The principal lesson is architectural. Security controls, safety functions, operating procedures, and recovery capabilities must be designed together. Adding a password to an unsafe architecture is not co-engineering.

10. Governance, Ethics, and Contemporary Practice

Security decisions affect workers, customers, suppliers, and the public. Excessive monitoring may violate privacy; collecting detailed operator activity requires purpose limitation, access control, retention limits, and transparent governance. Vulnerability disclosure should support timely remediation without unnecessarily exposing exploit details. Suppliers should provide security-update commitments, component inventories, secure development evidence, and end-of-support dates.

Relevant practice is informed by international industrial cybersecurity and functional-safety standards and by national critical-infrastructure, privacy, and product-security requirements. The exact obligations depend on jurisdiction, sector, and system role. Engineers must consult current authoritative standards rather than treating a textbook summary as legal advice.

Artificial intelligence can assist anomaly detection, malware triage, vulnerability prioritization, and predictive maintenance. It can also generate false alarms, conceal causal explanations, or produce unsafe recommendations. AI should not silently override a validated protective function. Models require controlled data, access restrictions, monitoring for drift, human accountability, and safe fallback behavior.

Challenges and Limitations

No control is perfect. Encryption cannot prevent a legitimate but malicious user from issuing an authorized command. Segmentation can fail through an incorrectly configured firewall. MFA may be unavailable during emergencies or vulnerable to social engineering. Secure boot cannot correct malicious logic that was legitimately signed. Redundancy can share common software, power, or environmental dependencies. Patching can introduce operational faults, while delayed patching leaves known vulnerabilities exposed.

Risk scores can create false precision, especially when likelihood ratings are subjective. Compliance documentation does not prove real security or safety. Penetration testing may miss process-specific hazards, and safety validation may not consider an adaptive attacker. Continuous asset discovery, realistic exercises, independent review, and lifecycle accountability are therefore essential.

Best-Practice Design Checklist

• Define safety, security, availability, privacy, and recovery requirements together.
• Maintain an owned and continuously updated asset inventory.
• Remove default credentials and prohibit unnecessary shared accounts.
• Use least privilege, MFA for high-impact access, and strong device identity.
• Protect data in transit and at rest, with validated certificate and key lifecycles.
• Use secure boot and signed updates where supported.
• Segment networks and permit only documented communication flows.
• Keep local protective functions independent of cloud services.
• Test patches, backups, restoration, and incident playbooks.
• Analyze common causes affecting both safety and security.
• Record residual risk, exceptions, owners, review dates, and lessons learned.

Chapter Summary

Connected mechatronic systems must be evaluated as cyber-physical systems in which digital compromise, accidental fault, and physical hazard can interact. Threat modeling identifies assets, trust boundaries, attack paths, vulnerabilities, and consequences. Risk assessment supports prioritization, but ordinal risk scores are decision aids rather than precise probabilities.

Effective protection uses unique identities, strong authentication, least-privilege authorization, authenticated encryption, secure boot, signed updates, disciplined key management, segmentation, monitoring, and controlled patching. Resilience adds graceful degradation, protected backups, tested restoration, redundancy, and incident response. Functional safety and cybersecurity require joint analysis because an attacker may manipulate the assumptions on which a safety function depends. Independent protective layers, local emergency action, lifecycle governance, ethical data practices, and continual review are central to trustworthy IoT-enabled mechatronics.

Key Terms

Asset: A resource or function requiring protection.

Attack surface: The reachable interfaces through which compromise may occur.

Authentication: Verification of an identity claim.

Authorization: Determination of permitted actions.

Availability: The property that a service is accessible when required.

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

Hazard: A potential source of harm.

Integrity: Protection against unauthorized or accidental alteration.

Key management: Lifecycle control of cryptographic keys.

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

mTLS: Mutual Transport Layer Security, in which both endpoints authenticate.

Network segmentation: Division of a network into controlled security zones.

Resilience: Capacity to withstand, adapt, recover, and learn after disruption.

Risk: Combination of likelihood and consequence.

Secure boot: Verification of authorized software before execution.

Safety function: A function intended to prevent or reduce physical harm.

Threat model: Structured representation of threats, assets, trust boundaries, and attack paths.

Vulnerability: A weakness that can be exploited or triggered.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. Why is a flat industrial network dangerous?
3. What is the purpose of secure boot?
4. Define recovery time objective and recovery point objective.
5. Why must safety and security analyses be coordinated?

Long Answer Questions

1. Explain a complete threat-modeling process for a connected robotic cell.
2. Compare preventive, detective, responsive, and recovery controls in industrial IoT.
3. Discuss the lifecycle requirements of cryptographic key management.
4. Explain how network segmentation can reduce, but not eliminate, cyber-physical risk.
5. Describe the relationship between functional safety independence and cybersecurity.

Analytical / Application Questions

1. A vendor requires permanent remote access to a PLC network. Analyze the risks and propose a safer operating model.
2. A cloud service becomes unavailable during production. Design a resilient architecture that preserves safe local operation.
3. A signed firmware update changes controller timing and causes nuisance safety trips. Analyze the governance and technical failures and propose corrective actions.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what actions are allowed, while authorization verifies identity.

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

C. Authentication encrypts data, while authorization compresses it.

D. Authentication applies only to devices, while authorization applies only to people.

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

Question 2

What is the principal purpose of network segmentation in an industrial IoT system?

A. To eliminate the need for software patches

B. To guarantee that every device is safe

C. To limit lateral movement and reduce the blast radius of compromise

D. To replace all physical safety functions

Correct Answer: C. To limit lateral movement and reduce the blast radius of compromise

Question 3

In the qualitative expression R = L × C, what do L and C represent?

A. Latency and capacity

B. Likelihood and consequence

C. Length and current

D. Logging and confidentiality

Correct Answer: B. Likelihood and consequence

Question 4

Which practice best supports least privilege?

A. Using one administrator account for all technicians

B. Giving every operator access to engineering functions

C. Granting each identity only the permissions required for its task

D. Allowing anonymous access inside the factory network

Correct Answer: C. Granting each identity only the permissions required for its task

Question 5

What does secure boot primarily verify?

A. That the network cable is connected

B. That authorized software is executed during startup

C. That production targets have been achieved

D. That all sensors measure identical values

Correct Answer: B. That authorized software is executed during startup

Question 6

Which feature most directly improves resilience against ransomware?

A. A permanently enabled vendor VPN

B. An untested backup stored on the same writable network

C. Protected backups that are periodically restored in tests

D. A shared local administrator password

Correct Answer: C. Protected backups that are periodically restored in tests

Question 7

Why should a safety function not automatically depend on a cloud service?

A. Cloud services always use weak encryption

B. Cloud dependence can introduce unacceptable delay or loss of protective action

C. Cloud services cannot store production data

D. Safety functions never require communications

Correct Answer: B. Cloud dependence can introduce unacceptable delay or loss of protective action

Question 8

Which is an example of a compensating control when an old device cannot be patched immediately?

A. Exposing the device directly to the Internet

B. Disabling all event logging

C. Isolating the device and restricting its accessible services

D. Replacing individual accounts with a shared password

Correct Answer: C. Isolating the device and restricting its accessible services

Question 9

What is a key reason to use independent protective layers in a mechatronic system?

A. To ensure one compromised component cannot defeat every protection

B. To increase the number of cloud dashboards

C. To avoid documenting safety requirements

D. To make patch testing unnecessary

Correct Answer: A. To ensure one compromised component cannot defeat every protection

Question 10

Which action is most appropriate at the beginning of an incident involving hazardous machinery?

A. Immediately delete all logs

B. Prioritize protection of people and stabilize the process safely

C. Publish unverified technical details publicly

D. Restore every backup without checking its integrity

Correct Answer: B. Prioritize protection of people and stabilize the process safely