Key takeaways
- Modbus was created by Modicon (now part of Schneider Electric) in 1979 as a simple, open, royalty-free way for a master device to poll and command PLCs over a serial line.
- CISA's advisory ICSA-17-101-01, covering the Schneider Electric Modicon Modbus protocol and published 11 April 2017, turns the abstract "no authentication" problem into two concrete, scored vulnerabilities.
- What this guide could not independently confirm is how broadly either specification has actually been implemented in deployed field devices.
- Assume every Modbus link you operate has zero built-in security, because it almost certainly does.
Modbus is the most widely deployed industrial protocol in the world, and it has no built-in authentication, no encryption, and no message-integrity check — a fact that was true of Modicon's original 1979 design and remains true of the Modbus Application Protocol specification the Modbus Organization publishes today. That gap is not a secret or a recent discovery: it is a documented, CVE-numbered finding in CISA's ICS advisory archive, and it is the reason every credible piece of Modbus security guidance, from CISA to NIST to the Modbus Organization's own add-on security specification, starts from the same premise — the protocol cannot protect itself, so something else has to.
A sourcing note: the Modbus Organization's own Modbus Security Protocol PDF (hosted under its "secure" file path) and CISA's and NIST's primary PDFs on ICS network defense could not be fully confirmed as extractable text by this guide's fetch tooling. Facts attributed to those documents below are drawn from the Modbus Organization's own HTML specifications index (fetched directly), CISA's HTML advisory page (fetched directly), and cross-checked secondary technical reporting. Confirm exact clause wording against the primary specifications linked above before citing this guide as authoritative on any single requirement.
Why Modbus has no security, by design
Modbus was created by Modicon (now part of Schneider Electric) in 1979 as a simple, open, royalty-free way for a master device to poll and command PLCs over a serial line. It succeeded for exactly the reasons that later became security liabilities: it is small, easy to implement on constrained hardware, and vendor-neutral, which is why it spread across decades of industrial equipment from dozens of manufacturers and is still the default protocol on a large share of installed PLCs, RTUs, sensors and gateways today. Nothing in the base Modbus Application Protocol specification — maintained since 2004 by the vendor-independent Modbus Organization — includes a field for a credential, a session key, or a signature. A Modbus server that receives a well-formed request simply executes it. There is no concept of "who is asking."
What that gap actually costs: a documented example
CISA's advisory ICSA-17-101-01, covering the Schneider Electric Modicon Modbus protocol and published 11 April 2017, turns the abstract "no authentication" problem into two concrete, scored vulnerabilities. CVE-2017-6034 (CVSS v3.0 base score 10.0, CWE-294, Authentication Bypass by Capture-Replay) covers the finding that "sensitive information is transmitted in cleartext in the Modicon Modbus protocol, which may allow an attacker to replay the following commands: run, stop, upload, and download" — an attacker positioned to observe traffic does not need to break anything, only capture a legitimate command once and replay it. CVE-2017-6032 (CVSS v3.0 base score 5.3, CWE-657, Violation of Secure Design Principles) covers a related finding that "the Modicon Modbus protocol has a session-related weakness making it susceptible to brute-force attacks." Both findings describe the protocol's own structure rather than a single implementation bug, which is why variations on the same class of finding — unauthenticated function-code execution, replayable commands, hijackable sessions — recur across Modbus-speaking products from multiple vendors in CISA's advisory archive, not just this one.
The compensating-control model: what CISA and NIST actually recommend
NIST SP 800-82 Revision 3, "Guide to Operational Technology (OT) Security" (September 2023), treats the absence of authentication and integrity protection in legacy field protocols like Modbus as a structural characteristic of OT environments to be managed at the network and architecture layer, not a defect to wait on a protocol revision to fix. CISA's long-standing ICS recommended practices point at the same handful of controls, repeated across its advisory guidance and defense-in-depth material:
| Control | What it does for Modbus specifically |
|---|---|
| Minimize network exposure | Modbus TCP (port 502) should never be directly reachable from the internet; CISA's recommended practice treats internet-facing control-system devices as a baseline failure, not an edge case |
| Segment and firewall | Keep Modbus traffic inside the control network, behind an industrial DMZ — see the Purdue Model for OT/ICS network architecture for the segmentation pattern this implements |
| Restrict remote access | Vendor and contractor remote-access paths are a common route into otherwise segmented Modbus networks; treat every remote-access path as a specific, reviewed exception, not a standing connection |
| Filter by function code | A protocol-aware firewall or gateway can allow only the function codes a given link actually needs — read-only traffic where that's sufficient, with write functions like Write Single Coil and Write Single Register blocked unless a specific link requires them |
| Monitor for anomalies | OT-aware monitoring that understands Modbus function codes can flag replay patterns, unexpected write commands, or traffic from devices that have no business issuing them — compensating for the protocol's inability to flag any of this itself |
See NIST SP 800-82: OT Security for the fuller control framework these recommendations sit inside, and IEC 62443-3-3: system security requirements for how a zone's target security level translates these same ideas into testable technical requirements.
Modbus Security: the protocol-level fix that exists, but isn't universal
The Modbus Organization itself has published an answer to the authentication gap: the Modbus Security Protocol, most recently documented in version MB-TCP-Security v3.6 (dated 2021-07-30, updating an earlier v2.1 from 2018-07-24) per the organization's own specifications index. It works by wrapping a standard Modbus/TCP message inside a TLS session — a profile the specification calls MBAPS — running over TCP port 802 instead of the plaintext default, port 502. Per the Modbus Organization's own description, the protocol "provides protection through the blending of Transport Layer Security (TLS) with the traditional Modbus protocol," requiring TLS 1.2 or later and using X.509v3 digital certificates to authenticate both the client and the server to each other — closing exactly the gap CISA's ICSA-17-101-01 advisory describes. A separate, still-unfinished IETF Internet-Draft (draft-liu-iotops-modbus-seriallink-sec-spec) proposes an equivalent approach for serial-line Modbus, which has no TCP connection to wrap in TLS in the first place.
What this guide could not independently confirm is how broadly either specification has actually been implemented in deployed field devices. Treat a vendor's claim of "Modbus Security" or "secure Modbus" support as a claim to verify against that specific product's own documentation and firmware version — not something to assume because the specification exists, and not something most of an existing, multi-year-old installed base will ever receive as a retrofit.
A workable starting point
Assume every Modbus link you operate has zero built-in security, because it almost certainly doesDesign your network as if the protocol provides no authentication, encryption or integrity check at all — because, per its own specification, it doesn't. Segment before you do anything elseNo Modbus device should be reachable from the internet or directly from corporate IT; an industrial DMZ between the control network and everything else is the single highest-leverage control available. Filter by function code, not just by IP addressA protocol-aware firewall or gateway that only passes the function codes a given link genuinely needs — blocking writes it doesn't — stops a large share of the replay and unauthorized-command scenarios CISA's advisories describe. Check for Modbus Security support per device, not per vendorIf a device genuinely supports the TLS-based MBAPS profile, prefer it; if it doesn't — and most of an older installed base won't — the network-layer controls above are not optional. Monitor for what segmentation alone missesA passive, OT-aware capture that understands Modbus function codes can catch replayed commands and unauthorized writes that a firewall configured only on IP and port would let straight through.
Modbus's lack of built-in security is not a fixable bug in any one product; it is why CISA's Secure by Demand guidance for OT products pushes asset owners to ask vendors directly what authentication and segmentation support a product actually has, rather than assuming parity across the Modbus ecosystem. SoftWSP's OT Snapshot builds a passive, factual picture of which devices on a shop floor are actually speaking Modbus (and to whom) from a mirror port, without touching production traffic: see OT Snapshot.
This guide draws on CISA's published ICS advisory and recommended-practices material, the Modbus Organization's own specifications index, NIST's OT security guidance, and an IETF Internet-Draft, cross-checked against each other where a primary PDF could not be rendered as extractable text. This guide is not a substitute for the Modbus Organization's own specifications, CISA's or NIST's own publications, or an engineer's assessment of a specific network.
Sources
- CISA ICS Advisory ICSA-17-101-01: Schneider Electric Modicon Modbus Protocol (11 April 2017; CVE-2017-6034, CVE-2017-6032)
- Modbus Organization: Specifications and Implementation Guides (modbus-specifications index, incl. Modbus Security Protocol)
- Modbus Organization: Modbus Security Protocol specification, MB-TCP-Security v3.6 (2021-07-30), updating v2.1 (2018-07-24)
- IETF Internet-Draft: Modbus Serial Link Communication Security Protocol Specification (draft-liu-iotops-modbus-seriallink-sec-spec)
- NIST Special Publication 800-82 Revision 3, Guide to Operational Technology (OT) Security (September 2023)
- CISA: Recommended Practices (control systems network segmentation, defense-in-depth, minimizing network exposure)
Frequently asked questions
Does Modbus have any built-in security at all?
No. Modbus — in its original serial RTU/ASCII form and in Modbus TCP/IP — was designed in 1979 by Modicon as a simple request-response protocol for talking to PLCs, with no field for authentication, no encryption, and no message-integrity check anywhere in its application-layer specification. Any device that can reach a Modbus server over the network or serial line can issue any function code that server accepts — read a register, write a coil, stop a process — and the protocol itself has no way to tell whether that command came from an authorized engineering workstation or an attacker. This is not an oversight that was later patched into the base protocol; the standard Modbus Application Protocol specification published by the Modbus Organization is unchanged on this point, which is exactly why a separate add-on specification, Modbus Security, exists.
What does a real Modbus security failure actually look like?
CISA's advisory ICSA-17-101-01, covering the Schneider Electric Modicon Modbus protocol (published 11 April 2017), is a concrete, documented example. It assigns CVE-2017-6034 (CVSS v3.0 base score 10.0, CWE-294 Authentication Bypass by Capture-Replay) to the finding that "sensitive information is transmitted in cleartext in the Modicon Modbus protocol, which may allow an attacker to replay the following commands: run, stop, upload, and download" — meaning an attacker who can observe traffic can capture a legitimate command and replay it later to the same effect, with no credential needed. The same advisory assigns CVE-2017-6032 (CVSS v3.0 base score 5.3, CWE-657 Violation of Secure Design Principles) to a separate finding that "the Modicon Modbus protocol has a session-related weakness making it susceptible to brute-force attacks." Neither finding is a coding bug in one vendor's firmware; both describe the protocol's own design, which is why the same class of finding recurs across Modbus-speaking products from multiple vendors in CISA's advisory archive.
Is there a secure version of Modbus, and does anything actually use it?
Yes — the Modbus Organization publishes a Modbus Security Protocol specification (the most recent version this guide could confirm from the organization's own specifications index is MB-TCP-Security v3.6, dated 2021-07-30, updating an earlier v2.1 from 2018-07-24) that wraps a standard Modbus/TCP Application Data Unit inside a TLS session — a profile the spec calls MBAPS — running over TCP port 802 rather than the standard, unencrypted port 502. Per the Modbus Organization's own description, the protocol "provides protection through the blending of Transport Layer Security (TLS) with the traditional Modbus protocol," using TLS 1.2 or later and X.509v3 digital certificates for mutual authentication of client and server. A separate, still-unfinished IETF Internet-Draft (draft-liu-iotops-modbus-seriallink-sec-spec) proposes an equivalent for serial-line Modbus, which has no TCP/TLS transport to piggyback on. What this guide could not independently confirm is how widely either specification is actually implemented in deployed field devices — treat any vendor's claim of "Modbus Security support" as something to verify against that specific device's documentation, not as something you can assume.
If a device can't do Modbus Security, is there anything else that actually helps?
Yes, and for most of the installed base — where devices are years old and will never get a TLS-capable firmware update — this is the real security model, not a fallback. NIST SP 800-82 Revision 3 explicitly treats the lack of authentication and integrity protection in legacy field protocols like Modbus as a structural OT risk to be managed with compensating controls at the network and architecture layer, not something to wait on the protocol to fix. CISA's long-standing ICS recommended practices point at the same controls: minimize network exposure so Modbus devices and the systems that talk to them are never reachable from the internet, segment control networks behind firewalls and an industrial DMZ, restrict and monitor remote access, and — specific to Modbus itself — filter at the function-code level so a firewall or protocol-aware gateway only passes the function codes a given link actually needs (read-only where that's all that's required, with write functions such as Write Single Coil and Write Single Register blocked unless specifically justified).
In this cluster
