IIoT Connectivity Checklist for Plant Engineers

This IIoT connectivity checklist collects the questions that decide whether a plant connection project goes live in a week or stalls for months. Work through it before the first gateway arrives and you will know exactly which firewall rules to request, which protocols you need to convert, how to name your data and which broker to connect to.

The checklist is grouped into six areas. Each item is something you can verify, not a vague principle, and several come with a command you can run today.

1. Scope and Ownership

Most stalled projects fail on people, not packets. Settle these before any hardware discussion.

1. Name one owner on the OT side and one on the IT side, each with authority to approve changes in their domain.
2. Write down the first use case in one sentence, for example "show live state and part count for the six CNC machines in cell 4."
3. List the machines in scope, their controllers and their physical locations.
4. Agree on what is out of scope for phase one. Writing to PLCs is the most common thing to postpone.
5. Define how you will measure success: data latency, completeness, and whether the people who asked for the data actually use it.

If those answers are fuzzy, our IIoT proof of concept plan gives you a 30-day structure to sharpen them.

2. Network Access Checklist

Your data needs a path from the machine to the broker. Map it hop by hop.

1. Identify the network zone of each machine and gateway: isolated cell network, plant OT network, DMZ or enterprise network.
2. Confirm whether the gateway will connect directly to the internet, through a DMZ broker, or through a proxy. Our guide to placing MQTT in an industrial DMZ compares these options.
3. Request outbound TCP 8883 (MQTT over TLS) to the broker hostname. Avoid plaintext 1883 across any zone boundary.
4. If browsers or web dashboards need live data, also request TCP 8084 (MQTT over secure WebSocket).
5. Confirm DNS resolution from the gateway's network.
6. Ask whether a TLS-inspecting proxy sits in the path. If yes, request an exception for the broker hostname.
7. Check the firewall idle timeout and set the MQTT keepalive below it.
8. Confirm the gateway can reach an NTP server. Wrong clocks break TLS validation and timestamps.

Verify the path from the gateway itself, not from your laptop:

# Linux gateway: DNS, TCP and TLS in one go
getent hosts broker.connectmq.com
openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null \
  | grep -E "subject=|issuer=|Verify return code"

# End-to-end MQTT test with a unique client ID and topic
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i gw-test-$RANDOM -t connectmq/demo/gw-test-$RANDOM/ping -m hello -d

On a Windows-based gateway or HMI PC, the quick equivalent is:

powershell -Command "Test-NetConnection broker.connectmq.com -Port 8883"

A Verify return code: 0 (ok) from OpenSSL and a CONNACK (0) from mosquitto_pub -d mean the network side is done.

3. Protocol and Data Source Checklist

Your machines speak whatever they were built with. Inventory it.

1. Record the protocol, IP address, and port or serial settings for each source.
2. Confirm read-only access is possible and get written approval from the controls owner.
3. Export the tag or register list and mark the tags you actually need. Twenty good tags beat two thousand unused ones.
4. Note polling limits. Some older controllers struggle when polled faster than once a second.
5. Decide whether the gateway will use plain MQTT with JSON or Sparkplug B. Both work; mixing them without a plan does not.

4. Data Modeling Checklist

Data that arrives with cryptic names is data nobody uses.

1. Choose a topic hierarchy, ideally aligned with ISA-95: enterprise, site, area, line, cell, and then the machine.
2. Write the naming rules down: lowercase, no spaces, hyphens or underscores, consistent units.
3. Define the payload format, for example {"value": 72.4, "unit": "C", "ts": "2026-10-16T08:00:00Z"}.
4. Decide which topics are retained (current state) and which are events (alarms, part completions).
5. Agree on report-by-exception rules: what change in value is worth a new message.
6. Reserve a separate subtree for gateway and device health: online status, last seen, firmware version.

The ISA-95 MQTT topics guide has worked examples you can adapt.

5. Security Checklist

1. Every client authenticates with its own username and password. No shared credentials across gateways.
2. TLS on every connection that crosses a zone boundary.
3. Gateways publish upward only in phase one. Any command path is explicitly designed and reviewed.
4. Credentials are stored on the gateway in a protected file, not hard-coded in scripts that end up in version control.
5. A last will message marks each gateway offline when it disconnects unexpectedly.
6. You have a process to revoke a credential when a gateway is replaced or stolen.
7. Nothing sensitive is ever published to a public test broker.

Treat these as minimums: a gateway that fails any of them should not be connected, even for a pilot.

6. Broker Selection Checklist

The broker is the hub everything else depends on. Check it against your plant's needs, not just a feature list.

1. Supports MQTT 3.1.1 and 5.0, so both older gateways and modern clients connect.
2. Offers TLS on 8883 and secure WebSocket for browser dashboards.
3. Handles your connection count and message sizes, with headroom for growth.
4. Supports QoS 1 at minimum, and QoS 2 if any consumer needs exactly-once delivery.
5. Supports retained messages and persistent sessions so state survives reconnects.
6. Understands industrial payloads such as Sparkplug B, or at least lets you inspect them.
7. Gives you visibility: who is connected, which topics are active, and alerts on thresholds.
8. Has a clear answer for who patches and monitors it. A self-hosted broker is one more server for the OT team to own.

For a deeper comparison, see how to choose an IoT MQTT broker and our guide to the cloud MQTT broker model. For how all of these pieces fit together in a plant, read the Industrial IoT with MQTT guide.

How ConnectMQ Fits the Checklist

ConnectMQ is a fully managed MQTT service designed with plant connections in mind. It supports MQTT 3.1.1 and 5.0 on TCP 1883, TLS 8883, WebSocket 8083 and secure WebSocket 8084, uses a Let's Encrypt certificate that standard CA stores already trust, and binds client IDs to issued credentials. It detects ISA-95 and Unified Namespace topics, decodes Sparkplug B payloads and can republish Sparkplug data into readable ISA-95 topics. The portal includes an in-browser MQTT client, a live topic explorer and threshold alert rules, which makes items in sections 4 and 6 easy to verify during commissioning.

Get Started with ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required. You will have credentials in minutes, so you can run the network tests in section 2 against your own ConnectMQ endpoint and tick off the first half of this checklist today.

Frequently Asked Questions

What ports does an IIoT gateway need to reach an MQTT broker?

Usually only outbound TCP 8883 for MQTT over TLS. Add TCP 8084 if browser dashboards connect over secure WebSocket. No inbound ports into the plant are required.

Who should own an IIoT connectivity project?

Both OT and IT. Name one owner on each side with authority to approve changes, because most delays come from unclear approvals rather than technical problems.

Should I use Sparkplug B or JSON for plant data?

Both work. Sparkplug B adds a strict session and state model that SCADA tools understand, while JSON with an ISA-95 topic tree is easier to read and integrate. Pick one per data source and document the choice.

How do I test connectivity before installing any gateway software?

Run DNS, OpenSSL and mosquitto_pub tests from a machine in the same network zone as the future gateway. If all three succeed against port 8883, the network path is ready.