CEH · M18

IoT and OT: include physical safety in security decisions

Connected devices may measure or change the physical world. Inventory function, communication needs and maintenance constraints before choosing controls that preserve operational safety.

After this lesson, you can
  • Explain OT availability, reliability and safety constraints.
  • Plan minimum necessary communication with a tabletop data-flow map.

Prerequisites: Firewalls and detection: verify allow, block and alert separately

Digital actions can have physical consequences

IoT includes varied connected sensors and service devices. OT involves systems that monitor or control physical processes. They overlap, but devices are not interchangeable. Restarting an office test machine can have very different consequences from interrupting a process controller.

Security measures must account for performance, reliability, physical safety and availability. Updates, scans or isolation may require vendor support, offline testing, operator coordination and maintenance windows. Ordinary IT scanning habits cannot simply be transferred.

Further reading: NIST SP 800-82 Rev. 3: OT Security

Identify communication that is actually necessary

Inventory device purpose, owner, version, support lifetime and required data flows. Segmentation and controlled channels can limit unnecessary connections, but rules must match operational needs and retain emergency and recovery procedures.

Begin validation with synthetic diagrams or an isolated test environment. Real-device changes must follow site approval procedures. This unit’s table establishes design reasoning, not verified safety of a production process.

Example: a temperature sensor and a controller

In a fictional greenhouse, a sensor sends temperature to a controller, which adjusts a fan. A reporting service only needs to read summaries.

The reporting service does not need to alter fan settings. Limit that unnecessary control path while retaining required sensing and control flows. Isolation should not blindly sever every connection.

Conclusion: Base the design on necessary flows; operational and safety verification remain necessary before activation.

Tabletop exercise: data flows and stop conditions

Use only the fictional greenhouse; connect to no real IoT or OT devices.

  1. Draw sensor, controller, fan and reporting-service nodes.
  2. Mark necessary flows and the unnecessary control path.
  3. List the maintenance window, recovery method and stop conditions requiring site-owner confirmation.

Expected result

Reporting and device control are separated while required control flows remain; real activation stays subject to site approval.

Check your work

Why is immediate rebooting not a universal response for every device?

Finish and clean up

Save the diagram and assumptions; no physical device state needs restoration.

Q&A · Check your reasoning

Choose an answer and confidence, then read every explanation. Answers stay in this browser.

ceh-m18-ot-q1 · Original practice

What is a main concern with directly applying ordinary scanning settings to OT?

What is a main concern with directly applying ordinary scanning settings to OT?
ceh-m18-ot-q2 · Original practice

A report service only needs summaries. How should communication be designed?

A report service only needs summaries. How should communication be designed?

Connect the next idea

Terms: Operational technology (OT)·Segmentation·Availability

Sources & scope

These sources support the technical principles. Examples, questions and exercises are original to this series.