Industrial IoT (IIoT) Security Guide: Device Identity, Gateways and Cloud Connections

Industrial IoT connects sensors, controllers and machines that were designed for closed plant networks to gateways, brokers and cloud platforms that sit on the internet. Every one of those connections needs a trustworthy device identity, an encrypted and authenticated protocol, and a clear boundary between the plant and the cloud. In practice many IIoT deployments rely on shared passwords, unencrypted MQTT or OPC UA in mode None, and gateways that nobody patches. This guide covers device identity and certificates, gateway design, MQTT and OPC UA security, cloud onboarding, and the standards and regulations that now apply (IEC 62443, the NIST IR 8259 series, ETSI EN 303 645 and the EU Cyber Resilience Act). It is written for OT and IoT security engineers, plant architects and the cloud teams who receive IIoT data.

Key takeaways

• Every device needs its own identity. A unique X.509 certificate with a private key that never leaves the device replaces shared passwords and fleet-wide API keys.
• The gateway is the most important asset. It bridges plant protocols to the cloud, holds credentials for both sides and is usually the first device an attacker reaches.
• Secure modes exist but are often switched off. MQTT over TLS on port 8883 and OPC UA in Sign or SignAndEncrypt mode should be the only options allowed in production.
• Connections should flow outward. Design so that plant devices and gateways initiate connections to the cloud, with no inbound path from the internet to control networks.
• Regulation has arrived for manufacturers. EU Cyber Resilience Act reporting obligations apply from 11 September 2026 and full obligations from 11 December 2027, so buy and build with that in mind.

How IIoT differs from enterprise IoT and classic OT

Classic OT keeps controllers and HMIs inside a layered architecture with tightly controlled paths in and out. Enterprise IoT puts cameras, badge readers and building sensors on the corporate network. IIoT sits between the two: devices sense or control physical processes, but their data is collected by edge gateways and sent to cloud analytics, digital platforms or vendor maintenance services. That creates three properties the security design must deal with.

• Long life: industrial devices often run for 10 to 20 years, far longer than the support period of the software stack inside them. Certificate lifetimes, cryptographic algorithms and firmware update channels must be planned for that span.
• Physical consequence: a compromised vibration sensor is a data problem; a compromised actuator or set-point writer is a safety problem. Separate read-only telemetry paths from write or command paths.
• Mixed ownership: devices may be owned by the plant, the machine builder, an integrator or a cloud provider, and each wants remote access. Ownership of credentials and of the connection must be written down.

See the IoT Security Guide for enterprise IoT and the OT Security Guide for the wider control system programme.

Reference architecture: zones, conduits and the gateway

IEC 62443 describes a system as zones (groups of assets with the same security requirements) connected by conduits (the communication paths between them), each with a target security level from SL 1 to SL 4. For IIoT a practical zone model looks like this.

The gateway is the conduit enforcement point. It should terminate southbound protocols, translate only the data points that are needed, and open a single outbound TLS connection northbound. If the gateway can also write to controllers, treat it as part of the control zone for security level purposes, not as an IT box. See the IEC 62443 Guide and the Network Segmentation Guide.

Device identity and certificates

NIST IR 8259A lists device identification as the first of six core device capabilities: the device can be uniquely identified, both logically and physically. The other five are device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness. For IIoT, identification in practice means a per-device X.509 certificate.

• Birth certificate: the manufacturer injects a key pair and an initial device certificate at production (IEEE 802.1AR calls this an IDevID). The private key should be generated inside a TPM, secure element or HSM-backed process and never exported.
• Operational certificate: during onboarding the owner enrols the device with its own CA and issues an operational certificate (an LDevID in 802.1AR terms). This is what the plant and cloud should trust, so that the manufacturer's CA does not become a permanent trust anchor in your environment.
• Cloud registration: cloud IoT services authenticate devices by mutual TLS. In AWS IoT Core, for example, a device certificate must be registered and in ACTIVE status, the device proves possession of the private key during the handshake, the private key never leaves the device, and the device must send Server Name Indication. Authorisation is separate: policies attached to the certificate decide which topics it may publish or subscribe to.
• Algorithms: use ECC P-256 or P-384, or RSA of at least 2048 bits, which are the families mainstream cloud IoT services accept. Plan for crypto-agility because a device shipped today may still be running when post-quantum migration is under way.
• Lifetime and renewal: long-lived device certificates (some services default to expiry dates decades away) are easy but leave revocation as your only control. Prefer operational certificates of one to three years with automated renewal over the device management channel, and test renewal for devices that are offline for weeks.
• Revocation: keep a per-device revocation path that works in the cloud registry (deactivate the certificate) and at the site broker or OPC UA server (CRL or trust list update).

See the Device and IoT Identity Guide, the Identity for IoT Fleets Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.

MQTT and OPC UA security

Two protocols carry most IIoT data. Both have solid security features, and both are frequently deployed with those features off.

MQTT

• Transport: use MQTT over TLS on port 8883 and block plain MQTT on port 1883 at every boundary. TLS 1.2 is the minimum; prefer TLS 1.3 where both ends support it.
• Client authentication: MQTT 5.0 supports username and password in CONNECT and an enhanced authentication exchange using the Authentication Method and Authentication Data properties and the AUTH packet. For devices, client certificates in mutual TLS are the stronger choice; passwords end up shared across a fleet.
• Authorisation: MQTT itself leaves authorisation to the broker. Write topic ACLs that bind each client identity to its own topic namespace (for example, a device may publish only to site1/line3/device-id/telemetry and subscribe only to its own command topic). Deny wildcard subscriptions (#) to devices.
• Signals: MQTT 5.0 reason codes 0x86 (bad user name or password), 0x87 (not authorised) and 0x8C (bad authentication method) in CONNACK are worth alerting on when they spike.

OPC UA

• Application identity: every OPC UA client and server has an application instance certificate. Peers reject connections from certificates, or issuing CAs, that are not in their TrustList.
• Security modes: OPC UA defines None, Sign and SignAndEncrypt. The specification states that None can be used only with the None security profile, which is disabled by default; Sign is sufficient where confidentiality is not required; the choice of SignAndEncrypt depends on the site's security management system. In production, disable None endpoints on servers.
• Security policies: a security policy fixes the signing, encryption and key derivation algorithms. The server announces the policies it supports and the client picks one. The OPC Foundation advises sites to review periodically whether the selected policies still meet security objectives and move to newer ones when they do not, so remove legacy policies from server configurations rather than leaving them enabled for compatibility.
• Certificate management: a Global Discovery Server (GDS) can push certificates, trust lists and CRLs to applications, or let them pull. Only administrators should be able to write trust lists, CRLs and trusted CA lists.
• User authentication: application certificates authenticate software, not people. Use user tokens (certificates or federated identity) for operators and engineers and map them to roles on the server.
• Scope: the OPC UA specification is explicit that it does not address threats to the operating systems that host OPC UA applications, so host hardening and patching are still yours.

Gateway and edge hardening

The gateway concentrates risk: it runs a general-purpose OS, has interfaces on both sides, stores credentials for the plant and the cloud, and often runs containerised workloads pushed from the cloud.

1. Boot integrity: enable secure boot and measured boot, and verify signed firmware and container images before they run. See the Firmware and Boot Security Guide.
2. Credential storage: keep private keys in a TPM or secure element; never store cloud connection strings or tokens in configuration files or container images.
3. Interface minimisation: disable SSH, web consoles, serial consoles and debug ports in production or bind them to a management network. NIST IR 8259A calls this logical access to interfaces.
4. Outbound-only by default: local firewall rules allow southbound protocols to known devices and northbound TLS to named cloud endpoints, nothing else.
5. Update channel: signed updates with a tested rollback path, staged by site and line so a bad update cannot stop the whole fleet.
6. State reporting: forward gateway logs (authentication, configuration change, update, certificate renewal) to the SOC; NIST IR 8259A calls this cybersecurity state awareness.

See the Edge Device Security Guide for network edge appliances more broadly.

Where identity fits: gateways, brokers and cloud connections as non-human identities

Every IIoT device, gateway, broker and integration is a non-human identity. The credentials that matter most are often not on the devices at all: the cloud service principal that the data pipeline uses, the API key a machine builder uses for remote diagnostics, and the broker administrator account. Inventory them, assign an owner, scope them to least privilege and rotate them. The Salt Typhoon telecom intrusions show how stolen credentials and secrets taken from network devices can keep an attacker inside infrastructure for years, and gateways hold exactly that kind of secret. See the OT and ICS Identity and Access Guide.

Standards and regulation that apply

Under the CRA, manufacturers report through ENISA's Single Reporting Platform: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days after a corrective measure is available for an actively exploited vulnerability (one month for a severe incident). The reporting duty also covers products placed on the market before December 2027. Asset owners should expect suppliers to show how they will meet this, and should ask for support periods in contracts. Industrial products that are important or critical under the CRA may require third-party assessment, so check how your suppliers classify theirs. See the ETSI EN 303 645 Consumer IoT Guide.

Threats mapped to controls and frameworks

For CIS Controls v8.1, the relevant controls are 1 (inventory of enterprise assets), 4 (secure configuration), 12 (network infrastructure management) and 13 (network monitoring and defence). In ISO/IEC 27001:2022 Annex A, see 5.9 (inventory of information and other associated assets), 8.20 (networks security) and 8.22 (segregation of networks).

Implementation roadmap

1. Inventory first (weeks 1 to 6): list every IIoT device, gateway, broker, cloud connection and vendor access path, with owner, firmware version and credential type. The joint CISA and partner guidance on OT asset inventory gives a taxonomy to follow. See the OT Asset Visibility Guide.
2. Close exposure (weeks 2 to 8): remove internet-reachable gateways and brokers, block port 1883 and OPC UA (default port 4840) at site boundaries, and move vendor access behind a controlled access point.
3. Stand up device PKI (months 2 to 4): choose the owner CA, define certificate profiles and lifetimes, decide where keys are generated, and pilot onboarding on one production line.
4. Turn on protocol security in audit mode (months 3 to 5): enable TLS listeners and OPC UA secure endpoints alongside existing ones, log which clients still use insecure paths, and fix them one by one.
5. Enforce (months 5 to 8): disable 1883 and None endpoints line by line, starting with telemetry-only lines. Keep a documented rollback (re-enable the legacy listener for that line only) agreed with operations, and schedule changes in maintenance windows.
6. Operate: automate certificate renewal, monitor broker and gateway logs, run quarterly reviews of topic ACLs, OPC UA trust lists and vendor accounts, and test revocation.

Decision guidance

• Direct device-to-cloud or via gateway: connect devices directly only when they can do mutual TLS, store keys in hardware and receive signed updates. Otherwise put a gateway in front and let it hold the cloud identity.
• Site broker or cloud broker: a site broker keeps the plant working when the WAN fails and gives one place to enforce ACLs, at the cost of another system to patch. Small sites with few devices can connect gateways straight to a cloud service.
• Sign or SignAndEncrypt: Sign protects integrity and is enough for non-sensitive process values; choose SignAndEncrypt when data is commercially sensitive or crosses untrusted networks.
• Own CA or manufacturer CA: large estates should run an owner CA so they can revoke and re-key without the manufacturer. Small organisations can use the cloud provider's certificate service but should still keep per-device certificates.
• Retrofit or replace: devices that cannot support any authentication should sit behind a gateway in their own zone with read-only data paths, and be scheduled for replacement.

Detection and measurement

Log and alert on: new device certificates registered in the cloud, certificates nearing expiry, authentication failures and reason code spikes at the broker, wildcard subscription attempts, OPC UA connections rejected for untrusted certificates, gateway configuration and firmware changes, and any inbound connection attempt to a gateway from the internet.

• Identity coverage: percentage of devices and gateways authenticating with a unique certificate (target 100% for new deployments).
• Insecure protocol use: number of clients still on port 1883 or OPC UA None, trending to zero.
• Internet exposure: count of IIoT assets reachable from the internet (target zero).
• Certificate health: renewals completed before expiry and mean time to revoke a compromised device certificate.
• Patch latency: median days from vendor fix to deployment on gateways.
• Vendor access hygiene: share of vendor sessions that were brokered, approved and recorded.

Common failure patterns

• One credential for the whole fleet: a single connection string or password baked into every device image means one extracted device compromises all of them.
• Secure endpoints added, insecure ones never removed: OPC UA servers left with None mode and legacy policies enabled, or brokers listening on both 1883 and 8883, so attackers simply use the weaker path.
• Auto-accepting certificates: OPC UA clients and servers configured to trust any presented certificate, which turns certificates into decoration.
• Gateways treated as appliances: no owner, no patching and remote management exposed, which is the pattern behind repeated exploitation of edge devices by state actors such as Volt Typhoon.
• Bidirectional cloud paths: cloud-to-device command channels that can write set points without approval or safety interlocks.
• No support period in the contract: devices bought without a stated security update period become unpatchable long before they are retired.

Practitioner checklist

• Inventory every IIoT device, gateway, broker, cloud connection and vendor access path with an owner.
• Issue a unique certificate to every device and gateway, with keys in a TPM or secure element.
• Run an owner CA or managed private CA, with automated renewal and a tested revocation path.
• Allow only MQTT over TLS (8883) with client certificates and per-identity topic ACLs.
• Disable OPC UA None endpoints and legacy security policies; manage trust lists through a GDS.
• Design all plant-to-cloud connections as outbound only, with no inbound internet path to control zones.
• Enable secure boot and signed updates with rollback on gateways.
• Broker vendor remote access with MFA, approval and session recording.
• Require suppliers to state their support period and their CRA reporting process in contracts.
• Track the six metrics above and review them quarterly with operations.

Standards and references

• ISA: ISA/IEC 62443 Series of Standards
• NIST: IR 8259A IoT Device Cybersecurity Capability Core Baseline
• NIST: SP 800-213 IoT Device Cybersecurity Guidance for the Federal Government
• ETSI: EN 303 645 Cyber Security for Consumer Internet of Things
• European Commission: Cyber Resilience Act summary
• OPC Foundation: OPC 10000-2 OPC UA Security Model
• OASIS: MQTT Version 5.0
• AWS: X.509 client certificates in AWS IoT Core

Related NHI Mgmt Group resources: Device and IoT Identity Guide · OT Security Guide · IEC 62443 Guide · OT Asset Visibility Guide