Modbus Security for Industrial Control Systems
Modbus runs an enormous share of industrial equipment: PLCs, drives, meters, sensors. It was designed in 1979 for a trusted serial wire and carries no authentication or encryption at all. On a modern TCP network that becomes a serious exposure. Here is how a Modbus assessment goes and why writes are the real risk.
Why Modbus Is So Exposed
A Modbus device exposes coils and registers that map to physical inputs and outputs: a coil might be a pump relay, a register a setpoint. The protocol has no users, no passwords, and no encryption, so any host that can reach TCP 502 can read and write those values. On an OT network, that is direct control of equipment.
Step 1: Find and Read
Confirm the service, then poll the coils to see the current state of the process:

nmap -p 502 192.168.0.10 mbpoll -a 1 -t 0 -c 8 192.168.0.10
502/tcp open mbap -- Polling slave 1... [1]: 0 [2]: 1 [3]: 0 [4]: 1
Step 2: From Reading to Writing
Mapping a coil to a function is reconnaissance. Writing it is the impact. An unauthenticated write-coil request changes the physical output:
# turn coil 1 on
mbpoll -a 1 -t 0 -r 1 192.168.0.10 1
Written 1 reference.
That single request flipped a physical output with no authentication. On real equipment, that is the line between a security finding and a safety incident.
Three Modbus Realities
The protocol’s design assumptions no longer hold on a routed network:

Defending Modbus
You cannot add authentication to classic Modbus, so defend around it: segment OT from IT networks, put Modbus behind a firewall that allows only known masters, use a protocol-aware gateway to block write functions from untrusted sources, and monitor for unexpected writes. Modbus/TCP Security with TLS exists for new builds.
Where This Fits
Mapping Modbus registers and proving what an unauthenticated client can change is core to an industrial penetration test. That OT work is the kind of work we do at Berkner Tech.