You Can't Manage What You Can't See: Network Management Strategies for Today’s Connected Industry
Key Highlights
- Modern network management platforms must go beyond basic monitoring to provide full topology visibility, bulk configuration capabilities and intelligent detection of hidden network elements like unmanaged switches.
- Network access control (NAC) software is transforming OT security by dynamically assigning devices to the correct network segment based on device class rather than static port assignments, eliminating a major source of misconfiguration errors.
- Intent-based networking and the convergence of network management with data platforms are emerging as key strategies for future-proofing industrial infrastructure as manufacturers adopt AI, digital twins and advanced analytics.
Ensuring the scalability and management of control networks has become a manufacturing imperative with the merging of IT and OT networks. This confluence of networks that were once separated means that industrial networks, in addition to managing thousands of connected plant floor devices as they always have, must also connect and coordinate these devices in ways that enhance operations through data sharing while ensuring visibility, often across multiple sites.
This reality is leading manufacturing organizations to use network management tools more commonly used on the IT side of the business. To get insights on what these tools offer to OT, Automation World spoke to Mike Fisher (MF), senior manager of solution architecture at Belden, a supplier of networking and data technologies.
AW: How should a network-management platform handle the integration and monitoring of diverse IoT devices and legacy industrial equipment as manufacturers scale from hundreds to thousands of connected endpoints?
MF: You can’t manage what you can’t see. So, a network-management platform needs to do more than just ping an address range and tell you that something has responded. It also needs to build the topology so you can understand how devices are connected to each other. This kind of visibility transforms troubleshooting. Instead of staring at a list of addresses that went red, you can see that a cluster went dark and quickly trace it back to the upstream switch or link that caused the cascade.
The best platforms can also detect hidden elements in your network. An unmanaged switch, for example, doesn’t transmit its own traffic and has no interface to ping, so you don’t know it’s there. But software like Hirschmann’s HiVision can recognize when an unmanaged switch is likely present between a managed one and a cluster of other devices. That kind of intelligence makes diagnostics much easier.
Also, the ability to perform bulk operations at scale is essential. If, for example, you have several thousand switches and need to push out a firmware update, going one by one would take forever. You want the ability to select your target devices, push the update and schedule when it takes effect. The same goes for configuration changes. Features like MultiConfig on HiVision let you update a security protocol or setting across your entire fleet in one operation, rather than requiring you to touch each switch individually.
Intent-based networking represents the next level of evolution in network management. The concept is to look at endpoint configurations and automatically configure the network based on what those devices need to accomplish.
AW: What capabilities should manufacturers look for on a platform to manage network performance and security across multiple manufacturing sites?
MF: Multivendor support is non-negotiable. It’s incredibly rare for large-scale networks to be truly single-vendor environments. A good network-management platform will let you add third-party devices so you can manage everybody with one tool, rather than juggling multiple interfaces.
The platform also needs to interact with multiple switches simultaneously. If all you can do is configure one switch at a time, you’re centralizing access but not actually saving time. Look for capabilities to apply firmware updates, protocol adjustments and security settings as bulk changes.
Also, realize that network access control (NAC) software changes the game for security. The old approach was static: Port 16 goes on this VLAN while Port 17 goes on that VLAN. But if someone accidentally plugs a device into the wrong port, it’s now on the wrong network segment and the only way you find out is when it can’t communicate properly. That’s the bane of every system integrator’s existence.
With modern NAC solutions like macmon, users set rules by device class rather than port number. The network automatically reconfigures itself based on what’s connected, regardless of which physical port you use.
AW: How should a network management platform identify and troubleshoot network problems before they affect production? What level of granular visibility is required here?
MF: When you have thousands of switches with dozens of connections each, that’s an enormous number of links to monitor. Traditionally, you’d have to check multiple factors independently, such as: Are devices online? Are links saturated? Is traffic quality degraded? Then you’d have to check them across multiple screens or overlaid color schemes, which makes it hard to get a quick read on overall health.
To streamline assessments, we developed ONE, the overall network effectiveness metric. It’s essentially OEE (overall equipment effectiveness) for your network. It incorporates link status, traffic levels and communication quality into one score to tell you at a glance whether your network is performing well or needs attention.
What makes this different from other network health scores is transparency. Many platforms offer health metrics, but they’re black boxes using pattern matching and heuristics you can’t deconstruct. With those metrics, if your score drops from 91 to 61, you have no idea what changed. The ONE metric, on the other hand, lets you drill down through the constituent elements to pinpoint where issues exist.
If all you can do is configure one switch at a time, you’re centralizing access but not actually saving time. Look for capabilities to apply firmware updates, protocol adjustments and security settings as bulk changes.
AW: How should network-management tools facilitate IT and OT collaboration yet maintain appropriate security boundaries?
MF: The cleanest approach is to have two network management systems — one watching the OT space, the other watching IT — separated by a demilitarized zone. The OT environment can generally run independently if the IT connection is severed. We see this dynamic all the time during cybersecurity incidents.
In practice, though, IT teams are increasingly administering portions of the OT space, or they have significant reach into OT networks. In these environments, your management platform needs to work with both IT and OT-grade equipment, and that often means dealing with multiple vendors. Some brands only make OT switches, others only IT. And even companies that offer both typically treat them as separate product lines internally.
Segmentation techniques like VLANs, firewall rules and access-control lists establish security boundaries, but they can also create blind spots for your management software, depending on where it sits. Planning, therefore, is critical. You need to recognize where boundaries exist and configure appropriate rules.
AW: What support should network management tools provide for Industry 4.0 initiatives, including edge computing, cloud connectivity and the massive data flows generated by smart manufacturing processes?
MF: This is an area where industry is actively evolving. Traditional network management focuses on the infrastructure layer, such as device configuration, monitoring and troubleshooting. Industry 4.0 initiatives, on the other hand, require extending visibility into how data flows through the network and reaches computing resources. This need for extended visibility is pushing network management and data platforms to converge.
One concrete capability to look for is time-sensitive networking (TSN) support. It lets you prioritize traffic within the network, designating certain communication streams as higher priority than others. This is critical for safety systems in OT environments. When someone hits an E-stop, for example, that signal needs to propagate immediately without being delayed by other traffic.
It’s incredibly rare for large-scale networks to be truly single-vendor environments. A good network-management platform will let you add third-party devices so you can manage everybody with one tool, rather than juggling multiple interfaces.
AW: What strategies and tools do you recommend manufacturing facilities use for future-proofing their network infrastructure as they continue adopting emerging technologies like artificial intelligence, digital twins and advanced analytics platforms?
MF: Intent-based networking represents the next level of evolution in network management. The concept is to look at endpoint configurations and automatically configure the network based on what those devices need to accomplish. With this approach, rather than manually configuring every switch and connection, you define the intended outcome and the system determines how to achieve it.
This approach works particularly well when devices are network aware. In the power industry, for example, equipment using IEC 61850 protocols often contains detailed information about communication requirements. You can ingest those device configurations and derive how the network should be structured around them. As other industrial protocols become more standardized and network-aware, we expect intent-based approaches to expand into those environments as well.
Also, cybersecurity planning should be front of mind for any future-proofing discussion. This means understanding your software bill of materials, not just what firmware versions are running on devices, but also what code bases, open-source components and service packs are embedded within that firmware.
More industrial network coverage from Automation World:
About the Author

James R. Koelsch, contributing writer
Contributing Editor

Leaders relevant to this article:
