SCADA protocols are communication standards used by supervisory control and data acquisition systems to exchange commands, telemetry and status data with industrial devices. They connect control servers, remote terminal units, programmable logic controllers and field equipment, often over serial links or IP networks, to manage monitoring and control in operational technology environments.
What SCADA Protocols Do
SCADA protocols define how supervisory control and data acquisition systems move commands, telemetry, alarms and status between control software and industrial assets. They sit at the communication layer of operational technology, where reliability, timing and deterministic behaviour matter as much as message content. In many environments, the protocol itself becomes part of the control surface.
Because these protocols connect control centres to remote terminal units, PLCs and field equipment, they are not just data transport. They are the mechanism through which operators observe process state and issue control actions, so weaknesses in protocol design or deployment can affect both visibility and physical process control.
Why SCADA Protocols Are Security Sensitive
Industrial protocols often inherited trust assumptions from closed networks and long device lifecycles. Many were designed before pervasive authentication, encryption and strong peer validation were routine, which means the protocol family can expose command injection, spoofing, replay, tampering or unauthorized control if the surrounding environment is weak.
That is why protocol choice and protocol mode matter. Even when a protocol is widely used, the question is whether it supports secure authentication, integrity protection and segmentation in the way the deployment needs. For operational technology environments, NIST SP 800-82 Rev 3, OT Security Guide remains a strong reference for understanding how protocol trust boundaries fit into broader ICS security architecture.
Common SCADA Protocol Families and Deployment Patterns
SCADA protocol is a broad label rather than one standard. In practice, organisations encounter legacy serial protocols, IP-based telecontrol protocols and vendor-specific variants, each with different assumptions about framing, addressing and session state. The security problem is often not the abstract protocol name, but how that protocol is exposed across serial links, routers, jump hosts and shared control networks.
This is also why inventory is essential. Teams need to know which protocol is in use, where it terminates, what assets speak it and whether it traverses segmented zones or routable IP paths. For protocol registries, port assignments and protocol parameters, IANA provides the authoritative reference point for many network identifiers, while industrial protocol-specific guidance helps interpret the practical security posture of common SCADA protocols.
How SCADA Protocols Should Be Secured and Monitored
Security usually depends on layering controls around the protocol rather than trusting the protocol alone. That means restricting who can reach control endpoints, using allowlists for master station communications, segmenting operational zones, and preferring secure variants or authenticated wrappers where the protocol supports them. Monitoring is equally important because unusual write commands, out-of-window polling, malformed frames or new peer relationships can indicate misuse.
Operational teams also need a protocol-specific detection strategy. Deep packet inspection, command baselining and alerting on unapproved function codes or unexpected station identities can reveal abuse that ordinary network monitoring misses. For a practical protocol-by-protocol view, the Industrial Protocol Security Guide and IEC 60870-5-104 Telecontrol Security Guide show how these controls are applied to real OT protocol deployments.
Why SCADA Protocol Choices Affect Recovery and Resilience
Protocol design influences more than confidentiality and integrity. It also affects failover behaviour, operator response, recoverability after disruption and the blast radius of a compromised control channel. In OT, a loss of trustworthy protocol communication can stop monitoring, block safe control actions or force manual fallback procedures that are slower and more error-prone.
For that reason, resilience planning should include protocol dependencies in the same way it includes controllers, historians and remote access paths. A mature OT programme treats the protocol layer as a critical dependency, not an implementation detail, and validates whether control communications still behave safely when links are degraded, peers are unreachable or traffic must be rerouted through compensating controls.
Risk and Threat Considerations
SCADA protocols are attractive to attackers because they can turn network access into process influence. If a protocol lacks strong authentication or message integrity, an adversary who reaches the control plane may be able to spoof a trusted peer, replay commands or alter telemetry in ways that are difficult to distinguish from legitimate operator activity.
Failure mechanism: Weak protocol trust assumptions, flat network exposure or unsupported secure modes can allow unauthorized command execution, false data injection or denial of control visibility.
Impact: The result can be unsafe process behaviour, operational disruption, poor operator decisions and broader compromise of industrial availability or integrity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | SCADA protocols rely on segmented trust boundaries and restricted control-plane paths. |
| IA-2 — Identification and Authentication (Organizational Users) | Operators and control users need strong authentication before issuing protocol commands. | |
| AU-2 — Event Logging | SCADA protocol monitoring depends on logging protocol activity and control actions. | |
| Recommendation — Enforce network boundaries and allowlists around SCADA protocol flows. Require authenticated operator access before any SCADA control action. Log protocol events, command attempts and peer changes for review. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Industrial protocol exposure is governed by network architecture, segmentation and controlled paths. |
| CIS-8 — Audit Log Management | Protocol abuse is often found through command and session logging in OT networks. | |
| Recommendation — Segment SCADA protocol traffic and remove unnecessary exposure paths. Centralize and review SCADA protocol logs for anomalous commands. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | SCADA protocols require controlled network communications and protected zones. |
| A.8.15 — Logging | Industrial protocol monitoring depends on traceable logs of control and telemetry activity. | |
| A.8.22 — Segregation of networks | OT protocol safety depends on separating control networks from less trusted networks. | |
| Recommendation — Protect SCADA communications with network security controls and restricted routes. Record protocol activity needed to detect misuse and support investigations. Separate SCADA protocol networks from enterprise and untrusted zones. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Least-Privilege Network Access | Zero Trust directly supports limiting trust in industrial protocol connectivity. |
| Recommendation — Grant SCADA protocol access only to explicitly authorized connections. | ||
Practitioner Guidance
Why practitioners should care: SCADA protocol security is rarely solved by the protocol spec alone. The operational decision is whether the protocol is confined to a trust boundary that matches its capabilities, or whether it is being asked to operate safely in an environment that exceeds its original design assumptions.
What to watch for: Treat any unauthenticated peer, unexpected master station, legacy cleartext link or unrestricted routing path as a sign that the protocol stack needs review. In OT, protocol behaviour and network placement should be assessed together, because either one can undermine the other.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org