OT Security Maturity Model: From Zero Visibility to Advanced Detection

Why OT needs a maturity model

The existing security frameworks, from IEC 62443 to NIST CSF, are comprehensive and rigorous assessment tools. They are also, often, too elaborate to be used as a starting point by an organization that does not yet know where it stands.

An OT manager or a CISO who wants to understand "where we are today and what to do tomorrow" needs a more direct model: a few levels, clear requirements, a defined next step. Not a framework to certify against, but a map to find your bearings.

The four-level model described in this article does not replace IEC 62443 or NIST CSF: it assumes them as the final horizon. Its purpose is to position you along the path, to triage priorities, and to build a sustainable roadmap for a mid-sized manufacturing organization.

Level 1: Blind

Characteristics: no OT asset inventory, no monitoring of industrial network traffic, no documentation of known vulnerabilities. The OT network topology exists in the head of whoever built it years ago, not in an up-to-date document. Communications between devices are unknown in detail.

What is missing: fundamental visibility. You cannot protect what you do not know, and at Level 1 you know very little.

Signs that you are at Level 1: the team does not know with certainty how many PLCs are on the production network; there is no up-to-date list of the firmware versions of critical devices; the only way to know whether there is a new device on the network is to notice it physically or to wait for a problem to surface.

The main risk of Level 1: it is not just that attackers are invisible. It is that even normal maintenance operations can cause unexpected problems, because the understanding of the environment is incomplete. A misconfigured device, a firmware version with a critical vulnerability: nobody knows because nobody has ever carried out a systematic census.

How long it takes to leave it behind: this depends on the size of the environment, but for a mid-sized manufacturing plant (tens or a few hundred OT devices) obtaining a first meaningful inventory takes weeks, not months, if you use passive discovery tools that analyze existing network traffic without disrupting the processes.

Level 2: Visible

Characteristics: a complete OT asset inventory exists, with the fundamental information for each device (type, manufacturer, model, firmware version, IP address, network zone). The network topology is documented. A baseline of normal traffic is available: which devices communicate with which, over which protocols, and how often.

How to reach Level 2: the technical prerequisite is passive monitoring of OT network traffic. A sensor positioned at strategic points of the network captures the traffic, decodes the industrial protocols (Modbus, OPC-UA, PROFINET, EtherNet/IP, DNP3 and others) and automatically builds the asset inventory and the communications map. There is no need to actively query the devices, an operation that can cause problems on legacy systems.

What you gain at Level 2: for the first time, the organization knows what is on the OT network. This has immediate value even independently of security: it supports preventive maintenance, helps identify legacy devices that were not known to be still active, and provides a documentary basis for the vendors who work on the plant.

The next step: Level 2 answers the question "what is there". Level 3 answers the question "what is at risk and why". The transition requires associating the inventory with known vulnerabilities.

How long it takes to advance: moving from Level 1 to Level 2 is often the fastest jump in terms of technical infrastructure, but it requires an organizational process: who keeps the inventory up to date, how changes are managed (within what timeframe must a newly installed device enter the inventory?), who has access to the network map. Without a process, the inventory ages quickly.

Level 3: Aware

Characteristics: the OT inventory is associated with known vulnerabilities. For each device it is possible to know which CVEs are applicable, what the EPSS score (probability of active exploitation) of the relevant vulnerabilities is, and what the remediation priorities based on real exposure are. Detection rules exist for the most obvious network anomalies and for behaviors that do not conform to the baseline.

How to reach Level 3: the prerequisite is a complete Level 2. The technical addition is the correlation between the inventory and vulnerability databases (NVD, ICS-CERT, CISA KEV). For OT devices this is not trivial: CVEs for industrial control systems are held in dedicated databases, and mapping the firmware version of a specific PLC to the applicable vulnerabilities requires tools specialized in OT.

The importance of EPSS in OT: the CVSS score alone is not sufficient for prioritization in the OT context. A vulnerability with CVSS 9.8 on a device isolated in a zone without remote access has a different priority compared to a vulnerability with CVSS 7.0 on an exposed device with a publicly available exploit. EPSS (Exploit Prediction Scoring System) provides the probability that a vulnerability will be actively exploited in the next 30 days, integrating with CVSS for prioritization based on real risk.

Basic detection: at Level 3 the first anomaly detection rules are added. Not the advanced behavioral analysis of Level 4, but the detection of the most obvious deviations from the baseline: a new device appearing on the network, a communication toward an unexpected external IP, an industrial protocol on a non-standard port, a change to a PLC configuration outside the maintenance windows.

How long it takes to advance: the main challenge of Level 3 is not technical but organizational: what to do with the vulnerabilities found. In OT, patching is often impossible or constrained by widely spaced maintenance windows, vendor certification requirements, and the impossibility of shutting the systems down. OT vulnerability management requires a residual-risk management process (compensating controls) that must be built with the operations team, not just with the security team.

Level 4: Operational

Characteristics: advanced anomaly detection based on behavioral models per asset and per zone. Integration with the SOC (internal or managed) for the handling of OT alerts. OT-specific incident response procedures, documented and tested with periodic exercises. Automated reporting for compliance (NIS2, IEC 62443) generated directly from the monitoring data.

How to reach Level 4: Level 4 is not a state that you reach once and maintain without effort. It requires a continuous cycle: baselines are refined over time, detection rules are updated when processes change, and response playbooks are revised after every incident or exercise. It is a program, not a project.

SOC integration: at Level 4, OT alerts reach the SOC in a normalized format (CEF, Syslog, JSON) and are correlated with IT alerts. This makes it possible to detect attacks that cross the IT-OT boundary, which are precisely the most dangerous and the hardest to spot by looking at only one of the two networks. SOC analysts must have at least a basic understanding of OT protocols and of the operational context to handle alert triage.

Tested response procedures: having a written playbook is necessary but not sufficient. Level 4 requires periodic tabletop exercises in which the team simulates OT incident scenarios and verifies that the procedures work: who calls whom, in what order, with what authorization an OT network segment is isolated, and how to coordinate with the operations team during an active incident.

How long it takes to reach Level 4: the typical interval from Level 1 to Level 4 for a mid-sized manufacturing organization is measured in years, not months. But the critical point is not the final destination: it is the first step. The transition from Level 1 to Level 2, from blindness to visibility, is the most significant change in posture and often the fastest to implement.

How to use this model

The model is not linear in an absolute sense: it is possible to have elements of Level 3 in some zones of the plant and to remain at Level 1 in others. This is common in organizations with distributed plants or with OT networks that have grown over time without centralized governance.

The practical use of the model is as an assessment and prioritization tool: map where each zone of the plant stands, identify the gaps relative to the level above, and translate the gaps into concrete actions with an estimate of the time and resources required. The result is a roadmap that does not start from the complete framework but from the most concrete next step.

For reporting toward management or toward NIS2 auditors, OT maturity expressed in levels is also an accessible language: it does not require deep technical knowledge to understand the difference between "we do not know what is on our OT network" and "we monitor the behavior of every asset and we know when something deviates from the norm".

The MON5 angle

The four levels described in this article closely mirror the MON5 operational path: the DISCOVER phase builds inventory and topology through passive discovery, without stopping production, and takes you from Level 1 to Level 2. The ANALYZE phase adds the correlation between assets, CVEs and EPSS scores that characterizes Level 3. The PROTECT phase, with continuous monitoring and ML anomaly detection, covers Level 4.

The key strength is modularity: there is no need to activate everything at once, capabilities are added as maturity grows. To position your plant on the scale and define the next step, the starting point is an OT assessment.