Industrial IoT security is the work of protecting the sensors, controllers, gateways and cloud platforms that connect physical equipment to networks, so that readings can be trusted and nobody can change a physical process without permission. It covers the plant floor and the control system as much as the cloud services that plant data now travels to.

Connecting equipment to the cloud is worth doing, and it also changes who can reach that equipment. An OT or IT lead planning that connection needs a clear picture of what attackers do in industrial environments, which weaknesses they use, and which controls make a difference. This article walks through each, from SCADA networks out to the cloud platform.

In short

  • The most common industrial incidents start in IT, through phishing, stolen remote-access credentials or ransomware, and reach operations because networks aren't separated.
  • SCADA systems are vulnerable because of old protocols without authentication, flat networks, shared accounts and software that can't be patched quickly.
  • Securing a SCADA system starts with an asset inventory and network segmentation, then controls remote access, accounts and backups.
  • IEC 62443 and NIST SP 800-82 are the main frameworks; on the cloud side, per-person access, scoped keys and an access record matter most.

What are the biggest industrial IoT security threats?

Industrial incidents get attention when they're dramatic, but the threats that cause most damage are ordinary. Each industrial IoT security threat below has a real precedent.

Ransomware that starts in IT is the most frequent problem. In May 2021, ransomware hit Colonial Pipeline's business systems in the United States. The pipeline's control systems were not reported as encrypted, yet the company shut down pipeline operations for several days as a precaution, because it couldn't be sure the attack wouldn't spread and couldn't run billing normally. Fuel shortages followed along the US East Coast, all from an incident in office IT.

Stolen or weak remote access follows close behind. Vendors and integrators often need to reach equipment, and a remote-desktop tool or a VPN account with a shared password becomes the easiest way in for an attacker too.

Default credentials on connected devices are another common way in. In 2016, the Mirai botnet took over hundreds of thousands of cameras, routers and other IoT devices simply by trying factory-default usernames and passwords, then used them for massive denial-of-service attacks. Industrial gateways and sensors shipped with default logins carry the same risk.

Targeted attacks on control systems are rarer and more serious. Stuxnet, discovered in 2010, manipulated Siemens PLCs to damage uranium enrichment centrifuges in Iran while showing operators normal values. Triton, found in 2017 at a petrochemical plant in Saudi Arabia, targeted a Schneider Electric Triconex safety instrumented system, the layer meant to shut a process down safely.

Finally, there's the insider and the accident: a contractor with more access than needed, or an engineer who plugs a laptop into the control network to "just check something".

Connected devices add one more category: physical access. A gateway mounted in an unlocked outdoor cabinet, or a sensor whose configuration port is reachable with a screwdriver, can be reset, swapped or used as a way into the network. Remote sites such as pumping stations and substations are visited rarely, so tampering there can go unnoticed for weeks unless door contacts or cabinet switches report it.

Common SCADA system security vulnerabilities

SCADA system security is hard for structural reasons, not because operators are careless. The common weaknesses keep recurring across industries.

Protocols without authentication are the oldest weakness. Classic Modbus and the original DNP3 were designed for closed serial networks; any device that can reach a controller can send it a valid command. Secure variants exist, but older equipment often can't use them.

Flat networks make that worse. In many plants, the office network, the SCADA servers and the PLCs sit in one network with no firewall in between, so one infected laptop can reach everything.

Shared accounts on HMIs and engineering workstations mean that every operator logs in as "operator", which makes it impossible to tell who did what.

Patching is slow. SCADA servers often run older operating systems because the SCADA software or a driver is certified only for that version, and a plant can't reboot a running process every month.

Internet exposure is a recurring finding. Search engines that scan the internet, such as Shodan, regularly find HMIs, PLCs and remote-access gateways reachable directly from anywhere.

Removable media and engineering laptops are a quieter route. Engineering workstations hold the software that can reprogram every controller in the plant, and they're often the machines that contractors connect to with their own laptops and USB sticks. Stuxnet is believed to have reached its isolated target network on removable media, which is why many plants now scan USB devices at a kiosk before they're allowed near a control system.

The December 2015 attack on Ukrainian electricity distributors used several of these at once. Attackers entered through phishing emails on office networks, harvested credentials, moved into the control environment and opened breakers remotely, cutting power to roughly 225,000 customers for several hours.

How do you secure a SCADA system?

No single product secures a SCADA system. The steps below follow the order most frameworks recommend, because each one makes the next easier.

  1. Build an asset inventory. List every controller, server, workstation, gateway and network connection, with firmware versions.
  2. Segment the network. Separate the business network from the control network, with a DMZ (a buffer zone) in between for anything both sides need, such as a historian copy. Allow only the traffic that's needed, in the direction it's needed.
  3. Remove direct internet exposure. Nothing in the control network should be reachable from the internet. Data going out to cloud services should leave through outbound connections from a gateway in the DMZ.
  4. Control remote access. Use a single managed entry point with multi-factor authentication, individual accounts for vendors, and access that is switched on only when needed.
  5. Give everyone their own account. Replace shared logins with personal accounts and the least privilege each job needs.
  6. Patch where you can, compensate where you can't. Test updates on a spare system; where a machine can't be patched, restrict what can talk to it.
  7. Monitor the network. Industrial intrusion-detection tools learn normal traffic between controllers and flag new devices or unusual commands.
  8. Back up and rehearse recovery. Keep offline copies of PLC programs, SCADA configurations and server images, and test restoring them.

SCADA system cyber security also depends on people. Operators and engineers should know how to report a suspicious email or a USB stick found in the parking lot, and the incident plan should say who decides whether to keep the process running.

With a limited budget, the order matters more than the completeness. A plant that has an inventory, a firewall between office and control networks, no direct internet exposure and personal accounts with multi-factor remote access has removed the paths used in most of the incidents described above. Network monitoring and formal security levels are worth adding after that, not instead of it.

Industrial IoT security standards

Two frameworks dominate industrial IoT security standards. IEC 62443 is a series of international standards for securing industrial automation and control systems. It introduces zones (groups of assets with the same security needs) and conduits (the controlled connections between them), defines security levels from 1 to 4 against increasingly capable attackers, and has separate parts for asset owners, system integrators and product suppliers.

NIST SP 800-82, published by the US National Institute of Standards and Technology, is a guide to operational technology security. Revision 3, released in September 2023, broadened its scope from industrial control systems to OT in general and maps its recommendations to the NIST Cybersecurity Framework.

Regulation is moving too. In the European Union, the NIS2 Directive covers energy, water, manufacturing and other sectors, with member states required to apply it from October 2024. The EU Cyber Resilience Act adds security requirements for products with digital elements, with most obligations applying from December 2027, which will affect connected sensors and gateways sold in the EU.

It also helps to know how these relate to ISO/IEC 27001, the widely used standard for information security management systems. ISO/IEC 27001 describes how an organization manages security risk in general, while IEC 62443 adds the technical and organizational requirements specific to control systems. Many industrial companies use both: 27001 for the company and its IT, 62443 for the plants.

Industrial IoT security best practices

The cloud side of an industrial IoT connection needs the same discipline as the plant side. A few industrial IoT security best practices hold on any platform. Data should leave the plant over outbound, encrypted connections that the gateway starts, so no inbound port is open. Wireless sensor networks bring their own protection: LoRaWAN, for example, encrypts each message with AES-128 session keys, which only helps if the keys used to provision the sensors are handled carefully. Every gateway and every connection needs its own credentials rather than one shared across sites. Those provisioning keys should be stored encrypted and visible only to the people who need them. Gateway firmware deserves the same patching attention as a PLC's, because the gateway sits right on the boundary between the plant and the internet.

On the platform side, Kilo's access controls work per person and per page, as Edit, View or No access, so a contractor can watch dashboards without being able to touch rules or connectors. API keys are scoped per area with separate read and write permissions, can carry an expiry date, and stop working immediately when rotated. The Audit Trail records invitations, permission changes and removals, so you can show who had access and when.

Industrial IoT security FAQ

How is industrial IoT security different from IT security?

In IT, confidentiality usually comes first; in industrial systems, availability and safety do, because stopping a process can be dangerous or expensive. Industrial equipment also often stays in service for 10 to 15 years, and sometimes more than 20, far longer than office IT, so security has to work around devices that can't be replaced quickly.

Who is responsible for SCADA system cyber security?

The asset owner, the organization that operates the plant, is accountable for it. IEC 62443 spreads the work: product suppliers build secure devices, integrators configure them securely, and the asset owner runs and maintains the system securely over its life.

What is zero trust in industrial IoT security?

Zero trust is an approach, described in NIST SP 800-207, in which no user or device is trusted because of its network location. Every request is authenticated and authorized. In plants it's usually applied gradually, starting with remote access and the boundary between IT and OT.

Before connecting anything from a production line, try the access model on a harmless signal. Put one temperature sensor in a plant room on Kilo's free plan, which needs no payment details, invite a colleague with View access only, and create one API key with read scope and an expiry date. Then rotate that key and check that a script using the old value stops working.