IEC 62443 and MQTT: Securing Industrial Messaging with Zones and Conduits

IEC 62443 MQTT design is about placing an MQTT data flow inside the zone-and-conduit model that industrial security teams already use. This guide maps the main IEC 62443 concepts onto a typical architecture of PLCs, edge gateways and a cloud broker, so you can explain your design in the language your OT security reviewers expect. It is an engineering guide, not legal or certification advice: compliance is assessed for your system and organisation, not granted by a single product.

A Short Primer on IEC 62443

IEC 62443 is a series of standards for the security of industrial automation and control systems (IACS). It is written for several audiences: asset owners who operate plants, system integrators who build solutions, and product suppliers who make components. A few concepts matter most for messaging design:

• Zones: groups of assets with shared security requirements, such as a cell of PLCs or an enterprise IT network.
• Conduits: the communication paths between zones, with their own security requirements.
• Foundational requirements (FR): seven categories that structure the technical requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability.
• Security levels (SL): targets from SL 1 to SL 4 that describe how capable an attacker the zone or conduit must resist, from casual misuse to sophisticated, well-resourced attacks.
• Risk assessment: the process (described in part 3-2) that decides zones, conduits and target security levels.

Several parts are relevant to MQTT projects. Part 3-3 lists system security requirements, part 4-2 covers component requirements, and part 2-1 covers the asset owner's security programme.

Why MQTT Fits the Zone-and-Conduit Model

MQTT has a property that security architects like: clients always connect outward to the broker. A PLC gateway publishes to a broker; nothing needs to connect inbound to the plant. That makes the communication path easy to describe as a single conduit with a defined direction, protocol and port.

Compare this with polling protocols, where a central system reaches into the plant network to read values. Every poll is an inbound flow that has to be allowed through firewalls. With MQTT, the plant initiates and the firewall can stay closed inbound.

Mapping an MQTT Architecture to Zones and Conduits

A typical industrial MQTT architecture has four zones:

And three conduits:

1. Control-to-edge conduit: read-only industrial protocol access from the gateway to the PLCs.
2. Edge-to-broker conduit: MQTT over TLS on port 8883, outbound only, from the gateway or DMZ to the broker.
3. Broker-to-consumer conduit: MQTT over TLS from analytics applications and dashboards to the broker.

The target security levels in the table are deliberately not fixed. They come from your risk assessment, and the same architecture might be SL 2 in one plant and SL 3 in another.

Document Each Conduit

For each conduit, write down: endpoints, direction of connection establishment, protocol and port, authentication method, encryption, allowed topics or data, and what happens when it fails. Reviewers will ask for exactly these details.

Applying the Foundational Requirements to MQTT

Commands Deserve Their Own Analysis

Sending telemetry out of a plant is one risk level. Sending commands into a plant is another. Many organisations keep the cloud conduit strictly read-only and handle writes locally. If you need remote setpoints, separate them: different topics, different credentials, validation on the gateway, and limits on what values the gateway will forward to the PLC. The control zone should never execute raw payloads from a broker.

Where a Managed Broker Fits

In this model, the cloud broker is one zone and the edge-to-broker link is one conduit. A managed broker does not make your system IEC 62443 compliant, and you should be wary of any vendor that implies it does. What it can do is provide controls that you reference in your own assessment.

ConnectMQ provides the following controls that can support such an assessment:

• TLS on port 8883 and secure WebSockets on 8084, with a Let's Encrypt certificate (FR3, FR4).
• Authentication with generated credentials, with client IDs bound to those credentials (FR1).
• Multi-tenant isolation, or an isolated cluster on Dedicated plans, or deployment into your own cloud account with BYOC (FR5).
• Per-plan quotas with MQTT 5 reason code 0x97, flood protection and IP blocking after repeated failed logins (FR6, FR7).
• Connection state visibility through $SYS/broker/connection/{clientId}/state, plus portal dashboards and threshold alert rules (FR6).

ConnectMQ does not offer per-topic ACLs, so use separate brokers or credentials per trust zone where topic-level separation is required, and enforce command filtering on your edge gateway. Record these responsibilities in your shared-responsibility matrix. The cloud MQTT broker guide compares shared, dedicated and BYOC models, which often matters for zone design.

Example: Edge Gateway Publishing Into the Broker Zone

The gateway is where most of the security work lives. A minimal Python gateway that reads values locally and publishes over TLS might look like this:

import json
import time
import paho.mqtt.client as mqtt

BROKER = "YOUR_BROKER_HOST"  # from the ConnectMQ portal
TOPIC = "connectmq/plant1/production/line1/press1/telemetry"

def read_plc_values():
    # Replace with your OPC UA or Modbus read; the gateway only reads.
    return {"pressure_bar": 182.4, "cycle_count": 50123, "state": "RUNNING"}

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()  # verify the broker certificate against system CAs
client.reconnect_delay_set(min_delay=2, max_delay=300)

client.connect(BROKER, 8883, keepalive=60)
client.loop_start()

while True:
    payload = read_plc_values()
    payload["ts"] = int(time.time())
    client.publish(TOPIC, json.dumps(payload), qos=1)
    time.sleep(10)

Notice what is absent: no inbound port on the gateway, no subscription to command topics, no credentials shared with other gateways. The topic follows an ISA-95 style hierarchy, which also makes your zone boundaries visible in the data model. The industrial IoT with MQTT guide explains this structure in more depth.

Review Checklist for an IEC 62443 MQTT Design

1. A risk assessment defines zones, conduits and target security levels for the MQTT flows.
2. Every MQTT connection crossing a zone boundary uses TLS and verifies the server certificate.
3. All connections are initiated from the plant side outward; no inbound ports into the control zone.
4. Each gateway and application has unique, revocable credentials.
5. Command paths are separated from telemetry and validated on the gateway.
6. Gateways buffer data when the conduit is down and recover without flooding.
7. Connection state, failed logins and abnormal rates are monitored with a defined response.
8. Shared responsibilities with the broker provider are documented.

For the network side of this checklist, read MQTT security for OT networks, and for the identity side, the zero trust for IoT messaging article.

Build Your Industrial Data Conduit on ConnectMQ

You can prototype the edge-to-broker conduit today. Create a private broker on the free Serverless plan at app.connectmq.com (no credit card), connect a gateway over TLS, and watch ISA-95 topics appear in the portal's devices view. When the design needs isolation, a fully managed MQTT service on a Dedicated or BYOC deployment keeps the same client configuration. The broader MQTT security best practices apply throughout.

Frequently Asked Questions

Is MQTT allowed under IEC 62443?

IEC 62443 does not ban or prescribe specific protocols. It requires that communication across zones meets the security requirements for its conduit, which MQTT over TLS with strong authentication can support.

Can a cloud MQTT broker be IEC 62443 certified for my plant?

Certification applies to specific products, processes or systems against specific parts of the standard. Your overall system's conformance is assessed for your plant; a broker provider can only supply controls you reference in that assessment.

Should commands flow from the cloud into the plant?

Only if the risk assessment allows it. Many sites keep the cloud conduit read-only, and those that allow commands separate them, validate them on the gateway and limit what can be changed.

Do I need a local broker in the DMZ?

Not always. A DMZ broker adds buffering and an inspection point, while a gateway publishing directly to a cloud broker over TLS is simpler. The risk assessment and target security level decide.