Certified: The CompTIA SecOT+ Audio Course

In this episode, we’re going to take a beginner-friendly tour of the main device roles you will see in operational technology, because OT can feel confusing until you know what each piece does and how they work together. When people first hear about OT security, they often picture a control room and a mysterious network, but the real story starts with devices that sense what is happening, devices that make things happen, and devices that decide what should happen next. Those roles show up in almost every industrial environment, whether it is a factory, a water facility, an energy site, or a building system. Once you understand the roles, you can understand why certain failures matter, why certain protections matter, and why certain incidents are dangerous. For exam success, you are not trying to memorize a pile of acronyms as trivia, you are trying to build a mental picture of a control system as a living loop. That loop starts with measurement, moves through decision, and ends with action, then repeats, sometimes many times per second. When you can describe that loop clearly, you can interpret OT scenarios without feeling lost.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Sensors are the starting point of the control loop, because they measure physical conditions in the real world and turn those conditions into signals a system can use. A sensor might measure temperature, pressure, flow, level, speed, vibration, chemical concentration, or position, and each measurement is called a process variable. The sensor itself might be a small device mounted on a pipe, a tank, a motor, or a production line, and it is often exposed to harsh environments like heat, moisture, dust, and vibration. The important beginner idea is that sensors do not just provide “data” like a spreadsheet, they provide the reality the control system believes. If a sensor is wrong, the system can make wrong decisions, even if every other component is working perfectly. Sensors also have limits, like accuracy, drift over time, and failure modes, such as getting stuck at a constant reading or producing noisy signals. That is why operators and engineers care about sensor health, calibration, and signal quality. From a security perspective, sensors are interesting because they can be targets for disruption, spoofing, or simply accidental damage, and any compromise can ripple into control decisions.

Actuators are the devices that do the physical work, meaning they take a command from the control system and cause something to change in the process. Common actuators include valves that open or close, motors that start or stop, pumps that move fluid, dampers that regulate airflow, heaters that add heat, and relays that switch circuits. If sensors are the eyes and ears of a system, actuators are the hands, because they move, push, turn, and regulate the physical world. A key beginner lesson is that actuators often operate under constraints, like maximum speed, safe ranges, and mechanical wear, so the system cannot simply command anything it wants without consequences. Actuators also have failure modes, like sticking, losing power, or moving more slowly than expected, and those failures can affect safety and production. Another important point is that actuator commands may be continuous, like adjusting a valve gradually, or discrete, like turning a motor on or off, depending on the process. Security matters here because a wrong command can cause real-world harm, and because preventing unauthorized commands is one of the central goals of OT security. When you understand actuators, you start to see why OT incidents can become physical incidents.

Between sensors and actuators, you need a decision-making component, and that is where controllers come in. A controller is a device or system that receives sensor input, compares it to desired conditions, and then decides what command to send to actuators. The desired condition is often called a set point, which is the target value the system is trying to maintain, like keeping a tank at a certain level or maintaining a room at a certain temperature. Controllers can be very simple or quite complex, but at a beginner level, you can think of them as machines that repeatedly ask, what is happening right now, what should be happening, and what adjustment should I make. That repeating behavior is what creates stable control, and it is why OT environments depend on reliable timing and predictable communication. Controllers may also handle alarms, interlocks, and safety-related logic that prevents dangerous actions. The security angle is that controllers are high-value targets because they influence what actuators do, and because they often sit at the center of many signals. A controller compromise can affect both visibility and control, which is a dangerous combination.

One of the most common types of controller in OT is the Programmable Logic Controller (P L C), which is designed to be rugged, reliable, and suited for industrial environments. A P L C typically reads input signals from sensors or switches, executes control logic, and writes output signals to actuators. The term “logic” here matters, because P L C behavior is based on programmed rules, often built to match the needs of a specific machine or process. A P L C is usually built to keep working for long periods with minimal downtime, and it often runs in environments where a standard office computer would not survive. Another beginner concept is that P L Cs interact with input and output modules, which are like the interface points that connect the controller to the real world. The controller might not directly connect to every sensor and actuator; instead, modules handle electrical signal conversion and wiring. P L Cs are common in manufacturing lines, packaging systems, and many types of industrial automation. From a security perspective, protecting P L Cs matters because they are often trusted components, and changes to their logic can alter physical behavior in subtle ways.

A Human-Machine Interface (H M I) is the point where people interact with the control system, and that makes it both powerful and risky. An H M I is typically a screen or workstation that shows process information, alarms, trends, and control options, and it allows an operator to monitor and influence the process. For beginners, it helps to think of an H M I as a window into the process state and a set of controls for interacting with that state. If the window is wrong, the operator’s decisions can be wrong, even if the process itself is behaving normally. If the controls are misused or abused, the operator can unintentionally create unsafe conditions, and an attacker could potentially do worse. H M Is are often configured to show simplified views, using graphics and labels that match the way operators think about the plant. They may also include access controls, such as requiring certain permissions to change set points or acknowledge alarms. Security concerns include authentication, integrity of displayed data, and preventing unauthorized remote access, because an H M I is often connected to broader networks. Understanding the H M I role helps you interpret questions about visibility, alarms, and operator actions.

Another device role you will see is the Remote Terminal Unit (R T U), which is common in environments where equipment is spread out over large distances. An R T U collects data from sensors and sometimes controls actuators, often in remote or harsh locations, and it communicates back to a central monitoring or control system. Think of an R T U as a field device that helps extend control and visibility beyond a single building, such as along a pipeline, across a water distribution network, or throughout an electrical grid. RTUs are associated with supervisory control environments, where a central system monitors many remote sites and issues high-level control commands. Unlike a P L C, which is often tightly tied to local machine logic, an R T U may be designed with communications and remote telemetry as a major focus. RTUs must often handle unreliable communication links, limited bandwidth, and environmental exposure, so they are built to be durable and tolerant. From a security perspective, RTUs are sensitive because they connect remote assets to centralized systems, and remote locations can have less physical protection. If a remote device is compromised, it can become an entry point, or it can feed false data that misleads operators.

It is also useful to understand that these roles can overlap, because real OT systems are built for practical needs, not for perfect category boundaries. A P L C can be part of a local system that also communicates with a central system, making it behave like an R T U in some contexts. An R T U can include local logic and control capabilities, making it behave like a controller as well as a telemetry device. An H M I might run on a general-purpose computer, but its role is still to provide human interaction, not to be a “server” in the office sense. Sensors and actuators can be “smart,” meaning they include digital communications and some local processing, which blurs the line between simple field devices and more complex nodes. The key for beginners is to focus on function rather than label: what does the device measure, what does it control, who interacts with it, and how does it communicate. When you answer exam questions, identifying roles often matters more than naming a specific brand or model. If you can identify the role, you can predict what risks and constraints apply.

Let’s connect these roles into a simple picture of how a control loop behaves in everyday operation. A sensor measures a process variable, like pressure in a pipe, and sends that value into the controller. The controller compares that value to a set point, like the desired pressure, and then calculates whether the actuator should change, such as opening a valve slightly to reduce pressure. The actuator moves, the pressure changes, and the sensor reports the new value, so the controller can adjust again. This loop repeats continuously, often quickly, and it is designed to keep the process stable. The H M I displays the pressure value, the set point, the valve position, and any alarms, so an operator can monitor and intervene if needed. In a distributed environment, an R T U might handle that sensor reading and send it to a central system, or it might receive a command from a central system and pass it to a local actuator. When you understand this loop, you can see how errors and attacks can cause harm, because a false sensor value can drive wrong decisions, a compromised controller can issue wrong commands, or a misleading H M I can cause wrong human actions. The system is a chain, and each role is a link.

Common misconceptions often come from assuming OT devices behave like IT devices, because that is what beginners are most familiar with. One misconception is that controllers are basically like servers, but controllers are usually designed for predictable control, not general computing tasks, and they may have constraints that make them less flexible. Another misconception is that an H M I is “just a screen,” but it is often a critical control point that shapes human decisions and can allow direct actions. Another misconception is that sensors only report “data,” but in control systems, sensor data is treated as truth unless proven otherwise, so integrity matters. Beginners also sometimes think that remote devices are less important because they are far away, yet remote devices can be essential to the system’s safety and reliability, and their physical isolation can make them harder to defend. There is also a misconception that the most important device is always the controller, but in many incidents, the problem starts with visibility, like an H M I showing wrong information or sensors providing bad readings. Understanding roles helps you see that security and safety depend on the full loop, not just the central component.

When you translate this into security thinking, you start to see natural questions the exam might ask. If an attacker wants to cause physical disruption, they might target actuators directly, or they might target controllers that command actuators. If an attacker wants to hide what they are doing, they might target H M Is and sensor values to distort what operators see. If someone wants to create long-term instability, they might alter control logic in subtle ways that cause small inefficiencies or occasional alarms that look like equipment issues. The exam does not require you to become paranoid, but it does expect you to recognize how device roles relate to risk. It also expects you to recognize operational constraints, like why you cannot simply reboot a controller whenever you want, or why you must coordinate changes with operations. The more you understand each role’s purpose, the more naturally these constraints make sense. Security in OT is about reducing the chance of wrong actions and wrong information, whether those problems are accidental or malicious. Device roles are the language you use to describe where that wrongness could enter.

To wrap up, sensors, actuators, controllers, P L Cs, H M Is, and R T Us are not just vocabulary terms, they are the basic characters in the story of how OT systems observe and control the physical world. Sensors measure reality and feed the control loop, actuators change reality based on commands, and controllers decide what commands should be issued to maintain stability and meet goals. P L Cs are common industrial controllers designed for reliable logic execution, H M Is provide the human window and control point for operators, and R T Us extend monitoring and control across distance in distributed environments. These roles often overlap in real systems, so the most important beginner skill is identifying function and understanding how information and commands flow through the loop. When you can describe that flow, you can reason through OT scenarios, recognize what kind of device is involved, and predict what risks and constraints matter most. That clarity will support everything you learn next, because OT security is much easier when you can picture the system as a loop rather than a pile of mysterious boxes.