Mike — Thinking Out Loud...
Welcome to Mikeland, a corner of Prescher.com where experience meets unfiltered perspective. After years of advising leaders on complex strategic and operational network and cybersec challenges, Mike uses this space to unpack what’s really happening behind the buzzwords — what actually moves the needle in a positive direction. Whether you’re a founder, owner, operator, or curious observer, here you’ll find practical insights, sharp opinions you can put to work in the real world.
Does Ai Belong in Critical Infrastucture?
Within my teams I'm well known to prefer to stand on the shoulders of giants, and there are plenty of technology and standards giants out there to help us do our work. NERC CIP SITES groups is one we like to follow closely as they tend to lead critical infrastructure environment thinking on secure communications. I had a chance to read the latest draft of NERC's AI/ML paper and it's about what I expected — a careful patient approach to introducing Ai/ML in to the North American grid systems. This is as it should be. The take-a-ways from this good work, in my own words (not theirs) are: Key Takeaways: — Establishes an AI/ML maturity model for electric utilities spanning experimentation, operational decision support, and bounded autonomy. — Reinforces that organizational accountability never transfers to AI. Utilities remain responsible for all outcomes. — Strongly prioritizes reliability, cybersecurity, data quality, governance, and workforce readiness above automation ambitions. — Promotes decision support and human-in-the-loop architectures as the near-term practical path for grid operations. — Identifies autonomous and agentic grid operations as possible future states, but only with extensive validation, regulatory acceptance, and cyber controls. For potential EPC Impact (Design, Build, Secure, Optimize): — Design: Increased demand for AI-ready OT architectures, data pipelines, observability, time synchronization, deterministic communications, and edge computing platforms. — Build: More projects will require integration of AI capabilities into EMS, ADMS, DERMS, cybersecurity, asset-management, and operational analytics environments — Secure: AI systems become new critical assets requiring segmentation, monitoring, validation, supply-chain scrutiny, and protection against model manipulation and data corruption. — Optimize: Creates opportunities for predictive maintenance, anomaly detection, operational decision support, outage response, and workforce productivity improvements. — Consulting/Governance: Likely drives demand for AI maturity assessments, cybersecurity assessments, OT . architecture reviews, AI governance frameworks, and compliance advisory services So, practically where are we going? AI instrumentation in U.S. critical infrastructure should be treated as a reliability tool first and an automation accelerant second—tightly governed, human‑in‑the‑loop, with familiar cyber concepts of (Ai) role based access controls and Zero Trust. Sounds familiar! From NERC’s AI/ML maturity work in 2026 the direction of travel is clear: utilities will need/want to integrate AI through staged maturity levels, robust data governance, and human‑machine teaming; extend security controls and cyber hygiene beyond traditional high‑impact assets into emerging OT and low‑impact domains (RBAC/ZeroT again); and intentionally purposely model, instrument, and protect AI‑driven admin and control so they don’t erode (only enhance) stability or, jump to far ahead of existing standards (which in any large industry, don't get applied in Ai-time dilation of microseconds...it's more like years. Maybe this will all begin to accelerate out there in the real world, but I don't see it yet.
Knowledge Sharing — Learning to Drive
The only way modern critical infrastructure can be sustained is if their teams (the Human Factor) keep pace with the rapidly changing technology which drives it. This is even more true if you've read another opinion on this page regarding NERC CIP's vision on Ai/ML's rapidly evolving impact. Humans are essential to the resilience and reliability equation. A “Front Seat, Side‑by‑Side, then Back Seat” approach lets an OT network consultant guide a customer through new communications technology in a way that builds both confidence and capability. In the front seat, the consultant leads design, deployment, testing, and turn‑up, so the solution is architected correctly and aligned with safety, reliability, and compliance needs from day one. Moving side‑by‑side, they co‑execute changes with the customer’s team, explaining decisions, documenting processes, and transferring practical skills while real work gets done. In the final steps, in the back seat, the consultant steps into a support and review role, allowing the customer to operate and evolve the network independently, but with expert backup when needed. This progression reduces risk, accelerates adoption, and leaves the customer with a resilient OT communications environment they truly understand and can sustain.
Why Boltzmann's Formula for Gas Entropy in a Vacuum Matters in OT Networks
I first heard about Boltzmann’s gas entropy in a vacuum formula in college but never fully appreciated it, until I had been in the large-scale data communication network business for about a decade. Then a light bulb above my headed started to flicker on when I truly appreciate that complex systems...they break. It's not a question of if, just when. That's not good for critical infrastructure. The concept of entropy offers a powerful mental (and actual) model for why some complex OT critical infrastructure networks may be destined to fail, soon. Boltzmann’s determined that a gas in a vacuum naturally spreads out into all available space, moving from an ordered state to a highly disordered one because there are simply more ways for the system to be disordered than ordered. The same thing happens in large OT data communications networks - as we add more devices, protocols, data paths, routes, and security privatizations and filtering, all combined with normal OA&M moves, adds, changes...the “state space” of the network expands. There are far more ways for configurations, interactions, and failures to combine into chaos, or at least mal-function states, than there are for everything to line up in a clean, predictable way. Over time, without strong constraints and oversight (preventive maintenance) operation standards and field and systems work QA, the network drifts toward higher “entropy”, more complexity, more hidden dependencies, and ultimately a more fragile state. For critical infrastructure, that inevitable drift toward disorder is not just inconvenient — it’s dangerous. Increasing complex OT networks are harder to understand, harder to secure, and harder to recover when something breaks. That’s why we have to actively fight this natural tendency by simplifying and at the same time further hardening our designs and doing better knowledge sharing with our customer's operations staff. This means reducing unnecessary variation, standardizing architectures, limiting the number of allowed paths and behaviors, and designing with clear boundaries and deterministic behavior wherever possible, while keeping tight to published system requirements. It all mans, when something does break, fix it, correctly...don't patch it. Don't 'believe' you have solved an issue. KNOW you have solved an issue. By intentionally lowering the entropy factors of our OT communications—through simpler topology logic, well‑defined roles, and robust, testable patterns — we trade a little flexibility, and yes some points of 9's availability, because 20 paths provide more availability potential than 2, but at what cost? Because what we want is overall life-cycle practical reliability - not theoretical reliability. This is what makes for improvements in safety, and resilience in the systems that keep the lights on and the industrial world running.
Follow The Spec. So Your Data Communications Networks Won't be a Wreck!
The advent of Ai tools for and against data security are changing the network design landscape. Even so, most of the architectural and functional design for a given communications project has in fact already been done for us through a myriad of applicable standards, (e.g. IETF, IEEE, ISA/IEC, CISA, NIST, INL CIE/CCE, HIPAA, PCI, CMMI/C, C2/M2, NERC, ISACA, ISC2, SANS, COBIT, ITIL, PMI PMBOK, and ISO). I often hear from customers that there are in fact too many standards and frameworks out there for them to reference - and first they need help in selecting the right one(s). Certainly it is true that this over-abundance of guidance advising us, secure critical infrastructure data network design/build projects and their successful operation have the potential to help self-define a secure communications network, if we let them. To elevate the prospect of creating a sustainable data communications system from a desired outcome to a certainty, remember… "Follow the spec. so your data communications systems won't be a wreck."
Schweitzer Engineering Labratories OT SDN — Fewer Knobs. Fewer Data Disruptions. Fewer Network Engineers!
I have recently had the opportunity to work with SEL's relatively new data network solution on a real-world grid project. This work was to replace a very complex legacy Multi-protocol Label Switching (MPLS) virtualized network where after many years of reliable service, entropy had invaded. The choice was to have rare and expensive MPLS senior network engineers refresh the existing infrastructure - or do something simpler. That something was SEL OT SDN. Here are my own classic data communications network challenges this solution helped address... Deterministic performance: It's funny, coming from years of Cisco Systems switch/route design engagements and way of thinking, as opposed to "More data paths equals more reliability". I quickly learned this is NOT the mantra nor philosophy for OT data network design. Rather, more paths equal more configuration knobs equals more complexity and feature code exposure (bugs) equals more fragility in the overall network. SEL OT SDN takes a more homogeneous (to OT owners/operations) approach. It enforces simple core data network principles including predictable latency and bandwidth, which is critical for protection, control, and real‑time monitoring in power and industrial systems. Stronger security model: Centralized control lets you strictly define which devices can talk, on which paths, and for what purposes, reducing attack surface and lateral movement. Simplified, centralized management: Instead of configuring dozens of switches one by one, policies and paths are managed from a single controller, making complex OT networks easier to operate. In my project, with a focus on knowledge transfer, we were able to hand-off OA&M for the solution to a group of EE grid engineers, NOT to a group of highly skilled data network engineers. This was perhaps the most impressive result (and lesson we learned) on this project. First time that's ever happened on one of my critical infrastructure projects. Built for critical‑infrastructure reliability: SEL designs for harsh environments, fail-over, and redundancy. They are the solution of choice for more than 50% of U.S. grid customers for protective relays. So the SDN fabric can maintain communications even during faults or cyber events. Ready for future grid and OT demands: As more IEDs, sensors, and analytics tools come online, SDN’s flexible, software‑defined paths make it easier to scale and adapt without constant hardware re‑engineering.
Read a good article from the BBC recently on a small trend of Analog Resilience and Security by Antiquity. Cute. The article wasn't focused on critical infrastructure but anybody in this space sees the parallels. U.S.critical infrastructure has dealt with this for years as it dealt with the transition to Smart Everything. The article made me revisit something common in many utilities today, avoiding expensive compliance regimes through data communications architecture manipulation. Couple this with the advent of Ai powered machine speed attack construction and...more soon.
Next Up — Analog Resilience?
MPLS: Build-It-Once, Use-It-Many.
In an OT network, IP packet networking refers to the way data is broken into specific flows and moved between devices—such as RTUs, PLCs, protective relays, SCADA servers, and control centers. Multi-protocol label switching ("MPLS") offers utility operators a way to carry the necessary application traffic across the wide-area network. For example, we might use one MPLS virtual network to connect substation SCADA traffic to the control center, while using separate virtual network—these are called VRFs or “Virtual Route Forwarding tables”—to keep SCADA traffic, protection traffic, voice, engineering access, and business data apart, each in their own virtual network. The traffic may share the same fiber, microwave link, copper, and router hardware, but the virtual network rules keep it separated. The various applications flows have their own private (virtualized) networks. “Build it once, use it many” means creating a standardized tiered and modular network design and configuration using MPLS. If a new data flow is needed, you can either add it to an existing flow (VRF) or create new, all while using the same networking routing hardware infrastructure. Thus, CapEx is greatly reduced for moves, adds or changes to networking logical architecture! We L-O-V-E virtual networks!
Ai Attacks — Don't Panic. Don't Throw Money. Be Practical.
AI is changing cybersecurity not so much by creating entirely new attack methods than by making familiar attacks dramatically faster, more automated, and more persistent. This results in many of the same pre-Ai cybersecurity preventative practices, still being a go-to framework for defense. The exploitation window is shrinking however. Attackers can use large language models to analyze newly disclosed vulnerabilities, reverse-engineer patches, and develop exploits within hours rather than days or weeks. AI-enabled attacks are relentless - don't wear down like a human attacker does. Autonomous or semi-autonomous agents can continuously scan, test access paths, map identity and access-management relationships, and pursue weaknesses without fatigue or coffee runs. Attackers can learn an environment quickly. Tasks that previously took human operators weeks - like understanding permissions, service relationships, and trust boundaries - can be greatly reduced. Asset visibility remains a central problem for organizing a sound defense. Few organizations have complete, real-time visibility into their assets and attack surface. Unknown systems and dependencies cannot be reliably defended. Faster alert response and triage is not enough. Some attack chains may look like legitimate activity and may not generate obvious anomalies. Defenders need proactive validation of what identities, services, and applications are actually able to do. AI creates a defensive opportunity as well as a threat. Organizations are increasing offensive-security spending and can use AI for attack-surface discovery, exposure validation, vulnerability prioritization, and controlled remediation. Automatic patching requires maturity. There must be definitive deliberate organizational support for carefully governed automation—using release rings, staged deployment, monitoring, and rollback—but warns that indiscriminate auto-patching can disrupt operational environments. For critical infrastructure, the central concern is that attacks against operational technology, enterprise IT, identity systems, and third-party services may progress faster than traditional approval, patching, and incident-response procedures. A compromise does not need to involve a custom unique exploit; a conventional attack executed at machine speed may be enough. How about five practical mitigation steps: 1. Maintain a continuously verified asset and dependency inventory. Identify every IT, OT, IoT, cloud, remote-access, identity, and third-party system, including software versions, owners, business or safety functions, network paths, and trust relationships. Continuously compare the inventory with network telemetry, endpoint data, cloud configurations, and vulnerability feeds so that unmanaged or unexpected assets are surfaced quickly. 2. Establish an emergency vulnerability-response process based on exploitability and consequence. Do not rely solely on severity scores or routine patch cycles. Prioritize vulnerabilities using factors such as internet exposure, active exploitation, access to privileged systems, proximity to safety-critical processes, compensating controls, and potential operational impact. Define preapproved decision paths for emergency isolation, mitigation, patching, and executive escalation. 3. Use staged, observable patching and configuration changes. For critical systems, test patches in representative environments, deploy them first to controlled release rings, and monitor system health, process behavior, safety alarms, and network communications before wider rollout. Maintain tested rollback procedures and use temporary controls—such as virtual patching, segmentation, access restrictions, or application allowlisting—when immediate patching is unsafe. 4. Continuously validate identity privileges and attack paths. Use attack-path analysis and least-privilege reviews to determine what users, service accounts, vendors, applications, and AI agents can actually access—not merely what permissions documentation says they should have. Remove stale accounts, reduce standing administrative privileges, enforce phishing-resistant multifactor authentication, protect privileged access, and monitor unusual changes in trust relationships. 5. Automate detection and response, but keep high-impact actions governed. Apply automation to asset discovery, vulnerability correlation, threat hunting, indicator enrichment, and low-risk containment. For actions that could interrupt generation, water treatment, transportation, healthcare, or other essential services, require predefined safeguards such as human approval, dual authorization, maintenance windows, fail-safe states, and tested manual operating procedures. Exercise these controls through red-team and incident-response drills that emulate fast, automated attackers. The practical lesson is that critical infrastructure should not attempt to match AI-driven attackers solely by hiring more analysts or accelerating alert review. It needs machine-speed visibility and prioritization, combined with carefully controlled human oversight for changes that could affect safety, reliability, or continuity of service.