10. Cybersecurity, Privacy, Safety, and Trust

Introduction and Context

The Internet of Things (IoT) connects sensors, actuators, embedded controllers, gateways, networks, cloud platforms, mobile applications, and human users. This connectivity creates operational value, but it also enlarges the number of places at which systems can be observed, manipulated, disrupted, or misused. An insecure consumer sensor may expose a household; an inadequately protected industrial controller may interrupt production; a compromised medical device may threaten life directly. IoT security therefore cannot be treated as an isolated information-technology function. It is simultaneously a matter of cybersecurity, privacy, physical safety, reliability, governance, and public trust.

IoT environments are especially difficult to protect because they are heterogeneous, widely distributed, resource-constrained, long-lived, and often physically accessible to adversaries. Devices may use different processors, operating systems, communication protocols, update mechanisms, and ownership models. Many remain deployed for a decade or longer, whereas their software dependencies and cryptographic assumptions may become obsolete much sooner. The security objective is consequently broader than preventing unauthorized access. A trustworthy IoT system must preserve confidentiality, integrity, availability, authenticity, accountability, privacy, resilience, and—where physical processes are involved—safe operation.

This chapter examines security and trust across the IoT lifecycle. It develops threat-modeling principles, explains secure boot and hardware roots of trust, evaluates identity and authentication, discusses encryption and key management, and introduces zero-trust architecture. It then considers privacy engineering, intrusion detection, safety-security interaction, governance, and post-quantum readiness. The emphasis is critical: no single mechanism provides security, and controls must be matched to assets, adversaries, consequences, and operational realities.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Construct and critically evaluate threat models for IoT and wireless systems.

2. Analyze device, network, cloud, application, human, and physical attack surfaces.

3. Explain secure boot, hardware roots of trust, identity, authentication, encryption, and key management.

4. Apply zero-trust principles to constrained and intermittently connected devices.

5. Design privacy-preserving data flows and distinguish privacy from confidentiality.

6. Evaluate intrusion-detection strategies and their operational limitations.

7. Analyze interactions between cybersecurity and functional safety.

8. Assess governance, ethical, regulatory, and professional responsibilities.

9. Develop a practical transition strategy for post-quantum cryptography.

From Connected Devices to Trustworthy Systems

Security goals are often summarized through the confidentiality, integrity, and availability triad. Confidentiality limits disclosure; integrity protects data and commands from unauthorized alteration; availability supports timely and dependable service. IoT adds further requirements. Authenticity establishes that a device, user, message, or software image is genuine. Non-repudiation and accountability support investigation and governance. Resilience concerns the ability to continue or recover operations under attack. Safety requires that the system avoid unacceptable physical harm, even when components fail or are maliciously manipulated.

Trust is not identical to security. Security describes protections and assurance mechanisms, whereas trust is a justified confidence that a system will behave acceptably under stated conditions. Trust may be technical, institutional, or social. A device can use strong encryption but still be untrustworthy if its manufacturer conceals data practices, cannot provide updates, or makes unsupported safety claims. Trust must therefore be earned through evidence: secure design, verifiable provenance, transparent governance, tested controls, and accountable operation.

Important terminology includes the asset, threat, vulnerability, attack, risk, control, and trust boundary. An asset is something requiring protection, such as firmware, a cryptographic key, a location record, a safety command, or system availability. A threat is a potentially harmful event or actor. A vulnerability is a weakness that can be exploited. Risk combines the likelihood and consequences of an adverse event, although precise numerical estimation is often difficult. A control reduces likelihood, impact, or recovery time. A trust boundary marks a change in authority or assumed security, such as the boundary between a field device and a cloud service.

Threat Modeling the IoT Attack Surface

Threat modeling should begin with the system rather than with a preferred security product. A useful process identifies assets, actors, interfaces, trust boundaries, threats, consequences, and controls. Data-flow diagrams can show sensors, gateways, brokers, APIs, administrators, third-party services, and physical processes. An adversary analysis should distinguish remote opportunists, botnet operators, criminal groups, insiders, competitors, activists, nation-state actors, and individuals with physical access. Their capabilities, resources, persistence, motivations, and legal access differ substantially.

The attack surface extends across several layers. At the device layer, attackers may exploit default credentials, exposed debug ports, insecure local storage, weak randomness, vulnerable libraries, malicious replacement components, or firmware flaws. At the wireless layer, threats include eavesdropping, traffic analysis, replay, jamming, rogue gateways, protocol downgrade, and unauthorized joining. At the edge and network layers, routing manipulation, denial of service, segmentation failures, and compromised gateways are significant. Cloud and application surfaces include insecure APIs, excessive privileges, weak tenant isolation, supply-chain compromise, poor logging, and exposed management interfaces. Human and organizational surfaces include phishing, unsafe maintenance, credential sharing, inadequate procurement, and unclear responsibility for updates.

Wireless systems require particular attention to availability and physical proximity. Encryption may prevent interpretation of a message but cannot by itself prevent radio-frequency interference. A correctly authenticated device may still be induced to transmit excessively, drain its battery, or operate in a congested environment. Availability controls may include channel diversity, rate limits, redundancy, interference detection, local fallback modes, and carefully bounded retries.

A threat model should also consider abuse cases and safety cases. An abuse case describes how a legitimate function can be misused—for example, repeatedly requesting a door unlock or changing a thermostat to create equipment stress. A safety case presents structured evidence that hazards are controlled. Combining the two prevents a narrow focus on data theft while ignoring manipulation of the physical process.

Risk analysis should be consequence-sensitive. A compromised inventory tag and a compromised infusion pump may share a software vulnerability but cannot be assigned the same tolerance for failure. Common methods include attack trees, misuse cases, STRIDE-style categorization, attack graphs, and quantitative or semi-quantitative risk matrices. These methods support reasoning; they do not replace expert judgment. A risk score can conceal uncertainty, interdependence, and cascading effects, so assumptions should be recorded and periodically revisited.

Establishing Device Authenticity

Secure boot is a chain-of-trust process in which each stage verifies the integrity and authenticity of the next stage before execution. A hardware-protected immutable root, or an equivalent trusted starting point, validates a bootloader; the bootloader validates the operating system; the operating system validates critical applications and configuration. Digital signatures generally provide authenticity and integrity, while hashes provide measurement or comparison. Secure boot is not the same as encrypted boot: encryption protects confidentiality of code, whereas signature verification determines whether code is authorized.

A hardware root of trust is a device or processor capability that protects foundational secrets and performs trusted operations. Examples include secure elements, trusted platform modules, one-time programmable memory, physically unclonable functions, and trusted execution environments. Such mechanisms can store private keys, generate device measurements, perform signing, and resist extraction better than ordinary flash memory. They do not make the entire device secure. Vulnerable authorized software, faulty provisioning, side-channel leakage, compromised update services, and poor lifecycle management remain possible.

Measured boot records what was executed, while verified boot prevents unauthorized software from executing. Remote attestation allows a verifier to assess device state using signed measurements. Attestation can support admission decisions, but it raises questions about privacy, verifier authority, measurement interpretation, and recovery when a device is noncompliant. In research and industrial settings, attestation is most valuable when measurements are linked to explicit policy rather than treated as an unquestioned proof of safety.

Firmware updates are a central trust mechanism. Updates should be authenticated, integrity-protected, version-controlled, rollback-resistant where appropriate, and recoverable after interruption. Key compromise requires a revocation and re-provisioning strategy. Emergency updates must be balanced against the risk that an attacker uses the update channel itself. Devices lacking sufficient memory, energy, or recovery storage require compensating controls and may need replacement before their operational life ends.

Identity, Authentication, and Authorization

An IoT identity should represent a device, service, user, role, or workload in a manner that supports accountability and lifecycle management. Shared passwords are especially weak because they prevent attribution and make compromise scalable. Better approaches use unique device credentials, certificates, hardware-bound keys, or carefully designed symmetric credentials. Identity proofing begins during manufacturing or commissioning and continues through ownership transfer, maintenance, suspension, and decommissioning.

Authentication answers “who or what are you?” Authorization answers “what may you do?” These must remain separate. A device authenticated as genuine should not automatically receive unrestricted access. Least privilege, role-based or attribute-based policies, command-specific permissions, and time-limited privileges reduce the consequences of compromise. Mutual authentication is important in machine-to-machine communication: the device should authenticate the server, and the server should authenticate the device.

Authentication methods must fit the environment. Public-key mechanisms simplify large-scale identity and rotation but may impose computational and communication costs. Symmetric methods can be efficient but create key-distribution and compromise-containment challenges. Human users may require multifactor authentication, while constrained sensors may use hardware-bound credentials and network admission policies. Biometrics can assist human authentication but introduce irreversibility and privacy concerns when biometric templates are compromised.

Identity lifecycle management is frequently more important than the initial protocol choice. Organizations need inventories, ownership records, certificate expiration monitoring, revocation procedures, secure transfer between owners, and reliable deletion at retirement. An unknown device is an unmanaged risk, even if it uses a strong cryptographic algorithm.

Encryption and Key Management

Encryption protects data in transit, at rest, and sometimes during processing. Authenticated encryption is generally preferable because it combines confidentiality with integrity and authenticity of the protected message. Transport-layer security and datagram-oriented variants can secure IP communication; link-layer mechanisms protect particular wireless segments. Encryption should not be assumed to protect metadata such as timing, packet size, location, or communication frequency.

Key management is the operational foundation of cryptography. It includes generation, distribution, storage, use, rotation, backup, revocation, recovery, destruction, and audit. Keys should be generated with approved randomness, stored in protected hardware where feasible, and separated according to purpose. A device key used for identity should not also decrypt long-term user data. Key hierarchies and derivation functions can limit exposure and support scalable provisioning.

The strongest algorithm fails if keys are embedded identically in every device, exposed in logs, transmitted without protection, or never retired. Manufacturing supply chains require secure personalization, protection of provisioning stations, separation of duties, and evidence of provenance. Field replacement and ownership transfer require procedures that do not leave former operators with continuing access.

Zero Trust in Distributed IoT

Zero trust rejects implicit trust based on network location. Every access request is evaluated using identity, device posture, resource sensitivity, context, and policy. In IoT, this does not mean repeatedly performing expensive interactive authentication on every tiny sensor. It means designing explicit, continuously governed relationships: a sensor may publish only specified measurements to a named broker; a gateway may issue only bounded commands; a maintenance engineer may access a controller only during an approved window.

A practical zero-trust architecture combines strong identities, segmented networks, policy enforcement points, least privilege, continuous telemetry, and rapid revocation. Microsegmentation limits lateral movement. A gateway can mediate protocol translation and enforce policies for constrained nodes. Local policy caches are useful during intermittent connectivity, but their duration and authority must be bounded. Fail-safe behavior must be carefully distinguished from fail-open behavior: loss of a policy server should not automatically grant dangerous privileges.

Zero trust has limitations. Device posture can be difficult to measure, legacy protocols may lack identity support, policy engines can become centralized targets, and excessive verification can harm availability. The architecture must therefore incorporate graceful degradation, local safety controls, and tested recovery procedures.

Privacy Engineering for IoT Data

Privacy concerns arise because IoT systems continuously observe people, spaces, behavior, and relationships. Privacy is broader than secrecy. It includes appropriate collection, purpose limitation, control over use, contextual integrity, fairness, and protection against harmful inference. Even apparently harmless sensor readings can reveal occupancy, health conditions, routines, productivity, or social associations when combined with other data.

Privacy engineering begins with data minimization: collect only what is necessary, at the required precision, for a defined purpose. Designers can use local processing, aggregation, pseudonymization, access controls, retention limits, selective disclosure, and privacy-preserving analytics. Pseudonymization reduces direct identification but does not guarantee anonymity; auxiliary data may enable re-identification. Differential privacy can limit the contribution of any individual to statistical outputs, but its privacy budget, accuracy trade-offs, and composition effects require careful governance.

Privacy impact assessments should examine data flows, affected groups, secondary uses, consent quality, retention, cross-border transfers, and redress. Consent is not a universal solution, especially where individuals cannot meaningfully refuse monitoring. Organizations should provide understandable notices, secure interfaces for access and deletion where applicable, and controls for authorized research use. Ethical review is important when IoT data affects employment, insurance, health, public services, or vulnerable populations.

Detecting and Responding to Intrusions

Prevention is insufficient because vulnerabilities remain and credentials may be stolen. Intrusion detection combines endpoint, network, protocol, and behavioral evidence. Signature-based systems recognize known patterns and are efficient but weak against novel attacks. Anomaly detection establishes a baseline and identifies deviations, although legitimate IoT behavior can change with seasons, maintenance, firmware updates, or physical conditions. Specification-based detection compares actions with an explicit model of permitted behavior and can be effective for industrial protocols.

Machine learning can classify traffic, detect botnet behavior, and prioritize alerts. However, models may suffer from biased training data, concept drift, adversarial manipulation, false positives, and poor explainability. Operational success depends on asset context and response capacity, not merely detection accuracy. A useful program defines alert ownership, triage severity, evidence preservation, containment authority, recovery procedures, and communication responsibilities.

Security monitoring should be privacy-aware and resilient. Logs need synchronized time, integrity protection, appropriate retention, and restricted access. Devices with limited resources may forward telemetry to gateways, but loss of connectivity requires local buffering or event prioritization. Incident response should include isolation without creating unsafe physical states, forensic preservation, eradication, restoration, and lessons learned.

When Cybersecurity Becomes a Safety Issue

Safety and security address different sources of harm but increasingly interact. Safety traditionally considers accidental failures, while security considers intentional and unauthorized actions. A cyberattack can create a safety hazard by altering sensor readings, disabling interlocks, issuing unsafe commands, or delaying emergency communication. Conversely, a safety mechanism can create a security weakness if it exposes an unauthenticated override.

Engineering analysis should connect hazard analysis, threat modeling, and failure-mode analysis. Safety functions should have independence, bounded authority, deterministic behavior, and carefully protected fail-safe states. Yet “fail-safe” is context-dependent: stopping a machine may protect workers but cause loss of refrigeration, traffic disruption, or hazardous pressure accumulation. Security controls must therefore be evaluated for their effects on real-world processes.

A mature organization uses defense in depth: segmentation, independent safety instrumentation, authenticated commands, rate limits, manual procedures, physical safeguards, and tested recovery. Safety-critical systems should not rely solely on cloud availability or a single authentication service. Change management must assess both cyber risk and process hazard, and exercises should include simultaneous technical and operational failure.

Governance, Regulation, and Professional Responsibility

IoT governance assigns responsibility across manufacturers, integrators, operators, cloud providers, maintainers, and users. Procurement contracts should require vulnerability disclosure processes, software bills of materials, update support periods, secure default configuration, incident notification, evidence of testing, and clear responsibility for end-of-life devices. Security claims should be proportionate to evidence.

Relevant standards and regulatory regimes vary by jurisdiction and sector, but common expectations include risk management, privacy protection, secure development, access control, auditability, vulnerability handling, and resilience. Organizations should map obligations to system functions rather than treating compliance certificates as proof of absolute security. Standards can establish a baseline, while doctoral-level analysis should ask whether the baseline is adequate for the specific threat and consequence environment.

Professionals have duties to avoid preventable harm, protect confidential information, disclose vulnerabilities responsibly, and challenge unsafe deployment decisions. Surveillance capabilities require proportionality and accountability. Security research involving IoT devices should consider authorization, disclosure, user impact, and preservation of evidence. Trust is damaged when organizations conceal breaches, overstate protection, or shift all responsibility to users who lack meaningful control.

Post-Quantum Readiness

Large-scale quantum computers could threaten widely deployed public-key systems based on factoring or discrete logarithms. Symmetric cryptography is generally affected differently, and larger key sizes can provide a security margin. The exact timing of quantum capability is uncertain, but IoT systems have long lifecycles and data may require confidentiality for many years. The relevant concern is “harvest now, decrypt later”: adversaries may collect encrypted traffic today for future decryption.

Post-quantum readiness begins with cryptographic inventory and dependency mapping. Organizations should identify algorithms, certificates, firmware signatures, communication protocols, hardware limitations, data-retention periods, and replacement constraints. Cryptographic agility—the ability to change algorithms without redesigning the whole system—is valuable, but uncontrolled agility can create downgrade and configuration risks. Hybrid key establishment or signatures may provide transitional protection where supported, with careful attention to message size, memory, energy, and interoperability.

Migration should prioritize long-lived devices, high-consequence systems, sensitive archived data, and trust anchors that are difficult to replace. Testing must include constrained radios, boot-time performance, certificate sizes, secure-element support, and recovery from failed updates. Post-quantum algorithms are not automatically safer in every implementation; side-channel protection, validation, secure provisioning, and lifecycle governance remain necessary.

Illustrative Case Study: Securing a Smart Water Treatment Network

Background

A regional utility operates remote pumping stations, chemical dosing controllers, water-quality sensors, programmable logic controllers, wireless links, and a supervisory control platform. Stations were installed by different vendors over fifteen years. Some devices use shared maintenance passwords, several cannot receive modern firmware updates, and remote access is provided through a central gateway.

Situation and Problem

An assessment identifies three risks. First, a stolen contractor credential could allow unauthorized access to multiple stations. Second, an attacker who compromises a sensor gateway could send manipulated readings to influence chemical dosing. Third, a denial-of-service attack against wireless links could interrupt monitoring and force operators into manual control. The utility initially proposes deploying a cloud-based anomaly-detection service, but the safety team objects that cloud unavailability must not prevent safe local operation.

Analysis

The asset analysis distinguishes confidentiality of operational data from integrity and availability of dosing commands. The threat model includes remote attackers, malicious insiders, compromised contractors, and individuals with physical access to cabinets. Safety analysis shows that excessive dosing and insufficient dosing have different consequences. The system therefore requires authenticated commands, independent local bounds, manual override, and validated fallback behavior. The existing flat network permits lateral movement, while shared credentials prevent attribution and efficient revocation.

Approach

The utility creates unique hardware-bound identities for new gateways and certificates for authorized services. Legacy devices are placed behind protocol-aware gateways and isolated into zones. Contractors receive multifactor, time-limited access through a broker; direct inbound access is removed. Secure boot and signed firmware are required for replacement gateways, and update packages are versioned and rollback-controlled. Local controllers enforce chemical limits independently of cloud analytics. Sensors are cross-checked using plausibility rules and redundant measurements before commands are accepted.

Telemetry is monitored at the gateway and central levels. A specification-based detector flags impossible command rates, unexpected write operations, and deviations from normal operating sequences. During communication loss, local systems continue bounded operation and alert operators rather than granting unrestricted access. The utility also establishes a vulnerability disclosure process, maintains a software bill of materials, and begins a cryptographic inventory for future post-quantum migration.

Outcome

The redesigned architecture reduces credential reuse, limits lateral movement, improves attribution, and preserves essential safety behavior during cloud or wireless outages. It does not eliminate risk: legacy controllers remain difficult to update, and false alarms require operational tuning. The utility therefore treats the program as continuous risk management rather than a one-time installation.

Learning Points

The case demonstrates that zero trust must be adapted to operational technology, that security monitoring cannot substitute for independent safety controls, and that identity lifecycle management is as important as encryption. It also shows why legacy constraints, procurement, maintenance, and future cryptographic migration must be addressed together.

Challenges and Common Design Errors

Common errors include treating encryption as a complete security solution, relying on default credentials, placing all devices on one network, assuming authenticated devices are trustworthy for every action, and deploying machine learning without a response process. Organizations also underestimate physical attacks, neglect certificate expiration, collect excessive personal data, and fail to define who owns a device after installation.

Other failures arise from optimizing for purchase price rather than total lifecycle cost. A device that cannot be updated may be inexpensive initially but costly and dangerous to operate. Security controls can also create availability or safety problems when introduced without process analysis. Excessive logging can create privacy risk; excessive authentication can encourage unsafe workarounds. Controls must therefore be proportionate, tested, explainable, and maintained.

Best-Practice Design Principles

A defensible IoT security program should:

• maintain an accurate asset and software inventory;
• model threats, misuse, hazards, and trust boundaries before deployment;
• use unique identities, mutual authentication, least privilege, and secure defaults;
• establish hardware-assisted roots of trust where risk justifies them;
• protect the complete key and firmware lifecycle;
• segment networks and design explicit, policy-based access;
• minimize personal data and govern retention and secondary use;
• combine prevention, detection, response, recovery, and tested resilience;
• integrate cybersecurity with safety engineering and operational procedures;
• require updateability, vulnerability disclosure, and supply-chain evidence;
• plan cryptographic agility and post-quantum migration early; and
• measure outcomes through meaningful indicators such as inventory coverage, patch latency, revocation time, privileged-access exposure, recovery performance, and unresolved high-consequence findings.

Chapter Summary

IoT cybersecurity is a lifecycle and systems-engineering problem involving devices, wireless links, networks, cloud services, people, organizations, and physical processes. Effective protection begins with threat modeling that identifies assets, adversaries, trust boundaries, consequences, and safety implications. Secure boot, hardware roots of trust, identity, authentication, authorization, encryption, and key management establish technical foundations, but none is sufficient alone. Zero-trust architecture limits implicit authority through explicit identity, segmentation, least privilege, and continuous evaluation. Privacy engineering addresses data collection, inference, retention, and accountability rather than merely encrypting information. Intrusion detection must be connected to response and recovery, while safety controls must remain dependable during cyber incidents. Governance, responsible procurement, lifecycle support, and post-quantum planning are essential because IoT systems are long-lived and difficult to replace.

Key Terms

Asset: A resource requiring protection, such as a device, key, command, data set, or service.

Attack surface: The set of interfaces and conditions through which a system may be attacked.

Authenticated encryption: Cryptography that provides confidentiality together with integrity and authenticity.

Hardware root of trust: Hardware-protected foundation for trusted keys, measurements, or execution.

Identity: A persistent representation of a device, user, service, or workload.

Measured boot: Recording software measurements during startup for later verification or attestation.

Mutual authentication: Authentication in which both communicating parties verify one another.

Post-quantum cryptography: Cryptographic methods designed to resist attacks by quantum computers.

Privacy engineering: Systematic design of technologies and processes that reduce privacy risks.

Remote attestation: Evidence supplied by a device about its software or configuration state.

Risk: The possibility and consequence of an adverse event affecting protected assets.

Secure boot: Verification of authorized software before it is executed.

Security information and event management: Collection and analysis of security events for monitoring and response.

Threat model: A structured representation of assets, adversaries, vulnerabilities, attacks, and consequences.

Trust boundary: A location where assumptions about authority, identity, or security change.

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

Key management: The lifecycle administration of cryptographic keys from generation to destruction.

Differential privacy: A mathematical approach limiting how much an individual affects a statistical result.

Functional safety: Protection against unacceptable harm arising from system operation or failure.

Review Questions

Short Answer Questions

1. Why is secure boot different from encrypted boot?

2. What is the difference between authentication and authorization?

3. Why does encryption not fully protect wireless availability?

4. Define a hardware root of trust.

5. What is meant by “harvest now, decrypt later”?

Long Answer Questions

1. Explain how an IoT threat model should incorporate both cyber threats and physical safety hazards.

2. Discuss the role of identity lifecycle management in large-scale IoT deployments.

3. Evaluate the benefits and limitations of zero-trust architecture for constrained devices.

4. Explain how privacy engineering differs from conventional information security.

5. Describe a comprehensive strategy for post-quantum readiness in long-lived IoT systems.

Analytical / Application Questions

1. A factory has authenticated sensors but shared administrator passwords, a flat network, and no local fallback during cloud outages. Analyze the major risks and propose a prioritized redesign.

2. A smart-building operator wants to collect continuous occupancy, audio, and energy data for “future analytics.” Apply privacy-engineering principles to assess and redesign the collection plan.

3. A medical-device manufacturer must choose between a low-cost device with no secure boot and a more expensive updateable device with hardware-backed identity. Develop a risk-based procurement recommendation, including safety and lifecycle considerations.

22. Multiple Choice Questions with Answers

Question 1

Which statement most accurately distinguishes secure boot from encrypted boot?

A. Secure boot protects data confidentiality, while encrypted boot provides availability.

B. Secure boot verifies authorized software before execution, while encryption protects code confidentiality.

C. Secure boot authenticates users, while encrypted boot authenticates networks.

D. Secure boot prevents radio jamming, while encrypted boot prevents replay.

Correct Answer: B. Secure boot verifies authorized software before execution, while encryption protects code confidentiality.

Question 2

A sensor is authenticated successfully but is allowed to publish data only to one specified broker. Which principle is primarily demonstrated?

A. Least privilege

B. Non-repudiation

C. Data anonymization

D. Measured boot

Correct Answer: A. Least privilege

Question 3

Why can encrypted wireless communication still be vulnerable to a denial-of-service attack?

A. Encryption always exposes private keys.

B. Encryption prevents interpretation but does not necessarily prevent interference or resource exhaustion.

C. Encryption disables device authentication.

D. Encryption guarantees that all packets arrive.

Correct Answer: B. Encryption prevents interpretation but does not necessarily prevent interference or resource exhaustion.

Question 4

Which control best limits lateral movement after one IoT gateway is compromised?

A. Increasing data-retention periods

B. Using a common password across gateways

C. Network segmentation with explicit policy enforcement

D. Collecting more raw sensor data

Correct Answer: C. Network segmentation with explicit policy enforcement

Question 5

What is the principal purpose of measured boot?

A. To record what software was executed for later verification or attestation

B. To conceal all firmware from administrators

C. To replace authorization policies

D. To increase wireless transmission power

Correct Answer: A. To record what software was executed for later verification or attestation

Question 6

An IoT organization uses anomaly detection but has no team responsible for investigating alerts. What is the most significant weakness?

A. The system cannot generate hashes.

B. Detection is disconnected from operational response and recovery.

C. The devices must use symmetric cryptography.

D. Privacy is automatically eliminated.

Correct Answer: B. Detection is disconnected from operational response and recovery.

Question 7

Which privacy-engineering practice most directly reduces unnecessary exposure of personal information?

A. Collecting all available data for possible future use

B. Increasing the precision of every sensor

C. Applying data minimization and local processing

D. Sharing pseudonymous data without retention limits

Correct Answer: C. Applying data minimization and local processing

Question 8

In the water-treatment case, why were local chemical bounds retained despite cloud analytics?

A. Cloud services cannot use encryption.

B. Independent local controls preserve safety during connectivity or cloud failure.

C. Local controls eliminate the need for identity.

D. Cloud analytics always produce incorrect results.

Correct Answer: B. Independent local controls preserve safety during connectivity or cloud failure.

Question 9

What is the first practical step in post-quantum readiness?

A. Replace every device immediately without an inventory

B. Disable all public-key cryptography

C. Identify algorithms, dependencies, data lifetimes, and replacement constraints

D. Assume quantum attacks are impossible until a quantum computer exists

Correct Answer: C. Identify algorithms, dependencies, data lifetimes, and replacement constraints

Question 10

Which statement best expresses the relationship between security and trust?

A. Strong encryption automatically proves institutional trustworthiness.

B. Trust is justified confidence supported by technical, operational, and governance evidence.

C. Trust and security are identical concepts.

D. Trust exists whenever a device is connected to a private network.

Correct Answer: B. Trust is justified confidence supported by technical, operational, and governance evidence.