OTCOGNISHIELD / ENGINEERING GUIDE
Passive Modbus TCP monitoring for small factories
How to review Modbus write observations without mistaking a function code for an unauthorised change.
Published 4 November 2026 · OTCogniShield engineering notes
FOR BUSINESS LEADERS
Business value
Understand whether recorded factory communications fit the activity your team expects and has authorised.
What to ask
Ask engineering to compare the observation with approved access, maintenance timing and the relevant equipment context.
Important boundary
A protocol function code is a clue to review. It does not by itself prove an unauthorised change or its operational effect.
| Protocol | Modbus TCP |
|---|---|
| Useful observations | Endpoints, function code, address, quantity and response where decoded |
| Important boundary | A write request is not proof of an accepted or unauthorised process change |
Read the operation before deciding its meaning
The Modbus specification defines function 06 (0x06) as Write Single Register and function 16 (0x10) as Write Multiple Registers. A maintenance tool, supervisory application or legitimate control workflow may issue writes. The function identifies an operation; it does not identify who approved it.
Build an engineering review record
Preserve the timestamp and its time zone, source and destination, decoded operation, address and request/response relationship. Link the record to the capture source where that reference actually exists. Missing fields should remain missing, rather than being inferred from a nearby event.
Then compare the observed peer pair and operation with the approved communications register and maintenance window. Ask the device owner to confirm the register map, engineering units and applicable scaling. A raw register address alone cannot reliably be described as a temperature setpoint or safety limit.
What OTCogniShield currently establishes
The platform has passive observation and selected rule paths. Function code 6 alone is not an implemented unauthorised-write alert. Command-policy acceptance needs a controlled replay demonstrating expected traffic, a policy deviation, the resulting finding and its evidence. Site-specific approval and process interpretation remain human decisions.
Pilot acceptance questions
- Does the supplied capture include both relevant directions?
- Can the parser recover the agreed operation and address fields?
- Does approved traffic avoid the proposed warning?
- Can an operator export the reviewed record and recover it after restart?