Water SCADA analytics GPUs share a ToR with guest Wi-Fi. What architecture change is required?
Select an answer to reveal the explanation.
Short Explanation
SCADA-adjacent AI should not ride the same ToR as guest Wi-Fi—separate the pipes. Bridging visitors into SCADA or dropping segmentation is asking for trouble. Public free-for-all telemetry is not isolation.
Full Explanation
Water SCADA analytics GPUs that share a top-of-rack with guest Wi-Fi collapse OT-adjacent and visitor trust boundaries. Architecture must isolate municipal OT-adjacent AI networks from guest Wi-Fi—separate switches/VRFs/firewalls and no bridging—so compromised guest devices cannot reach SCADA-correlated telemetry or GPU management planes. Segmentation is mandatory, not optional convenience. Bridging guest Wi-Fi directly into SCADA for convenience is a classic anti-pattern that invites lateral intrusion into operational technology. Publishing SCADA telemetry on open public dashboards without controls expands disclosure beyond isolation goals. Removing all network segmentation between OT and visitor traffic formalizes the failure the stem describes. Exam caveat: isolation includes management interfaces (BMC, storage, Kubernetes APIs), not only the GPU data VLAN—guest Wi-Fi often pivots through poorly segmented out-of-band nets. Operational check: confirm guest SSID VLANs have no routes to SCADA/AI ToRs, review firewall denies, and run a probe from a guest network showing unreachable OT-adjacent GPU endpoints. Treat SCADA-adjacent AI like other OT enclaves in the water utility: jump hosts, allow-listed management CIDRs, and monitoring that alarms on any guest-to-OT permit. Re-address GPU ToRs onto OT-aligned VRFs and remove the shared guest uplink so a compromised coffee-shop visitor device cannot ARP or scan analytics GPUs that correlate plant telemetry.