OT Networking & Secure Industrial Connectivity

Network architecture: from machine to cloud

Each zone has a purpose, an owner and explicitly permitted connections. IEC 62443 zones and conduits are established through risk assessment. ISA-95/Purdue levels describe typical operational roles; they do not by themselves establish security boundaries or assign a fixed level to a product.

Key rule: A VLAN separates broadcast domains, but is not a complete security perimeter. Cross-zone traffic needs controlled routing, firewall inspection and application permissions. Endpoint authentication is used where supported, with compensating controls for legacy devices.

Reference network diagram

Arrows show telemetry direction. They do not authorize reverse commands or identify who opens a session. The remote support route is separate and requires explicit approval.

Download network diagram Open the detailed OT to AWS guide ↗

Reference equipment and responsibilities

Final models, firmware, licenses, capacity, redundancy and controls require site review. The diagram uses separate firewall appliances at the two DMZ boundaries.

Multi-NIC equipment is not a firewall. Unintended bridging or IP forwarding can bypass boundaries. NAT and VPN encryption also do not replace access control.

Physical layer, switching and addressing

• Cable routes, cabinet locations, port schedules, patch maps and labelled connections.
• Industrial copper or fibre selected for distance, electrical noise, grounding, environment and motion. Cable category, PROFINET cable type and connector choices follow the application and device requirements.
• Fibre between cabinets where distance, interference or ground-potential differences make it appropriate.
• IGMP snooping with a correctly placed querier where IP multicast requires it, such as multicast EtherNet/IP I/O. PROFINET real-time Layer 2 traffic requires its own supported switching design; IGMP does not manage that cyclic traffic.
• Broadcast and multicast storm controls sized and tested for the application.
• An address register covering devices, subnets, VLANs, gateways, reservations and management interfaces.
• Duplicate OEM addresses managed through documented 1:1 NAT where supported. A PROFINET PN/PN coupler exchanges configured I/O data between networks; it is not a general NAT or routing replacement.
• Secured cabinets, disabled unused ports and restricted management interfaces. Use 802.1X where supported and tested; MAC-based admission offers weaker identity assurance.
• 24 VDC power, independent feeds where required, UPS capacity, spare ports and replacement arrangements.

Redundancy and recovery

Select supported protocols such as MRP, RSTP, PRP or HSR according to device capability and application needs. They have different architectures and recovery behaviour. A ring alone does not guarantee uninterrupted control. Validate the required recovery time against actual load, device watchdogs and control requirements.

Time synchronization

• Use a compatible IEEE 1588 PTP profile and supported clock/switch design where precision event or motion timing requires it. PTP capability alone does not guarantee the required accuracy.
• Use approved NTP relays for operational timestamps; enable authenticated time distribution where endpoints support it and restrict permitted time sources.
• Define authoritative sources, relay paths, holdover behaviour, acceptable clock offset and loss-of-sync alarms.
• Store UTC timestamps where appropriate and document local display time, source timestamp and ingestion timestamp.

Consistent time supports alarm correlation, historian ordering, certificate validation and incident investigation.

Protocols and approved communication

Record initiator, destination, purpose, protocol, permissions and failure behaviour for every boundary crossing.

AWS IoT Core supports certificate-authenticated MQTT over TLS on TCP 8883. Port 443 requires the appropriate supported authentication and client configuration. Restrict source, destination and service; an unrestricted “allow 443” rule is insufficient. Document DNS, time, renewal, monitoring and administration paths too.

Direct enterprise or internet access into production cells is blocked in this baseline. Engineering access follows a separate controlled path.

A production counter reaching AWS

A PLC counter changes to 14,500 bottles.

1. Kepware initiates the approved PLC read.
2. HighByte connects to Kepware through OPC UA and adds asset identity, units, source timestamp and quality.
3. HighByte publishes the approved telemetry copy through firewall A to the DMZ MQTT broker.
4. A configured Greengrass adapter consumes the message and initiates a TLS connection through firewall B to AWS IoT Core.
5. AWS routes the data to approved storage, reporting or application services.

Define and test queue capacity, supported outage duration, retry rules, duplicate handling and storage limits. This is a telemetry-only baseline. Programming, recipes, setpoints and remote commands need separate authorization and controls.

Control performance and deterministic operation

Reliable control depends on bounded, verified timing. Not every industrial network or application is deterministic by default.

• Assess controller tasks, priorities, device update rates and communication cycles.
• Measure latency, jitter, packet loss, switch loading, buffers and relevant retransmissions or missed cyclic frames.
• Check multicast, broadcast, redundancy recovery, polling and engineering traffic under representative load.
• Keep cloud connectivity outside the control loop. Cloud outages must not interrupt local control, interlocks or required operator functions.
• Validate safety communication and end-to-end response time separately, including sensor, controller, network and actuator delays.

Explore PLC logic, interlocks and cycle timing ↗

Secure engineering and remote access

• Do not expose PLCs to the internet or give vendors an unrestricted plant VPN.
• Terminate approved remote access at a hardened gateway or jump host, then permit only the required engineering destination.
• Use named accounts, MFA at supported access points, limited roles, time-bound approval and session logging or recording where the protocol and tool support it.
• Use application proxies or protocol breaks where suitable, rather than extending a flat network into the plant.
• A local keyswitch or hardwired enable may be appropriate for a specifically engineered remote programming path. Verify what it actually blocks; it is not a universal network security control.
• Separate programming from telemetry. Follow approval, backup, test, rollback and recovery procedures for production changes.

Monitoring, maintenance and recovery

Monitor link errors, topology changes, unexpected devices, firewall denials, authentication failures, certificate expiry, clock offset and data delays. Start with passive discovery where suitable. SPAN ports or network taps require appropriate placement and capacity; mirrored traffic may be incomplete. Active scanning needs approval and device sensitivity review.

Backup and disaster recovery

• Configuration snapshots for switches, firewalls, edge hosts, brokers and servers.
• Protected backups of PLC programs, HMI and SCADA projects, recipes, certificate material and license records. Protect private keys separately and verify license recovery terms.
• Golden images, compatible firmware/driver records, rollback packages and approved replacement hardware.
• Recovery priorities, dependencies, recovery time targets and acceptable data-loss targets.
• Tested restore steps, maintenance windows, compatibility checks and verification after patching.

OT risk assessment, patching and incident response ↗

Commissioning and handover

Readiness is demonstrated, recorded and accepted against the agreed requirements.

• Connectivity: Approved systems exchange the required information.
• Isolation: Unauthorized routes and connection attempts are blocked using approved, non-disruptive tests.
• Data integrity: A known PLC value matches the destination, including units, timestamp and quality.
• Performance: Control timing remains acceptable under representative traffic.
• Multicast and broadcast: Querier placement, group behaviour and storm controls work as designed.
• Time: Devices meet accuracy requirements and alarm on loss of synchronization.
• Recovery: Link, broker, edge and cloud outages produce agreed behaviour, including duplicate and backlog handling.
• Access: Engineering and remote support permissions match the approved scope.
• Restore: Configuration and recovery files restore successfully on an approved test target.
• Evidence: Owners accept drawings, registers, backups, results and remaining exceptions.

Download OT network checklist

Typical deliverables

• Physical and logical diagrams, cabinet layouts, cable schedules and patch records.
• IP, subnet, VLAN, NAT and MAC address registers.
• Zone-and-conduit drawings and communication/firewall matrices.
• Multicast, redundancy and time synchronization plans.
• Remote access, monitoring, backup and recovery procedures.
• Configuration files, commissioning results, failover/restore records and handover evidence.

Designs reference IEC 62443 and NIST SP 800-82 where applicable. Certification or regulatory claims require a defined scope, applicable requirements and supporting evidence.

Technical references

• PI North America: PROFINET networking
• Rockwell Automation: Ethernet reference manual
• Siemens: PN/PN coupler manual
• NIST SP 800-82 Rev. 3: OT security
• ISA/IEC 62443 standards
• Siemens SCALANCE security appliances
• AWS IoT Core protocols

Facility controls and power monitoring

See how the same network boundaries protect building controls, electrical monitoring and facility telemetry.