Security, Privacy, Safety and Resilience

Introduction

The Internet of Things (IoT) connects sensors, actuators, embedded controllers, gateways, cloud platforms, mobile applications and operational processes. This connectivity creates value through automation and data-driven decision-making, but it also expands the attack surface. A compromised smart lock, medical sensor, industrial controller or vehicle subsystem may cause consequences far beyond data loss. It may enable physical intrusion, unsafe machine behaviour, service disruption, environmental damage or harm to people.

IoT security therefore cannot be treated as an application-layer feature added after deployment. It is a lifecycle discipline involving hardware, firmware, networks, cloud services, users, physical environments and organizational processes. Privacy, safety, availability and resilience must be considered together with confidentiality, integrity and authentication.

This chapter presents practical and analytical foundations for securing IoT systems. It covers threat modeling, identity and access control, cryptography and key management, secure boot and firmware updates, network segmentation, zero-trust architecture, privacy engineering, safety, resilience and incident response. Artificial intelligence is considered both as a security enabler and as a source of additional risks.

Learning Objectives

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

1. Explain the security, privacy, safety and resilience requirements of IoT systems.

2. Conduct a structured IoT threat-modeling exercise.

3. Design device identity, authentication and authorization mechanisms.

4. Select appropriate encryption and key-management approaches.

5. Explain secure boot, signed firmware and secure update processes.

6. Apply network segmentation and zero-trust principles.

7. Assess privacy risks and physical safety implications.

8. Develop a basic incident-response and business-continuity plan for IoT.

9. Evaluate limitations, ethical issues and governance responsibilities.

1. The IoT Security Problem

An IoT ecosystem commonly includes the following layers:

• Device layer: sensors, actuators, microcontrollers, cameras and embedded operating systems.
• Connectivity layer: Wi-Fi, Bluetooth Low Energy, cellular, Ethernet, LPWAN, satellite and industrial protocols.
• Edge and gateway layer: protocol translation, local analytics, buffering and policy enforcement.
• Platform layer: device registries, message brokers, data storage, analytics and digital twins.
• Application and human layer: dashboards, mobile applications, enterprise systems and operators.
• Physical and organizational layer: buildings, factories, vehicles, patients, maintenance staff and governance processes.

A weakness in one layer can undermine the others. For example, strong cloud authentication cannot compensate for a device that accepts unsigned firmware. Likewise, encrypted communication does not prevent a legitimate but over-privileged operator from issuing a dangerous command.

The traditional security objectives are often summarized as the CIA triad:

• Confidentiality: preventing unauthorized disclosure.
• Integrity: preventing unauthorized alteration.
• Availability: ensuring authorized access when needed.

IoT adds several important objectives:

• Authenticity: confidence that a device, user, message or update is genuine.
• Safety: preventing unacceptable physical harm or hazardous states.
• Privacy: controlling the collection, use, inference and disclosure of information about people.
• Resilience: maintaining or restoring essential functions despite failures or attacks.
• Accountability: linking actions to responsible identities and preserving evidence.

Security and safety are related but not identical. A safety failure may result from a random component fault, while a security failure may be deliberate. However, a cyberattack can create a safety hazard, and a safety mechanism can reduce the consequences of a cyberattack. IoT engineering must therefore use both cybersecurity and safety analysis.

2. Threat Modeling for IoT

Threat modeling is a systematic process for identifying what must be protected, how it could be attacked or fail, and which controls should reduce the risk. It should occur during design and be updated when devices, networks, suppliers or operating conditions change.

2.1 Assets, Actors and Trust Boundaries

An asset is something valuable or something whose compromise could cause harm. IoT assets include:

• sensor readings and personal data;
• device identities and cryptographic keys;
• firmware and configuration files;
• actuator commands;
• cloud accounts and APIs;
• safety functions;
• network availability;
• audit logs and intellectual property.

Actors may include ordinary users, administrators, maintenance contractors, manufacturers, cloud providers, malicious insiders, criminal groups and nation-state attackers. An actor may be accidental or intentional and may possess physical access, network access, stolen credentials or supply-chain influence.

A trust boundary separates components with different assumptions about identity, authority or security. Examples include the boundary between a sensor and a gateway, a factory network and a corporate network, or a cloud API and a mobile application. Trust boundaries deserve explicit authentication, validation and monitoring.

2.2 A Practical Threat-Modeling Process

A suitable process for an IoT project is:

1. Define scope and safety context. Identify systems, locations, users, dependencies and unacceptable outcomes.

2. Construct a system model. Draw devices, data flows, protocols, storage locations, administrators and trust boundaries.

3. Identify assets and security objectives. Record confidentiality, integrity, availability, privacy and safety requirements.

4. Enumerate threats. Consider remote attacks, local attacks, supply-chain compromise, misuse, faults and environmental events.

5. Assess likelihood and impact. Use evidence where available and document assumptions.

6. Select controls. Prefer preventive, detective and recovery controls together.

7. Validate residual risk. Determine whether remaining risk is acceptable, transferred or requires redesign.

8. Maintain the model. Reassess after updates, incidents, new integrations or changes in use.

The STRIDE model is useful for software-oriented analysis. It considers Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. For IoT, STRIDE should be supplemented with physical tampering, unsafe actuation, privacy inference, sensor deception, environmental disruption and loss of fail-safe operation.

A risk register can record each threat, affected asset, attack path, consequence, likelihood, existing controls, owner and treatment decision. Qualitative ratings such as low, medium and high are often adequate for early design, provided that rating criteria are defined consistently. Numerical risk scores should not create false precision; a low-probability event with catastrophic safety consequences may require action even when its product score appears modest.

2.3 Example Threat Analysis

Consider a smart irrigation system consisting of soil sensors, a wireless gateway, a cloud service and remotely controlled water valves. Important assets include the valve-control function, water-use data, device credentials and cloud availability.

Possible threats include:

• an attacker impersonating a valve controller;
• replaying an old “open valve” command;
• extracting a device key through physical access;
• compromising the cloud administrator account;
• flooding the gateway so that irrigation cannot be controlled;
• changing firmware to keep valves open;
• inferring occupancy patterns from irrigation schedules.

Controls could include mutual authentication, message freshness indicators, signed commands, least-privilege roles, secure boot, encrypted storage, rate limiting, local safe-state logic, backups and audit logging. The threat model also reveals that availability and water damage may be more important than confidentiality in this particular system.

3. Identity, Authentication and Authorization

3.1 Device Identity

Every device should have a distinct, lifecycle-managed identity rather than sharing a factory-wide password. A device identity may be represented by a public-key certificate, a hardware-protected key, or a securely provisioned credential. Identity records should include ownership, manufacturing information, capabilities, status and revocation state.

A useful distinction is between:

• Identity: who or what an entity is.
• Authentication: evidence supporting that claim.
• Authorization: what the authenticated entity may do.
• Accounting: records of actions and decisions.

Device identities should be unique, difficult to forge and revocable. Default passwords, shared administrator accounts and credentials embedded in firmware are high-risk practices.

3.2 Authentication

Authentication factors include:

• knowledge, such as a password;
• possession, such as a cryptographic token;
• inherence, such as a biometric characteristic;
• device or contextual evidence, such as location or attestation status.

For constrained devices, public-key authentication is generally preferable to transmitting reusable passwords. Mutual TLS, certificate-based protocols and lightweight authenticated key-establishment mechanisms can allow both endpoints to verify each other. The design must still address certificate issuance, expiration, renewal and revocation.

Authentication should resist replay. A message that was valid yesterday should not automatically be valid today. Nonces, sequence numbers, timestamps with controlled clock assumptions, or challenge-response protocols can provide freshness. The chosen method must account for intermittent connectivity and devices without accurate real-time clocks.

3.3 Authorization and Least Privilege

Authorization policies should specify the subject, action, object, context and conditions. For example, a maintenance technician may read diagnostics from a particular machine during an approved service window but may not change safety limits.

Role-based access control (RBAC) grants permissions through roles such as operator, technician and administrator. Attribute-based access control (ABAC) evaluates attributes such as device type, location, time, purpose and risk state. IoT systems often benefit from a combination: roles provide understandable administration, while attributes express contextual restrictions.

Least privilege means granting only the permissions required for a task and only for as long as required. High-risk actions should require stronger authentication, dual approval or local confirmation. Authorization must be enforced at the device or gateway where appropriate, not only in a cloud dashboard, because cloud connectivity may be unavailable or compromised.

4. Cryptography and Key Management

4.1 Security Services

Cryptographic mechanisms provide distinct services:

• Encryption protects confidentiality.
• Message authentication codes (MACs) provide integrity and authentication when communicating parties share a secret.
• Digital signatures provide integrity, origin authentication and support for non-repudiation claims.
• Hash functions support integrity checking, fingerprints and secure constructions, but a plain hash does not authenticate its source.

Authenticated encryption with associated data (AEAD) is commonly appropriate for IoT messages. It encrypts sensitive plaintext and authenticates both ciphertext and selected unencrypted metadata. Examples include AES-GCM and ChaCha20-Poly1305 when implemented according to their specifications.

A critical operational rule is that an AEAD nonce must not be reused with the same key. Nonce generation, persistence across reboots and handling of message counters must therefore be designed explicitly. Encryption does not protect compromised endpoints, incorrect authorization or unsafe commands by itself.

4.2 Key Lifecycle

Key management is often more difficult than selecting an algorithm. A complete lifecycle includes:

1. secure generation using an appropriate random source;

2. provisioning or enrollment;

3. protected storage;

4. controlled use;

5. rotation and renewal;

6. backup where justified and secure recovery;

7. revocation or replacement;

8. destruction at decommissioning.

Keys should be separated by purpose. A device identity key should not also be used as a data-encryption key or firmware-signing key. Firmware-signing private keys require particularly strong protection, often through a hardware security module and multi-person administrative control.

Hardware-backed secure elements or trusted platform modules can protect private keys and support measured or verified boot. However, hardware protection does not solve weak authorization, insecure APIs or poor operational processes.

4.3 Encryption in Transit and at Rest

Data in transit should be protected across untrusted networks, including local wireless links, gateways and cloud connections. Data at rest may include sensor databases, logs, backups and device storage. Encryption keys must be managed separately from the data they protect; merely storing an encryption key beside encrypted data offers little protection.

Data minimization is often better than encrypting unnecessary data. If a system does not need precise location histories, it should avoid collecting them rather than relying solely on later encryption.

5. Secure Boot, Firmware and Supply Chain Security

5.1 Secure Boot

Secure boot establishes a chain of trust from an immutable or hardware-protected root of trust to the bootloader, operating system and application firmware. Each stage verifies the signature or measurement of the next stage before execution. Verification normally uses a public key or an equivalent trust anchor stored securely on the device.

Secure boot helps prevent unauthorized firmware from running, but it does not guarantee that approved firmware is free of vulnerabilities. It must be combined with secure development, vulnerability management and update mechanisms. Recovery paths must also be protected; otherwise an attacker may bypass secure boot through a debug interface or undocumented maintenance mode.

5.2 Secure Firmware Updates

A robust update process should provide:

• authenticated and integrity-protected update packages;
• authorization of the update publisher;
• version checks to prevent rollback to vulnerable firmware;
• compatibility and dependency checks;
• power-loss tolerance, such as an A/B image scheme;
• recovery to a known-good image;
• staged deployment and monitoring;
• an emergency revocation or replacement procedure.

The update service should verify not only that a package is signed but also that it is intended for the particular device model and configuration. Signing keys require strict governance. A compromise of the signing system can affect an entire product population.

Supply-chain security includes component provenance, software bills of materials, vulnerability disclosure processes, reproducible or verifiable builds where feasible, supplier assessment and control of manufacturing tools. Devices should not contain unused services, development credentials or exposed debug ports in production.

6. Network Segmentation and Zero Trust

Flat IoT networks allow an attacker who compromises one device to move laterally. Segmentation limits this movement and reduces the blast radius. Possible segments include:

• building-management devices;
• industrial control systems;
• medical devices;
• guest and employee networks;
• management interfaces;
• cloud or internet-facing services.

Segmentation can use VLANs, firewalls, software-defined networking, private wireless networks, gateways and protocol-aware filtering. Rules should allow only required flows, ports and directions. A gateway that merely forwards all traffic is not meaningful segmentation.

Zero trust is an architectural approach in which no user, device or network location is automatically trusted. Access is granted dynamically according to verified identity, device posture, policy, context and the requested resource. Core principles include:

• verify explicitly;
• use least privilege;
• assume breach;
• continuously monitor and reassess.

Zero trust does not mean that every sensor must communicate directly with a cloud identity provider. In constrained or safety-critical environments, a local gateway may enforce policy and cache short-lived credentials. The design should preserve essential local functions during loss of external connectivity.

Monitoring should identify unusual communication patterns, repeated authentication failures, unexpected firmware versions, command rates and changes in device behaviour. Detection must be accompanied by a response capability; collecting alerts without staff, playbooks or authority to act provides limited value.

7. Privacy Engineering for IoT

IoT devices often collect data continuously and indirectly. A smart speaker may reveal household routines; a wearable may reveal health conditions; an industrial badge system may reveal work patterns. Even data that appear harmless can become sensitive when combined with other datasets.

Privacy engineering principles include:

• Purpose limitation: collect and use data for specified legitimate purposes.
• Data minimization: collect only what is necessary.
• Transparency: explain collection, processing, retention and sharing.
• User control: provide meaningful choices where appropriate.
• Privacy by design and default: address privacy during architecture, not after deployment.
• Retention limitation: delete or anonymize data when no longer needed.
• Access and correction: support applicable rights of individuals.
• Accountability: document decisions and demonstrate compliance.

Privacy risk assessment should examine collection, transmission, storage, inference, sharing, secondary use and deletion. Anonymization is difficult when data are high-dimensional or linked over time. Pseudonymization reduces direct identification but does not necessarily remove legal or ethical obligations.

Regulatory requirements vary by jurisdiction and sector. Examples include data-protection laws, health-data rules, consumer-protection requirements, product safety law and critical-infrastructure regulation. Compliance is a baseline, not a substitute for ethical judgment. Organizations should also consider power imbalance, informed consent, discrimination and the effects of surveillance.

AI introduces additional privacy concerns. Machine-learning models may infer sensitive characteristics from apparently ordinary sensor streams. Model training data may contain personal information, and model outputs may be used to make consequential decisions. Access controls, retention limits, provenance, privacy-preserving aggregation and human review are therefore important.

8. Safety, Availability and Resilience

8.1 Cyber-Physical Safety

A cyber-physical system can convert a digital error into physical harm. Safety analysis should identify hazards, initiating events, consequences and protective barriers. Useful approaches include hazard and operability studies, fault-tree analysis, failure-mode and effects analysis, and safety cases supported by evidence.

Security controls should not create unsafe behaviour. For example, locking a controller during an attack may be safer for one machine but dangerous for another. Engineers must define safe states, degraded modes and manual override procedures. A sensor value should not be trusted merely because it is cryptographically authentic; a compromised but validly authenticated sensor may still report false conditions.

Safety mechanisms should be independent enough to resist common-cause failure. A safety shutdown should not rely on the same vulnerable software, network path and power supply as the function it protects.

8.2 Availability and Resilience

Availability concerns whether a service performs its required function when needed. Resilience is broader: the ability to anticipate, withstand, adapt to, recover from and learn from disruption.

Resilience measures include:

• local autonomy when cloud services fail;
• redundant sensors, communication paths or power supplies;
• graceful degradation;
• backup configurations and data;
• capacity planning and rate limiting;
• disaster recovery testing;
• spare hardware and replacement procedures;
• recovery-time and recovery-point objectives;
• rehearsed incident playbooks.

A resilient design distinguishes essential from nonessential functions. During an outage, it may be acceptable to suspend analytics while retaining local safety control. Recovery should be prioritized by safety and business impact rather than by convenience.

9. Incident Response for IoT

An IoT incident may involve devices, cloud services, suppliers, physical sites and public safety. A basic lifecycle comprises:

1. Preparation: define roles, contacts, logging, tools, legal processes and communication plans.

2. Detection and analysis: validate alerts, establish scope, preserve evidence and assess safety consequences.

3. Containment: isolate affected devices or segments, revoke credentials and prevent harmful commands while preserving essential operations.

4. Eradication: remove malware, correct vulnerabilities, replace compromised keys and eliminate persistence.

5. Recovery: restore from trusted images and configurations, monitor closely and return to service in stages.

6. Lessons learned: identify control failures, update the threat model and improve training and design.

Evidence handling is important because device logs may be volatile, clocks may be inaccurate and storage may be limited. Organizations should synchronize time where possible, protect log integrity, retain relevant network and cloud records, and document collection procedures.

If a compromised device controls machinery, incident responders must coordinate with safety engineers and site operators. Disconnecting power or blocking a network may itself create danger. Communications should distinguish confirmed facts from hypotheses, and notifications should follow applicable legal, contractual and safety obligations.

10. Illustrative Case: Connected Cold-Chain Monitoring

Background

A pharmaceutical distributor uses battery-powered temperature sensors in refrigerated containers. Sensors send measurements through cellular gateways to a cloud platform. Alerts are delivered to logistics staff, and a separate control system can adjust refrigeration settings.

Problem

An attacker gains access to a shared dashboard account and changes alert thresholds. A second weakness allows an old gateway firmware image to be installed. During a network outage, the cloud platform cannot deliver commands, and local operators have no clear manual procedure.

Analysis

The principal assets are medicine quality, temperature records, device identities, refrigeration control and audit evidence. Threats include account takeover, firmware rollback, falsified measurements, denial of service and unauthorized control. The consequences include financial loss, unsafe medicines and regulatory action.

The analysis reveals several weaknesses: shared credentials, excessive dashboard privileges, inadequate update authorization, no rollback protection, dependence on cloud availability and insufficient separation between monitoring and control.

Approach and Solution

The distributor implements unique user accounts with multifactor authentication and separates monitoring, maintenance and control roles. Device identities use certificates, while gateways use secure boot and accept only signed images with monotonically increasing version metadata. Sensor messages use authenticated encryption and freshness counters.

The network is segmented so that monitoring devices cannot directly reach corporate workstations. The control interface is placed behind a gateway enforcing device identity, command authorization and rate limits. Local controllers maintain safe temperature bounds during cloud outages, while operators receive a clear manual escalation procedure. Logs are centrally protected, and update deployment is staged on a small population before wider release.

Privacy analysis limits the collection of employee location data and establishes a retention schedule for operational records. Incident drills test credential revocation, gateway replacement, local control and regulator notification.

Outcome

The redesigned system reduces the likelihood of unauthorized control and improves operation during connectivity failures. It does not eliminate all risk: a compromised authorized operator, defective sensor or physical damage remains possible. Continuous monitoring and periodic reassessment are therefore retained.

Learning Points

The case demonstrates that IoT security is an ecosystem property. Authentication without authorization is insufficient; encryption without key management is fragile; cloud security without local resilience can threaten availability; and cybersecurity decisions must be evaluated against safety and regulatory requirements.

11. AI in IoT Security

AI can support anomaly detection by learning normal patterns of traffic, sensor values or command sequences. It can prioritize alerts, identify unusual device behaviour and assist vulnerability triage. However, machine-learning detection is probabilistic and can produce false positives, false negatives and model drift.

Attackers may manipulate sensor inputs, poison training data, evade classifiers or exploit weaknesses in an AI service. A model that incorrectly labels an unsafe state as normal may be more dangerous than a conventional rule-based failure. AI outputs should therefore be explainable enough for operators, monitored for drift and combined with deterministic safety constraints.

AI systems also require secure model deployment, access control, data provenance and update governance. In safety-relevant applications, human oversight and independently verified limits should remain in place.

12. Governance, Standards and Professional Practice

Effective IoT security requires clear ownership. Product teams are responsible for secure design; operations teams manage deployment and monitoring; procurement teams assess suppliers; executives allocate resources; and users follow safe procedures. Contracts should address vulnerability disclosure, update support, incident notification, data use, service continuity and end-of-life handling.

Organizations should align their practices with recognized cybersecurity, privacy and safety frameworks appropriate to their sector. Commonly used sources include risk-management frameworks, secure-development guidance, industrial security standards, privacy-management standards and product-specific regulations. The precise framework should be selected according to jurisdiction, industry and system criticality rather than copied mechanically.

Security claims should be evidence-based. Useful evidence includes architecture reviews, penetration tests, code analysis, update tests, key-management records, access reviews, recovery exercises and safety validation. Certification may support assurance, but certification does not remove the need for operational monitoring.

Challenges and Limitations

IoT security faces persistent constraints:

• low-cost devices may have limited memory, processing power and energy;
• devices may remain deployed for decades;
• patching may be difficult or impossible in remote locations;
• proprietary protocols reduce interoperability and independent review;
• supply chains may cross jurisdictions and organizations;
• physical access can expose devices and interfaces;
• legacy systems may not support modern authentication;
• security controls can conflict with latency, safety or usability;
• owners may lack expertise to manage certificates and updates.

There is no single control that solves these problems. Strong cryptography cannot compensate for poor governance, and zero trust cannot compensate for unsafe physical design. Risk-based prioritization, lifecycle planning and layered controls are necessary.

Best-Practice Checklist

A responsible IoT program should:

• maintain an up-to-date asset inventory and threat model;
• assign unique identities and prohibit default credentials;
• enforce least privilege and multifactor authentication for sensitive access;
• use authenticated encryption and protect key lifecycles;
• implement secure boot and signed, rollback-resistant updates;
• disable production debug interfaces and reduce attack surface;
• segment networks and apply zero-trust access policies;
• minimize personal data and define retention and deletion rules;
• design safe states, local operation and graceful degradation;
• protect logs and rehearse incident response;
• assess suppliers and plan end-of-life replacement;
• test controls under realistic operational and failure conditions.

Chapter Summary

IoT security must protect not only information but also identities, physical processes, safety functions, privacy and service continuity. Threat modeling begins with assets, actors, data flows and trust boundaries, then evaluates threats and residual risk. Secure identity requires unique device credentials, strong authentication, authorization and accountability. Cryptography provides confidentiality and integrity only when algorithms, nonces and keys are managed correctly.

Secure boot and authenticated firmware updates establish trust in software, while supply-chain controls address risks before deployment. Segmentation and zero trust reduce lateral movement and ensure that access is explicitly verified and limited. Privacy engineering minimizes collection and controls inference, use, retention and disclosure. Safety analysis defines safe states and degraded operation, while resilience combines redundancy, local autonomy, recovery and learning.

Incident response must integrate cyber, operational and safety teams. AI can improve detection but introduces model, privacy and adversarial risks. Ultimately, secure IoT depends on lifecycle governance, evidence-based engineering, skilled personnel and continuous reassessment.

Key Terms

Authenticated encryption: Encryption that also verifies the integrity and authenticity of protected data.

Authorization: Determining which actions an authenticated entity is permitted to perform.

Availability: The property that authorized users or processes can access a service when required.

Device identity: A distinct, managed representation of an IoT device.

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

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

Mutual authentication: A process in which both communicating parties authenticate each other.

Network segmentation: Dividing a network into controlled zones to limit communication and lateral movement.

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

Privacy by design: Incorporating privacy requirements into system architecture and defaults.

Resilience: The ability to withstand, adapt to and recover from disruption.

Secure boot: A startup process that verifies the authenticity and integrity of software before execution.

Secure element: Hardware designed to protect cryptographic keys and operations.

Safety: Freedom from unacceptable risk of physical harm or hazardous operation.

Threat model: A structured representation of assets, actors, attack paths, consequences and controls.

Trust boundary: A boundary across which identity, authority or security assumptions change.

Zero trust: An approach that grants no implicit trust and continuously verifies access.

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

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization in an IoT system.

2. Why is secure boot insufficient without secure firmware updates?

3. State two reasons why privacy risks arise even when sensor data do not contain names.

4. What is the purpose of network segmentation?

5. Identify two characteristics of a resilient IoT system.

Long Answer Questions

1. Explain a complete threat-modeling process for a connected industrial system.

2. Discuss the lifecycle of cryptographic keys in an IoT deployment.

3. Compare role-based and attribute-based authorization for IoT environments.

4. Explain how cybersecurity and physical safety analyses should interact.

5. Describe the stages of an IoT incident-response process and the evidence required.

Analytical / Application Questions

1. A smart-building gateway controls door locks, lighting and environmental systems. Construct a threat model identifying assets, trust boundaries, major threats and prioritized controls.

2. A remote agricultural sensor network has intermittent connectivity and battery-powered devices. Design an authentication, update and resilience strategy that preserves local operation during cloud outages.

3. An AI anomaly detector reports normal behaviour while an attacker gradually changes industrial sensor readings. Analyze possible causes and propose technical, operational and safety controls.

Multiple Choice Questions with Answers

Question 1

Which property ensures that an IoT message has not been altered and came from an authenticated source?

A. Availability

B. Message authentication

C. Data minimization

D. Network segmentation

Correct Answer: B. Message authentication

Question 2

What is the primary purpose of secure boot?

A. To reduce wireless bandwidth

B. To encrypt all cloud databases

C. To verify software before it executes

D. To assign user roles

Correct Answer: C. To verify software before it executes

Question 3

Which control most directly limits lateral movement after one IoT device is compromised?

A. Network segmentation

B. Data retention

C. Firmware compression

D. User interface redesign

Correct Answer: A. Network segmentation

Question 4

What is a key requirement when using an AEAD construction?

A. The same nonce must always be reused

B. A nonce must not be reused with the same key

C. Encryption keys should be publicly posted

D. Plain hashes replace authentication

Correct Answer: B. A nonce must not be reused with the same key

Question 5

Which authorization principle grants only the permissions necessary for a task?

A. Implicit trust

B. Least privilege

C. Open registration

D. Maximum availability

Correct Answer: B. Least privilege

Question 6

Which statement best describes zero trust?

A. All devices inside a local network are trusted

B. Only cloud users require authentication

C. Access is explicitly verified and continuously evaluated

D. Security depends entirely on perimeter firewalls

Correct Answer: C. Access is explicitly verified and continuously evaluated

Question 7

Which practice best helps prevent installation of an older vulnerable firmware version?

A. Rollback protection

B. Data anonymization

C. Traffic mirroring

D. Password sharing

Correct Answer: A. Rollback protection

Question 8

Which privacy principle recommends collecting only data necessary for a specified purpose?

A. Data minimization

B. Non-repudiation

C. Fail-safe design

D. Redundancy

Correct Answer: A. Data minimization

Question 9

During an incident involving a machine actuator, what should responders consider before isolating the device?

A. Whether isolation could create a safety hazard

B. Whether the device has a colorful interface

C. Whether encryption is commercially popular

D. Whether logs can be deleted

Correct Answer: A. Whether isolation could create a safety hazard

Question 10

Which feature most directly supports operation during loss of cloud connectivity?

A. Local autonomy and graceful degradation

B. Shared administrator passwords

C. Unrestricted internet access

D. Disabling all audit logs

Correct Answer: A. Local autonomy and graceful degradation