Five Common SCADA Network Errors We Keep Finding in Audits
Patterns we see repeatedly across plant audits — flat networks, undocumented changes, and credentials that have outlived three engineers.
Every audit we run turns up some version of the same five issues. None of them are exotic — they're the predictable result of a network that was built incrementally over a decade by different vendors, none of whom owned the whole picture. Here's what we find most often, in order of frequency.
1. The flat, unsegmented network
By far the most common finding: the OT network — PLCs, HMIs, drives, SCADA servers — sits on the same broadcast domain as office IT, sometimes with a single unmanaged switch as the only thing standing between a plant floor laptop and a corporate email server. This isn't a theoretical risk; it's the single most exploited weakness in the ICS incidents we've reviewed industry-wide.
A properly segmented network follows something close to the IEC 62443 zone-and-conduit model: distinct zones for enterprise IT, the DMZ, supervisory control (SCADA/HMI), and basic control (PLCs/RTUs), with firewalled conduits between them and nothing routing directly from enterprise to basic control.
2. Shared credentials with no audit trail
A close second: one HMI login, one SCADA admin account, shared across every shift and every contractor who's ever touched the system, often unchanged since commissioning. When something goes wrong at 3am, there's no way to know who made the change that caused it — which means the same mistake gets repeated.
This is rarely a technology problem. Most modern SCADA platforms support per-user accounts and change logging natively; it's almost always a process problem where convenience won out during commissioning and was never revisited.
3. Undocumented logic changes
We regularly find PLC programs with rungs of logic that don't match any version of the documentation on file — patches made during a production crisis, years ago, by someone who's no longer with the company. The logic works, mostly, but nobody fully understands why it's there, which makes every future change riskier than it should be.
"We found a timer block from 2019 with a comment that just said 'DO NOT REMOVE — ask Dave.' Dave left in 2021."
The fix isn't glamorous: a disciplined change-control process where every logic modification gets documented and version-controlled, even under production pressure — especially under production pressure, since that's when undocumented changes happen.
4. Single points of failure disguised as redundancy
Plants will often have a redundant SCADA server pair, but both servers sit on the same network switch, the same UPS, or even the same rack. The redundancy protects against a server-level fault but not against the actual most likely failure mode — a power event or a switch failure that takes both nodes down simultaneously.
5. Remote access left wide open
Vendor support access — for the drive vendor, the SCADA integrator, the robot OEM — frequently gets set up as a permanent, always-on remote connection during commissioning and is never revisited. We've found modem and VPN connections still active years after a vendor relationship ended.
| Finding | Typical root cause | Fix complexity |
|---|---|---|
| Flat network | Incremental growth without a network owner | High — requires planned downtime |
| Shared credentials | Convenience during commissioning | Low — mostly a process change |
| Undocumented logic | Crisis-mode patches, no change control | Medium — ongoing discipline required |
| Fake redundancy | Redundancy designed at the server layer only | Medium — infrastructure rework |
| Open remote access | Vendor access never offboarded | Low — access review and cleanup |
What fixing this actually looks like
None of these require ripping out and replacing existing control systems. Segmentation can usually be retrofitted with managed switches and firewalls at the zone boundaries during a planned maintenance window. Credential and remote-access cleanup is mostly a one-time audit plus an ongoing review cadence. The hardest part is rarely technical — it's getting organizational buy-in to treat OT network hygiene as a maintenance line item, not a one-time project.