10 min read

Industrial IoT Cybersecurity: The Reality of OT Discovery

What the Sales Brochure Leaves Out

• The Legacy Trap: Standard active vulnerability scanners frequently crash 1990s-era PLCs by overwhelming their primitive TCP/IP stacks.
• The Passive Blindspot: Mirroring network traffic via SPAN ports is safe, but configuring it across hundreds of unmanaged switches is an operational nightmare.
• The Edge Compromise: Deploying temporary, non-disruptive query executables to gather asset data without installing permanent software agents.
• The First Step: Run an on-demand, protocol-safe query on a single, well-understood subnet to validate your inventory before buying continuous monitoring.

Why Legacy PLCs Die Under Standard Active Vulnerability Scans

Deploying industrial IoT cybersecurity solutions often begins with a rude awakening: running a standard active ping scan can instantly crash a legacy programmable logic controller (PLC). In a typical factory environment, a standard IT vulnerability scanner treats an industrial network like an office subnet, firing rapid TCP SYN packets and UDP sweeps to map open ports. To a modern server, this is background noise; to an older controller managing a critical chemical feed, it is a denial-of-service attack that freezes the processor and halts production.

The core of the problem is that legacy operational technology (OT) was never built with modern network stacks. Many controllers still running in plants today use low-power microcontrollers with minimal memory and poorly implemented IP stacks that cannot handle out-of-order packets or high-frequency connection requests. When an IT scanner floods these devices, the buffer overflows, the device crashes, and the physical line stops. This is why plant managers historically barred IT security teams from touching the factory floor.

Yet, you cannot secure what you do not know exists. The half-finished migration we see today is a struggle between the absolute need for a complete asset inventory and the physical fragility of the hardware we are trying to discover. Security teams are caught between passive network monitoring—which is safe but incredibly expensive to deploy—and active scanning, which is cheap but operationally hazardous.

The Mechanics of Edge-Based Discovery vs. Network Taps

To resolve this tension, the market has split into two main architectural approaches, with a third hybrid model emerging. The traditional approach is passive deep packet inspection (DPI). This requires installing physical network taps or configuring switch port analyzer (SPAN) ports to mirror all network traffic to a centralized security appliance. While safe because it never injects packets into the network, the total cost of ownership (TCO) is staggering when you calculate the cabling, the managed switch upgrades, and the engineering hours required to route traffic from remote skids back to the collector.

Think of passive monitoring like trying to map a building's layout solely by listening to the echoes in the hallways; you will miss the closed rooms where nobody speaks, and you will spend a fortune setting up microphones in every single corridor.

The alternative is on-demand, protocol-safe active querying, pioneered by platforms like Claroty Edge [1]. Instead of flooding the network with generic IT probes, these tools send highly targeted, single-packet queries using the exact industrial protocols the controllers expect—such as Modbus TCP, EtherNet/IP, or Profinet. These queries mimic the native engineering workstations that configure the PLCs daily, extracting firmware versions, serial numbers, and card slot configurations without stressing the device's processor.

How On-Demand Querying Bypasses the Mirroring Bottleneck

The real advantage of an on-demand edge query tool is that it runs as a temporary executable on an existing Windows jump box or engineering workstation already connected to the OT network. It does not require installing permanent software agents on sensitive endpoints, nor does it require configuring complex SPAN ports across hundreds of legacy switches. Within minutes, the tool queries its local subnet, gathers the asset details, compiles them into a clean file, and shuts down. It trades continuous, real-time monitoring for rapid, low-friction visibility—a trade-off that makes immense sense for secondary sites or remote substations where the cost of physical taps cannot be justified.

"A perfect real-time map of your OT network is useless if the process of drawing it costs more than the risk of leaving it unmonitored."

A Step-by-Step Blueprint for Non-Disruptive OT Discovery

If you are tasked with building a comprehensive asset inventory across twenty manufacturing facilities, you cannot simply buy a tool and click run. You need a structured, risk-mitigated deployment plan that respects the physical limits of the plant floor.

1. Identify and isolate high-risk subnets: Map your network topology to locate legacy, critical controllers (such as older Siemens S7-300s or Rockwell ControlLogix units) and group them by operational risk.
2. Deploy safe local collectors: Run a temporary, protocol-safe query tool like Claroty Edge [1] from an engineering workstation on a single, non-critical subnet during a scheduled maintenance window.
3. Analyze response latencies: Monitor the round-trip times of your industrial communications during the discovery pass; if p95 latency spikes above 50 milliseconds, reduce the query frequency or limit the scope of the scan.
4. Establish a baseline and feed downstream systems: Export the discovered asset profiles—including firmware versions and open ports—into your configuration management database (CMDB) to serve as the foundation for your vulnerability management program.

How the Three Main Discovery Architectures Compare

Choosing the right architecture requires balancing deployment speed, hardware costs, and the level of security monitoring your operations actually require. The table below outlines how these approaches diverge in practice.

Discovery Method	Hardware Requirement	Deployment Timeline	Risk to Legacy PLCs	Primary Blindspot
Passive DPI (SPAN/TAP)	High (Taps, aggregators, cabling)	Months to years	Zero	Quiet devices that rarely communicate
On-Demand Querying	None (Runs on existing jump boxes)	Hours to days	Extremely low	Rogue devices plugged in between scans
Active IT Scanning	None (Centralized scanner)	Days	High (Device crashes)	Proprietary industrial protocols

The chart below illustrates the typical time-to-value across a multi-site enterprise deployment, demonstrating why many operators are shifting toward hybrid models rather than relying solely on traditional passive setups.

Federated Learning and the Edge Anomaly Detection Hype

Once you have discovered your assets, the next challenge is detecting anomalies without shipping gigabytes of raw industrial network traffic to a cloud-based security operations center (SOC). The bandwidth costs alone can make cloud-based analysis prohibitive for remote pipeline stations or offshore wind farms. This constraint has driven significant academic and industrial interest in decentralized detection models.

One emerging approach is the use of adaptive, privacy-preserving federated learning frameworks, such as SecuFL-IoT [2]. Instead of aggregating raw network packets or PCAP files at a central server, federated learning deploys local machine learning models directly onto edge gateways. These local models learn the normal communication patterns of the specific machines connected to them—such as the typical Modbus register read intervals of a water pump—and only transmit the model weights or updates back to a central coordinator.

This architecture solves two major headaches: it slashes outbound WAN bandwidth usage to a fraction of traditional methods, and it keeps sensitive operational data strictly inside the plant boundary, satisfying strict data sovereignty requirements. However, the operational catch is significant. Managing the training, drift, and version control of machine learning models across thousands of distributed edge gateways requires a level of DevOps maturity that most industrial organizations simply do not possess. If a local model starts throwing false positives because a machine's operating cycle changed, plant operators will simply disable the security tool to keep the line running.

The Three Dumbest Mistakes in Industrial Network Segmentation

While asset discovery and anomaly detection are critical, they only inform your defense; they do not stop an attacker. For that, you need network segmentation [3]. Unfortunately, most segmentation projects stall because teams treat the plant floor like an office building.

• Relying on MAC-filtering on unmanaged switches: Security teams often try to implement basic access control by white-listing MAC addresses on local switches. In an industrial environment, MAC addresses are easily spoofed, and unmanaged switches will simply fail open or drop traffic unpredictably under load, creating hard-to-diagnose connectivity drops.
• Blindly blocking outbound port 443: IT teams frequently block all direct outbound HTTPS traffic from the OT network to the internet. While noble in theory, this instantly breaks the remote diagnostics and predictive maintenance tunnels that machine OEM vendors rely on to service critical equipment, leading to unauthorized "shadow" cellular modems being plugged into the network by frustrated plant engineers.
• Treating the DMZ as a permanent storage dump: The Purdue Model dictates a Demilitarized Zone (DMZ) between the IT and OT networks. Too often, this DMZ becomes a dumping ground for legacy databases, historians, and unpatched jump boxes, turning a security barrier into a staging ground for lateral movement.

Where Active Querying Actually Fails

To write an honest buyer's guide, we must look at where on-demand active querying falls short. If your security strategy requires real-time, continuous threat detection—such as spotting an active brute-force attack on an engineering workstation or detecting a malicious firmware modification as it happens—on-demand tools will not save you. They are point-in-time snapshots. If an adversary plugs a rogue laptop into a switch five minutes after your scheduled weekly scan finishes, that device will remain completely invisible until the next run.

Furthermore, active queries cannot analyze the payload of the traffic passing between your devices. They can tell you that a PLC exists, what firmware it runs, and what ports are open, but they cannot tell you that an operator is currently sending an unauthorized "stop" command to a critical centrifuge. For high-value zones—such as the main control room of a power plant or a high-speed packaging line—you still need continuous passive monitoring, despite the high deployment cost. The smart play is not to choose one over the other, but to use rapid, on-demand querying to baseline your entire footprint, and then surgically deploy passive DPI only where the operational risk justifies the hardware spend.

Frequently Asked Questions

What happens to our compliance audit trail when a local OT switch loses its configuration during a power cycle?

If an unmanaged or poorly configured managed switch loses its configuration, any SPAN port mirroring you set up for passive monitoring will immediately stop working. Your central IDS will lose visibility, creating a silent gap in your compliance audit trail. Using on-demand edge queries as a secondary verification tool allows you to run scheduled scripts that verify switch configurations and confirm that your asset inventory matches your active network state.

Can we run federated learning frameworks like SecuFL-IoT on legacy Siemens S7-1200 PLCs?

No. Industrial controllers like the Siemens S7-1200 do not have the spare CPU cycles, memory, or operating system support required to run machine learning frameworks like SecuFL-IoT [2]. These federated learning models must run on dedicated edge compute gateways, industrial PCs, or modern protocol converters that sit alongside the PLCs and tap into the local network traffic switch ports.

Why can't we just use Nessus or Qualys to scan our industrial networks?

Traditional IT scanners are designed to find vulnerabilities by sending complex, high-frequency probes that test how a system handles unexpected inputs. When these probes hit the fragile, low-power TCP/IP stacks of legacy PLCs, they easily cause buffer overflows, processor lockups, or device reboots. Industrial-specific discovery tools use native, vendor-approved communication protocols to query devices safely without triggering safety faults.

How does Claroty Edge handle devices hidden behind local NAT routers on skid-mounted machinery?

Devices hidden behind local Network Address Translation (NAT) routers on skid-mounted machinery are invisible to centralized network scanners. To discover them, Claroty Edge [1] must be executed from a jump box or engineering laptop that has a physical or routed connection directly inside the NAT boundary, or the local NAT rules must be temporarily configured to allow the query tool's specific IP address to route through to the internal skid network.

The path forward is not a grand rip-and-replace of your legacy automation hardware, nor is it a blind trust in marketing promises of automated, cloud-delivered AI security. It is a slow, methodical process of deploying safe, protocol-aware edge tools to map your network, securing your DMZ boundaries, and reserving expensive continuous monitoring for the small percentage of assets that actually keep the lights on. Start by running a single, non-disruptive query pass on your most critical subnet this week, and let the real data dictate your next investment.

Engineering References & Signals

This guide is synthesized directly from active engineering signals and the reporting within the Source Data above.

• [1] Claroty Edge platform: On-demand, edge-based asset discovery and industrial cybersecurity capabilities designed to minimize network disruption across OT, IoT, and IIoT assets.
• [2] SecuFL-IoT framework: An adaptive, privacy-preserving federated learning framework published in Nature, focusing on decentralized anomaly detection in smart industrial networks.
• [3] BizTech Network Security: Practical operational guidance on securing industrial IoT networks through segmentation, patching, and targeted monitoring.

Related from this blog

• Predictive maintenance AI algorithms: The 2026 Integration Bottleneck
• Private 5G networks for factories: A $340k Autopsy
• Digital Twin Factory Simulation: The Production Reality
• SCADA System Modernization: The Buyer's Reality Guide
• Computer Vision in Quality Control: 8-Quarter Reality Check

Sources

• Claroty Edge platform boosts industrial cybersecurity across OT, IoT, IIoT assets - Industrial Cyber — Industrial Cyber
• SecuFL-IoT: an adaptive privacy-preserving federated learning framework for anomaly detection in smart industrial networks - Nature — Nature
• 5 Ways To Secure Your Industrial IoT Network - BizTech Magazine — BizTech Magazine