OT asset inventory: a registry of PLCs and sensors without stopping production

Why an OT asset registry is needed — and why it rarely exists "by default"

In OT there are almost always devices that run for years and fall out of view. Some were installed by contractors, some were replaced "temporarily", some moved between lines. As a result, a shop floor can host new PLCs and HMIs, older industrial PCs, cameras, gateways, sensors and small switches that get remembered only by the phrase: "the line runs, that's what matters."

Typically, untracked items include remote sensors and actuator modules, cameras "for local tasks", HMIs after upgrades, industrial PCs in cabinets, and small gateways or interface converters (RS-485/Ethernet and similar).

Purchase lists and project diagrams don't equal reality on site. A purchase order may say "20 sensors bought", but not where they are installed or which ones were replaced. A diagram shows "how it should be", but doesn't reflect temporary bypasses, added ports, IP changes, or devices that are powered off yet physically remain in a cabinet.

"Without stopping production" brings constraints: you can't touch live controllers, aggressive scans are forbidden, access to some zones is possible only in short windows or only with operations present. So the registry must be collected carefully: by observation, on-site verification and safe network discovery.

The registry is useful for both cybersecurity and operations, but their goals differ. Cybersecurity needs to know what to protect and where the risks are: what's critical, what is reachable from outside, what hasn't been updated. Operations needs to quickly find an owner, documentation and spare parts to repair without "digging around". One current list becomes a single source of truth for both.

In practice, OT asset inventory starts not from perfection but from a simple question: which devices produce products today and who is responsible for them.

Preparation: boundaries, roles and rules so you don't get stuck

Inventories often stall not for lack of data but over disputes: what counts as an asset, who is responsible and where control ends. Resolve these questions up front in short agreements of 1–2 pages.

First, fix the boundaries. It's convenient to describe them the way you actually manage production: site — workshop — line. Add technical boundaries: subnets, control cabinets, separate video segments, and remote access points. Decide now what to do about contractors: are their controllers and laptops in your cabinets your assets, theirs, or "temporary but tracked"?

Roles and responsibilities

Next, assign roles, otherwise the registry becomes "nobody's". Typically four groups are involved: Process Control (ACS) (they know the equipment and modes), Operations (keep things running), IT (networking, addressing, asset systems), and Cybersecurity/InfoSec (requirements, risks, control). Video and access control often need a separate owner (security/video) because those devices live close to technology but follow different rules.

To keep it simple, fix the minimum:

• who creates a new record (e.g., ACS or operations)
• who validates the data (line/area owner)
• who is responsible for network fields (IT)
• who assigns criticality (InfoSec together with the process owner)

Record format and update rules

At the start, a spreadsheet is enough if it has a single asset identifier and clear statuses (draft, confirmed, decommissioned). You can migrate later to an asset system, but don't wait for the "perfect tool".

Agree on simple rules: how to name assets, where to store photos of nameplates/cabinets, how to mark disputed devices and how often to reconcile (for example, quarterly and after any change to a line). Without this the registry will quickly become outdated and cease to help both cybersecurity and operations.

Safety of work: how not to stop production

The main OT rule: it's better to gather less data than to cause a line outage. Inventory should follow agreed safe actions, not a "let's try scanning and see" approach.

What you can usually do passively without affecting traffic or controllers:

• take a SPAN/mirror port and analyze traffic selectively
• read network device configs and MAC tables on switches
• verify documentation, cabinet nameplates, serial numbers and firmware versions on site
• collect logs from engineering stations and SCADA servers if it doesn't load the system

Active polling may be needed (for example, to confirm a PLC model or HMI version), but only in maintenance windows and in small steps. Start with one segment and one device type, limit request frequency and have a preplanned way to stop activity quickly. If no window exists, close gaps using passive sources.

It's easier to get operations on board if you define "red lines" in advance:

• do not send requests to PLC/RTU without an agreed bench test or maintenance window
• do not change switch settings, routing or VLANs without a rollback plan
• do not touch I/O or sensors that affect safety without permits and accompaniment
• stop any activity at the first sign of instability (errors, timeouts, rising load)

Record risk directly in the registry or alongside it: where scanning is forbidden, why (critical line, legacy equipment, no window, no responsible person) and what safe alternative is agreed (SPAN port, read configs, walkthrough). This prevents "heroic" attempts to collect everything at once and helps plan the next iterations.

Walkdown inventory: what you can actually collect on site

A physical walkdown often yields more than expected. It allows you to quickly collect a first layer of the registry without risking the line: you don't change configs or scan the network, you record facts. This is important because some devices never appear in IT documentation.

Start with a route: workshop -> control cabinet -> rack/panel -> field (sensors, cameras, actuators). Go with someone who "knows where things are": an instrumentation electrician or a technician. During this step "gray" devices often surface: small untracked switches in a cabinet, media converters, consumer Wi‑Fi routers "for convenience", separate PoE injectors for cameras.

What makes sense to collect and immediately enter as a draft:

• make and model (PLC, HMI, camera, sensor), serial number, year of manufacture (if visible)
• exact location: workshop, line, cabinet, cell; for field devices — area and a clear description of mounting point
• cable and terminal markings, breaker/fuse number (if visible)
• external signs: modem/radio channel, USB drive, second network port, antennas
• ownership signs: contractor stickers, service log entries, contact info on the cabinet door

Photos speed the process: a wide shot of the cabinet, then close-ups of the nameplate and connections. Tag photos immediately (for example, "Workshop 2, cabinet SHU-17, PLC-1"), otherwise they become a set of images without context.

After the walkdown, do a quick check against documents: diagrams, equipment lists, datasheets, maintenance logs. Diagrams usually show "how it should be"; the walkdown shows "how it is". The differences become the list of clarification tasks.

Network discovery: what you can collect without aggressive scanning

If a walkdown answers "what sits in the cabinet", network discovery helps understand "what actually speaks on the network" and where it's connected. Devices move between ports and stickers/diagrams don't always keep up with reality.

Start with passive sources that don't touch endpoints. Usually you only need access to network devices and logs:

• MAC tables on switches (which MAC is on which port and VLAN)
• ARP tables on L3 devices (IP-to-MAC mappings)
• DHCP logs and reservations (if DHCP is used)
• firewall/router logs (who talks to whom and on which ports)
• SPAN/mirror capture analysis (selectively and by agreement)

Interpret passive data carefully so IT and OT are not conflated. Shop floors often have separate VLANs/segments, NAT on industrial gateways, floating addresses behind proxies and even one-way channels. One IP can hide several devices, and external logs may only show the gateway. Always record the "visibility point": which switch/firewall and which interface provided the data.

Active discovery is allowed only under agreed rules. The safest approach is short checks against a white list: confirm liveness (ICMP ping or ARP probe), check a couple of known ports without port scans, read standard banners where safe. Always stop on the first sign of instability.

To avoid duplicates, keep the combination IP + MAC + switch port + physical location. A camera that gets a new IP after replacement often keeps its MAC and cabinet port, which helps avoid duplicate entries.

Owners and responsibilities: without this the registry won't work

Hardware matters, but people matter more. Without an owner, records quickly become outdated: a controller is replaced, a password changed, a port moved, but the table still shows old data. So always record responsibility alongside the device.

Prefer assigning ownership to a group and role rather than a person's name. For PLCs this is often Process Control (ACS) or the I&C team; cameras — security or IT; sensors — the area or workshop. If maintenance is outsourced, the internal party that accepts the work remains the owner, and the contractor should be recorded as the servicing organization.

It's useful to separate two responsibilities: who operates/maintains (responds, repairs) and who authorizes changes (firmware, logic, network settings, replacements). When these roles are mixed, changes happen "by phone" and the registry stops being a source of truth.

To help during incidents, add a short escalation chain:

• primary role (e.g., "ACS shift engineer")
• on-call phone or dispatch entry point
• responsible manager (who decides on shutdown/mitigation)
• vendor/service company (if under contract)

Simple rule: "no owner — no operation". If an asset is found but no owner is known, close the gap immediately:

• assign a temporary owner for 2–4 weeks (often the area supervisor)
• create a task to confirm ownership or transfer the asset
• forbid changes without explicit owner approval
• if no owner is identified, decide the asset's fate: decommission or legalize it

Example: an HMI in a cabinet serves two lines. Operations owns it as a user, ACS owns changes to logic, and IT owns the network. If these roles are recorded in the registry, the "who's to blame" argument becomes an actionable flow.

Criticality and risks: how to prioritize without complex methods

When there are many assets, the debate is usually: what to protect and service first. To start, a simple 1–3 scale is enough to get order and avoid drowning in details.

Simple 1–3 criticality scale

Assign each device a level based on four questions: does it affect personal safety, will its failure stop production, will it ruin product quality, are there regulatory or reporting requirements?

• 3 (high): risk of injury, line stoppage, major scrap, regulatory breach.
• 2 (medium): partial performance loss, local scrap; workarounds exist but are costly.
• 1 (low): affects convenience or monitoring; easy replacement.

Assess devices by dependencies. A simple pressure sensor can be level 3 if its failure makes the PLC trigger an emergency stop. A camera can be level 2 or 3 if it's part of quality control and shipments cannot leave without its footage.

Highlight remote access points separately, because they raise risk even for low-criticality devices: remote maintenance, modems, service ports, engineering laptops, and shared passwords.

What to do first

Start with level 3 devices and anything with remote access or uncontrolled service ports. Then follow a clear order: assign an owner and on-call contact, check spare parts and replacement plans, define safe maintenance (windows, permits), record remote access and accounts; schedule updates and checks for level 2 devices. Level 1 can wait.

Example: the PLC controls pumps, the HMI only displays, and a level sensor commands shutoff. The sensor and PLC get level 3, the HMI is usually level 2. This shows where to send engineers and cybersecurity resources first.

Minimum registry fields for cybersecurity and operations

A usable OT registry doesn't have to be perfect from day one. It must let you find a record, have an owner, and help make quick decisions during an incident or outage.

Fields without which the registry becomes a "graveyard of records"

Keep a short "passport" for each device. If information is missing, record that explicitly rather than leaving blanks.

• Identification: type (PLC, HMI, camera, sensor), manufacturer, model, serial number (or inventory tag), site name/tag.
• Network: IP (if any), MAC (if any), segment/VLAN, physical location (cabinet/rack), switch port (if known), main protocols/services (e.g., OPC UA, Modbus/TCP) — only what is confirmed.
• Operations: installation location (workshop, area), line/node, purpose (what it controls/measures), owner (department), servicing party (ACS, contractor), status (active/spare/decommissioned).
• Cybersecurity: criticality (1–3 or low/medium/high), access type (local only/remote access exists), remote access points (if set), date of last check/inventory.
• Data quality: confidence level (confirmed/by word/probable) and a "task to clarify" with an owner and deadline.

How to store "unknowns" so they aren't lost

Agree on values like "not determined" and "requires verification". If a sensor's serial number isn't visible, write: "S/N: not determined" and create a task: "photograph nameplate at next stop" with an owner. The registry stays honest and usable from day one.

Step-by-step plan: from zero to a living registry in iterations

To build an OT inventory without stopping production, go in short cycles: draft, on-site confirmation, then network reconciliation. This yields a working picture faster than chasing perfection.

Iteration 1: gather a base and quickly check reality

Start from existing sources: diagrams, cabinet plans, IP lists, procurement exports, commissioning reports, maintenance logs. Compile a draft registry even if it has many gaps.

Check the most critical areas next: nodes where downtime is expensive (filling line, packaging). During the walkdown record what can be seen safely: PLC/HMI models and serials, device location, wiring marks, and who usually accesses the cabinet.

Iteration 2: find discrepancies and assign responsibility

After the walkdown, do cautious network checks: passive monitoring, switch table reads, port mirroring (if allowed), ARP/MAC analysis within allocated segments. The goal is not to "scan the whole network" but to find mismatches: "seen on the network, not in the registry" and vice versa.

Then close organizational gaps. A good registry lives on owners and simple update rules. Typical process logic: draft from documents, confirm priority areas by walkdown, reconcile with the network, assign owner and criticality, then update the registry on events (repair, replacement, relocation, firmware) and through short scheduled reconciliations.

For example, if a camera is visible in the network but has no owner, agree boundaries: operations is responsible for power and mounting, IT (or ACS) for networking, security for video storage and access. This drastically reduces "lost" devices.

Common mistakes and traps when accounting PLCs, HMIs and sensors

The most common mistake is to start with the network and immediately run active scans across the industrial network. Even "light" scans can generate traffic, affect old PLCs, or overload a small cabinet switch. In OT, agree rules first and collect via walkdowns, passive sources and targeted checks.

Another trap is mixing IT and OT in one list without marking segment and purpose. Then an office printer sits next to an HMI in the registry and no one knows what belongs to the shop floor. That ruins prioritization and incident response.

A third error is keeping records only by purchase. Some equipment is still in storage, some was already replaced during repairs, and contractors sometimes install temporary switches or cameras without notice. The registry should reflect installed and powered devices: where they sit, what they're connected to, and what actually works.

A fourth trap is not recording owners and contacts. When a temperature sensor starts giving noisy data, InfoSec doesn't know who to call and operations doesn't know who authorized changes. An owner contact often solves this in minutes.

A fifth mistake is failing to plan updates. The registry becomes stale after the first repair.

To avoid most problems, keep core rules in one place: any network check only by agreement and with limits; separate fields for OT/IT, segment and location; reconcile "purchased" vs "installed and powered"; owner plus on-call contact for every asset; and clear events that force record updates.

Example: an HMI is replaced with an identical model but keeps a temporary IP and hostname. If the registry isn't updated, monitoring will see "a new device" at night and the team will waste time finding the responsible person instead of fixing the issue.

Quick registry quality check (10-minute checklist)

A registry is useful only if you can quickly find a device and assess how bad it is if it fails. This quick check shows whether the registry is "alive" after inventory.

10-minute checklist

Pick 5–10 most important nodes (main line, packaging, raw material area) and verify five things:

• Coverage: each critical line has at least primary controllers, HMIs, key cameras and sensors listed, not just "what was found by chance".
• Owners: each asset has an owner and a servicing party (ACS, I&C, IT, contractor). "Workshop" without a role is not ownership.
• Findability: for network devices there is enough to locate them (IP or MAC plus segment/workshop or switch/cabinet). For non-network sensors — at least cabinet and terminal or loop.
• Criticality: roughly assigned and agreed with operations, not only InfoSec.
• Freshness: date of last check and a clear update trigger (replacement, repair, upgrade, relocation).

If two or more items fail, the registry is still a list of observations rather than a working tool.

Sample scenario: a line with PLCs, HMIs, cameras and "lost" sensors

A filling line has 2 PLCs, 3 HMIs, 12 cameras and about 40 sensors. Some sensors and one camera were installed by contractors during upgrades and documentation is scattered across people's mailboxes. No one will approve stopping the line, so work begins with what can be done safely and quickly.

First, do a walkdown focusing on cabinets, DVR racks, and areas where sensors most often cause downtime. In cabinets you often find PLC model, I/O module composition, cable markings and sometimes contractor stickers. For cameras, record angle, mounting height, nearby equipment and cable routing.

At the same time enable non‑aggressive network discovery: check ARP/MAC tables on switches, client lists on the recorder, DHCP leases (if any). This reveals an "extra" camera — a MAC with a camera OUI appears in the network but no one remembers installing it. You might also find an unknown switch in a cabinet: MACs show some cameras are plugged into a different place than expected.

Then assign owners: PLCs and sensors — I&C team; HMIs — operations as users and I&C as service; video — contracted video company, but power and mounting are the workshop's responsibility.

After the first iteration you already see what matters: what causes downtime (PLCs and level sensors), where remote access exists (HMI with service VPN or a camera with a forwarded port), which devices are "off‑scheme" (extra camera, unknown switch), what to check first during incidents (accounts, firmware, backups) and who to call for shutdown or isolation.

Next steps: turning a one‑off task into a continuous process

A registry rapidly becomes stale if it's not integrated into routine work. After any PLC swap, firmware change, HMI move, camera or sensor addition, the record must be updated just like closing a maintenance ticket.

Working rule: "no registry update — no acceptance of the work." The asset owner confirms changes and the registry keeper verifies that critical fields are filled and no gray devices appear.

Next, address forgotten accounts, temporary connections and unlabeled devices. Start with high‑impact actions that don't require a big project: tidy up remote access, apply physical labeling (unique ID on cabinet/panel and the same ID in the registry), define basic spare parts for critical nodes, and set a short monthly check for 5–10 most critical assets and segments.

One practical thought: data needs a "home." Even if you started with a spreadsheet, you need version control, access rights and backups. Minimum — a separate backed‑up storage and clear roles on who can edit and who can view.

If the registry and changes require infrastructure (servers, workstations, network, support), it's easier to do with a system integrator. In Kazakhstan such tasks are often implemented using solutions and equipment from GSE.kz (manufacturing and IT system integration) so the inventory stays alive for years and doesn't become a one‑time campaign.