NCSC OT Advisory: Visibility First with GLPI

The NCSC has put OT visibility back on the board agenda

Last week, the National Cyber Security Centre published an advisory calling on all organisations that use operational technology to review their security in light of increased global targeting of OT systems.

The message is direct: this is not a niche IT concern. Any organisation with internet-exposed OT could be affected and you should not assume your OT is inaccessible from the internet without verifying it. Unintended exposure through misconfigurations, legacy connections, or unmanaged assets is exactly how risk accumulates quietly.

Across eight recommended actions, one theme runs through the guidance: visibility comes first.

Build a definitive view of your OT architecture, including all assets, communications pathways and external connections.

NCSC advisory — first recommended action

Everything else — credential hardening, network segmentation, secure protocols, logging and monitoring, backup and recovery — depends on that foundation. You cannot remove default credentials from devices you do not know exist. You cannot segment networks you have not mapped. You cannot monitor for unexpected traffic to PLCs and HMIs if those assets are not in your inventory.

This is not new thinking. The NCSC has been clear for some time that understanding your OT environment is the first step to stronger cyber security. What has changed is the urgency. The threat picture has shifted, and the guidance is now aimed at every organisation running OT — not only critical national infrastructure.

The visibility gap is the vulnerability

In our work with public sector and shared services organisations, we see the same pattern repeatedly.

OT environments grow organically. A PLC installed during a plant upgrade. An HMI connected for remote monitoring. A gateway added to feed data to a management dashboard. Engineering teams maintain detailed knowledge in their heads, spreadsheets, or vendor-specific tools while the central CMDB holds only traditional IT endpoints.

The result is a dangerous gap between what the network actually contains and what the organisation officially knows about.

That gap matters because the NCSC's advisory is not only about dramatic attacks. It is about avoidable exposure: systems that should never have been internet-facing, devices running default credentials, boundary equipment past end-of-life, and connections nobody documented because they were "temporary" five years ago.

The comment threads on the NCSC's LinkedIn post reflect this tension well, particularly in regulated environments where change control, validation, and operational continuity can slow security response. The answer is not to choose between compliance and security. It is to build a maintained, authoritative view of assets that both engineering and security teams can trust.

Asset discovery is not a nice-to-have — it is the control

If the NCSC's guidance were a checklist, item one would be an asset management problem.

That is where GLPI and specifically its discovery and inventory capabilities provides a practical, open-source foundation that organisations can deploy without waiting for a multi-year enterprise CMDB programme.

At Echo-9, as a GLPI Partner, we help organisations build exactly this kind of visibility: a living inventory that spans IT and OT, tied into service management workflows so asset data is not siloed in a spreadsheet that goes stale the week after the audit.

Here is how GLPI's discovery capabilities map directly to what the NCSC is asking for.

1. Network discovery — find what is on the wire

The GLPI Inventory plugin, working with the GLPI Agent, performs automated network discovery across defined IP ranges. Using ICMP, ARP, NetBIOS, and SNMP, it identifies devices on the network and reports them back to GLPI for classification and import.

This is the starting point for answering the NCSC's core question: what is actually connected, and where?

Discovery can be scoped deliberately — by VLAN, site, or subnet — so OT environments are scanned in a controlled way without overwhelming fragile networks. That matters in industrial settings where aggressive scanning can itself cause operational risk.

2. SNMP inventory — identify industrial and network devices

Discovery tells you something is there. SNMP inventory tells you what it is.

GLPI's network inventory retrieves manufacturer, model, serial number, firmware, and other SNMP-accessible attributes from switches, routers, printers, and network-connected industrial devices. The GLPI Agent maintains a device identification database and supports MibSupport modules for specialised hardware that does not fit standard profiles — extending identification to appliances and devices common in OT and facilities environments.

For organisations working toward the NCSC's recommendation to retire insecure management protocols, this inventory also surfaces what protocols and interfaces devices expose — a prerequisite for migrating away from SNMPv1/v2 and Telnet.

3. Remote inventory — reach into segmented and isolated networks

OT networks are often segmented, air-gapped, or policy-restricted. Installing an agent on every device is frequently impossible.

GLPI Agent's remote inventory capabilities — managed through the Toolbox plugin — allow credentialed collection via SSH, WinRM, and SNMP from a designated agent host, without requiring every endpoint to connect back to a central server. This is particularly relevant for:

• Isolated OT segments that should not route to the internet
• Linux-based industrial appliances
• VMware hosts and mixed environments at the IT/OT boundary
• Environments where change control limits what can be installed

The Toolbox approach also supports running discovery and inventory tasks locally and pushing results to GLPI — useful where direct connectivity from OT to a management platform is restricted by design.

4. A CMDB that connects assets to action

Discovery alone is not enough. The NCSC's guidance extends to access control, segmentation, logging, change protection, and recovery — all of which require ownership, criticality, and relationships between assets.

GLPI provides this as an integrated ITSM and ITAM platform. Once assets are discovered, they become configuration items in a CMDB that can be linked to:

• Incidents — when anomalous traffic is detected, analysts know what the device is, who owns it, and where it sits
• Problems — recurring exposure patterns can be tracked to root cause
• Changes — modifications to OT assets go through controlled workflows
• Locations and groups — supporting the NCSC's emphasis on segmentation by function and criticality

This is the difference between a one-off network scan and a maintained definitive view — the exact language the NCSC uses.

5. Extending visibility with OT-native tooling

For organisations with dedicated OT security monitoring, GLPI integrates with platforms such as Nozomi Vantage, enriching OT network observations with authoritative CMDB data — ownership, location, lifecycle, and software inventory. Network-observed assets are reconciled against GLPI records, surfacing devices that exist on the network but not in the CMDB, and vice versa.

That reconciliation is precisely the governance workflow OT and IT teams need to keep asset data accurate over time — not just at point of discovery.

Mapping GLPI to the NCSC's eight actions

GLPI will not single-handedly deliver every control in the advisory. No tool will. But the asset foundation it provides underpins most of them:

The NCSC also notes that non-OT organisations face parallel risks from internet-exposed edge devices. The same GLPI discovery capabilities that surface OT assets also inventory routers, switches, and exposed infrastructure — supporting the advisory's call for an accurate inventory of internet-facing systems.

Where to start

The NCSC is clear: act now, and start with visibility.

A practical starting point for most organisations looks like this:

1. Define scope — identify OT and OT-adjacent network segments, including "temporary" connections and remote access paths
2. Run controlled discovery — scoped network discovery via GLPI Agent, with appropriate change notification to operational teams
3. Enrich with SNMP inventory — classify devices, capture firmware and serial data, identify unmanaged assets
4. Reconcile and govern — import into GLPI's CMDB, assign ownership and criticality, link to incident and change processes
5. Maintain — schedule recurring discovery to catch drift, new devices, and configuration changes

At Echo-9, our OT/IoT Asset Visibility & Risk and Asset Discovery & CMDB Rebuild consulting offerings are built around this exact workflow — baseline coverage, discovery runbooks, CI taxonomy, data quality scoring, and segmentation recommendations grounded in what is actually on your network.

The bottom line

The NCSC advisory is a reminder that OT security is now a board-level resilience issue. But the guidance does not begin with expensive tooling or disruptive network redesign. It begins with a question every organisation must be able to answer confidently:

Do we know what OT assets we have, how they are connected, and what is exposed?

If the honest answer is no — or "we think so, but we have not verified" — then asset discovery is not a future project. It is this quarter's priority.

GLPI provides an open, partner-supported path to building that definitive view — and at Echo-9, we help organisations turn discovery into durable governance.