OT Security Maturity Model: 5 Levels, 10 Domains

Most industrial operators can list the OT security tools they have bought, but few can show whether a vendor could still reach a controller tonight with a shared password, or whether the plant could run for a week with IT switched off. OT maturity is whether controls hold at the site with the oldest equipment, the most remote access and the thinnest staff. This model scores OT security on the same five-level Ad hoc to Optimised scale as the other NHI Mgmt Group maturity models, across ten capability domains, and lines those levels up with the US DOE C2M2, IEC 62443, CISA's Cross-Sector Cybersecurity Performance Goals (CPGs) and the NCSC Cyber Assessment Framework (CAF). It is for OT security leads, plant and engineering managers and CISOs who need an honest baseline across sites. For OT fundamentals, see the OT Security Guide.

Key takeaways

Score each site and each domain separately. A corporate average hides the one plant with an internet-exposed PLC, and that plant sets your real level.
Maturity and security level are different measures. IEC 62443 security levels describe the attacker a zone can withstand; maturity levels describe how reliably the processes that keep it there are run.
Level 3 (Defined) is the right first target: a passive inventory, documented zones and conduits, brokered remote access with named accounts, and an OT incident plan exercised with operators.
Identity is the domain most sites score lowest on. Default and shared credentials, always-on vendor access and old service accounts on historians and engineering workstations are common ways in.
Score evidence, not policy: inventory exports, dated rule reviews, remote session records, restored logic backups and manual operation drills.

The five levels

Level	Name	Description
1	Ad hoc	Security depends on individual engineers. No reliable inventory, flat or dual-homed networks, vendors connect with shared or default credentials, and nobody owns OT cyber risk.
2	Developing	An OT security owner is named and initial practices are performed unevenly across sites: partial inventory, an IT/OT firewall without reviewed rules, a remote access tool not always used.
3	Defined	Documented, resourced practices at every site: passive inventory, zones and conduits with an industrial DMZ, brokered remote access with MFA and recording, an OT incident plan and offline logic backups.
4	Managed	Practices are measured and enforced: target security levels per zone, scheduled rule and account reviews, OT detections handled by the SOC, supplier terms in contracts, and timed recovery drills.
5	Optimised	Metrics, incidents and threat intelligence drive improvement. Consequence-based engineering removes cyber-exploitable failure modes from the worst scenarios, and security capability rises at every refresh.

How the levels relate to C2M2, IEC 62443, CPGs and the CAF

This model gives one scale to compare sites; keep the framework your regulator or customers ask for as the system of record.

Framework	What it measures	Scale	Best used for
US DOE C2M2 Version 2.1 (June 2022)	356 practices in 10 domains, IT and OT	MIL1 Initiated, MIL2 Performed, MIL3 Managed (MIL0: not performed)	Energy and critical infrastructure self-evaluation with per-domain targets
ISA/IEC 62443 maturity levels (2-1:2024, 2-4, 4-1)	How well asset owners, service providers and suppliers run security processes	ML1 Initial, ML2 Managed, ML3 Defined (Practiced), ML4 Improving	Holding integrators and suppliers to a stated maturity per requirement
ISA/IEC 62443 security levels (3-3, 4-2)	Strength of technical requirements per zone, system or component	SL 1 to SL 4, as target (SL-T), capability (SL-C) and achieved (SL-A)	Design and procurement
CISA Cross-Sector CPGs	38 baseline goals for IT and OT, organised by CSF functions	Goal met or not met	A minimum baseline for small operators
NCSC CAF 4.0	Outcomes and indicators of good practice across four objectives and 14 principles	Not achieved, Partially achieved or Achieved, against a CAF Profile	UK operators of essential services under the NIS Regulations

Approximate correspondence: Level 2 here is close to C2M2 MIL1 and 62443 ML1 (performed but ad hoc); Level 3 to MIL2 and ML2 to ML3 (documented, resourced, followed); Level 4 to MIL3 (policy-driven, responsibility assigned, effectiveness tracked); Level 5 to ML4, where process metrics drive improvement. Treat this as a sense check, not an equivalence.

The 62443 maturity level names come from the ISA Global Cybersecurity Alliance quick start guide, which notes that ML4 combines CMMI levels 4 and 5 and that "Security Levels are a measure of the strength of technical requirements, Maturity Levels are a measure of processes." The standard texts are paywalled; the public 2-4:2023 preview lists a maturity model clause but not the definitions. See the IEC 62443 Guide for zones, conduits and security levels.

Choosing a frame: US energy operators usually start with C2M2 and DOE's self-evaluation tool. UK operators under NIS use the CAF. Manufacturers and buyers of integration services use 62443, because contracts can name a part, an SL-T and an ML. A small water utility starts with the CPGs. Large operators often report through C2M2 or the CAF and engineer to 62443.

The ten capability domains

Levels 2 and 4 sit between the descriptions shown; the roadmap below lists what moves a site up.

Domain	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Governance and ownership	IT and engineering each assume the other owns OT risk	Named OT security leader and site owners; engineering signs off changes	OT risk reported to the board by consequence; cyber PHA drives investment
Asset inventory	Site spreadsheets, years out of date	Passive inventory with firmware, protocols, owner, criticality and device accounts	Continuously reconciled with monitoring and change records; device provenance known
Architecture and segmentation	Flat networks, dual-homed hosts, direct IT to OT paths	Zones and conduits documented; Level 3.5 DMZ terminates IT to OT sessions; SIS in its own zone	SL-T met per zone or gaps formally accepted; unidirectional gateways where justified
Remote and third-party access	Always-on vendor tools and shared VPN accounts	One DMZ broker: named accounts, MFA, approval windows, recording	Just-in-time access tied to work orders, with automatic expiry
OT identity and accounts	Default passwords, shared HMI and engineering logins, OT domain trusting IT	Defaults changed at commissioning; separate OT domain; service accounts owned	Individual authentication for critical operator actions; service credentials vaulted and rotated where vendors allow
Vulnerability and patch management	Patches applied when a vendor engineer visits	Advisories triaged against inventory; patches aligned to outages; compensating controls documented	Exposure-based prioritisation with tracked time to mitigate
Monitoring and detection	No OT visibility; firewall logs unread	Passive protocol-aware monitoring at key conduits; OT playbooks in the SOC	Detections tuned to ATT&CK for ICS; OT threat hunting
Configuration and logic integrity	No known-good copy of PLC logic or HMI images	Offline backups of logic, firmware and HMI images; changes matched to tickets	Running logic compared automatically with approved baselines
Incident response and recovery	IT plan only; nobody knows who can order a shutdown	OT incident plan; authority for manual operation and isolation defined; exercised with operators	Timed drills; each site can run isolated from IT for a defined period
Supply chain and workforce	Contracts silent on security; no OT training	62443-2-4 terms in service contracts; role-based OT training	4-1 and 4-2 evidence required at procurement; suppliers in exercises

The domains cover the C2M2 domain set (ASSET, ARCHITECTURE, PROGRAM, RESPONSE, ACCESS, RISK, SITUATION, THIRD-PARTIES, THREAT, WORKFORCE) and the joint government Principles of operational technology cyber security (2024), which give two tests worth applying: "a more critical environment should never be administered from a less critical environment" and "Critical OT systems should not be reliant on IT systems to operate."

Where identity fits

Identity decides who crosses a conduit. MITRE ATT&CK for ICS (v20) records the patterns: T1694.001 Default Credentials, with procedure examples including the Unitronics Defacement Campaign (C0031) and the 2026 U.S. Water Utilities Attacks (C0066); T0859 Valid Accounts, used in the 2015 Ukraine electric power attack over VPN and by Triton's operators through RDP jump boxes; T0822 External Remote Services; and T0883 Internet Accessible Device.

Level 2 to 3: change default passwords, broker vendor access through one DMZ path and disable accounts when contracts end; CISA lists both among five primary OT mitigations.
Level 3 to 4: give every historian, OPC, SCADA and backup service account an owner, remove interactive logon and separate operator, engineer and administrator roles.
Level 4 to 5: just-in-time engineering access, vaulted device credentials and certificate lifecycle management for OPC UA machine identities.

The Colonial Pipeline ransomware attack began with one unused VPN account. See the OT and ICS Identity and Access Guide, the Remote Access Identity Guide and the Service Account Security Guide. Bulk electric system entities should map this domain to CIP-005 and CIP-007; see the NERC CIP Guide.

Scoring method and evidence

Score per site: list each site's zones, from the DMZ down to safety systems, and score every domain per site before rolling up.
Apply a cumulative rule: as C2M2 puts it, "To earn a MIL in a given domain, an organization must perform all practices in that level and in the preceding level."
Require evidence: a policy alone scores Level 2 at most.
Set a target profile: C2M2 notes that "Establishing a target MIL for each domain is an effective strategy for using the model." Aim for Level 4 in remote access and segmentation at high-consequence sites, Level 3 elsewhere.
Report the weakest link: a site's level is its lowest score among the domains a likely attack path depends on, usually remote access, identity, segmentation and recovery.

Assess with operations and engineering, and never actively scan Level 1 and 2 devices for evidence. CISA's Cyber Security Evaluation Tool (CSET) desktop tool gives a repeatable baseline. For inventory method, see the OT Asset Visibility Guide.

Self-assessment questions

Exposure: when did you last confirm that no PLC, HMI or RTU at any site is internet-reachable, and how?
Inventory: could you list within a day every controller running a firmware version named in a new ICS advisory, with zone and owner?
Segmentation: does any path from corporate IT to Level 2 bypass the DMZ, including dual-homed hosts and historian links?
Remote access: how many ways can a vendor connect, and is every session tied to a named person, MFA, an approval and a recording?
Accounts: how many default, shared or ownerless accounts remain in OT zones, including service accounts?
Integrity and response: when did you last restore a controller from offline backup, and who can order manual operation at 3am?

Moving up a level

Size changes the route, not the target. A small utility reaches Level 3 through the CPGs, often with an integrator held to written terms. A large operator needs a reference zone model, an SL-T library per asset type, central OT monitoring and 62443-2-4 terms in every service contract. See the Top 10 OT Security Risks for where to look first.

From Ad hoc to Developing

Name an OT security owner and a contact at each site, with operations as co-owner.
Remove internet exposure (CPG 2.X Limit OT Connections to Public Internet) and change default passwords (CPG 2.A) on every controller and HMI.
Back up controller logic, firmware and HMI configurations offline.

From Developing to Defined

Build a passive inventory from SPAN ports or taps (CPG 1.A Asset Inventory); use vendor-approved active queries only in maintenance windows.
Document zones and conduits and build the Level 3.5 DMZ. Run new conduit rules log-only through a full production cycle, enforce one zone at a time in a planned outage with an engineer on site, and keep the previous rule set ready to restore. See the Network Segmentation Guide.
Consolidate remote access onto one broker with phishing-resistant MFA (CPG 2.H), approval and recording; pilot with one site and one vendor before closing old paths. See the Third-Party Access Guide.
Write and exercise an OT incident plan with authority for manual operation and isolation. See the OT Incident Response Guide.
Start OT security training for engineers and operators (CPG 2.J).

From Defined to Managed

Run a 62443-3-2 risk assessment for the highest-consequence area and set SL-T per zone and conduit.
Send OT detections to the SOC, alerting on program downloads, mode changes, firmware sessions (T1693 Modify Firmware) and unexpected writes (T1692.001 Command Message). See the OT Security Platform Buyer's Guide.
Review conduit rules, OT accounts and vendor access quarterly with named approvers.
Time recovery drills: restore a controller and an HMI and run a unit manually; CISA's primary mitigations call manual operation capability "vital" and say fail-safe and backup arrangements "should all be routinely tested".

From Managed to Optimised

Apply consequence-based engineering so safety in the worst scenarios does not depend on a network control.
Compare running logic and firmware with approved baselines automatically.
Require 4-2 capability and 4-1 processes at every refresh, and bring suppliers into exercises.

Framework mapping

NHI Mgmt Group's own mapping for orientation, not an official crosswalk.

Domain	C2M2	CISA CPG	IEC 62443	NIST CSF 2.0	NCSC CAF
Governance and ownership	PROGRAM, RISK	1.C	2-1	GV.RR	A1, A2
Asset inventory	ASSET	1.A	SR 7.8	ID.AM	A3
Architecture and segmentation	ARCHITECTURE	2.F, 2.X	3-2, FR5	PR.IR	B4, B5
Remote and third-party access	ACCESS, THIRD-PARTIES	2.H	SR 1.13, 2-4	PR.AA	B2, A4
OT identity and accounts	ACCESS	2.A, 2.H	FR1, FR2	PR.AA	B2
Vulnerability and patch	THREAT	1.E	2-3	ID.RA, PR.PS	B4
Monitoring and detection	SITUATION	2.T	FR6	DE.CM	C1, C2
Configuration and logic integrity	ASSET	2.R	FR3, SR 7.3	PR.PS	B4
Incident response and recovery	RESPONSE	2.S	FR7, SR 7.4	RS.MA, RC.RP	D1, D2
Supply chain and workforce	THIRD-PARTIES, WORKFORCE	2.J	2-4, 4-1, 4-2	GV.SC, PR.AT	A4, B6

NIST SP 800-82 Rev. 3 provides an OT overlay for SP 800-53 Rev. 5; a Rev. 4 draft is open for comment until 30 November 2026.

Metrics that show maturity

Exposure: internet-reachable OT devices and direct IT to OT flows (target: zero).
Inventory coverage: percentage of OT assets with firmware, zone, owner and criticality recorded.
Brokered access: percentage of remote sessions with a named account, MFA and recording.
Credential hygiene: default, shared or ownerless accounts remaining in OT zones.
Change integrity: percentage of logic and firmware changes matched to an approved ticket.
Recovery readiness: exercised time to restore a critical controller, and hours each site can run isolated from IT.

Common failure patterns

Averaging across sites: a group Level 3 that conceals a site with exposed PLCs and default passwords, the gap behind the Unitronics campaign and the 2026 water utility attacks.
Confusing a certificate with maturity: an SL 2 capable controller deployed with defaults, or a supplier's ML claim accepted without asking which requirements it covers.
Scoring policy, not practice: a remote access standard exists while engineers keep a separate vendor tool for emergencies.
Untested IT dependence: OT segmented on paper but reliant on IT authentication, backups or business systems. Colonial Pipeline halted its pipeline as a precaution after ransomware reached only its IT systems.

Practitioner checklist

Score all ten domains per site with evidence, jointly with operations.
Pick one system of record (C2M2, CAF, 62443 or CPGs) and map this model to it.
Target Level 3 in 12 months, with Level 4 for remote access and segmentation at high-consequence sites.
Confirm monthly that no OT device is internet-reachable and no default password remains.
Route all vendor access through one broker and give every OT service account an owner.
Restore a controller from offline backup and drill manual operation at least yearly.
Baseline the six metrics, report quarterly and reassess annually.

OT Security Maturity Model