Dev.to Security 🔐 Cybersecurity 👁 0 📖 6 min read

How to Reduce OT Security Risk With Complete OT Asset Discovery and Visibility

How to Reduce OT Security Risk With Complete OT Asset Discovery and Visibility Ask a utility operator or plant manager how many devices sit on their control network, and you'll usually get an estimate rather than a num

How to Reduce OT Security Risk With Complete OT Asset Discovery and Visibility

Ask a utility operator or plant manager how many devices sit on their control network, and you'll usually get an estimate rather than a number. That's understandable. Industrial environments grow in layers over decades, and the people who installed a device are often not the people responsible for it today. But it creates a real problem for security, because you can't protect, patch, or monitor something you don't know exists.

This is why OT asset discovery tends to be the first step in almost every serious operational technology security program. This post walks through what it involves, why it's harder in OT than in IT, and how complete visibility helps reduce risk in practical terms.
Why OT asset discovery comes first

In a corporate IT network, asset management tools have been around for years, and most organizations have at least a rough inventory of laptops, servers, and applications. Operational technology is different. It includes programmable logic controllers (PLCs), remote terminal units, human-machine interfaces (HMIs), SCADA servers, historians, engineering workstations, sensors, and a growing number of connected IoT devices. Many of these were installed long before cybersecurity was a design consideration, and some have never been touched by an IT team.
The result is a blind spot. Every other security control, whether it's segmentation, vulnerability management, monitoring, or incident response, depends on knowing what's actually on the network. Without that baseline, those controls are built on assumptions.

What OT asset discovery actually covers
A useful inventory is more than a list of IP addresses. For each device, teams generally want to know:
• What it is: make, model, device type, and function in the process
• What it runs: firmware version, operating system, and installed software
• How it communicates: protocols used, which systems it talks to, and whether it has any path to the internet or to the corporate network
• Where it lives: physical location, network zone, and the site or process it supports
• Who owns it: the person or team responsible for changes, maintenance, and vendor contact
• How critical it is: what would happen to operations, safety, or service if it failed or was manipulated

Once that information exists in one place, it can feed everything else: risk scoring, patch planning, segmentation design, and detection rules.

What recent incidents show about visibility gaps

The link between visibility and risk isn't theoretical. As covered in Futurism Security's write-up on recent attacks on U.S. water systems, more than 30 Minnesota water systems reported coordinated cyberattacks on July 26 and 27, 2026. Nine Michigan systems later reported related malicious activity, and two Colorado utilities were reportedly targeted by foreign actors who changed equipment settings, disabled alarms and remote access, and modified pumping cycles. Several utilities had to move from automated to manual operations. No public health impact was reported.
Federal agencies linked the activity to Iran-affiliated actors that target internet-exposed PLCs, SCADA environments, and HMIs. Those are exactly the kinds of assets that tend to go missing from inventories, particularly when remote access was set up years ago for convenience and never revisited.

The pattern is worth noting. In many cases, the question for defenders isn't only "how did they get in?" but "did we know that device was reachable in the first place?" Complete OT asset discovery is how an organization answers that question before an attacker does.

Why OT environments are hard to inventory
If asset discovery were simple, everyone would have finished it already. A few things make OT different from IT:
• Fragile devices. Some older controllers can behave unpredictably when hit with the kind of active scan that's routine in IT. A scan that's harmless on a server can disrupt a process.
• Proprietary and legacy protocols. Industrial devices often speak protocols that standard IT tools don't understand, so they simply don't show up.
• Hidden connections. Vendor remote access, cellular modems, and old workarounds can create paths nobody documented.
• Split ownership. Operations, engineering, and IT may each hold a piece of the picture, and nobody holds all of it.
• Long lifecycles. Equipment can stay in service for decades, so the inventory has to account for systems that are out of support and can't easily be replaced.
A practical approach to OT asset discovery
There's no single right method, but a few principles show up again and again.
Start with passive monitoring. Listening to network traffic, usually through a span port or network tap, lets you identify devices and map communications without sending anything to the devices themselves. It's the lowest-risk way to get a first, fairly complete picture.
Use active queries carefully. In some cases, targeted and well-tested queries fill in details that passive monitoring can't, such as firmware versions. These should be planned with the operations team, scoped narrowly, and run with an understanding of what each device can tolerate.
Combine tools with people. Network data won't capture everything. Engineering drawings, change records, vendor documentation, and walk-downs of sites help find devices that are offline, isolated, or only used occasionally.
Map the communications, not just the devices. Knowing which systems talk to each other, and which ones shouldn't, is what makes segmentation and anomaly detection possible later.
Add context. Pair the inventory with known vulnerabilities, default or weak credentials, unsupported software, and internet exposure. An inventory without risk context is just a spreadsheet.
Keep it current. Networks change. A one-time exercise goes stale quickly, so continuous or at least regularly repeated discovery matters more than a perfect initial snapshot.

Turning visibility into lower risk
A complete inventory doesn't reduce risk on its own. What it does is make the next steps possible and better targeted:

  1. Find and close unnecessary exposure. Identify PLCs, HMIs, and remote access services reachable from the internet, and decide which ones truly need to be.
  2. Prioritize vulnerabilities. With device details and criticality in hand, teams can focus on the weaknesses that matter most instead of trying to fix everything.
  3. Design segmentation. Separating OT from corporate IT, and critical zones from less critical ones, limits how far an intruder can move after initial access.
  4. Monitor with context. Detection works much better when the baseline of normal behavior is known. Unexpected devices or new connections stand out quickly.
  5. Prepare incident response. Responders can't contain or recover systems they can't identify. An accurate asset list shortens the time spent figuring out what's affected. For a refresher on the basics, see this overview of what incident response involves.
  6. Support compliance. Frameworks such as IEC 62443, NIST guidance, and NERC CIP all assume that an organization knows what it's operating. A reliable inventory is the foundation for showing alignment.

Common mistakes to avoid
• Treating the inventory as an IT project and leaving operations out of it
• Relying only on spreadsheets that were accurate at one point in time
• Running aggressive active scans on live process networks without testing
• Ignoring small, remote, or "temporary" sites
• Collecting data but never connecting it to risk decisions

Where outside support can help

Some organizations build this capability in-house. Others bring in specialists, especially when staff are stretched thin or the environment spans many sites. If you're weighing that option, OT/IoT security consulting services typically cover asset discovery and visibility alongside vulnerability and risk assessment, network segmentation, secure architecture design, threat detection and response, and compliance alignment. Futurism Security, for example, lists these as part of its OT and IoT offering, with a focus on industries such as manufacturing, energy and utilities, healthcare, and smart infrastructure.
Whichever route you choose, it's worth confirming that the approach is safe for live operations, works with the tools you already use, and produces something your own team can maintain afterward.

Final thoughts
OT security can feel like a huge, open-ended problem, and it's easy to get stuck deciding where to begin. Complete OT asset discovery is a sensible answer. It's concrete, it doesn't require shutting anything down when done carefully, and nearly every later decision gets easier once you can see what you have.
If you take one thing from this post, let it be this: start by finding out what's actually on your network, then use that picture to decide what to fix first.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.