IoT Security, Privacy and Resilience

Introduction and Context

The Internet of Things (IoT) connects sensors, actuators, embedded controllers, gateways, cloud platforms, mobile applications and operational systems. This integration creates value through monitoring, automation and data-driven decision-making, but it also enlarges the attack surface. A compromised thermostat may expose a household network; a manipulated industrial sensor may cause unsafe control decisions; and a ransomware attack on connected medical devices may threaten patient safety.

IoT security therefore cannot be reduced to encrypting network traffic. It requires coordinated protection of hardware, firmware, communication protocols, identities, applications, data, cloud services, physical environments and organizational processes. Privacy and resilience are equally important. Privacy limits inappropriate collection and use of personal or sensitive information, while resilience enables an IoT system to continue safe operation, recover from compromise and learn from incidents.

This chapter develops a security architecture for IoT systems. It covers threat modelling, identity, authentication, authorization, cryptography, key management, secure boot, trusted hardware, firmware updates, zero-trust principles, privacy engineering and incident response. It also examines limitations, governance and a representative industrial case.

Learning Objectives

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

1. Identify IoT assets, adversaries, attack surfaces and security objectives.

2. Construct a threat model using structured methods such as STRIDE and attack trees.

3. Design identity, authentication and authorization mechanisms for constrained and heterogeneous devices.

4. Explain encryption, key management, secure boot, trusted hardware and secure update architectures.

5. Apply zero-trust principles to IoT networks and distributed systems.

6. Evaluate privacy risks and select appropriate privacy-enhancing controls.

7. Develop incident-response and resilience strategies for IoT deployments.

8. Critically assess practical, ethical, regulatory and lifecycle constraints.

1. Security Objectives and IoT Characteristics

The classical security objectives are confidentiality, integrity and availability, often called the CIA triad. Confidentiality prevents unauthorized disclosure; integrity prevents unauthorized alteration; and availability ensures that authorized users and processes can obtain services when needed. IoT adds several related objectives:

• Authenticity: assurance that an entity, message or measurement is genuine.
• Authorization: assurance that an authenticated entity is permitted to perform a requested action.
• Safety: prevention of physical harm, including harm resulting from cyber events.
• Accountability: ability to associate actions with responsible identities and preserve trustworthy evidence.
• Privacy: appropriate control of personal data and inferences about individuals.
• Resilience: ability to resist, absorb, recover from and adapt to disruptive events.

IoT security is difficult because devices are numerous, geographically distributed and often resource-constrained. Devices may have limited memory, processing power and battery capacity. They may remain deployed for ten or twenty years, even though their software libraries become obsolete. Physical access is frequently possible, allowing adversaries to probe memory, replace components or manipulate sensors. Devices also interact across administrative boundaries: a manufacturer supplies firmware, a network operator supplies connectivity, a cloud provider stores data, and an asset owner controls operations.

The physical consequences of digital compromise distinguish IoT from many conventional information systems. Security controls must therefore be evaluated not only against data loss but also against unsafe actuation, loss of visibility, environmental damage and disruption of essential services.

2. Threat Modelling for IoT

Threat modelling is a systematic process for identifying what must be protected, from whom, by what mechanisms and with what residual risk. A useful model begins with four questions:

1. What are the assets?

2. Who are the relevant adversaries?

3. How can the assets be attacked?

4. What controls reduce the likelihood or impact of attack?

2.1 Assets and trust boundaries

Typical assets include device identities and private keys, firmware, sensor measurements, control commands, user credentials, cloud APIs, logs, configuration data, personal information and physical processes. A data-flow diagram should show devices, gateways, networks, cloud services, administrators and external integrations. Trust boundaries should be marked wherever data or authority crosses from one security domain to another.

For example, a smart-factory architecture may contain a device zone, an industrial control zone, an enterprise IT zone and a cloud analytics zone. A gateway between zones is not automatically trustworthy; it is a security enforcement point whose software, credentials and logs must themselves be protected.

2.2 Adversaries and capabilities

Adversaries may include opportunistic internet scanners, malicious insiders, criminal groups, industrial competitors, nation-state actors and compromised suppliers. Their capabilities range from password guessing to firmware reverse engineering, traffic injection, supply-chain compromise and physical laboratory attacks. A realistic model specifies whether an attacker can access the device physically, observe traffic, control a cloud account, obtain a valid credential or influence a software update.

2.3 STRIDE and attack trees

STRIDE classifies threats as spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. It is useful during design reviews because it prompts analysis of both data flows and components. For a temperature sensor, spoofing may involve a counterfeit device identity; tampering may involve altered measurements; information disclosure may reveal production conditions; denial of service may prevent safety monitoring; and elevation of privilege may allow a sensor to issue actuator commands.

Attack trees provide a complementary method. The root is an attacker goal, such as “cause an unsafe valve opening.” Branches represent alternative paths, such as compromising an actuator, compromising the control server or injecting commands through a gateway. Attack trees help identify single points of failure and combinations of controls.

Risk can be ranked qualitatively or quantitatively. A simple qualitative approach uses likelihood and impact categories. A quantitative expected-loss model may be written as:

Expected annual loss = p × I

where p is the probability of a specified adverse event during a defined period and I is its monetary or operational impact. The model assumes that p and I are estimated for the same period and event definition. In practice, estimates are uncertain and should be accompanied by confidence ranges or scenario analysis; the equation is not a precise prediction.

2.4 Security requirements derived from threats

Threat modelling should produce testable requirements. Examples include:

• Every device must possess a unique, manufacturer-provisioned identity.
• Measurement messages must be authenticated and protected against replay.
• Safety-critical commands must require authorization by an independent control policy.
• Firmware must be accepted only if its signature verifies and its version is not revoked.
• Administrative actions must generate tamper-evident audit records.
• Loss of cloud connectivity must place the process in a defined safe state.

Requirements should specify assurance levels, failure behavior, ownership and verification methods. “Use strong security” is not an actionable requirement.

3. Identity, Authentication and Authorization

3.1 Device identity

An IoT identity is a persistent or lifecycle-managed representation of a device, service or human. It should be unique, difficult to clone and associated with ownership and status information. Common approaches include X.509 certificates and public-key infrastructure, symmetric device keys, secure hardware identifiers and federated tokens.

Certificates are useful when many parties must authenticate devices without sharing a common secret. A certificate binds a public key to an identity and is signed by a certification authority. Certificate issuance, renewal, revocation and inventory management are as important as the cryptographic algorithm itself. A certificate that remains valid after a device is sold or compromised creates serious risk.

Symmetric keys require less computation and communication, but key distribution and compromise recovery are more difficult. A single fleet-wide key is unacceptable for most consequential deployments because compromise of one device exposes the entire fleet. Per-device keys, and preferably per-session derived keys, limit blast radius.

3.2 Authentication

Authentication verifies an identity. Device-to-cloud mutual TLS can authenticate both endpoints and establish encrypted sessions. In constrained environments, protocols such as OSCORE protect application messages over suitable transports, while EDHOC can establish compact authenticated keying material. The selected protocol must match device capability, network conditions and assurance requirements.

Human administrators should use phishing-resistant multi-factor authentication where practical, with role separation for high-impact operations. Credentials must not be embedded identically in firmware images. Passwords, when unavoidable, must be individually provisioned, rate-limited and protected using appropriate password-hashing mechanisms on the verification service.

Authentication is not authorization. A genuine sensor identity should not automatically be allowed to reconfigure a plant or update another device.

3.3 Authorization and policy enforcement

Authorization determines what an authenticated subject may do to a particular resource under specified conditions. Role-based access control assigns permissions to roles; attribute-based access control evaluates attributes such as device type, location, time, process state and command criticality. Capability-based designs provide an unforgeable token granting a narrowly defined authority.

IoT authorization should follow least privilege and separation of duties. A vibration sensor may publish measurements but should not issue actuator commands. A maintenance engineer may update firmware only for an assigned device group and only during an approved maintenance window. Policies must include deny-by-default behavior, expiration, revocation and safe handling when policy services are unavailable.

4. Cryptography and Key Management

Cryptography provides confidentiality, integrity, authentication and non-repudiation-like evidence, although cryptographic signatures alone do not prove that a human approved an action. Authenticated encryption, such as AES-GCM or ChaCha20-Poly1305, combines confidentiality with integrity. Correct nonce management is essential: nonce reuse under many authenticated-encryption constructions can compromise security. Algorithms must be selected according to current standards, hardware support and lifecycle expectations rather than convenience.

Public-key cryptography supports identity and key establishment. Elliptic-curve systems often provide smaller keys and signatures than traditional RSA at comparable security levels, which benefits constrained devices. However, implementation quality, secure randomness and side-channel resistance matter more than nominal algorithm choice.

4.1 Key lifecycle

A complete key-management lifecycle includes generation, provisioning, storage, distribution, use, rotation, backup where appropriate, revocation, recovery and destruction. Private keys should be generated in or imported into protected hardware whenever feasible and should be non-exportable. Production, development and test keys must be separated.

Key derivation functions can create independent session keys from a master secret. A conceptual derivation is:

K_session = KDF(K_master, context)

where K_master is a protected secret, context includes identities, protocol parameters and a freshness value, and KDF is a standardized key-derivation function. The context must prevent accidental key reuse across devices or purposes. This expression is a design abstraction; an implementation must specify a standardized KDF, encoding rules and authentication of the inputs.

Key compromise must be assumed possible. Systems should support rapid revocation, re-enrolment and fleet-wide policy changes. A key hierarchy can reduce operational complexity: a root of trust protects intermediate signing keys, which authorize device or update keys. Root keys require exceptional protection, restricted access and offline or hardware-backed storage.

5. Secure Boot, Trusted Hardware and Firmware Updates

5.1 Chain of trust

Secure boot establishes that only authorized software executes. A hardware- or ROM-based root of trust verifies a first-stage bootloader; that loader verifies the next stage; and subsequent stages verify the operating system and application. Verification normally uses a digital signature over a firmware image or manifest. The device must fail safely when verification fails, rather than silently executing untrusted code.

Secure boot does not prove that software is free from vulnerabilities. It proves only that the software is authorized according to the verification key and policy. Therefore, signing-key protection, vulnerability management and update capability remain essential.

5.2 Trusted execution and hardware protection

Trusted platform modules, secure elements and trusted execution environments can protect keys, measure software state and isolate sensitive operations. A secure element may perform signature operations without exposing a private key. A trusted execution environment can separate security-critical code from less-trusted applications, although isolation failures and complex trusted code bases remain risks.

Hardware security should be proportionate to the threat model. A low-cost environmental sensor may need secure storage and signed updates, while a payment terminal or medical actuator may require tamper detection, measured boot, protected debug interfaces and formal evaluation. Debug ports should be disabled or authenticated in production, but a secure maintenance mechanism must remain available.

5.3 Secure firmware updates

A secure update system verifies authenticity, integrity, target compatibility, version policy and installation status. Update metadata should identify the device class, dependencies, release version and cryptographic hash. Anti-rollback protection prevents an attacker from installing an older vulnerable version. Recovery partitions or dual-bank designs allow rollback to a known-good image when an update fails, but rollback must not defeat anti-rollback security.

The update service should support staged deployment, health monitoring, cancellation and emergency revocation. Update signing must be separated from release approval, and high-risk updates should require multiple authorized parties. Supply-chain security requires reproducible or verifiable builds, dependency scanning, software bills of materials and protection of build infrastructure.

6. Zero Trust for IoT

Zero trust is an architectural approach in which no device, network location or connection is automatically trusted. Access is continuously evaluated using identity, device posture, requested resource, context and policy. It does not mean that every packet must be individually inspected regardless of operational constraints; rather, trust decisions are explicit, least-privileged and continuously subject to validation.

An IoT zero-trust architecture commonly includes:

• Strong identities for devices, users, services and gateways.
• Segmentation based on function and risk, not merely physical location.
• Policy enforcement points at gateways, brokers, APIs and critical controllers.
• Continuous telemetry about identity use, software state and behavior.
• Short-lived credentials and narrowly scoped authorization.
• Protected management planes separated from ordinary data flows.

Micro-segmentation can prevent a compromised camera from reaching a safety controller. However, segmentation is not a substitute for endpoint security. Legacy protocols may lack authentication, and industrial systems may have strict latency or availability constraints. Zero-trust controls must therefore be engineered with safe fallback behavior and validated through operational testing.

7. Privacy Engineering in IoT

IoT devices can collect location, voice, health, behavior and inferred household or industrial information. Privacy risk may arise even when data appears harmless: a sequence of power measurements can reveal occupancy, while sensor timing can reveal production activity.

Privacy engineering begins with purpose specification and data minimization. Organizations should collect only data necessary for a defined purpose, retain it for no longer than justified, and provide transparency about processing, sharing and automated decisions. Privacy impact assessments should examine direct identifiers, linkability, inference and secondary use.

Technical controls include encryption in transit and at rest, pseudonymization, access logging, aggregation, local processing and carefully designed differential privacy. Differential privacy adds calibrated randomness to outputs so that the presence or absence of an individual has limited influence on a released statistic. Its effectiveness depends on the privacy budget, query composition and protection of auxiliary information; it is not a universal solution for raw-stream disclosure.

Consent is not always sufficient, particularly where individuals cannot realistically refuse monitoring in workplaces, public spaces or essential services. Governance must address lawful purpose, data-subject rights, processor responsibilities, cross-border transfers, breach notification and retention. Regulations vary by jurisdiction, but privacy-by-design, security safeguards and accountability are broadly important principles.

8. Resilience and Incident Response

Security prevents and detects compromise; resilience prepares the system to operate safely despite compromise. Resilience engineering should identify essential functions, maximum tolerable interruption, safe states, dependencies and recovery priorities.

A resilient IoT system may include local control when cloud services fail, redundant communication paths, independent safety mechanisms, rate limits, watchdogs, immutable or remote logs, backups and manual override. Redundancy must not create common-mode vulnerabilities: identical credentials, software and network paths can cause all redundant components to fail together.

Incident response normally comprises preparation, detection and analysis, containment, eradication, recovery and post-incident learning. Preparation includes asset inventories, contact lists, forensic procedures, tested backups and exercises. Detection combines signature-based alerts with behavioral indicators, such as an actuator issuing commands outside its normal role or a sensor communicating with an unknown endpoint.

Containment must consider physical safety. Disconnecting a device may stop an attack but also remove critical monitoring. A response plan should define when to isolate, when to move to manual control and how to preserve evidence. Recovery includes credential rotation, firmware reinstallation, vulnerability remediation and validation before reconnection. Post-incident reviews should identify architectural causes rather than assigning blame solely to operators.

Useful resilience measures include recovery time objective, recovery point objective, mean time to detect and mean time to recover. These metrics require clear definitions. For example, recovery time should specify whether it measures service restoration, safe operation or full functionality. Metrics should not encourage unsafe rapid recovery at the expense of verification.

9. Illustrative Case: Securing a Connected Water-Treatment Facility

Background

Consider an illustrative municipal water-treatment facility using networked chlorine sensors, programmable controllers, pump actuators, historian databases and cloud-based maintenance analytics. Sensors communicate with local gateways, while engineers access dashboards through an enterprise identity provider.

Problem

A security assessment finds shared administrator passwords, unsigned firmware, flat network connectivity and cloud accounts with long-lived credentials. A compromised maintenance laptop could potentially reach controllers. Sensor readings are transmitted without message authentication, and the facility has no tested procedure for operating during cloud or network loss.

Analysis

The assets include chlorine concentration data, controller logic, pump commands, device keys, operator identities and public safety. Threats include ransomware, spoofed sensor values, unauthorized dosing commands, insider misuse and supply-chain compromise. The highest-impact scenario is manipulation of sensor readings that causes incorrect chemical dosing. Availability is important, but integrity and safety dominate for this process.

Approach and solution

The facility establishes unique device identities using certificates stored in secure elements. Mutual authentication is required between gateways and authorized services. Sensor messages include freshness protection and are accepted only from enrolled devices. Network segmentation separates sensors, controllers, historian services and enterprise IT. A gateway enforces allow-listed communication, while controllers reject commands from unauthorized roles.

Secure boot and signed firmware are enabled for gateways and controllers where supported. Firmware releases require two-person approval, software inventory records and staged deployment. Emergency revocation lists are distributed through a protected management channel. Operators receive phishing-resistant multi-factor authentication, and maintenance permissions are time-limited and restricted by equipment group.

The control process is redesigned so that loss of cloud connectivity does not stop local safety functions. Independent alarm thresholds and manual operating procedures are tested. Logs are forwarded to a protected monitoring service, with local buffering during disconnection. Incident exercises simulate a compromised sensor, requiring operators to compare readings with an independent measurement and place the process in a safe state.

Outcome

The architecture reduces the likelihood that a single stolen credential or compromised sensor can directly control treatment equipment. It also improves recovery because devices can be re-enrolled, firmware can be verified and operations can continue locally. Residual risks remain, including physical tampering, vulnerabilities in legacy controllers and incorrect safety thresholds.

Learning points

First, security controls must reflect physical consequences. Second, identity and segmentation must be combined with command authorization. Third, signed firmware is valuable but cannot compensate for weak key governance. Finally, resilience depends on tested operating procedures, not merely on technology.

10. Challenges, Governance and Contemporary Directions

IoT security faces economic and technical constraints. Manufacturers may prioritize low cost and rapid release over long-term maintenance. Owners may not know which devices are deployed or who is responsible for patching them. Legacy equipment may not support modern cryptography. Battery-powered devices cannot maintain expensive continuous monitoring. Supply chains may contain opaque dependencies and counterfeit components.

Governance should allocate responsibility across manufacturers, integrators, operators and service providers. Procurement contracts should specify vulnerability disclosure, security-update duration, identity ownership, incident notification, end-of-life handling and evidence of secure development. Organizations should maintain an accurate asset inventory and classify devices by safety and business impact.

Secure development practices include threat modelling, code review, static and dynamic analysis, fuzz testing, penetration testing, dependency management and coordinated vulnerability disclosure. Security claims should be tied to evidence and assurance boundaries. Conformity labels can be useful, but certification does not remove the need for operational risk management.

Artificial intelligence can support anomaly detection, malware analysis and prioritization of vulnerabilities. However, machine-learning systems can generate false positives, be evaded through adversarial behavior and expose sensitive telemetry. AI should assist, not replace, human authorization for high-impact actions. Models require protected training data, monitoring for drift and clear accountability.

Post-quantum cryptography is relevant to long-lived IoT deployments because data encrypted today may be collected for future decryption, and devices may remain deployed beyond the transition period. Migration requires inventory of cryptographic dependencies, algorithm agility and careful evaluation of increased key or signature sizes. Organizations should not replace proven systems impulsively; they should plan transition based on standards, threat horizon and device capability.

Best-Practice Design Checklist

A postgraduate security review should ask:

1. Is every device known, uniquely identified and assigned an owner?

2. Are identities and keys individually provisioned, protected and revocable?

3. Are authentication and authorization separate, least-privileged and auditable?

4. Are messages protected against alteration, replay and endpoint impersonation?

5. Does boot verify an authorized software chain, and can firmware be securely updated?

6. Are signing, build and release processes protected against supply-chain compromise?

7. Are critical functions segmented and able to fail safely?

8. Does the design minimize personal data and limit retention and secondary use?

9. Can the organization detect, contain, recover from and learn from incidents?

10. Have controls been tested under physical, network, cloud and operational failure conditions?

Chapter Summary

IoT security is a lifecycle and systems-engineering discipline involving devices, networks, software, people and physical processes. Effective design begins with threat modelling that identifies assets, adversaries, trust boundaries and safety consequences. Unique identities, strong authentication, least-privilege authorization and disciplined key management establish the foundation for trustworthy interaction. Authenticated encryption protects communications, while secure boot, trusted hardware and signed updates protect the software lifecycle.

Zero-trust architecture replaces implicit network trust with explicit, contextual and continuously evaluated authorization. Privacy engineering limits collection, exposure and inference through minimization, purpose limitation, local processing and appropriate technical safeguards. Resilience extends security beyond prevention by enabling safe operation, detection, containment, recovery and learning. Governance, supply-chain assurance, vulnerability management and clear accountability are necessary because no single technical control is sufficient. The central design principle is to align security strength, privacy protection and recovery capability with the physical and societal consequences of failure.

Key Terms

Asset: A resource requiring protection, such as data, software, identity or physical process.

Authentication: Verification of the identity of an entity.

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

Authenticated encryption: Encryption that provides confidentiality and integrity protection.

Attack surface: The set of interfaces and conditions through which an attacker may act.

Certificate: A signed binding between an identity and a public key.

Confidentiality: Protection against unauthorized disclosure.

Differential privacy: A method limiting the influence of one individual on a released result.

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

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

Least privilege: Granting only the authority required for an authorized task.

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

Privacy by design: Incorporating privacy requirements throughout system design and operation.

Resilience: Capacity to resist, absorb, recover from and adapt to disruption.

Secure boot: Verification of an authorized software chain before execution.

Segmentation: Isolation of systems or communication domains to limit attack propagation.

Threat model: Structured representation of assets, adversaries, attack paths and controls.

Trusted execution environment: An isolated execution area intended to protect sensitive code and data.

Zero trust: An architecture that grants no implicit trust based solely on network location or device presence.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization in an IoT system.

2. Why is a single fleet-wide symmetric key dangerous?

3. What security property does secure boot establish, and what does it not establish?

4. State two privacy risks created by IoT data inference.

5. Why must incident response plans account for physical safety?

Long Answer Questions

1. Explain how STRIDE and attack trees can be combined to threat-model an industrial IoT system.

2. Describe a complete cryptographic key lifecycle for a large fleet of constrained devices.

3. Discuss the role of secure boot, trusted hardware and signed firmware updates in establishing a device root of trust.

4. Explain how zero-trust principles can be adapted to legacy industrial protocols and operational constraints.

5. Critically evaluate privacy-by-design measures for a connected healthcare monitoring system.

Analytical / Application Questions

1. Design an identity, authorization and segmentation architecture for a smart factory containing sensors, robots, gateways and cloud analytics. Justify the trust boundaries.

2. An IoT fleet has 10,000 devices, each with an independent annual compromise probability of 0.002. Assuming independence, estimate the probability that at least one device is compromised in a year using 1 − (1 − p)^n, and explain why the result affects key-isolation strategy.

3. Develop an incident-response plan for a water-treatment facility in which sensor readings are suspected to be spoofed while cloud connectivity is unavailable. Include detection, containment, safe operation, recovery and evidence preservation.

Multiple Choice Questions with Answers

Question 1

Which property ensures that an authenticated IoT device is allowed to perform only approved actions?

A. Confidentiality

B. Authorization

C. Availability

D. Non-repudiation

Correct Answer: B. Authorization

Question 2

What is the primary purpose of secure boot?

A. To increase wireless bandwidth

B. To encrypt all user data permanently

C. To ensure that only authorized software executes

D. To eliminate all software vulnerabilities

Correct Answer: C. To ensure that only authorized software executes

Question 3

Which practice best limits the impact of compromise of one device in a fleet?

A. Using one shared fleet-wide key

B. Disabling all device identities

C. Using individually provisioned device keys

D. Allowing anonymous updates

Correct Answer: C. Using individually provisioned device keys

Question 4

In STRIDE, altered sensor measurements represent which threat category?

A. Tampering

B. Spoofing

C. Repudiation

D. Information disclosure

Correct Answer: A. Tampering

Question 5

What is a central principle of zero-trust architecture?

A. Trust every device inside the corporate network

B. Trust devices after their first successful login forever

C. Grant access based only on IP address

D. Continuously evaluate explicit, least-privileged access

Correct Answer: D. Continuously evaluate explicit, least-privileged access

Question 6

Why is nonce reuse dangerous in many authenticated-encryption schemes?

A. It guarantees higher availability

B. It can compromise confidentiality or integrity

C. It prevents certificate issuance

D. It disables physical tamper detection

Correct Answer: B. It can compromise confidentiality or integrity

Question 7

Which control most directly prevents installation of an older vulnerable firmware version?

A. Anti-rollback protection

B. Data aggregation

C. Network address translation

D. Password hashing

Correct Answer: A. Anti-rollback protection

Question 8

Which privacy measure reduces collection of unnecessary personal information?

A. Data minimization

B. Credential sharing

C. Flat network design

D. Long-lived administrator accounts

Correct Answer: A. Data minimization

Question 9

If each of 10,000 devices has an independent compromise probability of 0.002, which expression gives the probability of at least one compromise?

A. 0.002 / 10,000

B. 1 − (1 − 0.002)^10,000

C. 10,000 / 0.002

D. (1 − 0.002) / 10,000

Correct Answer: B. 1 − (1 − 0.002)^10,000

Question 10

Which resilience measure allows a critical process to continue safely when cloud connectivity fails?

A. Dependence on a single remote controller

B. Local control and defined safe-state behavior

C. Removal of all monitoring alarms

D. Use of identical credentials on redundant systems

Correct Answer: B. Local control and defined safe-state behavior