The Industrial Site Connectivity Checklist

This is the checklist we work from on OT and SCADA sites. It is written so you can use it with any provider, including one that isn't us.

Two things make industrial connectivity different from office IT, and almost every problem traces back to one of them.

The first is that the control network does not tolerate what the office network shrugs off. A broadcast storm is an annoyance in an office and a stopped line on a plant. A firmware update is routine on a laptop and a change-control event on a PLC.

The second is that the site is usually somewhere inconvenient. Nobody is walking to the cabinet at 2am. Every decision below is really a question about what happens when something fails and the nearest engineer is forty minutes away.

We are an IT and network company. We do not program PLCs and we do not write control logic — and you should be wary of anyone who claims to do all of it.

• What is actually being connected: PLC, RTU, HMI, SCADA server, meters, cameras, or a mix
• Makes and models, with firmware versions where you have them
• Which protocols are in use: Modbus TCP, DNP3, IEC 60870-5-104, OPC UA, EtherNet/IP, PROFINET, or vendor-proprietary
• Is the requirement monitoring only, or does anyone need to write commands down to the plant
• How many sites, and are they identical or all different
• Site power: reliable supply, and UPS at the cabinet as well as at the server
• Cabinet environment: temperature, dust, vibration, indoors or in plant
• Distances — cabinet to cabinet, and cabinet to the nearest telecoms entry point
• Who owns the site: your company, a landlord, a free zone authority, or a client of yours
• Existing network: is there one, and is it documented

• Control traffic and office traffic on physically or logically separate networks, with an enforcement point between them
• A firewall between OT and IT allowing only what is named — not any/any with a comment saying it will be tightened later
• The list of flows that genuinely need to cross the boundary, written down, with a reason for each
• Nobody's laptop, printer or guest wifi shares a switch with the control system
• Remote sites cannot reach each other unless there is a stated reason
• The SCADA server's position agreed: which side of the boundary, and what reaches it
• VLANs alone understood not to be a security boundary — they are traffic separation, not enforcement

• Fixed line, cellular, or both — and which is primary
• If cellular: is a static IP or private APN required, and has the carrier confirmed it. Standard consumer SIMs sit behind carrier NAT and nothing can dial in
• Failover tested by unplugging the primary, not by reading a config
• Failback tested too. Plenty of links fail over cleanly and never come back
• Latency and jitter requirements stated by whoever owns the control system, not guessed by the network supplier
• Bandwidth is usually small; the real requirement is consistency, not capacity
• Data caps, and what happens when they are hit — throttled, billed, or cut off
• Who holds the SIM account and the carrier contract — you, or your integrator
• Antenna placement for cellular sites. Metal cabinets are excellent faraday cages

This is where most industrial sites are actually compromised. Not by an attacker picking a lock — by a convenience left in place after a commissioning visit.

• No direct port forwarding to a PLC, HMI or SCADA server. Ever. Not on a high port, not just for now
• Remote access through a controlled path: a jump host, or a VPN terminating at a firewall rather than at the device
• Multi-factor authentication on every remote access account
• Vendor and integrator access time-bounded and switched off between visits
• Named accounts per person. No shared engineer login
• A log of who connected, when, and what they touched
• Consumer remote-desktop tools on the HMI identified and removed, or formally accepted in writing
• A documented way to grant emergency access at 2am without permanently weakening anything

• UPS on the network cabinet, not only the servers. A running SCADA server with a dead switch is a dark site
• Out-of-band access: if the primary link dies, is there any way in at all
• Managed switches with remote reboot, or a switched PDU
• What the system does on link loss: buffer and forward, or lose the data
• How long it buffers for, and whether anyone has ever tested that
• A named escalation path with real phone numbers, not a group mailbox
• Spares: which single component, if it fails, stops everything — and is there one on a shelf
• Recovery time you can live with, agreed before you need it

Unglamorous, and the cause of most intermittent faults.

• Fibre rather than copper between buildings, or anywhere near heavy machinery
• Data cabling separated from power runs, crossing at right angles where it must cross
• Surge and lightning protection on anything leaving a building
• Proper earthing, checked rather than assumed
• Industrial-rated switches where the cabinet gets hot. A cabinet in Dubai summer sun is not a comms room
• Cabinet temperature considered, and ventilation or cooling where needed
• IP rating appropriate to where the enclosure actually sits, including wash-down areas
• Every cable labelled at both ends
• No temporary cable left in place. There is no such thing

• An IP addressing scheme with room to grow, written down before anything is configured
• No duplicate ranges across sites, especially if they will ever be joined by VPN
• Time synchronisation from a common source. Correlating an incident across drifting clocks is close to impossible
• Naming convention agreed and used consistently
• DNS behaviour decided for the control side, including what happens when the link is down

Standard IT security advice fails on OT because you often cannot patch and cannot reboot. What follows is what actually applies.

• An asset inventory: every device, its firmware, and what it talks to. You cannot protect what nobody has listed
• Default credentials changed on switches, gateways and cameras — checked device by device, not assumed
• Unused switch ports disabled
• Configuration backups of switches, firewalls and gateways, held somewhere other than the site
• PLC and HMI program backups confirmed to exist and confirmed restorable. Ask when a restore was last tested
• Patching approach for what can be patched, and compensating controls written down for what cannot
• Removable media policy, because USB sticks are still how things get onto isolated networks
• Who to notify if there is an incident, and within what timeframe under your obligations

UAE organisations should confirm their obligations with the UAE Cyber Security Council and any sector regulator. Requirements as of August 2026 and subject to change.

Insist on witnessing these rather than accepting a report.

• Poll a live value from the SCADA system and watch it update
• Pull the primary link and confirm failover, with the time it took recorded
• Restore the primary and confirm failback
• Attempt to reach a control device from the office network and confirm it is refused
• Attempt remote access as a vendor would and confirm it lands where you expect, with MFA
• Power-cycle the cabinet and confirm everything returns without a manual step
• Confirm an alert actually reaches a human phone, by triggering one
• Leave it running for a fortnight and review the logs before signing off

• Network topology drawing that matches reality on the day of handover
• IP address schedule and VLAN plan
• Firewall rule set with the reason for each rule
• Device inventory with models and firmware
• Configuration backups for every managed device, in your possession
• Carrier account and SIM ownership in your company's name
• Credentials handed over properly, and a record of who else holds access
• The escalation path and support arrangement in writing

Carrier NAT. A cellular link is installed, everything works outbound, and nobody can dial in. The fix is a static IP or private APN, and it is far cheaper to specify at the start than to retrofit.

The flat network. Everything on one range because it was quicker during commissioning. It works perfectly until the day it does not, and by then the plant is running.

The vendor's remote tool. Installed to finish a commissioning job, never removed, still logged in, tied to an account nobody at your company controls.

Power to the switch. The server has a UPS. The switch it plugs into does not. The site goes dark on a flicker.

Nobody has the PLC backup. The integrator has it. Or had it. Or has a copy from before the last three changes.

Clocks. Three devices, three times, one incident nobody can reconstruct.

Heat. A cabinet that was fine in February. Commercial-grade switches in a sealed enclosure in a Dubai August is a summer of intermittent faults nobody can reproduce.

We handle the network, the connectivity, the segmentation, the remote access design and the documentation. We do not write control logic or take responsibility for process safety, and any change touching a running plant belongs in your change-control process with the people who own that plant.

If your integrator and your IT provider are pointing at each other, that gap is usually where the fault lives, and it is worth naming it early.