Exam objective 4.4, 'Design solutions for securing IoT and Operational Technology environments,' addresses the unique challenge of protecting devices that control the physical world. This matters for your SC-100 study because Microsoft sees the convergence of IT and OT as a critical security frontier, and you will be expected to design architectures that safely connect factory robots, medical devices, and building sensors to cloud services without inviting disaster.
Jump to a section
A simple way to picture Designing IoT and Operational Technology Security Architecture
A modern office building is a complex system of interconnected systems.
The building has a central security desk that monitors video feeds, controls door locks, and tracks who enters and exits through the main lobby. This is like the corporate IT network that manages user identities and protects data. But the building also has a separate, critical infrastructure: the boiler room that heats the entire building, the elevator machinery on the roof, and the industrial chiller that provides air conditioning. These systems have their own specialised controllers and sensors that keep the building operational. They were originally designed to be isolated, with no connection to the office network or the internet, because a failure in the boiler could cause a real-world disaster, not just a data breach.
Now, imagine a facilities manager wants to monitor the boiler's temperature and the elevator's performance from a smartphone app. This means connecting those previously isolated, specialised systems to the office network, and potentially to the cloud. This creates a security risk. An attacker who compromises the smartphone app might not only steal office files but could also send a command to the boiler to overheat and explode. The security architecture must therefore treat the building's physical systems differently from the office computers. It needs a strong wall between them, called a 'security gateway,' that carefully inspects every message going in or out of the boiler room. It also requires that all devices in the boiler room have unique identities, just like office workers have ID badges, to ensure only authorised commands are ever executed. This is precisely the challenge of securing IoT and OT environments: protecting the physical world while enabling modern digital control.
To understand IoT and OT security, you first need to know the difference between the three main computing environments you will encounter in a modern organisation.
First, there is Information Technology, or IT. This is the world of computers, servers, networks, and software that you probably already know. IT systems manage data: emails, documents, databases, and user identities. The main goal of IT security is to protect the confidentiality, integrity, and availability of that data. If a laptop is stolen, the data might be compromised, but no physical damage occurs beyond the loss of the device itself.
Second, there is Operational Technology, or OT. This is the hardware and software that detects or causes a change in the physical world through direct monitoring and control of physical devices, processes, and events. Think of the systems that control a power plant's turbines, a factory's assembly line robots, a water treatment facility's valves, or an oil pipeline's pressure regulators. Historically, OT systems were completely isolated from IT networks because they ran critical infrastructure. Their primary security goal was availability above all else, because stopping a blast furnace incorrectly could cause an explosion or destroy expensive equipment. Security meant physical locks on control rooms and obscurity of the proprietary protocols used to communicate with the machines.
Third, there is the Internet of Things, or IoT. IoT devices are typically simpler, cheaper, and lower-powered physical objects embedded with sensors and software that connect to the internet. Examples include smart thermostats, video doorbells, connected medical infusion pumps, and inventory tracking tags. Unlike traditional OT, IoT devices are designed with the expectation of cloud connectivity. Their security challenge is scale and diversity: a single building might have thousands of light bulbs, each with a tiny chip that can be hacked to launch a denial-of-service attack.
The core problem is that these worlds are now merging. Organisations want to collect data from their OT sensors to perform predictive maintenance, so they connect factory floor machines to the cloud. They want to use smartphone apps to control building lighting and HVAC, so they connect IoT devices to the corporate network. This convergence creates a security gap. OT devices were not designed to defend against sophisticated cyber attacks; many run on outdated operating systems that cannot be patched easily. IoT devices often have hard-coded passwords and no built-in security updating mechanism.
The Microsoft approach, which you must understand for SC-100, involves several key principles. The first is network segmentation. This means you do not put OT or IoT devices on the same network as your corporate email servers. You create a separate, isolated network zone, often called an 'OT network segment' or 'IoT network segment'. You then control all communication between this segment and the rest of the world through a single, tightly controlled gateway. This gateway can be a specialised device that understands OT protocols like Modbus or Profinet, allowing it to inspect the content of messages, not just their source and destination IP addresses.
The second principle is asset inventory and visibility. You cannot protect what you do not know exists. Many organisations discover they have thousands of unmanaged printers, sensors, and controllers attached to their network. A key architectural solution is to deploy a service that continuously discovers and identifies every device, including its firmware version, open ports, and known vulnerabilities.
The third principle is identity and access management for devices. Just as you use Microsoft Entra ID to assign identities to users, you must assign a unique digital identity to every device. This is often achieved with digital certificates, also known as PKI (Public Key Infrastructure). Each device gets a certificate that proves who it is. When a sensor tries to send data to the cloud, it must present its certificate. The cloud service checks that the certificate is valid and that the device is authorised to send that type of data. If a certificate is revoked because the device was compromised, communication is automatically blocked.
The fourth principle is secure remote access. OT and IoT environments are often geographically dispersed, like oil wells in a desert or wind turbines out at sea. Engineers need to troubleshoot these devices remotely. The secure solution is not to open a direct VPN link to the device, which would expose it to the internet. Instead, you use a 'jump box' or a bastion host, which is a hardened server in a secure zone. The engineer connects to the jump box first, and the jump box then initiates a connection to the OT device. This way, the OT device never directly faces the internet.
Finally, there is protocol filtering and deep packet inspection. Traditional network firewalls look at header information like source and destination IP addresses. But OT protocols carry commands like 'open valve', 'increase speed', or 'set temperature'. A security architecture must include a device that can understand these commands and block any that violate the expected behaviour for that system. For example, a firewall should be configured to block a command from an unknown IP address that tries to open a safety valve during normal operation. This is called an 'industrial firewall' or 'OT security gateway'.
Microsoft Azure provides specific services for this: Azure IoT Hub for managing IoT devices, Azure Defender for IoT for threat monitoring in OT environments, and Azure Arc to manage and secure on-premises servers as if they were cloud resources. Your role as an architect is to combine these services with network segmentation and identity management to create a secure architecture that allows the business benefit of data from the physical world without exposing the organisation to catastrophic risk.
1. Asset Discovery and Classification
Identify every device on the operational network, including controllers, sensors, HMIs, and engineering workstations. Classify each device as either IT, IoT, or OT based on its function. Document its communication protocols, firmware version, and whether it can be patched. This step is critical because you cannot design security measures for devices you do not know exist.
2. Network Segmentation and Zone Design
Design a network architecture that places all OT and IoT devices on a separate, isolated network segment, often called an OT-DMZ. Define the security boundaries using industrial firewalls that can inspect protocols like Modbus, Profinet, or OPC-UA. Decide which data flows are allowed to cross the boundary, such as read-only sensor data going to the cloud, and block all write commands except from authorised engineering workstations.
3. Secure Data Export to Cloud
Install a gateway appliance or data diode at the boundary between the OT network and the corporate/cloud network. This device receives data from the OT devices using their native protocol, converts it to a secure format like MQTT over TLS, and transmits it to Azure IoT Hub. Ensure the gateway has no listening ports on the OT side that could be exploited from the cloud.
4. Device Identity and Authentication Setup
Provision each IoT/OT device with a unique digital identity. Use Azure IoT Hub Device Provisioning Service (DPS) to automatically assign X.509 certificates to devices during enrollment. Configure the cloud service to reject any communication from devices with invalid or revoked certificates. This ensures that even if an attacker obtains a device's IP address, they cannot impersonate it without the correct certificate.
5. Deploy Continuous Monitoring and Anomaly Detection
Install Azure Defender for IoT sensors on the OT network to passively monitor all traffic. Configure the sensor to learn normal behaviour patterns for each device over a baseline period. Set up alerts for any deviation, such as a device suddenly communicating with a new IP address or sending a command that changes a control parameter outside of its normal range. Integrate these alerts into a security operations centre (SOC) workflow.
6. Implement Secure Remote Access Architecture
Set up a bastion host or jump box within the OT-DMZ. Configure Azure Bastion to provide secure RDP/SSH access to this jump box over HTTPS. Ensure that all remote engineers must authenticate with Azure AD and multi-factor authentication before reaching the jump box. From the jump box, they can then connect to OT devices inside the segmented network. No OT device should ever have a direct RDP or SSH port exposed to the internet.
7. Define and Test Incident Response Plan
Create a separate incident response plan for OT incidents that includes coordination with plant operations. Train the SOC team on the difference between an IT incident (where disconnecting a device is the first step) and an OT incident (where you must first bring the physical process to a safe state). Regularly test the plan with tabletop exercises that simulate a ransomware attack on the OT network.
Imagine you are the security architect for a company called GreenChem, a large chemical manufacturer. They have a massive factory that produces industrial solvents. The factory floor is controlled by a system called a Distributed Control System (DCS) from a vendor like Siemens or Rockwell. This DCS manages hundreds of sensors measuring temperature, pressure, and chemical levels, and it controls valves and pumps to keep the chemical reactions safe. Historically, this DCS was completely air-gapped, meaning it had no connection to the corporate network or the internet. It was run by OT engineers who managed it from a dedicated control room.
GreenChem's new management wants to implement 'Industry 4.0'. They have approved a project to collect sensor data from the DCS and send it to the Azure cloud to build a predictive maintenance model. The model will predict when a pump is likely to fail, reducing downtime by 20%. Your job is to design the security architecture for this project.
Here is what you would do step by step:
First, you perform a discovery and risk assessment. You walk the factory floor with an OT engineer and identify every device: the DCS controller cabinet, the individual sensors, the Human Machine Interface (HMI) computers that operators use, and the engineering workstations used to program the DCS. You find that most sensors communicate using the Modbus TCP protocol, which has no built-in encryption or authentication. You also discover that an old HMI is running Windows XP, which is unsupported and has no security updates.
Second, you design network segmentation. You create a new network zone called the 'OT-DMZ' (de-militarised zone). The DCS and all its associated controllers remain on a tightly isolated OT network. You install a specialised OT firewall at the boundary of this network. This firewall is configured to understand Modbus protocol. You write rules that allow only specific Modbus commands: for example, read-only commands from a specific data historian server to collect temperature readings, and absolutely no write commands from any source other than the official engineering workstation that is physically located in the control room.
Third, you design a secure data collection mechanism. Instead of connecting the DCS directly to the internet, you install a data diode (a one-way gateway) or a secure Gateway appliance. The device receives the Modbus data from the OT network, translates it into a secure protocol like MQTT with TLS encryption, and forwards it to Azure IoT Hub. The data diode physically ensures that no internet traffic can ever flow back into the OT network.
Fourth, you deploy Azure Defender for IoT. You install a sensor on the OT network that passively monitors all traffic. This sensor builds a baseline of normal behaviour for each device. When the system is running, it knows that Sensor 12 typically sends a pressure reading every 5 seconds. If an attacker compromises a device and starts sending data every second, or sends a command to close a valve, the sensor alerts the security operations centre in real time.
Fifth, you implement an identity and access management plan. Every device that sends data to Azure IoT Hub is provisioned with a unique device identity in the Azure IoT Hub device registry. The device authenticates using a X.509 certificate. You set up a policy that revokes the certificate of any device that shows signs of compromise. For remote troubleshooting, you deploy Azure Bastion to allow engineers to securely access the jump box in the OT-DMZ without exposing any ports to the internet.
Finally, you document an incident response plan. You create a playbook specifically for OT incidents, which is different from IT incidents. In an IT incident, the first step is often to disconnect the affected device from the network. In an OT incident, disconnecting a device could cause a pressure valve to fail or a robot arm to stop in an unsafe position, causing physical harm. The OT playbook involves coordinating with the shift supervisor to safely shut down the affected process before any technical actions are taken.
This real-world scenario shows that designing IoT and OT security is not just about applying IT security solutions. It requires understanding the physical process, the legacy protocols, the availability requirements, and the safety implications. The SC-100 exam expects you to recognise that OT security requires a different architectural mindset.
The SC-100 exam objective 4.4 is specifically about designing solutions for securing IoT and OT environments. This is a domain where Microsoft expects you to demonstrate understanding of specialised architectures, not just general security principles. The exam will present scenarios that force you to choose between a standard IT security solution and an OT-specific solution.
Here are the exact concepts the exam loves to test:
Network segmentation with OT-specific firewalls: You must know that standard firewalls are insufficient because they do not understand industrial protocols. The exam will present a scenario where a company wants to connect a factory floor to the cloud. The correct answer will involve deploying an OT firewall or a gateway that can inspect and filter protocol-specific commands like Modbus or OPC-UA. The trap answer will suggest placing a standard Azure Firewall between the OT network and the internet, which would fail to prevent a malicious 'open valve' command that uses a valid IP address.
Device identity and certificates: The exam tests your knowledge of using X.509 certificates to authenticate IoT devices to IoT Hub. You will be given a scenario where thousands of devices are enrolling. The correct answer involves using a certificate enrollment service, not manually installing certificates on each device. The trap will suggest using a shared access key across all devices, which is a security risk.
Defender for IoT's role: You must understand that Defender for IoT is the primary Azure service for securing OT environments. It passively monitors OT network traffic, builds a behavioural baseline, and detects anomalies. The exam will test whether you know it can monitor unmanaged devices. A trap might suggest using a tool designed for IT workloads, like Microsoft Defender for Cloud Apps, for OT monitoring, which is incorrect.
The difference between IoT and OT: The exam will try to confuse you with a scenario that is appropriate for IoT but not OT, or vice versa. For example, a smart building's light bulbs are IoT, and they are low risk. The correct architecture might allow them to directly connect to the cloud with a simple device key. But a power plant's turbine controller is OT, and it must be segmented behind a gateway with protocol filtering. Choosing a flat 'connect all devices to IoT Hub' architecture for the turbine scenario would be wrong.
Secure remote access: The exam tests the concept of using a bastion host or jump box for OT. The correct pattern is that no OT device is directly accessible from the internet. All remote access goes through a central, hardened server. The trap answer might suggest using a point-to-site VPN directly to the OT device, which is less secure.
Data diodes and one-way gateways: For high-security OT environments, the exam expects you to know that a 'data diode' is a hardware device that physically prevents any data from flowing from the cloud back to the OT network. This is used for highest safety requirements. The correct answer may involve deploying a data diode for a nuclear plant, whereas a simple firewall would be insufficient.
Patching and firmware updates: The exam will test that OT devices often cannot be patched during operation. The correct solution involves creating a maintenance window, staging the update on a separate server, and testing it before deployment. The trap is to suggest deploying updates automatically from the cloud via IoT Hub, which could disrupt a continuous chemical process.
The question types are typically 'Select the best solution' or 'Which of the following is the most secure architecture?' You will be presented with a diagram or a description of a proposed architecture, and you must identify the security flaw. The correct answer pattern consistently prioritises network segmentation, protocol-aware filtering, and identity-based authentication over simpler alternatives like IP whitelisting or shared keys.
IoT and OT security requires network segmentation using protocol-aware firewalls that understand industrial commands, not just IP addresses and ports.
The primary security goal for OT environments is availability and safety of physical processes, whereas IT prioritises confidentiality of data.
Azure Defender for IoT is the primary Microsoft tool for passively monitoring OT networks, building a behavioural baseline, and detecting anomalies in unmanaged devices.
All IoT devices should be authenticated using X.509 certificates provisioned through a scalable enrollment service, never using shared access keys.
Remote access to OT devices must always go through a bastion host or jump box; direct internet connectivity to OT controllers is never permitted.
A data diode or one-way gateway is the most secure method for extracting data from a high-sensitivity OT network to the cloud, as it physically prevents any return traffic.
Incident response for OT incidents must be coordinated with physical process shutdown procedures, differing significantly from IT incident response playbooks.
Microsoft Entra ID (formerly Azure AD) can be used for human identities, but device identities for IoT and OT require a separate certificate-based identity system, often integrated with Azure IoT Hub.
These come up on the exam all the time. Here's how to tell them apart.
IoT Device Security
Typically uses lightweight security like TLS for cloud communication
Requires protocol-specific filtering for commands like Modbus
Often allows direct connection to cloud IoT Hub
OT Device Security
Cannot usually run security agents due to limited processing power and real-time constraints
Requires deep packet inspection of industrial protocols by a separate gateway
Must never directly face the internet; always behind a segmented DMZ
Standard Firewall
Inspects IP addresses, ports, and protocols at layers 3-4
Cannot understand industrial commands like 'open valve'
Sufficient for IT network segmentation
Industrial Firewall
Can inspect application-layer content of OT protocols like Modbus and Profinet
Can block specific commands from specific devices even within a valid session
Required for OT network segmentation to prevent command injection
Cloud Patch Management (IT)
Automatic, frequent updates deployed via cloud services
Devices can be rebooted at any time
Security updates can be pushed immediately
OT Patch Management
Updates require scheduled plant shutdowns, often every 1-3 years
Devices cannot be rebooted without stopping production
Relies on virtual patching via IPS until downtime is available
IT Incident Response
First step is often to disconnect the affected device from the network
Focus on containing data breach and malware
Can restore from backup without physical consequences
OT Incident Response
First step is to physically shut down the process safely, coordinated with operations
Focus on preventing physical damage and safety hazards
Restoring from backup may require recalibration of physical equipment and safety checks
Mistake
IoT devices are just small computers, so you can secure them the same way you secure a laptop, by installing antivirus software.
Correct
Most IoT devices run on such limited hardware that they cannot run standard security software. Their operating system is often a stripped-down version of Linux or a real-time OS without a graphical interface. Security must be built into the device's firmware and communication protocol, not added as a post-install application.
This misconception comes from assuming that all 'computers' are general-purpose machines like PCs. Beginners do not realise that many IoT devices have only enough processing power to perform their single function and cannot run complex security agents.
Mistake
If an OT network is not connected to the internet, it is completely secure and requires no further security measures.
Correct
An air-gapped network is only safe if it stays air-gapped. In reality, engineers often connect a laptop to the OT network for maintenance, and that laptop may have been on the internet the night before. A determined attacker can use a USB drive, a rogue engineer's laptop, or a compromised vendor support tool to cross the air gap. Defence in depth is still required inside the OT network.
This mistake is rooted in the simplistic idea that 'not connected = no risk'. Beginners underestimate the human element and the complexity of maintaining a true air gap, especially in modern industrial environments where even a single diagnostic laptop can introduce malware.
Mistake
The only difference between IoT and OT security is that OT uses older, slower equipment.
Correct
The fundamental difference is the consequence of failure. A failed IoT sensor might mean a wrong temperature reading on a smart home app. A failed OT sensor in a chemical plant could cause a toxic gas release or an explosion. OT has higher safety and availability requirements, and its systems are designed for real-time deterministic control, which means you cannot simply 'reboot' a device without causing a production stoppage. The security architecture must respect these operational constraints.
Beginners focus on the technology alone (old vs new) rather than the operational context and risk profile. They do not grasp that the 'O' in OT stands for 'Operational', meaning it directly affects physical operations and safety.
Mistake
A simple firewall is sufficient to protect an OT network because it can block unauthorised IP addresses.
Correct
Standard firewalls operate at layers 3 and 4 of the network stack, inspecting IP addresses and ports. They cannot examine the content of industrial protocols. For example, a malicious command that says 'set pressure to 5000 PSI' might come from a legitimate IP address but use a valid Modbus function code to perform an illegal action. Only an OT-specific firewall or gateway that understands Modbus semantics can detect and block that command.
Most people's mental model of a firewall is 'block bad IPs, allow good IPs'. They do not understand that in OT, the 'bad' action is embedded inside a legitimate message from a legitimate source, much like a valid email containing a malicious attachment.
Mistake
All IoT and OT devices must be individually patched and updated like your personal phone or laptop.
Correct
Many OT devices cannot be patched without taking them offline, which may require a scheduled plant shutdown that happens only once every three years. Additionally, the device's manufacturer may no longer exist or may not provide updates. The security architecture must compensate by using network segmentation, anomaly detection, and virtual patching (by an intrusion prevention system that blocks malicious traffic to the unpatched device) rather than relying on the device's own patching mechanism.
This misconception comes from the home user experience of clicking 'Update Now' on a phone. Beginners do not appreciate that industrial processes run 24/7 and that a software update on a critical controller could introduce a bug that stops a billion-dollar production line.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IoT devices are simpler, often consumer-grade devices like sensors and smart appliances that are designed to connect to the internet. OT devices are industrial controllers that manage critical physical processes. The difference matters because OT has much higher safety and availability requirements, and OT devices often use proprietary, unencrypted protocols that are more vulnerable to manipulation.
Azure Firewall can provide basic network security between segments, but it does not understand industrial protocols like Modbus or Profinet. For OT environments, you need a specialised industrial firewall or gateway that can inspect the content of the commands being sent, not just the source IP address.
A data diode is a hardware device that physically allows data to flow in only one direction. You use it when you need to export data from a highly secure OT network to a less secure cloud network, while absolutely ensuring that no data or commands can ever flow back into the OT network. It is common in critical infrastructure like power plants.
You cannot patch most OT devices while they are running a continuous process. The solution is to use virtual patching: deploy an intrusion prevention system (IPS) in front of the unpatched device to block traffic that exploits known vulnerabilities. You also schedule a maintenance window during the next planned plant shutdown to apply the real patch.
Azure Defender for IoT is a Microsoft security solution that passively monitors all traffic on an OT network. It learns the normal behaviour of every device and uses machine learning to detect anomalies such as a device sending unexpected commands or communicating with a new, unknown IP address. It can monitor unmanaged devices that do not have an agent installed.
You need a separate identity system for devices. While Microsoft Entra ID manages human identities, IoT and OT devices use digital certificates, often through a Public Key Infrastructure (PKI) or Azure IoT Hub's Device Provisioning Service. These certificates provide machine identities that are independent of user accounts.
You've finished Designing IoT and Operational Technology Security Architecture. Continue through the SC-100 study guide to build a complete picture of the exam.
Done with this chapter?