Modbus is an industrial communication protocol used widely by PLCs and other OT devices for monitoring and control. It was not designed with modern authentication or encryption assumptions, so command integrity and network containment become critical compensating controls in operational environments.
Expanded Definition
Modbus is a legacy industrial communications protocol used by PLCs, RTUs, HMIs, and other OT devices to exchange commands and telemetry over serial links or TCP/IP. In NHI security, it matters because the protocol itself does not provide native authentication, encryption, or strong message integrity. That means the trust boundary shifts to the surrounding architecture: network segmentation, device allowlisting, protocol-aware monitoring, and controlled command issuance.
Definitions vary across vendors when Modbus is discussed as a “secure” protocol, but no single standard governs this yet in the way modern IT protocols often assume. For practitioners, the key distinction is between protocol function and security posture. Modbus can move operational data reliably while still leaving exposed attack paths if unauthorized clients can reach the network segment. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to secure assets and communications as part of a broader risk program, not as a property of the protocol itself.
The most common misapplication is treating Modbus traffic as trustworthy once it is inside the plant network, which occurs when flat OT segmentation is assumed to be sufficient control.
Examples and Use Cases
Implementing Modbus rigorously often introduces operational friction, requiring organisations to weigh visibility and control against latency, vendor compatibility, and maintenance constraints.
- A utility uses Modbus TCP to poll substation equipment, but only a dedicated engineering workstation is allowed to issue writes, reducing the chance of unauthorized setpoint changes.
- A manufacturing site places Modbus devices on isolated VLANs and uses firewall rules to permit only specific master addresses, limiting lateral movement from IT to OT zones.
- An integrator reviews command patterns from HMIs against maintenance windows and alerts on unexpected write requests, aligning with the defensive approach described in the Ultimate Guide to NHIs.
- A SOC correlates Modbus function codes with asset criticality so that reads are tolerated while writes to safety-relevant devices trigger immediate escalation.
- A plant migration project replaces ad hoc remote access with brokered access and strict session records, using NIST Cybersecurity Framework 2.0 principles to preserve operational continuity.
These patterns are common because Modbus often remains embedded in long-lived equipment where firmware change is impractical and downtime is expensive.
Why It Matters in NHI Security
Modbus is relevant to NHI security because many OT actions are initiated by software entities, gateways, scripts, historians, or service accounts that behave like non-human identities. When those identities can reach Modbus endpoints without strong containment, they can alter process states, not just read telemetry. NHI governance therefore has to account for who or what is permitted to send control messages, under what conditions, and with what monitoring.
NHI Mgmt Group notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, a strong reminder that OT protocols like Modbus cannot be left outside identity governance. The same logic applies to industrial control environments: access needs to be constrained, observable, and revocable, especially where commands may have physical consequences. The Ultimate Guide to NHIs is useful for framing that governance model, while NIST Cybersecurity Framework 2.0 provides the broader control lens for protecting assets and communications.
Organisations typically encounter the severity of Modbus risk only after an unauthorized write, process disruption, or incident review reveals that a benign-looking service account had direct control-plane reach, at which point Modbus becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 | Modbus risk hinges on limiting device and service access to approved communications paths. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero Trust requires explicit verification before software or users can issue OT commands. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Modbus often depends on service accounts and machine-issued commands that need containment. |
| CSA MAESTRO | Agentic systems controlling OT assets must be bounded to prevent unsafe command execution. | |
| NIST AI RMF | Operational AI systems affecting OT need risk treatment for unsafe or unauthorized actions. |
Inventory non-human actors that reach Modbus and constrain their privileges to the minimum.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
