Converged OT networks, network slicing, and automated grid control look like three unrelated engineering topics. They share the same underlying risk: in each case, an AI or orchestration model sits at the exact point in the architecture with the broadest reach across the system.
Part 2 of TeckNexus’s Utilities Intelligence Series, sponsored by Palo Alto Networks, builds directly on the 4-layer security architecture introduced in Part 1 to answer three questions utility security and technology leaders run into the moment they move from framework to real deployment:
- How do you secure a converged OT network when dozens of legacy single-purpose systems, from SCADA to metering to workforce voice and video, are consolidated onto one shared platform?
- What does network slicing actually mean for grid security, beyond a performance and quality-of-service capability?
- As distribution automation and automated de-energization systems move from supervised to more autonomous operation, what does it take to secure a system where a security failure has immediate physical consequences, not just a data breach?
Here’s what the research found.
Converged OT Networks: The Security Blind Spot
Utilities historically operated several application-specific networks in parallel, one for SCADA telemetry, another for workforce push-to-talk, another for metering, another for video security. Building and maintaining that many single-purpose networks is expensive, so it is increasingly common to consolidate them onto one converged private wireless platform.
That consolidation solves a real cost and complexity problem. It also creates a security concentration that did not exist when these systems were physically separate: a single shared platform now carries teleprotection, SCADA, metering, workforce, and video traffic simultaneously, and the management layer governing that platform has reach across every one of those domains at once. Legacy network limitations are cited as a top-five challenge in 19.6% of qualified deployments in the TeckNexus evidence base, a clear signal that utilities are actively retiring single-purpose networks in favor of a converged approach.
Convergence risk plays out layer by layer. Radio and spectrum allocation, identity and authentication, and the data plane each carry single-domain exposure if compromised. The management plane is different: if it is compromised, every consolidated domain is exposed at once.
There is also a governance question that is easy to leave unresolved. Three ownership models are common on a converged platform, utility-owned and operated, managed service or third-party operator, and cooperative or shared regional platform, and each carries a different balance of control, operational burden, and risk. When a converged network replaces several previously independent single-purpose networks, security policy ownership can become ambiguous in exactly the way that creates gaps adversaries exploit.
One more risk worth flagging: a converged platform that depends entirely on a centralized core creates a second, distinct exposure. If backhaul or power is lost during a storm, precisely when grid operations matter most, the entire converged network can go dark at once. Distributed or local core components that keep protection and control functions operating independent of backhaul availability are a security requirement as much as a resilience one.
Network Slicing: Segmentation That’s Structural, Not Just Policy
Network slicing allows a single physical network, the same radios, core, and backhaul, to be divided into multiple logically isolated virtual networks, each tuned to a specific operational domain: teleprotection, SCADA, AMI/smart metering, DER control, field workforce, and video security can all run on the same physical infrastructure while behaving as entirely separate networks.
The distinction that matters for security: a traditional network achieves segmentation through policy, firewall rules and VLAN tags layered on top of a network that is, underneath, a single shared fabric. Those policies can be misconfigured or bypassed. A properly architected slice does not rely on policy enforcement to prevent cross-domain traffic; the isolation is structural.
Not every slice carries the same risk. Teleprotection traffic is the highest-stakes slice in the taxonomy, sub-10ms command traffic with direct equipment and safety consequences, requiring continuous, latency-sensitive monitoring. SCADA and distribution automation slices need real-time anomaly detection. DER slices need monitoring tuned to detect falsified demand or generation data as autonomy over generation and storage assets increases.
The slice orchestration layer is where the real exposure sits. It creates, resizes, and reassigns every slice boundary, making it the one component with visibility and control over all domains simultaneously. A compromise of a single slice is contained by design. A compromise of the orchestration layer is not: an adversary with control over it can reshape slice boundaries and erase isolation across teleprotection, SCADA, metering, and workforce domains at once, structurally the same risk pattern as the converged OT management plane.
That risk compounds as utilities adopt AI-driven dynamic slicing, using machine learning to automatically resize or reprovision slices in real time, for example expanding workforce slice capacity during storm restoration while protection traffic holds guaranteed bandwidth. The model making those decisions inherits the same grid-wide blast radius as the orchestration layer itself, and it can be manipulated through nothing more than falsified demand data or spoofed traffic patterns.
There is also a practical bridging problem: many legacy RTUs, relays, and IEDs communicate over serial or narrowband protocols never designed for a shared wireless network. A wireless bridge that faithfully carries a legacy protocol’s bytes without validating its commands has not actually extended the security boundary, only the network’s reach.
Automated Grid Control: Where a Network Failure Becomes a Physical Incident
Distribution automation, Fault Location Isolation and Service Restoration (FLISR), and automated de-energization systems are moving from human-supervised operation toward faster, more autonomous decision loops, because the entire point of these systems is to reduce outage duration from minutes to seconds.
That speed requirement is also what makes automated grid control the highest-stakes use case in this research: a security failure here does not stay contained to a data system. It results in an incorrect physical action on live grid equipment.
Securing automated grid control means protecting every stage of the control loop, not just the network connection, which is where most conventional security thinking starts and stops:
| Control loop stage | Primary attack surface | Required control |
|---|---|---|
| Sensor/telemetry input | Falsified voltage, current, or fault-condition data | Input anomaly detection before the model consumes data |
| Decision model (FLISR / DA logic) | Adversarial manipulation of automated decisions | Runtime integrity checks, adversarial testing |
| Command channel | Unsigned or injected switching / de-energization commands | Dedicated segment, signed command authentication |
| Fail-safe layer | Default-continue on failure, no fail-safe or ambiguous fallback | Explicit, tested fallback behavior for every failure condition |
The hardest part of securing automated grid control is that fail-safe behavior is context-dependent. For an autonomous vehicle, the correct default on failure is almost always a safe stop. Automated grid control has no single universal safe default: de-energizing a line when it should stay live can cut power to hospitals and life-safety equipment, while failing to de-energize when conditions call for it can start a fire. That means fail-safe behavior cannot be left as an implicit vendor assumption. It has to be an explicit, documented, and tested design decision for each automated function, agreed before deployment.
One Risk Pattern, Three Systems
Converged OT networks, network slicing, and automated grid control look like three unrelated topics. They share a single underlying risk pattern: in each case, a model or automated decision system has been placed at the exact point in the architecture with the broadest reach across the system, the converged OT management plane, the slice orchestration layer, and the FLISR/de-energization decision loop.
This is not a coincidence. AI and automation get adopted at these exact points because dynamic resource allocation, dynamic slice provisioning, and sub-second fault response are genuinely hard problems that static, rule-based systems handle poorly. The operational logic is sound. The security consequence is that the model’s trustworthiness now determines the trustworthiness of the single most consequential component in each architecture.
An adversary targeting any of these three systems does not need to breach the platform itself. They only need to corrupt the data the model is making decisions from, falsified telemetry, spoofed demand data, or manipulated sensor feeds. Runtime integrity checks and input anomaly detection are not optional hardening measures here. They are the primary control, because they address the attack path adversaries are most likely to actually use.
What’s Inside the Full Securing Grid-Scale Network Architecture Brief
This article covers the concepts. The full executive brief covers the implementation detail. Securing Grid-Scale Network Architecture: Spectrum, Segmentation, and Automated Grid Control includes:
- A full architecture reference matrix mapping converged OT, slicing, and automated grid control back to the 4-layer framework from Part 1
- A two-stage implementation checklist, vendor and architecture evaluation, then pre-deployment verification, for all three systems, built for evaluation rather than procurement
- Detailed control-loop and orchestration diagrams for converged OT, slicing, and automated grid control deployments
- Three recommendations for implementation teams on where to weight security investment first
FAQ
- Do I need to read Part 1 first? This brief assumes familiarity with the 4-layer security architecture (Core, Edge, AI Ecosystem, Governance) introduced in Part 1, Secure AI-Enabled Private Networks for Utilities.
- Is the implementation checklist framed for procurement or RFPs? No. It’s built for vendor and architecture evaluation and pre-deployment verification, regardless of how a utility selects its vendors: competitive bid, direct negotiation, cooperative procurement, systems integrator relationship, or internal build.
- Is this brief vendor-specific? No. TeckNexus is a vendor-neutral research platform. Palo Alto Networks sponsored this brief but did not contribute to, review, or approve the editorial content prior to publication.
This brief was produced by TeckNexus and sponsored by Palo Alto Networks. The research, analysis, and recommendations are solely those of TeckNexus and reflect the independent judgement of TeckNexus analysts.
