IoT Security vs OT Security: Where the Risks and Controls Diverge

IoT and OT devices often look alike on a network scan, but securing a connected camera like a PLC, or a PLC like a camera, produces the wrong controls in both places. IoT security deals with large fleets of cheap, cloud-connected devices whose main risk is mass compromise; OT security deals with control systems where a bad command can injure people or stop a plant. This guide sets out where the two disciplines diverge: threat models, architecture, patching, identity, monitoring and vendor access, and where industrial IoT (IIoT) sits between them. It is for security architects, OT engineers and IoT platform owners who have to decide which rulebook applies to a given device. For the IT and OT contrast see IT Security vs OT Security; this page does not repeat it.

Key takeaways

• The short answer: IoT security is mainly about device identity, secure defaults and update at fleet scale; OT security is mainly about safety, process integrity and controlling every path into the control network.
• Consequence decides the rulebook, not the device type. A sensor that only reports data can follow IoT practice; a device that can write a set point or actuate equipment belongs under OT governance, whatever it is called.
• The threat models differ. IoT attackers mostly want volume, recruiting devices into botnets as Mirai did with about 600,000 infections at its peak; OT attackers want effect, such as the IRGC-affiliated actors that replaced ladder logic on internet-exposed PLCs in 2023.
• IT patch cadence breaks OT and suits IoT. IoT fleets should update automatically and often; OT changes go through engineering review, testing and outage windows, with compensating controls in between.
• The riskiest case is IoT on the OT network. Unmanaged cameras, building sensors and vendor gateways connected inside control zones bypass the zoning that protects controllers.

What each discipline protects

OT is defined in NIST SP 800-82 Rev. 3 (Guide to Operational Technology Security, September 2023) as a broad range of programmable systems and devices that interact with the physical environment, detecting or causing change by monitoring or controlling devices, processes and events. Its examples include industrial control systems, building automation, transportation, physical access control and environmental monitoring. NIST lists a Rev. 4 initial public draft with comments due by 30 November 2026, so expect revisions.

IoT covers network-connected devices that combine sensing or actuation with a network interface, usually managed through a vendor or cloud platform: IP cameras, smart building sensors, badge readers, wearables, consumer devices and connected products sold to customers. The governing baselines are device-centric, such as NIST IR 8259A (the IoT device cybersecurity capability core baseline) and ETSI EN 303 645 for consumer devices. Note that NIST withdrew IR 8259 on 20 April 2026 and replaced it with IR 8259 Rev. 1.

IIoT is the overlap: connected sensors, gateways and edge devices inside plants and utilities that send data to cloud analytics. It takes IoT's device and cloud identity problems and OT's safety consequences together. The Industrial IoT (IIoT) Security Guide covers its reference architecture.

Threat models compared

IoT: recruitment at scale

The economics of IoT attacks reward volume. Identical devices with the same weakness can be compromised by automation, and the payoff is a large pool of bandwidth and IP addresses for denial of service, proxy networks and credential stuffing. The Mirai botnet, analysed in the USENIX Security 2017 paper "Understanding the Mirai Botnet", grew to about 600,000 infections of low-end embedded and IoT devices and was used in large DDoS attacks in late 2016. Its successors still spread through default credentials and exposed management services. See the Mirai and IoT Botnet Families Guide and the Botnets Guide.

The second IoT threat is the vendor cloud itself. Fleet management platforms hold the keys to every customer device, so one stolen administrator credential can expose many customers at once. In the Verkada camera breach, admin credentials left on an internet-reachable support server gave attackers access to cameras at 97 customers.

OT: manipulation of the process

OT attackers are fewer and more deliberate. Their goal is to alter, stop or hide the physical process: modify controller logic, change parameters, suppress alarms or deny operators a view of the plant. MITRE ATT&CK for ICS describes these as techniques such as T0821 Modify Controller Tasking, T0836 Modify Parameter, T0889 Modify Program and T0831 Manipulation of Control. See the MITRE ATT&CK for ICS Guide.

The joint advisory AA23-335A from the FBI, CISA, NSA, EPA, the Israel National Cyber Directorate, the Canadian Centre for Cyber Security and the UK NCSC attributes a 2023 campaign to IRGC-affiliated actors operating as "CyberAv3ngers". They compromised at least 75 Unitronics Vision Series PLCs and HMIs in the United States, at least 34 of them in the water sector, by logging in to internet-connected devices that used the default password or none, on the default TCP port 20256. They then replaced ladder logic and defaced HMI screens. The entry point was an IoT-style weakness; the impact was an OT one.

Architecture in words

A typical IoT architecture has devices connecting outbound over TLS to a vendor or enterprise cloud broker, often through a home or office network the device owner does not control. Security rests on the device: its identity, its firmware integrity and its secure defaults, plus the cloud platform's access controls. The network is assumed hostile. In the enterprise, the right pattern is a dedicated IoT segment with egress allowed only to the vendor endpoints, and network access control that profiles devices on connection. See the Enterprise IoT Security Programme Guide.

A typical OT architecture layers the plant into levels: field devices and controllers at the bottom, supervisory systems and HMIs above, site operations and historians above that, and a DMZ separating the plant from the enterprise. ISA/IEC 62443-3-2 and 3-3 formalise this as zones (groups of assets with common security requirements) and conduits (the controlled communication paths between them), each assigned a target security level. Many field protocols, such as Modbus/TCP on port 502, have no built-in authentication, so security rests on the network around the device. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

The design difference follows: IoT pushes security into the device because it cannot trust the network; OT pushes security into the network because it cannot change the device.

Controls per domain

The CISA, FBI, EPA and DOE "Primary Mitigations to Reduce Cyber Threats to Operational Technology" condense the OT baseline into five actions: remove OT connections to the public internet, change default passwords, secure remote access, segment IT and OT networks, and practise manual operation. The first four apply equally to IoT; the fifth is what makes OT different.

Where identity fits

Identity is the clearest place the disciplines diverge. In IoT the device identity is the primary control, and getting it right at manufacture determines whether one compromised unit spreads to the fleet; see IoT Device Certificates vs Pre-Shared Keys and the Identity for IoT Fleets Guide. In OT the critical identities are people and machine accounts on the systems around controllers: engineering workstation logins, shared operator accounts, historian service accounts, vendor remote access accounts and the credentials stored in project files. These are non-human identities that rarely rotate and often have no clear owner. See the OT and ICS Identity and Access Guide and NHIs in OT.

Decision guidance: which rulebook applies

Small organisations, such as a single water utility or a building owner, rarely have separate IoT and OT teams. A practical split is to apply OT rules to anything that controls the process or safety, and IoT rules to everything else, with one inventory covering both. Large organisations should give plant engineering authority over changes in control zones and give the IoT or IT team the device identity and update platform, with a joint policy for IIoT gateways that cross the boundary.

Worked scenarios

Scenario 1, smart building in a hospital: 3,000 lighting sensors and cameras plus a building management system controlling air handling for operating theatres. The sensors and cameras follow IoT practice: own segment, egress only to the vendor cloud, automatic updates. The building management controllers for theatre air handling affect patient safety and follow OT practice: zone, conduit to the supervisory server only, change control with clinical engineering. See the Hospital Clinical Network Segmentation Guide.

Scenario 2, predictive maintenance on a packaging line: wireless vibration sensors report to an edge gateway that sends data to a cloud analytics service. Because the sensors are read-only, they can be managed as IoT devices with per-device certificates. The gateway is the risk: it sits in the plant and talks to the internet. Place it in a DMZ zone, allow outbound connections only, forbid any write path from the cloud to controllers, and treat its cloud credentials as a non-human identity with an owner and rotation.

Common failure patterns

• Applying IT patch cadence to PLCs: pushing firmware or OS updates to controllers or HMIs on a monthly IT cycle without engineering testing, causing unplanned stops. See the OT Patch Management Guide.
• Treating IoT as too small to patch: the opposite mistake, leaving cameras and sensors on factory firmware for years because "they are not computers", which is how botnets find them.
• Unmanaged IoT on OT networks: cameras, wireless access points and vendor cellular gateways installed inside control zones by facilities or contractors, creating internet paths that bypass the DMZ.
• Internet-exposed controllers with default credentials: the exact pattern in advisory AA23-335A, where PLCs were reachable on their default port with default or no passwords.
• Standing vendor access: always-on vendor VPNs into OT, or vendor cloud admin accounts with access to every customer device, as in the Verkada case.
• Active scanning of OT with IoT tooling: running discovery tools built for IT or IoT networks against fragile controllers instead of passive monitoring. See the OT Asset Visibility Guide.

Implementing a combined approach

1. Build one inventory: discover IoT and OT assets passively in plant networks and through NAC and cloud platforms elsewhere; tag each device with its consequence class (safety, process, data only).
2. Assign the rulebook: apply the decision table to each device class and record the owner.
3. Remove internet exposure: close any direct internet path to controllers and management interfaces first; it is the fastest risk reduction available.
4. Segment: put IoT on its own segments with egress allowlists; move any IoT found in control zones out, or into a dedicated zone with a defined conduit.
5. Fix credentials: replace default passwords, issue unique device credentials for IoT and bring OT shared and vendor accounts under privileged access controls.
6. Pilot monitoring: deploy passive OT monitoring on one site in learning mode, tune alerts with operations, then expand. Roll back by removing span sessions, which leaves the process untouched.
7. Govern vendors: broker all OT remote access and review vendor cloud admin practices in contracts.

Detection and measurement

• IoT signals: new outbound destinations per device class, connections on Telnet or other management ports, sudden traffic volume increases, and failed authentication bursts against device fleets.
• OT signals: program downloads or uploads to controllers (T0843 Program Download), controller mode changes, new hosts speaking industrial protocols, and remote sessions outside approved windows.

Metrics:

• Percentage of IoT and OT assets in the inventory with an owner and consequence class.
• Number of internet-exposed controllers or management interfaces (target zero).
• Percentage of IoT devices on supported firmware, and median age of OT firmware versus vendor current with documented compensating controls.
• Number of IoT devices found inside control zones without an approved conduit.
• Percentage of OT vendor sessions brokered, approved and recorded.

Framework mapping

The EU Cyber Resilience Act entered into force on 10 December 2024; according to the European Commission its reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027. It covers hardware and software products with digital elements, so it reaches IoT products and many OT components alike. See the EU Cyber Resilience Act Guide.

Practitioner checklist

• Classify every connected device by consequence before choosing controls.
• Remove all direct internet exposure of controllers and device management interfaces.
• Give IoT devices unique identities and automatic signed updates.
• Put OT changes under engineering change control with tested rollback.
• Find and move IoT devices installed inside control zones.
• Monitor OT passively; reserve active scanning for maintenance windows and tested assets.
• Broker, approve and record every vendor session into OT; review vendor cloud admin practices for IoT.
• Keep logic backups, golden images and a practised manual operation plan for OT.

Standards and references

• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• NIST: IR 8259A IoT Device Cybersecurity Capability Core Baseline
• ISA: ISA/IEC 62443 Series of Standards
• CISA: AA23-335A IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• ETSI: EN 303 645 Cyber Security for Consumer Internet of Things: Baseline Requirements
• European Commission: Cyber Resilience Act
• USENIX: Understanding the Mirai Botnet

Related NHI Mgmt Group resources: IoT Security Guide, OT Security Guide, Device and IoT Identity Guide, OT Remote Access Guide, IEC 62443 Guide.