BEA Industrial Networking Blog
KISS in SCADA: Why Over-Engineered Networks Create Operational Nightmares
Most industrial network designs look convincing in a presentation. At 2:00 a.m., the measure that matters is whether an on-call technician can identify a failed path, preserve safe local control, and restore telemetry quickly.
Complexity multiplies the fault domain
Layered topologies, nested VLANs, enterprise authentication, redundant rings, SD-WAN overlays, and multi-hop VPNs can each solve a legitimate problem. When stacked without a clear operational need, they create a chain in which one unavailable service or one incorrect rule can interrupt critical communications.
Practical rule: Critical OT communications should remain predictable and operational when enterprise services or wide-area links are unavailable.
Four common ways complexity becomes an outage
1. Enterprise dependency creep
A field switch or controller depends on remote authentication, DNS, certificate, or cloud services. A WAN failure then becomes a local operations problem.
Design response: Keep essential local control independent, and document which external services affect recovery.
2. Segmentation without visibility
Too many zones and rule sets hide the traffic technicians need to diagnose intermittent EtherNet/IP, PROFINET, or Modbus TCP issues.
Design response: Group devices by process function, allow only required flows, and preserve approved diagnostic access.
3. Fragile remote connectivity
Nested tunnels, carrier addressing changes, continuous polling, and manual reconnect procedures make small communications events expensive.
Design response: Support safe local operation, data buffering, automatic reconnection, and efficient reporting.
4. Redundancy that obscures failure
Poorly controlled rings, gateways, and high-availability pairs can introduce loops, duplicate addresses, slow convergence, or split-brain behavior.
Design response: Test failover, define expected recovery time, and keep replacement procedures usable by on-call staff.
Visual contrast: complicated recovery versus supportable recovery
Operational nightmare
- Ownership changes at every layer
- Unknown dependencies on WAN services
- Firewall policy is the only traffic map
- Failover behavior is assumed, not tested
- Replacement requires proprietary expertise
Supportable SCADA network
- Process zones have clear purposes
- Controllers fail safely and operate locally
- Data flows and dependencies are documented
- Recovery is tested under realistic outages
- Backups and preconfigured spares are ready
Segmentation still matters, but it needs an operational purpose
Simple does not mean flat or unprotected. Segmentation remains an important control for limiting access and containing threats. The goal is deliberate zoning with understandable boundaries, not a separate island for every device. Network diagrams should show major connections, allowed data flows, remote access paths, and external dependencies so both operations and incident response teams can work from the same picture.
Remote sites should remain useful when the link is down
Lift stations, well sites, valve vaults, and pumping stations often rely on cellular service. A sound design assumes interruptions will occur. The PLC, RTU, or controller should continue its approved local strategy, buffer important records where appropriate, and reconnect without a truck roll. Protocol choices such as MQTT Sparkplug B, DNP3 exception reporting, or store-and-forward features may reduce traffic and improve recovery, but suitability depends on the application, threat model, and validated system design.
Four KISS rules for reliable SCADA networks
Favor predictability
Use controlled addressing and minimize dynamic service dependencies for critical OT assets.
Prioritize local autonomy
Design PLCs, RTUs, and controllers to maintain approved safe operation during communication loss.
Keep infrastructure supportable
Document and back up configurations. Prepare tested spares and clear replacement steps.
Monitor the boundaries
Build visibility at firewalls, gateways, and remote links before adding custom workarounds.
Questions to ask before adding another layer
- Which specific operational or security risk does this component reduce?
- What happens locally if it or its upstream service is unavailable?
- Can the on-call team see and diagnose the resulting traffic path?
- Has failover been tested with realistic power, carrier, and configuration failures?
- Can a documented spare restore service without specialist escalation?
How can BEA help?
BEA can help review industrial network architecture, map dependencies, assess remote communications, simplify support procedures, and plan tested migration or recovery steps. The target is not the fewest possible components. It is the simplest design that meets the application, cybersecurity, availability, and lifecycle requirements.