Key takeaways
- In OT, continuity comes first: a flow must not disturb the shop-floor system, should start with read permissions and should behave predictably in an outage.
- The zones and conduits approach of IEC 62443 is a good framework for thinking about where to place the integration server in the network.
- Certificate expiry is a common cause of lost connections; track expiry dates and plan renewal.
- Security alone is not enough: an outage buffer, duplicate protection and a stale-data alert are part of operability.
In an industrial setting, security is not only protecting a data flow against unauthorised access but also keeping it running without affecting production. In IT confidentiality often comes first, whereas in OT continuity and safety take priority. This article summarises what to address when designing an integration flow, together with generally accepted frameworks.
What are we trying to protect?
The security literature names three goals: confidentiality, integrity and availability. In corporate IT confidentiality often leads. In industrial settings process continuity and safety (of people and equipment) are decisive; so an integration that does not strain the shop-floor system, does not perform unexpected writes and behaves predictably in an outage is as important as preventing unauthorised access.
As frameworks, the ISA/IEC 62443 series addresses the security of industrial automation and control systems and NIST SP 800-82 is a widely consulted guide to OT security. For how systems are positioned functionally see the ISA-95 levels article.
Network zones and conduits
IEC 62443 recommends dividing the system into zones with similar security requirements and routing communication between zones through defined conduits. For integration these questions matter:
- In which zone will the integration server run and which zones will it reach?
- Which side initiates the connection? Where possible, outbound connections from OT towards IT are preferred, so no inbound connection to the shop floor has to be opened.
- Which ports and protocols are open between zones, and are they documented?
- Is an intermediate zone (DMZ) needed?
These decisions are made with the network and security teams and written down in the pilot scope.
Identity, permissions and secrets
- Least privilege. Set up the first flow with read-only permission. If writing is needed, grant permission only to the nodes and operations required.
- Separate service accounts. Use a separate account for each flow or system; a shared administrator account removes both traceability and the ability to revoke.
- Keeping secrets. Do not put passwords and keys in documents, e-mails or version control; keep them where access is restricted.
- Broker and database permissions. Restrict each MQTT publisher to its own topic subtree and each database account to only the tables it needs.
Encryption and certificates
In OPC UA connections the signing and encryption mode and application certificates are part of the security model (OPC UA architecture). In MQTT TLS and client authentication are configured on the broker (MQTT in production). Three points matter operationally:
- Trust lists. Each side must explicitly place the other’s certificate in its trusted list; a “trust every certificate” setting removes the protection.
- Expiry. A certificate that expires drops the connection. Keep dates in an inventory and place renewal in a planned change window.
- Old policies. Disable deprecated algorithms and do not use the “None” security mode in production.
See the OPC UA certificate guide for a detailed checklist.
Outage and recovery behaviour
Reliability is part of security: data loss and double records damage integrity. Answer three questions up front:
- What happens to data if the destination is unreachable? Records can be buffered locally and delivered when the connection returns (Store & Forward). Buffer capacity depends on outage duration, data rate and record size; the data buffer calculator helps you estimate. An unconditional “zero data loss” guarantee cannot be given; what happens when capacity is exceeded must also be designed.
- Does replay create double records? You need a unique event key and a write pattern that makes repeated processing harmless (idempotency).
- What happens when the source value goes stale? A retained or cached value can stay old; a timestamp and a maximum data age let a stale value be flagged.
These behaviours should be verified in acceptance by cutting and restoring the connection, slowing down the destination and restarting the service.
Monitoring and change management
A running flow that silently breaks means a breakage nobody notices. Monitor the flow’s run state, source and destination record counts, latency, error logs and sources from which no data has arrived for a set time (a heartbeat or stale-data alert).
On the change side, keep a backup and version history of the configuration, make changes in a defined window and write the rollback step beforehand. These topics are also part of the commissioning handover checklist.
A short checklist for a flow
- Are the integration server’s zone and permitted connections documented?
- Is the flow set up with least privilege (read-only first)?
- Is there a separate, revocable account for each flow?
- Are certificate trust lists and expiry dates managed?
- Are the outage buffer and capacity-exceeded behaviour defined?
- Has it been tested that replay does not create double records?
- Is there an alert for stale data and for a stopped flow?
- Are a configuration backup and a rollback step ready?
The project readiness check can be used to make missing responsibilities visible.
Frequently asked questions
Which network zone should I put OPC Router in?
There is no single right answer; it depends on the systems being connected, your security policy and your network topology. The general principle is to keep connections between zones defined and documented and, where possible, to initiate connections outward from OT. The decision is made with the network and security teams.
What happens if a certificate expires?
The connection usually cannot be established and the flow stops. Track expiry dates in an inventory, renew in a planned window and verify the connection after renewal.
Is it possible to prevent data loss completely?
No unconditional guarantee can be given. You can reduce the risk with buffering, safe reprocessing and monitoring; what happens when buffer capacity is exceeded must also be designed.