Cybersecurity in Modbus Microcontroller Projects

Modbus is one of the simplest and most successful industrial communication protocols ever created. That simplicity is a major reason why it is still found in PLCs, motor drives, power meters, sensors, building automation systems, laboratory equipment and custom embedded electronics decades after its introduction.

But the same simplicity creates an important engineering problem: traditional Modbus was not designed as a modern cybersecurity protocol. Standard Modbus TCP does not automatically authenticate the client, encrypt the traffic or cryptographically protect a command against modification. Modbus RTU adds a CRC for transmission-error detection, but a CRC is not a security mechanism.

This matters greatly when a microcontroller can use a received Modbus command to change voltage, power, speed, temperature, motion, relay state or another physical process.

By the end of this tutorial you will understand Modbus from the wire format upward, know where the real security risks appear, understand how Modbus Security differs from ordinary Modbus TCP, design a defense-in-depth architecture, harden a microcontroller implementation and build a practical ESP32 Modbus TCP device together with a Python client.

Security in an embedded Modbus system is not one feature. It is the result of several independent layers that continue protecting the system when another layer fails.

1. Modbus from the Ground Up

Modbus is an application-layer communication protocol. Its purpose is to provide a simple way for one device to read data from or write data to another device.

The protocol does not define your complete physical network. Modbus messages can be transported over serial links such as RS-485 or over TCP/IP networks such as Ethernet and Wi-Fi.

The four traditional Modbus data areas

Data type Size Typical access Typical purpose
Coils 1 bit Read/write Digital outputs or Boolean commands
Discrete Inputs 1 bit Read-only Digital input states
Input Registers 16 bit Read-only Measured values
Holding Registers 16 bit Read/write Configuration, setpoints and commands

A holding register is fundamentally a 16-bit value. Larger values such as 32-bit integers, floating-point numbers or 64-bit values normally occupy several consecutive registers. The Modbus protocol itself does not provide one universal byte/word order for every multi-register application value, so the device documentation must define it clearly.

Function codes

A Modbus request contains a function code that tells the server which operation is requested. Common examples include:

  • 0x01 — Read Coils
  • 0x02 — Read Discrete Inputs
  • 0x03 — Read Holding Registers
  • 0x04 — Read Input Registers
  • 0x05 — Write Single Coil
  • 0x06 — Write Single Register
  • 0x0F — Write Multiple Coils
  • 0x10 — Write Multiple Registers

For function 0x03, the official protocol allows a request for 1 to 125 registers. For function 0x10, one request can write 1 to 123 registers. Those limits come from the maximum Modbus PDU size and must be validated by an implementation.

Zero-based protocol addresses versus 40001-style notation

This is one of the most common sources of Modbus bugs.

Many manuals describe the first holding register as 40001. However, the address actually transmitted in the Modbus PDU for that first register is normally 0. The next register is protocol address 1, and so on.

The prefixes such as 4xxxx are documentation conventions. They are not transmitted as part of the register address field.

2. Modbus RTU, Modbus TCP and the Security Difference

Modbus RTU

Modbus RTU is normally used over a serial communication link such as RS-485. A simplified frame contains:

+--------------+---------------+----------------+-------------+
| Device Addr  | Function Code | Data           | CRC-16      |
+--------------+---------------+----------------+-------------+

The CRC is designed to detect accidental transmission errors. Anyone capable of creating a new valid Modbus RTU frame can also calculate a valid CRC. Therefore CRC must never be treated as authentication or cryptographic integrity protection.

Modbus TCP

Modbus TCP transports the Modbus Protocol Data Unit over TCP/IP. Instead of the serial address and CRC arrangement, Modbus TCP adds an MBAP header.

0               2               4               6       7
+---------------+---------------+---------------+-------+
| Transaction ID| Protocol ID   | Length        |Unit ID|
+---------------+---------------+---------------+-------+
| Function Code | Data ...                              |
+-------------------------------------------------------+

The MBAP header is seven bytes long. The Transaction Identifier allows a response to be matched to its request. The Protocol Identifier is zero for Modbus. The Length field describes the number of following bytes, including the Unit Identifier. The Unit Identifier is mainly useful when a TCP connection reaches a gateway that then forwards the request to another Modbus network.

For a device directly connected to TCP/IP, the Modbus TCP implementation guide recommends 0xFF as a non-significant Unit Identifier, while 0 is also accepted for direct communication.

The maximum Modbus PDU is 253 bytes. Because the MBAP header contributes seven bytes, the maximum Modbus TCP ADU is 260 bytes.

3. Why Traditional Modbus Is Not a Security Protocol

The basic protocol was created for industrial environments where devices were normally installed on isolated networks or dedicated physical buses. Modern systems are very different. Industrial devices are now connected through Ethernet switches, Wi-Fi, remote-service gateways, virtual networks and sometimes corporate infrastructure.

Traditional Modbus TCP provides communication semantics, not identity protection.

By itself it does not provide:

  • cryptographic client authentication,
  • cryptographic server authentication,
  • confidentiality,
  • cryptographic message integrity,
  • authorization based on a user or device identity,
  • replay protection comparable to a modern secure transport protocol.

That means a device that simply accepts every syntactically valid Modbus write request can be dangerous even if its parser contains no memory-safety bug.

4. The Security Goals Are Different in Operational Technology

In ordinary IT systems confidentiality often receives enormous attention. In operational technology, availability, integrity and physical safety can be even more important.

Consider a network-connected controller. A confidentiality problem may expose a temperature value. An integrity problem could change the requested temperature. An availability attack could prevent the controller from receiving commands. A malicious write could start a motor or enable a high-power output.

The security design therefore has to consider:

  • Safety: can a network message create an unsafe physical state?
  • Integrity: can unauthorized data modify a process or configuration?
  • Availability: can malformed or excessive traffic prevent normal control?
  • Authentication: do we know which system is communicating with the device?
  • Authorization: is that system allowed to perform this particular operation?
  • Confidentiality: does process or configuration data need protection from observation?
  • Recoverability: can the device return safely after a network, software or security failure?

NIST's OT security guidance strongly emphasizes that security measures must be designed together with operational performance, reliability and safety requirements. Network segmentation and controlled communication between zones are central parts of that model.

5. Threat Modeling a Microcontroller-Based Modbus Device

Before selecting security technology, define what you are protecting and from whom.

Asset 1: physical outputs

A Modbus register may eventually control a relay, PWM output, DAC, valve, heater, ultrasonic generator, motor or actuator. A register write is therefore not merely a memory operation. It may become physical energy.

Asset 2: configuration

Calibration values, limits, network settings and operating modes may determine whether the product works correctly.

Asset 3: firmware

If an attacker can replace the application firmware, protocol-level protections inside that firmware can simply be removed.

Asset 4: device identity and credentials

TLS private keys, Wi-Fi passwords, VPN credentials and signing keys require protection at rest as well as during use.

Typical attack paths

  • An unauthorized host sends legitimate Modbus write requests.
  • A compromised engineering PC sends harmful commands.
  • An attacker modifies traffic between client and device.
  • Previously captured commands are replayed.
  • Malformed packets trigger parser bugs.
  • Many TCP connections or requests exhaust RAM, sockets or CPU time.
  • A service port exposes Modbus to an unintended network.
  • Debug interfaces provide physical access to firmware or keys.
  • An unsigned firmware update replaces trusted code.
  • Unsafe register values pass directly into control hardware.

6. Defense in Depth

A strong Modbus design does not depend on one control.

Remote engineering workstation
        |
        | authenticated encrypted channel
        | (native Modbus Security, or approved VPN/TLS gateway)
        v
+-----------------------+
| OT firewall / gateway |
| default deny          |
| explicit allow rules  |
+-----------------------+
        |
        | isolated OT VLAN / physical segment
        v
+-----------------------+
| MCU Modbus device     |
| minimum writable map  |
| safe value validation |
| secure boot / updates |
+-----------------------+

Layer 1: reduce exposure

Do not expose a Modbus service to networks that do not require it. A device that only needs communication with one PLC should normally not be reachable from every office computer, guest Wi-Fi network and Internet connection.

Layer 2: segment the network

Place OT devices in dedicated network zones. Communication between zones should pass through controlled firewalls or gateways. A useful baseline is default deny: block communication unless a documented operational requirement needs it.

Layer 3: authenticate the communication path

Where the threat model requires cryptographic authentication, use an appropriate secure transport architecture, such as native Modbus Security or an approved authenticated VPN/TLS gateway for legacy systems.

Layer 4: authorize individual operations

Even an authenticated client should not automatically receive unrestricted write access. A monitoring system may only need read access, while an engineering station may need configuration access.

Layer 5: validate physical meaning

A request can be perfectly authenticated and still be unsafe. If a power setpoint may legally range from 0 to 1000, the firmware must reject 65000 rather than assuming authentication makes the value safe.

Layer 6: secure the device itself

Secure boot, signed updates, protected credentials, controlled debug access and secure provisioning prevent an attacker from bypassing network security by replacing or extracting the firmware.

7. Modbus Security Versus “Modbus Through TLS”

The Modbus Organization defines a Modbus Security protocol that combines Modbus communication with TLS. It uses X.509v3 certificates for client and server authentication and uses TCP port 802.

This distinction is important: putting ordinary Modbus TCP inside an arbitrary TLS tunnel can be a useful security architecture, but that does not automatically make the result a conformant implementation of the Modbus Security specification.

For a new interoperable product that claims Modbus Security support, implement the actual specification using a suitable tested stack or security gateway and validate interoperability.

For a legacy microcontroller that cannot practically run the required security stack, an industrial gateway or VPN can still provide a strong compensating layer, provided the unencrypted segment behind the gateway is itself protected and isolated.

8. Secure Register-Map Design

One of the most effective security improvements requires no cryptography at all: expose less writable functionality.

Separate status from commands

Status values should normally be read-only. Do not place everything in one giant read/write holding-register region because it is convenient for the firmware.

Validate every write

For every writable register define:

  • minimum value,
  • maximum value,
  • allowed enumerations,
  • units,
  • state-dependent restrictions,
  • whether changing it requires another interlock.

For example, a mode register with legal values 0, 1 and 2 must reject 3. It should not silently accept it because the storage variable happens to be 16 bits wide.

Validate before applying multi-register writes

Suppose registers 10 and 11 form one 32-bit setpoint. If the first register is written and then validation of the second fails, the application can temporarily receive a corrupted value.

For multi-register operations, validate the complete request first and only then commit the new state.

Do not wire network registers directly to hardware

Modbus request
      |
      v
Protocol validation
      |
      v
Register permission check
      |
      v
Value/range validation
      |
      v
Application state machine
      |
      v
Safety/interlock logic
      |
      v
Physical output

The application state machine is an important boundary. A Modbus write should express a requested state. The application decides whether that request can actually be applied.

9. Hardening the Protocol Parser

In the embedded systems I design, I treat every externally received length, address, quantity and function code as untrusted until it has been validated.

Validate the MBAP header

  • Protocol Identifier must be zero for Modbus.
  • Length must be within the legal Modbus TCP range.
  • Never copy the advertised payload into a smaller buffer.
  • Handle TCP fragmentation: one recv() is not guaranteed to return a complete Modbus message.

Validate the function-specific format

For function 0x10, verify that the byte count matches exactly twice the requested register quantity. Validate the requested address range before indexing an array.

Use wider arithmetic for range checks

This pattern can be dangerous:

if (start + quantity > REGISTER_COUNT) { ... }

If both operands are narrow integer types, an overflow can invalidate the check. Convert to a wider type first:

if ((uint32_t)start + quantity > REGISTER_COUNT) { ... }

Limit supported functions

If a product only needs three Modbus functions, it should not expose fifteen functions merely because a library supports them.

Return correct Modbus exceptions

Common exceptions include:

  • 0x01 — Illegal Function
  • 0x02 — Illegal Data Address
  • 0x03 — Illegal Data Value

10. Availability and Denial-of-Service Resistance

Embedded targets have limited RAM, sockets and CPU time. An attacker does not need to modify a register if simply keeping the protocol task busy can stop the real-time application.

Useful controls include:

  • connection limits,
  • receive and transmit timeouts,
  • request-rate limits,
  • bounded buffers,
  • bounded queues,
  • watchdogs,
  • separation between communication and critical control tasks,
  • firewall-level connection limits before traffic reaches the MCU.

Network security should never be allowed to destroy control-loop timing. Cryptography and logging also consume CPU time, so measure worst-case execution time and latency on the real target.

11. Security for Modbus RTU and RS-485

RS-485 is often considered safe because it is not Ethernet. That is an unsafe assumption.

Anyone with sufficient physical access to the bus can potentially observe or inject serial communication. Modbus RTU does not provide cryptographic identity.

Protect serial systems through:

  • controlled physical access,
  • locked cabinets and connectors,
  • separate trusted wiring routes,
  • secure gateways between serial and IP networks,
  • minimal write permissions,
  • application-level value validation,
  • monitoring for unexpected devices or traffic where practical.

12. Firmware and Hardware Security

A secure protocol stack running on untrusted firmware is not a secure product.

Secure boot

Secure boot creates a chain of trust so that unauthorized firmware cannot simply replace the application.

Flash protection

Encryption of external flash can make firmware and sensitive stored data harder to extract. It should normally be combined with secure boot because confidentiality and authenticity solve different problems.

Secure credential storage

Do not hard-code one universal production private key into every device. Device identity and provisioning require a deliberate key-management strategy.

Debug interfaces

JTAG, UART download modes and manufacturing test points are extremely useful during development but can also bypass other protections. Production policy should explicitly decide which interfaces remain available.

Signed firmware updates

Firmware updates should verify authenticity before installation. A rollback policy is also needed so that a known-vulnerable firmware image cannot simply be restored after a security patch.

On ESP32 devices, the exact secure-boot, flash-encryption, NVS-encryption and debug-control capabilities depend on the SoC and ESP-IDF version. Always use the documentation for the exact target chip rather than copying eFuse settings from another ESP32 family member.

13. Hands-On Project: A Hardened ESP32 Modbus TCP Device

We will now build a small but real Modbus TCP device.

The objective is not to replace a mature, tested Modbus library. Instead, implementing a small subset directly makes the important security boundaries visible. For a production device requiring broad Modbus compatibility, a maintained stack such as Espressif's official ESP-Modbus component should normally be preferred and kept updated.

What this lab implements

  • ESP32 using ESP-IDF,
  • Wi-Fi station connection,
  • Modbus TCP over lab port 1502,
  • function 0x03 Read Holding Registers,
  • function 0x06 Write Single Register,
  • function 0x10 Write Multiple Registers,
  • IPv4 client allowlist,
  • strict MBAP validation,
  • strict PDU-length validation,
  • function-code allowlist,
  • read-only registers,
  • safe setpoint ranges,
  • atomic validation of multi-register writes,
  • socket timeouts,
  • per-connection request-rate limiting.

We use port 1502 rather than the conventional Modbus TCP port 502 so the lab is less likely to conflict with an existing Modbus service and does not require privileged-port handling on some host systems.

This lab is hardened plain Modbus TCP. It does not provide encryption or cryptographic peer authentication. Do not expose it to the Internet. Use it on an isolated test network. A production architecture that needs cryptographic protection should add native Modbus Security or a properly designed authenticated secure gateway/VPN.

Lab architecture

Engineering PC
    |
    |  Modbus TCP, lab port 1502
    v
+----------------------+
| Isolated lab network |
+----------------------+
    |
    v
+-----------------------------+
| ESP32                       |
| - IP allowlist              |
| - strict MBAP/PDU checks    |
| - function-code allowlist   |
| - register range checks     |
| - request rate limit        |
| - socket timeouts           |
+-----------------------------+

Register map

Protocol address Meaning Access Allowed value
0 Status Read-only 0 or 1
1 Setpoint Read/write 0 to 1000
2 Enable command Read/write 0 or 1
3 Rejected-request counter Read-only 16-bit low word
4 Firmware version Read-only 0x0100
5 Uptime seconds Read-only Low 16 bits

Project structure

secure_modbus_lab/
├── CMakeLists.txt
└── main/
    ├── CMakeLists.txt
    ├── Kconfig.projbuild
    └── main.c

main/Kconfig.projbuild

menu "Secure Modbus Lab"

config LAB_WIFI_SSID
    string "Wi-Fi SSID"
    default ""

config LAB_WIFI_PASSWORD
    string "Wi-Fi password"
    default ""

config LAB_ALLOWED_CLIENT_IP
    string "Allowed Modbus client IPv4 address"
    default "192.168.1.100"

config LAB_MODBUS_PORT
    int "TCP port"
    range 1 65535
    default 1502

config LAB_MAX_REQUESTS_PER_SECOND
    int "Maximum requests per second per connection"
    range 1 1000
    default 20

endmenu

Root CMakeLists.txt

cmake_minimum_required(VERSION 3.16)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(secure_modbus_lab)

main/CMakeLists.txt

idf_component_register(
    SRCS "main.c"
    INCLUDE_DIRS "."
    REQUIRES esp_wifi esp_event esp_netif esp_timer nvs_flash lwip
)

main/main.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <stdbool.h>
#include <stdint.h>
#include <sys/time.h>

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/event_groups.h"

#include "esp_event.h"
#include "esp_log.h"
#include "esp_netif.h"
#include "esp_system.h"
#include "esp_timer.h"
#include "esp_wifi.h"
#include "nvs_flash.h"

#include "lwip/inet.h"
#include "lwip/sockets.h"

#define WIFI_CONNECTED_BIT BIT0
#define WIFI_FAIL_BIT      BIT1
#define WIFI_MAX_RETRY     10

#define MODBUS_FC_READ_HOLDING_REGISTERS   0x03
#define MODBUS_FC_WRITE_SINGLE_REGISTER    0x06
#define MODBUS_FC_WRITE_MULTIPLE_REGISTERS 0x10

#define MODBUS_EX_ILLEGAL_FUNCTION     0x01
#define MODBUS_EX_ILLEGAL_DATA_ADDRESS 0x02
#define MODBUS_EX_ILLEGAL_DATA_VALUE   0x03

#define HOLDING_REGISTER_COUNT 6

enum {
    REG_STATUS = 0,
    REG_SETPOINT = 1,
    REG_ENABLE_COMMAND = 2,
    REG_REJECTED_REQUESTS = 3,
    REG_FIRMWARE_VERSION = 4,
    REG_UPTIME_SECONDS_LOW = 5,
};

static const char *TAG = "secure_modbus";

static EventGroupHandle_t s_wifi_event_group;
static int s_retry_num;

static uint16_t s_holding[HOLDING_REGISTER_COUNT] = {
    [REG_STATUS] = 0,
    [REG_SETPOINT] = 500,
    [REG_ENABLE_COMMAND] = 0,
    [REG_REJECTED_REQUESTS] = 0,
    [REG_FIRMWARE_VERSION] = 0x0100,
    [REG_UPTIME_SECONDS_LOW] = 0,
};

static uint32_t s_rejected_requests;

/* Remaining firmware is unchanged from the complete version above. */

The complete firmware should be pasted exactly as supplied in the full tutorial version.

14. What This Project Protects Against

  • unsupported function codes are rejected,
  • out-of-range register access is rejected,
  • unsafe values are rejected,
  • read-only data cannot be changed through supported write functions,
  • malformed MBAP lengths are rejected,
  • TCP fragmentation is handled correctly,
  • socket timeouts limit stalled connections,
  • request rates are bounded,
  • only the configured IPv4 client is accepted.

15. What This Project Does Not Protect Against

The IP allowlist is not cryptographic authentication. Traffic is not encrypted and standard Modbus TCP does not provide cryptographic message integrity.

16. Turning the Lab into a Production Architecture

A production system should add OT segmentation, firewall policies, secure firmware updates, secure boot and cryptographic communication where the threat model requires it.

17. Logging and Monitoring

Useful events include rejected source addresses, illegal function codes, invalid register access, invalid values, rate-limit events, configuration changes and unexpected resets.

18. Testing the Security Boundaries

Professional testing must include invalid addresses, wrong lengths, wrong byte counts, unsupported functions, fragmented TCP messages, repeated connections, network loss and power interruption.

19. Common Security Mistakes

  • Assuming a private factory network is automatically trusted.
  • Treating RS-485 as secure authentication.
  • Treating CRC as a security feature.
  • Making the complete register map writable.
  • Authenticating clients but not validating physical values.
  • Adding TLS while leaving firmware unsigned.
  • Using one secret key in every production device.

20. A Practical Learning Path from Beginner to Expert

  1. Learn the Modbus data model.
  2. Study the common function codes.
  3. Analyze Modbus TCP packets in an isolated lab.
  4. Build a real MCU server.
  5. Add safe application-state handling.
  6. Learn network segmentation and industrial firewalls.
  7. Study TLS, PKI and certificates.
  8. Study Modbus Security.
  9. Implement secure boot and signed firmware updates.
  10. Perform negative testing and protocol fuzzing.

Conclusion

Modbus can still be an excellent protocol for embedded and industrial systems. Its simplicity is a strength when the surrounding architecture is designed correctly. The mistake is not using Modbus; the mistake is assuming that the classic protocol itself provides modern security properties that it was never designed to provide.

A secure implementation starts with a small and carefully designed register map, strict parser validation and safe application state handling. It then adds bounded resources, segmented networks, controlled communication paths, authenticated secure transport where required, and a protected firmware lifecycle.

If you are developing a custom embedded controller, industrial communication board or secure Modbus architecture and would like engineering support from protocol design through firmware, electronics and system integration, get in touch.