Legacy SNMP and Modbus to MQTT: a safe gateway boundary

A legacy-to-MQTT gateway should make existing observations usable without inventing a new control path. Its purpose is read, validate and map, normalize, assign quality and time, then publish. It does not prove that a returned protocol value is physical truth, and it does not authorize discovery scans, generic writes, or changes to a production device.

Start with the real equipment map

Build an as-found inventory before polling. Record device_id, owner, zone, interface, firmware, network address, OID or register-map revision, data type, unit, scale, offset, byte and word order, polling owner, and operational purpose. A drawing or spreadsheet can be stale; reconcile it with approved records and the installed device before treating an address as usable.

The map needs provenance. Say whether a value came directly from a field device, from a gateway cache, or from a derived calculation. A topic name cannot repair an unknown source. If a signal is not documented, leave it outside the first rollout rather than probing an estate broadly.

Treat SNMP as a managed interface

An SNMP OID has meaning only with its MIB and the device implementation. Poll documented scalar OIDs at a rate the device owner accepts, account for counters, and preserve the MIB revision in the mapping record. Do not assume that two products expose the same enterprise OID or counter behavior.

Use SNMPv3 USM rather than treating community strings as a security boundary. USM provides authentication and integrity choices, and privacy protection is used with authentication. Assign separate service identities, limit their views to required OIDs, protect credentials, and document the selected algorithms according to current device support. A response with valid authentication says that this managed interface replied; it does not establish sensor accuracy or process condition.

Treat Modbus as an application protocol

Modbus defines four object tables: coils, discrete inputs, input registers, and holding registers. Read and write are different operations with different authorization and process consequences. A function code, zero-based address convention, quantity, vendor map, scale, signedness, and endianness must all be known before a value is normalized.

There is no universal register map. A manual reference such as 40101 may be a presentation convention rather than the wire offset a client needs. Do not use trial writes or broad unit scans to resolve ambiguity. Start with approved read-only points and a vendor-documented function. A structurally valid response can still contain an implausible scale, stale device data, or the wrong word order.

Normalize after validation

Use the fixed pipeline: read → validate/map → normalize → quality/time → publish. Validate response shape, function, byte count, expected type, configured range, and source identity before conversion. Normalize units and representations in one owned transformation, not in several downstream dashboards.

A compact published record can look like this:

{
  "device_id": "boiler-07",
  "protocol": "modbus-tcp",
  "address": "holding:100",
  "value": 42.3,
  "unit": "Cel",
  "scale": 0.1,
  "quality": "valid",
  "measured_at": "2026-08-17T12:00:00Z",
  "received_at": "2026-08-17T12:00:01Z",
  "sequence": 1842
}

The MQTT topic and schema identify the governed contract, for example a device telemetry topic plus a versioned schema name. Keep protocol address in metadata rather than making a topic hierarchy depend on an undocumented vendor convention.

Publish quality and time honestly

At minimum distinguish valid, stale, timeout, out-of-range, bad mapping, device fault, and communication failure. These are not interchangeable. A valid protocol response is not physical truth: a transmitter can be failed, a cached value can be old, and a register can be mapped incorrectly while bytes still decode.

Keep measured_at separate from received_at. If the legacy device cannot supply source time, state that clearly and use gateway arrival time only as arrival time. Consumers must apply their own freshness rule; a successful MQTT delivery does not make an old measurement current.

Bound polling and recovery

Set per-device rate limits, request timeouts, concurrency limits, and reconnect backoff. Protect fragile serial converters and older management agents from polling storms. A timeout should yield timeout or communication-failure quality, not a repeated old good value presented as current.

Retry only bounded, idempotent reads. Reconnect does not justify replaying unsafe commands because this gateway should not own commands. Keep rejected mappings and parse failures in a bounded diagnostic path with reason and count, not an unlimited copy of payloads or secrets.

Zone the bridge

Place the collector in the approved OT zone or DMZ boundary, not as an unrestricted dual-homed shortcut. Use allowlists for destination addresses and ports, least-privilege identities, broker topic ACLs, TLS where supported, and managed credential rotation. NIST guidance frames these choices as part of OT architecture, not as a late application setting.

Keep management access, telemetry publication, and engineering work separate. A cloud consumer must not gain a route to Modbus writes or SNMP administration merely because it receives normalized data.

Roll out read-only and keep rollback ready

Begin with one documented read-only source during an approved window. Verify topic identity, schema, value conversion, quality transitions, timestamps, rate limits, and health indicators. Test a timeout, bad mapping, stale value, device fault, and reconnect in an isolated or authorized setting.

Baseline the gateway configuration, mapping revision, ACLs, credentials location, and previous data path before rollout. Rollback means stopping collection, restoring the prior approved configuration, and confirming that no write or broad scan was introduced. It does not mean deleting the evidence needed to diagnose the change.