Author: Vincent Rodriguez
Why Batch Pipelines Break AI Agents: The Case For Streaming-First Network Operations
By Shazia Hasnie, Ph.D, editorial review by IEEE Techblog team member Sridhar Talari Rajagopal
Abstract:
The adoption of AI agents in network operations has exposed a critical architectural gap. Most enterprise data pipelines were designed for dashboards and reporting, not autonomous decision-making. When AI agents consume data from batch-oriented pipelines, five distinct failure modes emerge: stale data, memory gaps, delete blindness, schema fragility, and coordination failure. This article examines each failure mode, explains the underlying mechanism, and proposes architectural remedies grounded in streaming-first design principles. It also connects each technical failure to measurable business outcomes—extended downtime, recurring incidents, compliance exposure, silent decision degradation, and cascading impact. The result is both a diagnostic framework for I&O leaders and a financial argument for treating streaming data infrastructure as the prerequisite for autonomous operations.
Introduction: The Data Foundation Gap
Artificial intelligence is reshaping network operations. AI agents promise to detect anomalies, diagnose root causes, and execute remediation faster than human engineers. The industry has focused attention on models, GPUs, and orchestration frameworks. The data layer remains largely unexamined.
This is a critical oversight. Most enterprise data pipelines were built for human consumers. They serve dashboards, weekly reports, and historical analysis. Humans tolerate latency. Humans bring context. Humans notice when something looks wrong.
AI agents require something fundamentally different. They need real-time context. They need historical state. They need accurate representations of current reality. When these requirements are not met, agents do not complain. They act—on incomplete information, with incorrect assumptions, producing wrong outcomes.
The gap between what batch pipelines deliver and what agents require creates failure modes that most teams do not see until an agent makes the wrong decision. Recent analysis has identified the economic dimensions of this gap [1], while industry resources have begun documenting the specific failure patterns that arise when batch processing meets autonomous agents [6]. This article extends that work by identifying five distinct failure modes and proposing a streaming-first architectural response.
FIVE FAILURE MODES: ANATOMY OF BATCH-TO-AGENT MISMATCH
The following five failure modes represent the specific ways batch data pipelines undermine autonomous network operations. Each is examined through its mechanism—how the batch pipeline architecture produces the failure—its operational consequence, and the streaming-first architectural remedy that eliminates it. Together, they form a diagnostic taxonomy for any I&O team evaluating whether their data foundation is ready for Agentic AI.
Failure Mode 1: Stale Data
Mechanism: Batch telemetry pipelines poll, collect, and process data in cycles. Data is extracted on a schedule, transformed in bulk, and loaded into a destination—a warehouse, data lake, time-series database, or feature store that holds a static, point-in-time snapshot of the source. Between cycles, the pipeline holds no current state. An AI agent that spins up between cycles receives a snapshot of the past.
Consequence: The agent diagnoses an outage using telemetry from five minutes ago. The network state has changed during that interval. Routes have shifted. Traffic has been redirected. Thus, the agent’s diagnosis is based on a reality that no longer exists. Remediation actions applied to a past state can worsen the current incident. The agent becomes a liability rather than an asset. Industry documentation confirms that AI agents require continuous data freshness to function correctly [5].
Architectural Remedy: Streaming telemetry replaces cyclical polling with continuous event push. Data flows from source to consumer in real time, ingested directly into the streaming platform’s durable event log [2]. The agent consumes from a live stream, not a stale snapshot. Context acquisition takes milliseconds. The cognitive loop remains intact. This is not an add-on to the batch pipeline. It is a structural replacement of the ingestion layer.
Failure Mode 2: Memory Gap
Mechanism: Batch pipelines deliver windows of data—the last hour, the last day, the last processing cycle. They do not preserve the sequence of events that led to the current moment. Historical context is stripped away with each new extract. The pipeline knows what happened. It does not know what happened before.
Consequence: An agent responding to an interface flap cannot answer the most basic diagnostic question: has this happened before? It cannot correlate the current event with the three similar events that occurred in the preceding 24 hours. It cannot detect the pattern that would reveal a degrading optical module. Every incident appears isolated. Pattern recognition—the core value proposition of AI-driven operations—is structurally impossible. The distinction between streaming and batch architectures for these use cases has been well-documented [4].
Architectural Remedy: A durable event log with configurable retention serves as the agent’s memory [2]. Unlike a batch window, which discards history with each new extract, the event log preserves the ordered sequence of all events within the retention period. The agent seeks backward in the log on startup and replays the preceding window of telemetry. Pattern detection across time becomes native to the architecture. This is not a separate cache layered on top. It is the storage layer itself—immutable, ordered, and built for event replay from any offset.
Failure Mode 3: Delete Blindness
Mechanism: Batch pipeline’s Extract, Transform, Load (ETL) processes compare snapshots of source data. They do not watch the database transaction log. They identify what exists at two points in time and process the difference. When a record is deleted from the source system, the pipeline has no way of distinguishing between a row that was deleted and a row that was simply omitted due to extraction error, filtering logic, or schema mismatch. The absence of a row is not an event. It is a gap. Batch pipelines are not designed to interpret gaps as meaningful signals. The record simply vanishes from the next extract. The downstream consumer—an AI agent or any other system—has no way of knowing the record ever existed.
Consequence: The agent queries the downstream data store and finds no record for a deactivated account, a revoked certificate, or a cancelled change order. It cannot distinguish between “never existed” and “was deleted,” so it treats the absence as neutral.
The agent makes decisions on ghosts—data that no longer exists in source systems. In access control scenarios, this is not an operational error. It is a security incident. This specific failure mode has been identified in analyses of batch processing limitations for AI agents [6].
Architectural Remedy: Change data capture (CDC), implemented through Kafka Connect with Debezium connectors, reads the database transaction log directly [2], [8]. Debezium provides CDC source connectors for MySQL, PostgreSQL, MongoDB, SQL Server, and other databases — capturing inserts, updates, and deletes as discrete events with explicit operation types by tailing the database’s native transaction log. Nothing is invisible to the pipeline. The streaming architecture knows not only what exists but what ceased to exist. This is not an ETL workaround with soft-delete flags. It is a structural capability of the integration layer, converting database changes into first-class events the moment they occur.
Failure Mode 4: Schema Fragility
Mechanism: Source database schemas change over time. Columns are renamed, added, deprecated, or re-typed. Batch pipelines are configured for a specific schema at extraction time. When the source schema changes, the pipeline responds in one of two ways. It fails silently and drops the affected field from every subsequent extract. Or it fails loudly and stops processing entirely.
Silent failure is the more dangerous outcome. The pipeline continues delivering data. The consumer has no indication that a critical field is missing.
Consequence: The agent continues operating without a critical data input. It makes decisions with incomplete information. It has no awareness that its reasoning is compromised. The wrong decisions accumulate. By the time the missing field is discovered—often through an operational failure rather than a monitoring alert—the cost of remediation includes auditing and correcting every decision made during the degradation window.
Architectural Remedy: A schema registry with compatibility enforcement validates schema changes before they propagate to downstream consumers [2]. Streaming platforms can enforce backward and forward compatibility rules at the producer level. A breaking schema change is rejected before any data is published. The pipeline fails loudly and immediately. This is not a documentation standard or a code review checklist. It is a structural governance layer embedded in the streaming architecture itself, preventing silent field loss at the point of ingestion.
Failure Mode 5: Coordination Failure
Mechanism: When multiple AI agents operate on batch-derived data, each agent consumes a separate, potentially inconsistent snapshot. Agent A receives data from the 10:00 AM extract. Agent B receives data from the 10:15 AM extract. The extracts differ. Each agent holds a different version of reality. There is no shared, ordered log of events that all agents consume.
Consequence: Two agents respond to the same cascading failure. Agent A identifies a BGP routing issue and begins rerouting traffic. Agent B identifies a DNS resolution failure and begins modifying name server configurations. Neither agent knows the other acted. The redundant changes compete. The conflicting configurations create new instability. The original incident expands rather than resolves. What began as a single point of failure becomes a cascade that erodes trust in autonomous operations.
Architectural Remedy: A shared, ordered event log serves as a single source of truth for all agents in the system. Every agent consumes from the same log. Actions taken by one agent are published back to the log as events, immediately visible to all others [7]. Coordination becomes native to the architecture.
Visibility alone, however, does not prevent conflicting actions. Two agents may observe the same anomaly and both initiate remediation before either’s action becomes visible on the log. In practice, this is addressed through complementary mechanisms layered on the same event-driven model: action intent events that signal an agent is about to act, giving others a window to defer; idempotency keys that prevent duplicate remediation from causing harm; and lightweight leases for resources that should only be modified by one agent at a time. These mechanisms do not require a central coordinator. They are published to the same log, consumed by the same agents, and enforced through the same ordered stream.
This is not a separate orchestration layer or message bus bolted onto the side. It is the core of the streaming platform—a unified, ordered, multi-consumer event stream that provides both the shared state and the coordination primitives that eliminate the inconsistent snapshots batch architectures produce by default.
Batch-to-Streaming Reference Architecture — Five Failure Modes and Their Architectural Remedies
THE UNIFIED DIAGNOSTIC FRAMEWORK
The five failure modes translate into a practical audit that I&O leaders can apply to their own infrastructure. Each question corresponds to a specific architectural requirement.
The Five-Question Audit
- Can the data pipeline deliver real-time context to an agent the moment it wakes up? If not, the system is vulnerable to stale data failures.
- Can the agent access the preceding window of telemetry to detect patterns across events? If not, the system is vulnerable to memory gap failures.
- Does the pipeline capture deletes as explicit events with operation types? If not, the system is vulnerable to delete blindness.
- Does the pipeline detect schema changes before they propagate to downstream consumers? If not, the system is vulnerable to schema fragility.
- Do all agents share a single, ordered view of events with visibility into each other’s actions? If not, the system is vulnerable to coordination failure.
A negative answer to any one of these questions signals a data foundation that is not ready for autonomous operations. The model is not the bottleneck. The GPUs are not the bottleneck. The telemetry pipeline is.
THE MIGRATION PATH: FROM BATCH TO STREAMING-FIRST
Adopting a streaming-first architecture does not require abandoning existing batch investments overnight. For most organizations, the transition follows a coexistence model: streaming pipelines are introduced alongside batch pipelines, not as an immediate replacement.
The practical starting point is to identify the highest-value agent—the one whose decisions carry the greatest operational or financial consequence—and convert its data pipeline first. This agent is typically the one where stale data, memory gaps, or coordination failures have produced measurable incidents. Converting this single pipeline to streaming telemetry with a durable event log delivers a targeted operational improvement while the rest of the batch estate continues to function.
From there, adoption expands incrementally. Each additional agent is migrated as operational experience with the streaming platform grows. Teams develop competence in offset management, schema governance through the registry, and backpressure handling while batch pipelines continue to serve lower-priority consumers. The streaming and batch estates coexist for a transition period measured in months, not days.
This incremental approach also reveals where streaming delivers the greatest marginal benefit. Not every data flow requires real-time treatment. Dashboards fed by hourly batch extracts may serve their purpose indefinitely. The streaming investment should be directed at the pipelines that feed autonomous agents—the flows where the five failure modes carry real operational consequence. The goal is not to stream everything. It is to stream the right things first.
THE BUSINESS IMPACT: FROM TECHNICAL FAILURE TO FINANCIAL CONSEQUENCE
Technical failures in the data pipeline do not remain technical. They cascade into business outcomes that appear on budget reviews, SLA reports, and board presentations. Each failure mode carries a distinct financial consequence.
Stale Data → Extended Downtime
An agent diagnosing from stale telemetry makes incorrect decisions. Remediation applied to a past state can worsen the current incident. Mean Time to Resolution increases. For revenue-generating services, every minute of extended downtime translates to lost revenue and SLA penalty accrual.
Consider an illustrative model: a Tier-1 service provider processing $50M in customer transactions per hour, 5-minute stale-data induced misdiagnosis that extends an outage by 15 minutes represents $12.5M in direct revenue loss—not counting SLA penalties, regulatory scrutiny, or reputational harm. The cost of a single such incident can exceed the annual investment in the streaming infrastructure that would have prevented it. If even a portion of such incidents are eliminated by replacing the batch pipeline feeding the diagnostic agent with a streaming backbone, the infrastructure investment is recovered in a single avoided outage.
Memory Gap → Recurring Incidents
An agent without historical context cannot recognize chronic conditions. A flapping interface, a memory leak, or a degrading optical module triggers the same alert repeatedly. Each occurrence consumes GPU inference cycles. Each occurrence generates a ticket. Each occurrence may require human escalation. The cumulative cost of a single undiagnosed chronic issue, multiplied across an enterprise network over a year, represents operational expenditure that a stateful agent could eliminate.
Delete Blindness → Compliance and Security Exposure
An agent acting on deleted records makes authorization decisions based on invalid state. A deactivated account granted access. A revoked certificate treated as valid. In regulated industries, these errors are compliance violations with defined financial penalties and reporting obligations. The cost of a single access control error caused by ghost data can exceed the annual cost of the streaming infrastructure that would have prevented it.
Schema Fragility → Silent Decision Degradation
When a batch pipeline drops a critical field, the agent does not fail loudly. It continues operating with incomplete inputs. Decisions degrade silently. The cost includes not only the direct operational impact but the effort of auditing and correcting every decision made during the degradation window. Silent failure multiplies eventual remediation cost.
Coordination Failure → Cascading Impact
When multiple agents act on inconsistent views of reality, they create new problems. Redundant changes compete. Conflicting configurations destabilize the environment. The original incident expands. The cost includes extended resolution time, additional engineering effort, and eroded trust in autonomous operations. Organizational credibility is a balance sheet item that coordination failure depletes.
The Aggregated View
Taken together, the five failure modes represent a predictable drain on AI investment returns. An organization that deploys expensive GPU infrastructure, fine-tunes capable models, and implements event-driven orchestration [3]—but feeds all of it with a batch data pipeline—has built an autonomous operations capability on a foundation that guarantees suboptimal outcomes. The streaming backbone is not an incremental cost. It is the insurance policy that protects the returns on every other AI infrastructure investment.
CONCLUSION: STREAMING-FIRST AS THE ARCHITECTURAL PREREQUISITE
The five failure modes share a common root cause. Batch data pipelines were designed for human consumers who tolerate latency, bring context, and notice anomalies. AI agents tolerate nothing. They act on what they receive.
Each failure mode is addressable within a unified streaming data architecture. Streaming telemetry solves stale data by replacing cyclical polling with continuous event push. Durable event logs solve memory gaps by preserving the sequence of events with configurable retention, allowing agents to replay history and detect patterns across time. Change data capture—a structural component of the streaming architecture implemented through Kafka Connect and Debezium—solves delete blindness by reading database transaction logs directly, capturing inserts, updates, and deletes as discrete events with explicit operation types. A schema registry with compatibility enforcement solves schema fragility by validating schema changes before they propagate downstream, catching breaking changes at the source rather than discovering them after agent failure. A shared, ordered event log solves coordination failure by serving as a single source of truth that all agents consume, ensuring every agent operates on the same reality with visibility into every other agent’s actions—complemented by intent events, idempotency keys, and lightweight leases that prevent conflicting actions without a central coordinator.
These are not disparate tools. They are structural elements of a single streaming data architecture. Apache Kafka provides the durable, shared event log at the core. Kafka Connect provides the integration framework for change data capture, ingesting database changes as first-class events. Schema Registry provides the compatibility governance layer. Together, they form a complete data foundation where stale data, memory gaps, delete blindness, schema fragility, and coordination failure are eliminated by design—not patched after the fact.
These architectural components eliminate the data-layer failure modes. But real-time data also enables real-time action—and that speed demands an execution-layer governance framework. Policy-as-code engines ensure that agent decisions, even when based on perfect context and full state, are validated against operational guardrails before they become cluster changes. The streaming backbone delivers the context. The policy layer ensures that context is acted upon safely.
This streaming architecture is not an end in itself. It is the data foundation upon which event-driven network operations can be built. While the streaming backbone eliminates the data-layer failure modes, organizations that pair it with event-driven compute unlock an additional dimension of efficiency. When a telemetry event flows through the event log and an anomaly is detected, that same stream can trigger the Kubernetes Event-driven Autoscaling (KEDA) of inference workloads [3]—spinning up the right-sized model at the right moment, on the right context. The streaming backbone delivers the context. Event-driven orchestration delivers the compute. Together, they close the loop from detection to inference, ensuring the agent has both the data and the compute it needs without the waste of always-on infrastructure.
The barrier is not technology. Each of these architectural components is proven, open-source, and deployed in production environments today. The barrier is architectural awareness. Organizations that invest in a streaming-first data architecture will deploy AI agents that deliver on their promise. Organizations that do not will discover these failure modes in production—after the wrong decision is already made.
The streaming data architecture is not a performance upgrade for Agentic AI. It is the architectural prerequisite.
REFERENCES
[1] P. Madduri and A. L. Thakur, “The Financial Trap of Autonomous Networks: Scaling Agentic AI in the Telecom Core,” IEEE ComSoc Technology Blog, April 2026. [Online]. Available: https://techblog.comsoc.org/2026/03/30/the-financial-trap-of-autonomous-networks-scaling-agentic-ai-in-the-telecom-core/
[2] Apache Software Foundation, “Apache Kafka Documentation.” [Online].
Available: https://kafka.apache.org/42/getting-started/introduction/
[3] Cloud Native Computing Foundation, “KEDA: Kubernetes Event-driven Autoscaling.” [Online]. Available: https://keda.sh/
[4] Streamkap, “Streaming ETL vs. Batch ETL: A Decision Framework.” [Online].
Available: https://streamkap.com/resources-and-guides/streaming-etl-vs-batch-etl
[5] Streamkap, “Real-Time vs Batch Data for AI Agents: Why Freshness Matters.” [Online]. Available: https://streamkap.com/resources-and-guides/real-time-vs-batch-data-for-agents
[6] Streamkap, “Why AI Agents Can’t Use Batch Data.” [Online]. Available: https://streamkap.com/resources-and-guides/why-agents-cant-use-batch-data
[7] Redpanda, “Building safe, multi-agent AI systems in Redpanda Agentic Data Plane.” [Online]. Available: https://www.redpanda.com/blog/adp-governed-multi-agent-ai-cloud
[8] Debezium Community, “Debezium: Open-Source Change Data Capture,” Debezium Documentation. [Online]. Available: https://debezium.io/
ABOUT THE AUTHOR
Shazia Hasnie, Ph.D., is VP, Product Strategy and Innovation at Cuber AI, focused on Agentic Network Operations, AI-driven automation, and streaming data architectures. Her work explores the intersection of autonomous systems, cloud-native infrastructure, and the economic models that make AI operations sustainable at scale.
Key Differences Between Network Cybersecurity and Control System Cybersecurity & Why It Matters
By Joe Weiss with Alan J Weissberger
Introduction:
The Operational Technology (OT) [1.] cybersecurity [2.] community continues to ignore control system cyber-incidents [3.] – a governance failure masquerading as a vocabulary issue.
IT and OT network data breaches are documented in multiple sources such as the Verizon Data Breach Report, CISA documents, and others. Palo Alto Networks notes that nearly 70% of industrial firms had an OT cyber-attack last year. Those cyber-attacks were from data breaches – not always causing equipment damage.
Industrial organizations need an integrated and cyber resilient IT-OT framework to address this increasingly sophisticated threat landscape, but it appears they’re not well prepared to defend against network or control system cyberattacks.
Note 1. Operational Technology refers to the combination of hardware and software designed to directly monitor, control, and manage physical devices, industrial equipment, and critical processes.
Note 2. Cybersecurity can be defined as the practice of protecting people, systems and data from cyberattacks by using various technologies, processes and policies.
Note 3. Cyber-incidents are defined as electronic communications between systems that effects Confidentiality, Integrity, or Availability. This is an IT-centric definition because Safety is not addressed.
Image Credit: txOne Networks
There are two communities addressing cybersecurity:
- The more prevalent community is the one involved in data security. This includes IT and OT network security and is focused on data breaches.
- The second community is focused on engineering security. It is less well-known, but very critical. This discipline is focused on safety, reliability, and productivity.
Professor Ross Anderson stated in his seminal book, “Security Engineering: A Guide to Building Dependable Distributed Systems,” that security engineering is about building systems to remain dependable in the face of malice, error, or mischance.”
The culture gap between network security and engineering organizations will be addressed in the June 2026 issue of IEEE Computer magazine, “Packets and Process: What Network Security and Engineering Get Wrong About Each Other.”
Discussion:
The OT cybersecurity community’s mission is to focus on OT network cyber-attacks. However, its charter does not extend to malicious and unintentional control system cyber incidents involving process sensors, actuators, motors, turbines, transformers, etc.
Importantly, control system cyber incidents can be physics-related rather than network-related. The 2007 Aurora vulnerability test at the Idaho National Laboratory destroyed a 2 MW commercial diesel generator by remotely restarting the generator out- of-phase with the grid. This is a gap in protection of the electric grid and was addressed in the October 2025 IEEE Computer magazine article, “Physics-Based Cyberattacks Against Electric Power Grids and Alternating Current Equipment.”
Idaho National Laboratory ran the Aurora Generator Test in 2007 to demonstrate how a cyberattack could destroy physical components of the electric grid. The diesel generator used in the experiment beginning to smoke as shown below:
Aurora Generator Test. Image Credit: Wikipedia
Industry and government OT cybersecurity experts continue to downplay the threat of control system cyberattacks and ignore actual control system incidents that do not originate from OT networks by not calling them cyber-related.
There have been more than 20 million control system cyber incidents that have killed more than 30,000 people. Most of these incidents occurred below the IP-Ethernet layers where there is no cyber forensics nor cybersecurity training. As a result, the majority of these incidents were not identified as being cyber-related.
This indicates that control system cyber incidents that are not classified as IP-Ethernet incidents need their own classification as issues to be addressed by cybersecurity policy, especially for critical infrastructure where accidental and/or malicious cyber failures could result in widespread death and destruction.
Given the current geopolitical environment, nation-states are actively reassessing their capabilities to disrupt adversary infrastructure at scale. In this context, dismissing control system cyber incidents solely because they do not originate from traditional IP-based vectors introduces significant risk. Threat actors are increasingly targeting critical infrastructure and associated control systems—spanning both IT and OT domains—leveraging diverse attack surfaces beyond conventional network entry points.
A parallel issue within both the IT and OT security communities is the tendency to classify incidents as “cyber” only when malicious intent is confirmed. This narrow definition is problematic.
For example, the July 2024 CrowdStrike-related outage, which caused global operational disruptions, clearly met the functional criteria of a cyber-incident due to its systemic impact on networked systems. However, its non-malicious origin led some security governance bodies to exclude it from cyber incident classification. Such distinctions can undermine resilience planning, as they fail to account for the full spectrum of cyber-induced operational risk, including software supply chain failures and systemic misconfigurations.
ERPI Focus:
The European Risk Policy Institute (ERPI) was founded by the Australian Risk Policy Institute as part of the Global Risk Policy Network. EPRI Chairman wrote in a blog titled, “Control system cyber incidents and network breaches are apples and oranges”:
“From our ERPI / 3°C World SRP® perspective, Weiss is pointing at a governance failure masquerading as a vocabulary issue: if you define “cyber incident” through an IT breach lens, you will miss (or dismiss) the incidents that actually move risk —those that degrade continuity lifelines by disrupting physical processes. He makes the case that control-system cyber incidents include electronic/automation failures across sensor signals, control logic, firmware and field device communications, and that many are non-malicious yet still produce loss of view, loss of control, equipment damage, and safety/environmental consequences.
What matters strategically is the reporting and response architecture. Breach-centric metrics (and the cultural reflex that “no attack = no incident”) bias organizations toward under-detection, weak root-cause discipline, and false trend comparisons—exactly when coupled infrastructures are most fragile and repair cycles are tight. Weiss’s bridge condition is practical: align engineering and security on a shared incident definition, and train both communities in control-system incident reality so that operational anomalies are treated as cyber-relevant signals, not “maintenance noise.”
If you’re responsible for critical infrastructure, this is a reminder to recalibrate your incident taxonomy and your board narrative: the control-room outcome is the headline, and the network story is only one possible path to it.”
The Crucial Importance of Process Sensors:
Process sensors represent the biggest gap between data security and engineering security. Perplexity.ai explains this gap in detail -see below, but first we distinguish between data security and engineering security:
- Data security focuses on IP-native devices such as firewalls, routers, switches, etc.
- Engineering security should be focused on engineering devices and equipment that could cause equipment damage and deaths but have no cybersecurity, authentication, or cyber forensics. This includes process sensors, actuators, motors, transformers, inverters, etc. However, that focus is often not achieved.
Perplexity.ai on the Data vs. Information Security Gap:
Process sensors sit at the junction of physical process integrity and digital telemetry, so they expose a gap that neither data security teams nor engineering security teams fully own today. In practice, security teams tend to focus on protecting data pipelines, identities, and networks, while engineering teams focus on measurement accuracy, calibration, availability, and safety; the sensor itself often falls between those disciplines.
Process sensors are not just data endpoints; they are safety- and control-relevant instruments whose outputs can drive operators, PLCs, DCS logic, and downstream automation. If a sensor is spoofed, degraded, miscalibrated, or manipulated, the result is not only bad data but potentially unsafe or physically damaging control actions.
Traditional data security assumes the main problem is confidentiality, integrity, and availability of information in transit or at rest. But process sensors often use legacy field protocols, serial links, gateways, or embedded devices that were engineered for function and reliability rather than cryptographic assurance, making them difficult to secure using conventional enterprise controls.
Engineering security is usually optimized for process correctness, alarms, redundancy, and fail-safe behavior, not adversarial manipulation of the measurement layer. That means the sensor may be treated as trustworthy instrumentation, even though compromised or false sensor data can undermine control logic, operator decisions, and safety systems.
The core mismatch: The real issue is that data security protects the pipeline, while engineering security protects the process, but process sensors belong to both domains. Because ownership is split, sensor trust, authentication, anomaly detection, and physical tamper resistance are often addressed inconsistently or not at all, creating a blind spot at the boundary between cyber and physical risk.
Highlights of Sensors Converge Conference Presentation:
To address these important issues and gaps, I will be presenting at the Sensors Converge conference in Santa Clara, CA on May 7, 2026. The title of my talk is, “Process Sensor Monitoring for Cybersecurity, Reliability, and Safety.” The presentation will include the following topics:
- Process sensors (Level 0 devices) are inherently cyber vulnerable yet remain largely unrecognized by cybersecurity organizations.
- Process sensor incidents, both malicious and unintentional, have caused catastrophic and fatal cyber/operational events across multiple sectors, but were not identified as being cyber-related.
- Fatalities have occurred in every decade since the 1980s, including this decade.
- Monitoring process sensors at the physics level can materially improve reliability, safety, and cybersecurity.
- A discussion of what a process sensor cybersecurity program should include and what organizations should be involved.
- The implications of process sensors which are not cyber-secure, because they don’t meet U.S. and/or EU cybersecurity requirements.
Nation-state actors, including Russia, China, and Iran, understand Level 0 cyber deficiencies. In sharp contrast, most cyber defenders do not and won’t identify process sensor incidents as being cyber-related. This gap helps explain why process sensor cybersecurity remains largely absent from OT security forums and RSA Conference discussions. It may also explain why government OT cybersecurity advisories don’t include insecure Level 0 devices, even though process sensors provide the trusted input to controllers and SCADA/DCS systems.
Conclusions:
Network cybersecurity functions across IT and OT domains, and control system engineering organizations, operate with fundamentally different objectives, taxonomies, and thresholds for identifying and classifying cyber incidents. This divergence has led to a persistent disconnect in how incidents affecting control systems are recognized and addressed within broader network security governance frameworks. Dismissing control system cyber events because they fall outside narrow, IT-centric definitions is not merely a semantic issue—it reflects a structural governance gap with direct implications for critical infrastructure resilience.
To address this, industry and government stakeholders must converge on a harmonized definition of cyber incidents that encompasses both network-centric and control system–centric perspectives. This alignment should be supported by cross-domain training, ensuring that both network security practitioners and engineering teams possess sufficient understanding of control system architectures, threat models, and failure modes. Without such integration, efforts to compare incident frequency, severity, and systemic impact across IT networks and control systems will remain inconsistent and misleading. More critically, this fragmentation will continue to obscure systemic risk, leaving essential infrastructure sectors exposed to increasingly sophisticated and multi-domain cyber threats.
About Joe Weiss:
Joe Weiss is an expert on control system cyber security. He authored the 2010 book, “Protecting Industrial Control Systems from Electronic Threats.”
Joe is an ISA Fellow, Emeritus Managing Director of ISA99, an IEEE Senior Member, has patents on instrumentation, control systems, and OT networks. He is a professional engineer with CISM and CRISC certifications and is a member of Control Process Automation Hall of Fame.
References:
https://www.paloaltonetworks.com/resources/research/state-of-ot-security-report
OT Cybersecurity: The Guide to Securing Industrial Systems
Verizon Business sees escalating risks in mobile and IoT security
Anthropic’s Project Glasswing aims to reshape IT cybersecurity
Emerging Cybersecurity Risks in Modern Manufacturing Factory Networks
Cybersecurity threats in telecoms require protection of network infrastructure and availability
StrandConsult Analysis: European Commission second 5G Cybersecurity Toolbox report
IEEE/SCU SoE Virtual Event: May 26, 2022- Critical Cybersecurity Issues for Cellular Networks (3G/4G, 5G), IoT, and Cloud Resident Data Centers
The Financial Trap of Autonomous Networks: Scaling Agentic AI in the Telecom Core
By Pavan Madduri with Ajay Lotan Thakur
The telecom industry wants autonomous, self-healing networks, but nobody is looking at the GPU bill. Running Agentic AI 24/7 “just in case” will bankrupt your IT department and ruin your ESG goals. The only way to survive the autonomous era is ruthless, event-driven orchestration that scales cognitive compute to absolute zero.
Introduction – The Compute Crisis:
The Compute Crisis Nobody is Talking About
Everyone in telecom right now is obsessed with “self-healing” autonomous networks. The vendor pitch sounds amazing. Just drop in some Agentic AI, let it watch your data plane, and watch it fix anomalies without a human ever touching a keyboard. But there’s a massive trap hiding underneath all that hype, and enterprise architects are completely ignoring it. It comes down to the raw physics of AI compute.
Unlike your standard microservices, which just run deterministic, compiled code on cheap CPU cycles, Agentic AI needs massive foundation models. To actually reason through a network failure, these models have to load gigabytes of weights into Video RAM and generate tokens. You need dedicated GPUs for this. We aren’t talking about cheap, stateless API calls here. These are the most expensive, power-hungry workloads in your entire datacenter.
If a telco tries to run an autonomous core the old-fashioned way by keeping high-end GPU nodes spinning 24/7 just in case a BGP route flaps, their cloud bill is going to wipe out any operational savings the AI was supposed to deliver.
The reality is that autonomy is no longer just a software problem. It’s a financial one. The telcos that actually win will not be the ones with the smartest AI. They will be the ones who figure out how to build a strict “scale-to-zero” environment. They need to spin up that expensive cognitive compute exactly when it is needed, and kill it the exact second the job is done.
Why Traditional Auto-scaling is Broken for AI:
When platform engineers first see the compute costs of running these AI agents, their first instinct is usually just to slap standard Kubernetes Horizontal Pod Autoscaling (HPA) on the cluster and call it a day. But standard HPA was built for stateless web servers, not massive cognitive engines. If you try to use it for Agentic AI in a telecom core, you’re going to fail for two big reasons.
The Cold-Start Penalty: Traditional autoscaling is entirely reactive. It sits around waiting for a CPU to hit 80% before it decides to scale up. In telecom, SLAs are measured in sub-milliseconds. If you wait for an anomaly to spike your CPU, then provision a new GPU node, pull a massive AI container image, and load the model weights into VRAM, you are talking about minutes of delay. By the time your AI agent actually wakes up to fix the problem, you have already breached your SLA.
CPU Utilization is a Liar: For AI workloads, standard hardware metrics are completely misleading. A GPU could be pegged at 90% utilization just thinking through a minor log warning, while a massive, critical network failure is stuck waiting in the queue. If your scaling logic is tied to hardware metrics instead of the actual severity of the event queue, you are just going to burn budget scaling blindly.
We have to abandon reactive resource metrics entirely and move to event-driven orchestration.
The Fix – Event-Driven Orchestration:
If standard HPA is broken for this, what is the fix? You have to completely decouple the infrastructure from the workload using strict, event-driven orchestration.
Instead of keeping baseline infrastructure running just to maintain a state, you treat cognitive compute as 100% ephemeral. You don’t scale based on how hard the CPU is working. You scale based on the exact depth and severity of the anomaly queue.
To actually build this, architects need purpose-built event-driven scalers like KEDA (Kubernetes Event-driven Autoscaling). KEDA lets your cluster completely bypass those reactive hardware metrics and listen directly to the network’s data plane.
But how do you avoid the cold-start latency of booting a fresh GPU pod? KEDA solves this by reacting to the event queue length itself rather than waiting for an existing pod’s CPU to max out. By the time a traditional HPA notices a CPU spike, the system is already overwhelmed. (To solve this exact issue in production, I open-sourced a custom KEDA scaler specifically designed to scrape and react to native GPU metrics, allowing the orchestrator to scale cognitive workloads preemptively. You can view the architecture on [GitHub])
KEDA intercepts the telemetry trigger at the source. When paired with a warm pool of paused GPU nodes and pre-pulled container images, KEDA can scale a pod from zero to active in milliseconds. The infrastructure is anticipating the load based on the queue, not reacting to the stress of it.
Here is what the workflow actually looks like when you do it right:
- The Trigger: Telemetry picks up a severe anomaly ,like a sudden 5G slice degradation, and pushes an event straight to a message broker like Kafka.
- The Scale-Up: KEDA intercepts that exact metric and instantly provisions a dedicated, GPU-backed AI pod from a warm standby pool.
- The Execution: The Agentic AI loads into VRAM, figures out the blast radius of the anomaly, and executes a fix. This is usually by reconciling the state through a GitOps controller.
- The Kill Switch: The absolute millisecond that the event queue clears and the network is stable, the orchestrator aggressively terminates the pod and gives the GPU back to the node pool.
You only pay the premium GPU tax during moments of active reasoning. The 24/7 idle tax is gone.
Architecting the Scale-to-Zero Core:
To make this scale-to-zero dream a reality, you have to fundamentally change how you handle network observability. The biggest mistake I see architects make is tightly coupling their monitoring tools with their AI execution layer. If your observability stack is running on the same hardware as your AI engine, you are literally wasting premium GPU compute just to watch logs.
You need a strict, physical separation of concerns:
The Watchers (The Lightweight Control Plane):
Your network data plane needs to be monitored by lightweight, CPU-efficient edge collectors like Prometheus or OpenTelemetry. These sit right at the edge, continuously eating millions of telemetry data points and BGP state changes. Because they don’t do any complex reasoning, they run incredibly cheap on standard CPU nodes.
The Thinkers (The Heavyweight Execution Plane):
Your expensive AI models are completely isolated in a separate, GPU-backed node pool that literally defaults to zero instances.
When the Watchers spot an anomaly, they don’t try to fix it. They just fire an alert to KEDA. KEDA then wakes up the Thinkers, spinning up the exact number of GPU pods needed to handle that specific blast radius. By decoupling the watchers from the thinkers, you guarantee that not a single cycle of GPU compute is wasted on baseline monitoring.
The Bottom Line:
Autonomous telecom networks are going to happen. But trying to brute-force the infrastructure provisioning is a fast track to bankrupting your IT department. The smartest Agentic AI in the world is useless if you can’t afford the cloud bill to run it.
Furthermore, this isn’t just about protecting the IT budget. Running idle GPUs 24/7 creates a massive, unnecessary carbon footprint. By enforcing a scale-to-zero architecture, telcos can drastically reduce the energy consumption of their autonomous networks, turning a massive ESG liability into a sustainable operational model.
Autonomy is no longer just a software engineering problem. It is an infrastructure balancing act. If Agentic AI is going to survive in the telecom core, we have to ditch legacy threshold scaling and embrace strict, event-driven orchestration.
Tools like KEDA give us the ability to build networks that are both cognitively brilliant and financially ruthless. We can spin up massive intelligence at the exact millisecond of failure and scale right back to zero the moment the network is healed.
References and Further Reading:
- Unlocking Energy Saving in Telecom Networks: A Path to a Sustainable Future – A deep dive into the operational and ESG mandates driving energy efficiency in modern telecom infrastructure.
- KEDA Documentation: Kubernetes Event-driven Autoscaling – Technical specifications for decoupling workload scaling from standard CPU/Memory metrics.
- keda-gpu-scaler – An open-source custom KEDA scaler I developed to enable event-driven autoscaling specifically tied to native GPU telemetry and queue depth.
Building and Operating a Cloud Native 5G SA Core Network
How Network Repository Function Plays a Critical Role in Cloud Native 5G SA Network
HPE Aruba Launches “Cloud Native” Private 5G Network with 4G/5G Small Cell Radios
…………………………………………………………………………………………….
About the Author:
Pavan Madduri is a Cloud-Native Architect, CNCF Golden Kubestronaut, and active IEEE researcher specializing in enterprise infrastructure automation, Agentic SREs, and Kubernetes networking. He designs scalable, zero-trust cloud environments and frequently writes about the intersection of AI governance and cloud-native infrastructure.
Connect with Pavan Madduri on [LinkedIn] .
Disclaimer: The author acknowledges the use of AI-assisted tools for structural formatting, language refinement, and copyediting during the drafting of this article. The core architectural concepts, technical opinions, and engineering strategies remain entirely original.
Part II: Outcomes from the IEEE–ITU Sustainable Climate Symposium
IEEE–International Telecommunication Union (ITU) Symposium on Achieving a Sustainable Climate – Part II
by Marta Koch, IEEE Europe Member & PhD Researcher & Teaching Facilitator, Imperial College London with Alan J Weissberger, IEEE Techblog Content Manager
Editor’s Note: This is the second of a two-part article summarizing this ITU-IEEE Symposium. Part I is here.
Why AI Matters for Sustainable Telecommunications:
The IEEE–ITU Symposium on underscored that developing AI‑enabled sustainable telecommunications networks represents a fundamentally multidisciplinary challenge situated at the intersection of communications engineering, energy systems, computer science, climate science, and public policy. Delivering meaningful climate outcomes through digital technologies requires not only progress in algorithms, architectures, and network optimization, but also institutional frameworks that enable responsible, interoperable, and scalable deployment across diverse operational contexts.
A systems-level view of telecommunications sustainability os needed—beyond traditional performance metrics—to one where future networks are intelligent, adaptive, and energy‑efficient by design. Building on ITU analyses positioning AI, advanced connectivity, and digital platforms as key enablers of environmental action, participants also highlighted the importance of understanding their environmental trade‑offs.
Machine Learning for Climate‑Aware Network Optimization:
Machine learning (ML) is emerging as a strategic enabler of climate‑aligned energy management across telecom networks. ML techniques now underpin network‑wide energy optimisation, demand and renewable generation forecasting, power–communications coordination, and climate services such as early warning and adaptive planning. In resource‑constrained or climate‑vulnerable contexts, ensuring model robustness, transparency, and alignment with sustainability objectives is essential. Research priorities include energy‑ and carbon‑aware model design, integration of grid and resilience metrics, and standardised evaluation methods for sustainability‑critical ML applications.
Use Cases for Energy‑Efficient Operations via AI:
Important AI applications include traffic prediction, adaptive resource management, energy‑aware RAN optimisation, and predictive network sleep modes. Cross‑layer and multi‑timescale optimisation enables maximum energy efficiency without compromising service quality.
Network Resilience Under Climate Stress:
With climate‑related disruptions increasing globally, AI‑enabled predictive maintenance, self‑healing architectures, and climate‑aware planning have become core to resilient network operations. These approaches align with UN‑led initiatives on climate services and disaster early warning systems.
Power–Communications Interdependencies:
Participants highlighted the coupling between power and communications systems, emphasising cascading‑failure scenarios and the potential of AI‑enabled digital twins for joint optimisation. These perspectives align with ITU frameworks on digital public infrastructure and smart sustainable cities, which stress interoperability across physical and digital systems.
Sustainable AI and Hardware–Software Co‑Design:
Effective climate action depends on co‑optimising physical and digital infrastructure—from data centres and energy systems to ML models and orchestration layers. Sustainable network intelligence requires energy‑efficient algorithms, hardware‑aware deployment, and system‑level governance. The approach aligns with ITU’s Green Digital Action initiative and related efforts by ISO, IEC, UNEP, and WMO to advance standards‑driven, science‑informed digital sustainability.
Digital Public Infrastructure and Climate‑Resilient Digitalization:
Digital Public Infrastructure (DPI)—open and interoperable systems for identity, payments, data exchange, and connectivity—was highlighted as foundational for inclusive, climate‑resilient digital transformation. Effective DPI design requires governance, risk management, and safeguards, as emphasised by UNDP and the UN Office for Digital and Emerging Technologies.
IEEE Technology Assessment Tool:
The symposium introduced an IEEE envisioning proof‑of‑concept tool to support sustainable network planning through systematic assessment of digital and energy technologies, evaluating trade‑offs across performance, sustainability, and resilience.
Importance of International Standards:
A central outcome of the symposium was recognition of the critical role of international standardization in translating technological innovation into practical, climate‑relevant impact. As telecommunications networks become increasingly software‑defined, AI‑driven, and interconnected with energy and physical infrastructure systems, standards provide the technical and governance foundations essential for interoperability, data integrity, trustworthiness, and long‑term sustainability. Presentations from global standards organizations highlighted the importance of harmonized frameworks that can minimize market fragmentation, facilitate cross‑border interoperability, and incorporate environmental and resilience criteria directly into network design, operation, and lifecycle management.
Standards were identified as key to scalable, trustworthy AI deployment, with interoperability and data governance central to ITU‑T Study Group 5’s agenda.
Sessions also reinforced the importance of equitable access—advancing AI‑assisted network planning and cost‑efficient deployment in climate‑vulnerable regions to balance sustainability, affordability, and inclusion.The symposium further emphasized the need for a system‑level approach, recognizing that telecommunications networks operate as integral components within broader energy, transport, and urban infrastructure ecosystems. In this context, AI and machine learning increasingly serve as coordinating layers across hardware, software, and physical assets, enabling cross‑domain optimization. Standardization plays a crucial enabling role by aligning interfaces, performance metrics, and assessment methodologies across sectors, thereby supporting coherent operation of digital and physical systems under conditions of resource constraint, geopolitical uncertainty, and climate stress.
Implications for IEEE Communications Society:
For IEEE Communications Society (ComSoc) members, discussions highlighted a dual responsibility and opportunity. There is a responsibility to ensure future communications networks are designed to minimize environmental impact, maintain resilience under climate extremes, and promote equitable access to essential connectivity and data sharing.
Simultaneously, there is an opportunity for researchers and practitioners to contribute technical evidence, performance models, and quantitative metrics that inform and advance international standardization.
By maintaining sustained collaboration among research institutions, industry stakeholders, standards bodies, and policy entities—and engaging with the broader frameworks of global climate and sustainable‑development governance—the telecom community can play a defining role in enabling energy‑efficient, climate‑aware, and resilient digital infrastructure worldwide.
…………………………………………………………………………………………………………………………………………………………………………
References:
[1] M. Koch and UN Climate Technology Centre and Network (UN CTCN), “Maximizing Emerging Trends in Locally-Led AI Solutions for Climate Action,” SDG Knowledge Hub, International Institute for Sustainable Development, 2025.
https://sdg.iisd.org/commentary/guest-articles/maximizing-emerging-trends-in-locally-led-ai-solutions-for-climate-action/
[2] M. Koch, “Stakeholder asset-mapping of climate technology infrastructures,” Nature Reviews Earth & Environment, 2025.
DOI: 10.1038/s43017-025-00737-z
[3] World Meteorological Organization, Early Warnings for All: Executive Action Plan 2023–2027, WMO, Geneva, 2023.
https://wmo.int/media/magazine-article/overview-of-early-warnings-all-executive-action-plan-2023-2027
[4] United Nations Environment Programme, Global Climate Risk Assessment Framework, UNEP, Nairobi, 2023.
https://www.unepfi.org/themes/climate-change/2023-climate-risk-landscape/
[5] ITU, WMO, UNEP, and UNFCCC, Global Initiative on Resilience to Natural Hazards through AI Solutions, United Nations, Geneva. https://www.itu.int/en/ITU-T/extcoop/ai4resilience/Pages/default.aspx
[6] ITU-T Study Group 5, Work Programme on Environment, Climate Action, Circular Economy and Electromagnetic Fields, International Telecommunication Union, Geneva.
https://www.itu.int/en/ITU-T/studygroups/2022-2024/05/
[7] International Telecommunication Union – Telecommunication Standardization Sector, Building Digital Public Infrastructure for Cities and Communities, ITU, Geneva, 2025.
https://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-SMARTCITY-2025-9-PDF-E.pdf
[8] International Telecommunication Union – Telecommunication Standardization Sector, Frontier Technologies to Protect the Environment and Tackle Climate Change (T-TUT-ICT-2020-02), ITU, Geneva, 2020.
https://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ICT-2020-02-PDF-E.pdf
[9] International Telecommunication Union – Telecommunication Standardization Sector, Smart Sustainable Cities and Digital Infrastructure Frameworks, ITU, Geneva, 2025.
https://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-SMARTCITY-2025-6-PDF-E.pdf
[10] International Telecommunication Union, Green Digital Action, ITU, Geneva.
https://www.itu.int/initiatives/green-digital-action/
[11] World Bank Group, Digital Public Infrastructure and Development: A World Bank Group Approach, Washington, DC, 2025.
https://openknowledge.worldbank.org/entities/publication/cca2963e-27bf-4dbb-aa5a-24a0ffc92ed9
[12] United Nations Office for Digital and Emerging Technologies and United Nations Development Programme, DPI Safeguards Initiative. https://www.dpi-safeguards.org
……………………………………………………………………………………..
About Marta Koch:
Marta Koch is an IEEE member, PhD Researcher and Teaching Facilitator at Imperial College London, Research Associate at the Oxford Computational Political Science Group at the University of Oxford and Research Consultant at UNOPS. She has been nominated as research delegate to UN Climate Change (UNFCCC), UNEP, UNDESA, UNIDO and ITU meetings.
Part I: Outcomes from the IEEE–ITU Sustainable Climate Symposium
IEEE–International Telecommunication Union (ITU) Symposium: Achieving a Sustainable Climate 2025 Outcomes: Capitalizing on AI for Energy-Efficient and Climate Resilient Telecommunications Networks
By Marta Koch, IEEE Europe Member & PhD Researcher & Teaching Facilitator, Imperial College London with Alan J Weissberger, IEEE Techblog Content Manager
Editor’s Note: This is the first of a two part article summarizing this ITU-IEEE Symposium. The second article is here.
Introduction:
Telecommunications networks are increasingly recognized as critical infrastructure for both economic development and societal resilience. As climate change accelerates and energy systems undergo rapid transformation, the telecoms sector faces a dual challenge: 1.] Reducing its own environmental footprint while ensuring reliable connectivity under growing physical, climatic, and 2.] Systemic stress.
These two themes were the focus of the IEEE–International Telecommunication Union (ITU) Symposium on Achieving a Sustainable Climate, which was held in December 2025 at the ITU headquarters in Geneva.
The symposium convened researchers, industry leaders, standards bodies, and United Nations agencies to examine how digital transformation, artificial intelligence (AI), and emerging ICT solutions can support the energy transition and climate mitigation and adaptation, and the governance and standardisation developments needed to effectively and sustainably leverage this technology globally.
As an Imperial College London researcher and IEEE member, I attended the symposium as part of ongoing work at the intersection of telecommunications, artificial intelligence, and climate action, with a focus on the governance, design, and deployment of AI-enabled systems for climate mitigation and adaptation, as well as the environmental and systems-level sustainability of AI-driven digital infrastructure.
Organization and Collaboration:
The symposium was co-organized by the ITU Telecom Standardization Bureau (ITU-T) and ITU T Study Group 5, which focuses on environment, climate action, circular economy, and electromagnetic fields. This collaboration underscored the central role of international standardization in shaping sustainable, climate-resilient ICT systems and provided a strong standards-oriented framework for discussions on AI deployment, energy efficiency, and network resilience [6].
Symposium photo courtesy of the ITU
……………………………………………………………………………………………………………………………………….
Key Discussion Themes:
Across plenary sessions, thematic panels and case studies, several cross-cutting issues emerged:
- Expanding role of AI and machine learning (ML) in enabling more energy-efficient, resilient, and inclusive telecommunications networks.
- The role of the ICT sector in accelerating decarbonisation and strengthening climate adaptation, particularly in support of the global energy transition
- Interactions between physical and digital infrastructure systems, including electrification and communications, as enablers of circular economy models
- Digital and AI standardisation as foundations for sustainable, climate-resilient development and place- and people-based outcomes
- Intersections between decarbonisation, electrification, circularity, digital access, and equity
- Public–private collaboration models supporting climate finance, eco-design, and scalable deployment in climate-vulnerable and developing regions.
International Policy Governance Perspectives at the Symposium:
The symposium featured strong representation from international organisations, grounding technical discussions in policy, standards, finance, and real-world deployment realities across the ICT, energy, and climate domains.
ITU delegates Tomas Lamanauskas, Seizo Onoe, Bilel Jamoussi, and Dominique Würges emphasized the importance of aligning global mandates with local needs in sustainable ICT ecosystems.
The following are essential to both decarbonization and resilient digital infrastructure: robust standards, interoperability, and AI governance frameworks (particularly those addressing environmental sustainability, circular economy principles, and responsible management of electromagnetic fields). That message was consistent with the opening plenary’s framing of international policy, eco-design, and circularity as foundational for practical deployment.
Energy and electrification perspectives were discussed by Dario Liguti of the United Nations Economic Commission for Europe and Norela Constantinescu of the International Renewable Energy Agency. They highlighted the global energy transition focus on both progress and persistent gaps in decarbonization and electrification. Coordinated planning between energy systems and telecommunications can significantly improve resilience, system efficiency, and equity for climate-adaptive services.
Industrial deployment and logistics viewpoints were provided by Luca Longo of the United Nations Industrial Development Organization and Yaxuan Chen of the Universal Postal Union. They described how integrated ICT and energy solutions could enhance operational outcomes, sustainability, and service delivery across industrial and sectoral contexts. Cross-sector collaboration was identified as a critical enabler of scalable impact.
Standards alignment was discussed by Matthew Doherty of the International Electrotechnical Commission and Noelia García Nebra of the International Organization for Standardization. They reinforced the essential need for international standards frameworks for translating research and innovation into deployable, interoperable solutions. This theme resonated strongly with the standards session’s emphasis on practical tools to support sustainable, climate-resilient outcomes across markets and regions.
Financing and digital innovation perspectives were contributed by Seth Ayers of the World Bank, who highlighted how digital and AI-enabled approaches can help unlock finance, de-risk investment, and expand access to sustainable energy and connectivity solutions in underserved and marginalised contexts, supporting climate resilience and inclusive growth.
Disaster risk reduction and emergency management perspectives were contributed by Yuji Maeda of NTT, Inc., Maeda-son highlighted how advanced aerial technologies and environmental sensing can be used to mitigate the impacts of extreme natural events. He shared ground-breaking research at NTT in Japan demonstrating the world’s first drone designed to act as a “flying lightning rod”, an invention selected by TIME Magazine as one of the Best Inventions of 2025. They are using a protective Faraday cage and a conductive tether to deliberately trigger and safely redirect lightning strikes away from critical infrastructure, illustrating the potential for drone-enabled systems to improve emergency response, infrastructure protection, and climate resilience.
Innovation diffusion was addressed by Heather Jacobs of WIPO GREEN, who underscored the importance of technology transfer, matchmaking platforms, and collaboration mechanisms in scaling affordable and climate-relevant digital and energy technologies. Her remarks highlighted the symposium’s focus on public–private partnerships and global deployment pathways.
A European Green Digital Coalition case study was presented by Ilias Iakovidis of the European Commission Directorate-General for Communications Networks, Content and Technology. He highlighted the development and deployment of a scientific methodology to assess the Net Carbon Impact of ICT solutions. His contribution demonstrated how digitalisation’s sustainability benefits can be quantified and scaled through coordinated industry engagement, financial sector alignment, and evidence-based deployment guidelines.
The growing Global Initiative on Resilience to Natural Hazards through AI Solutions was presented by Elena Xoplaki, Vice-Chair of the UN ITU, WMO, and UNEP Global Initiative on Resilience to Natural Hazards. She explained how AI, data integration, and resilient telecommunications networks underpin multi-hazard early warning systems and climate risk reduction efforts worldwide [5].
……………………………………………………………………………………………………………………………………….
Part II. of this report, listing all references, is here.
About Marta Koch:
Marta Koch is an IEEE member, PhD Researcher and Teaching Facilitator at Imperial College London, Research Associate at the Oxford Computational Political Science Group at the University of Oxford and Research Consultant at UNOPS. She has been nominated as research delegate to UN Climate Change (UNFCCC), UNEP, UNDESA, UNIDO and ITU meetings.
Her research and consultancy work focuses on digital and AI governance, development and deployment for climate action and sustainable development, with particular emphasis on climate technology digital and physical infrastructures and the sustainability of AI and digitalisation. Her research has been funded by the United Nations, Natural Environment Research Council (NERC) and the UK Science & Technology Network (STN) under the Foreign, Commonwealth & Development Office and the Department for Science, Innovation & Technology, and endorsed by the UNESCO International Decade of Sciences for Sustainable Development.
From LPWAN to Hybrid Networks: Satellite and NTN as Enablers of Enterprise IoT – Part 2
By Afnan Khan (ML Engineer) and Mehsam Bin Tahir (Data Engineer)
Introduction:
This is the second of two articles on the impact of the Internet of Things (IoT) on the UK Telecom industry. The first is at
Enterprise IoT and the Transformation of UK Telecom Business Models – Part 1
Executive Summary:
Early Internet of Things (IoT) deployments relied heavily on low power wide area networks (LPWANs) to deliver low-cost connectivity for distributed devices. While these technologies enabled initial IoT adoption, they struggled to deliver sustainable commercial returns for telecom operators. In response, attention has shifted towards hybrid terrestrial–satellite connectivity models that integrate Non-Terrestrial Networks (NTN) directly into mobile network architectures. In 2026, satellite connectivity is increasingly positioned not as a universal coverage solution but as a resilience and continuity layer for enterprise IoT services (Ofcom, 2025).
The Commercial Limits of LPWAN-Based IoT:
LPWAN technologies enabled low-cost connectivity for specific IoT use cases but were typically deployed outside mobile core architectures. This limited their ability to support quality of service guarantees, enterprise-grade security and integrated billing models. As a result, LPWAN deployments often remained fragmented and failed to scale into durable enterprise business models, restricting their long-term commercial value for telecom operators (Ofcom, 2025).
Satellite and NTN as Integrated Mobile Extensions:
In contrast, satellite and NTN connectivity extends existing mobile networks rather than operating as a parallel IoT layer. When non-terrestrial connectivity is integrated into 5G core infrastructure, telecom operators are able to deliver managed IoT services with consistent security, performance and billing models across both terrestrial and remote environments. This architectural shift allows satellite connectivity to be packaged as part of a unified enterprise service rather than sold as a standalone or niche connectivity product (3GPP, 2023). Figure 1 illustrates this hybrid terrestrial–satellite model, showing how satellite connectivity functions as an extension of mobile networks to support continuous IoT services across urban, rural and remote environments.
Figure 1: Hybrid terrestrial–satellite connectivity supporting continuous IoT services across urban, rural and remote environments.
Industrial Use Cases and Hybrid Connectivity
In sectors such as offshore energy, agriculture, logistics and remote infrastructure monitoring, IoT deployments prioritise coverage continuity and service resilience over peak data throughput. Hybrid terrestrial–satellite connectivity enables operators to offer coverage guarantees and service level agreements that LPWAN-based models could not reliably support. In 2026, Virgin Media O2 launched satellite-enabled services aimed at supporting rural connectivity and improving resilience for IoT-dependent applications, reflecting a broader operator strategy to monetise non-terrestrial coverage where reliability is a core requirement (Real Wireless, 2025).
The commercial implications of this transition are further illustrated in Figure 2, which contrasts siloed LPWAN deployments with integrated mobile and satellite IoT services delivered through a unified network core.
Figure 2: Transition from siloed LPWAN deployments to integrated mobile and satellite IoT services delivered through a unified network core.
Satellite Connectivity and Enterprise IoT at Scale:
The UK Space Agency has identified hybrid terrestrial–satellite connectivity as an enabling layer for remote industrial operations, environmental monitoring and agricultural IoT systems. UK-based firms such as Open Cosmos are contributing to this model by integrating Low Earth Orbit satellite connectivity with existing mobile core networks. This approach allows telecom operators to deliver end-to-end managed connectivity for enterprise customers without deploying separate IoT network stacks, converting coverage limitations from a cost burden into chargeable, service-based revenue opportunities (Open Cosmos, 2024; UK Space Agency, 2025).
Conclusion
In 2026, IoT is reshaping the UK telecom sector primarily by enabling new revenue models rather than by driving incremental network expansion. Following the limited commercial success of LPWAN-based IoT strategies, satellite and Non-Terrestrial Network integration is increasingly deployed as an extension of mobile networks to provide coverage continuity and service guarantees for industrial and remote use cases. When integrated into 5G core architectures, satellite connectivity enables telecom operators to monetise resilience and reliability as part of managed enterprise services rather than offering standalone connectivity. Taken together, these developments show that satellite and NTN integration has become a critical enabler of scalable, enterprise-led IoT business models in the UK (Ofcom-2025; 3GPP-2023).
…………………………………………………………………………………………………………………………………………………………………………
References:
Ofcom. (2025). Connected Nations UK report.
https://www.ofcom.org.uk
Real Wireless. (2025). Satellite to mobile connectivity and the UK market.
https://real-wireless.com
UK Space Agency. (2025). Connectivity and space infrastructure briefing
https://www.gov.uk/government/organisations/uk-space-agency
Open Cosmos. (2024). Satellite solutions for IoT and Earth observation.
https://open-cosmos.com
3GPP. (2023). Non-Terrestrial Networks (NTN) support in 5G systems.
https://www.3gpp.org/news-events/ntn
Non-Terrestrial Networks (NTNs): market, specifications & standards in 3GPP and ITU-R
Keysight Technologies Demonstrates 3GPP Rel-19 NR-NTN Connectivity in Band n252 (using Samsung modem chip set)
Telecoms.com’s survey: 5G NTNs to highlight service reliability and network redundancy
ITU-R recommendation IMT-2020-SAT.SPECS from ITU-R WP 5B to be based on 3GPP 5G NR-NTN and IoT-NTN (from Release 17 & 18)
China ITU filing to put ~200K satellites in low earth orbit while FCC authorizes 7.5K additional Starlink LEO satellites
Samsung announces 5G NTN modem technology for Exynos chip set; Omnispace and Ligado Networks MoU
Enterprise IoT and the Transformation of UK Telecom Business Models – Part 1
By Afnan Khan (ML Engineer) and Raabia Riaz (Data Scientist)
Introduction:
This is the first of two articles on the impact of the Internet of Things (IoT) on the UK Telecom industry. The second is at
From LPWAN to Hybrid Networks: Satellite and NTN as Enablers of Enterprise IoT – Part 2
Executive Summary:
In 2026, the Internet of Things (IoT) is fundamentally changing the UK telecom sector by enabling new business models rather than simply driving incremental network upgrades.
As consumer mobile markets show limited YoY growth between 2025 and 2026, telecom operators have prioritised IoT-led enterprise services as a source of new revenue (as per Ofcom-2025; GSMA-2024). Investment has shifted away from consumer facing upgrades towards private networks, managed connectivity and long-term service contracts for industry and infrastructure. This change reflects a broader move from usage-based connectivity towards service-based delivery.
IoT and Enterprise Connectivity through Private 5G:
Figure 1: Transition from consumer mobile connectivity to enterprise IoT services in the UK telecom sector, highlighting the shift towards managed connectivity and long-term service contracts.
The growth of private 5G and managed enterprise networks represents one of the clearest IoT driven business shifts. Industrial customers increasingly require predictable performance, low latency and enhanced security, which are not consistently available through public mobile networks. 5G Standalone architecture enables features such as network slicing and low latency communication, allowing operators to sell connectivity as a managed service rather than a commodity product (Mobile UK, 2024).
In the UK, this model is visible in projects such as the Port of Felixstowe private 5G trials supporting automated port operations and asset tracking (BT Group, 2023), the Liverpool City Region 5G programme focused on connected logistics (DCMS, 2022), the West Midlands 5G transport and connected vehicle projects (WM5G, 2023) and Network Rail 5G rail monitoring trials supporting safety and asset management (Network Rail, 2024). These deployments are typically delivered through long term enterprise contracts.
Together, these projects illustrate how connectivity is increasingly sold as a managed operational capability embedded within enterprise workflows rather than them being priced through consumer-style data usage as illustrated in figure 1.
IoT and Long-Term Infrastructure Revenue:
IoT enables telecom operators to participate in long-term infrastructure-based revenue models. The UK national smart meter programme illustrates this shift. By the third quarter of 2025, more than 40 million smart and advanced meters had been installed across Great Britain, with around 70% operating in smart mode (Department for Energy Security and Net Zero, 2025).
These systems rely on continuous, secure connectivity over long lifecycles. The Data Communications Company network processes billions of encrypted messages each month, creating sustained demand for resilient connectivity (DCC, 2024). Ofcom has linked the growth of such systems to increased regulatory focus on network resilience where connectivity underpins critical national infrastructure, while the National Cyber Security Centre has highlighted security risks associated with large IoT deployments (Ofcom, 2025; NCSC, 2024).
For telecom operators, these deployments favour long-term service contracts and regulated infrastructure partnerships over short-term retail revenue models.
Conclusions:
In 2026, IoT is transforming the UK telecom sector primarily by reshaping how connectivity is monetised rather than by driving incremental network upgrades. As consumer mobile markets show limited growth, telecom operators have increasingly aligned investment with enterprise IoT demand through private 5G deployments and long-term infrastructure connectivity. These models prioritise predictable performance, security and service continuity over mass-market scale. Private 5G projects across ports, transport networks and logistics hubs demonstrate how IoT demand has accelerated the commercial adoption of 5G Standalone capabilities, allowing operators to sell connectivity as a managed operational service embedded within enterprise workflows (Mobile UK, 2024). At the same time, national smart infrastructure programmes such as smart metering illustrate how IoT supports long-duration connectivity contracts that favour regulated partnerships and resilient network design over short-term retail revenue (Department for Energy Security and Net Zero, 2025; DCC, 2024). Taken together, these developments indicate that IoT is no longer an adjunct to UK telecom networks. Instead, it has become a central driver of enterprise-led, service-based business models that align network investment with stable, long-term revenue streams and critical infrastructure requirements.
…………………………………………………………………………………………………………………………………………………………..
References:
BT Group. (2023). BT and Hutchison Ports trial private 5G at the Port of Felixstowe.
https://www.bt.com/about/news/2023/bt-hutchison-ports-5g-felixstowe
Data Communications Company. (2024). Annual report and accounts 2023–24.
https://www.smartdcc.co.uk/our-company/our-performance/annual-reports/
Department for Digital, Culture, Media and Sport. (2022). Liverpool City Region 5G Testbeds and Trials Programme.
https://www.gov.uk/government/publications/5g-testbeds-and-trials-programme
Department for Energy Security and Net Zero. (2025). Smart meter statistics in Great Britain Q3 2025.
https://www.gov.uk/government/collections/smart-meters-statistics
GSMA. (2024). The Mobile Economy Europe.
https://www.gsma.com/mobileeconomy/europe/
Mobile UK. (2024). Unleashing the power of 5G Standalone.
https://www.mobileuk.org
National Cyber Security Centre. (2024). Cyber security principles for connected places.
https://www.ncsc.gov.uk
Network Rail. (2024). 5G on the railway connectivity trials.
https://www.networkrail.co.uk
Ofcom. (2025). Connected Nations UK report.
https://www.ofcom.org.uk
MTN Consulting: Satellite network operators to focus on Direct-to-device (D2D), Internet of Things (IoT), and cloud-based services
IoT Market Research: Internet Of Things Eclipses The Internet Of People
Artificial Intelligence (AI) and Internet of Things (IoT): Huge Impact on Tech Industry
ITU-R M.2150-1 (5G RAN standard) will include 3GPP Release 17 enhancements; future revisions by 2025
5G Americas: LTE & LPWANs leading to ‘Massive Internet of Things’ + IDC’s IoT Forecast
GSA: 102 Network Operators in 52 Countries have Deployed NB-IoT and LTE-M LPWANs for IoT
LoRaWAN and Sigfox lead LPWANs; Interoperability via Compression
IEEE/SCU SoE Virtual Event: May 26, 2022- Critical Cybersecurity Issues for Cellular Networks (3G/4G, 5G), IoT, and Cloud Resident Data Centers
Automating Fiber Testing in the Last Mile: An Experiment from the Field
By Said Yakhyoev with Sridhar Talari & Ajay Thakur
The December 23, 2025 IEEE ComSoc Tech Blog post on AI-driven data center buildouts [1.] highlights the urgent need to scale optical fiber and related equipment[1]. While much of the industry focus is on manufacturing capacity and high-density components inside data centers, a different bottleneck is emerging downstream— a sprawling last-mile network that demands testing, activation, and long-term maintenance. The AI-driven fiber demand coincided with the historic federal broadband programs to bring fiber to the premises for millions of customers[2]. This not only adds near-term pressure on fiber supply chains, but also creates a longer-term operational challenge: efficiently servicing hundreds of thousands of new fiber endpoints in the field.
As standard-setting bodies and vendors are introducing optimized products and automation inside data centers, similar future-proofing is needed in the last-mile outside plant. This post presents an example of such innovation from a field perspective, based on hands-on experimentation with a robotic tool designed to automate fiber testing inside existing Fiber Distribution Hubs (FDHs).
While central office copper terminating DSLAMs—and Optical Line Terminals (OLTs) in Passive Optical Networks (PONs)—aggregate subscribers and automate testing and provisioning, FDHs function as passive patch panels[3] that deliberately omit electronics to reduce cost. Between an OLT and the subscriber, the passive distribution network remains fixed. As a result, accessing individual ports at a local FDH—and anything downstream of it—remains a manual process. In active networks, DSLAMs and OLTs can electronically manage thousands of subscribers efficiently, but during construction this manual access is a bottleneck. There are likely tens of thousands of FDHs deployed nationwide.
Consider this problem from a technician’s perspective: suburban and urban Fiber to the Home (FTTH) networks are often deployed using a hub-and-spoke architecture centered around FDHs. These cabinets carry between 144 and 432 ports serving customers in a neighborhood, and each line must be tested bidirectionally[4]. In practice, this typically requires two technicians: one stationed at the FDH to move the test equipment between ports, and another at the customer location or terminal.
Testing becomes difficult during inclement weather. Counterintuitively, the technician stationed at the hub—often standing still for long periods—is more exposed than technicians moving between poles in vehicles. In addition to discomfort, there is a real economic penalty: either a skilled technician is tied up performing repetitive port switching, or an additional helper must be assigned. Above all, dependence on both favorable weather and helper availability makes testing schedules unpredictable and slows network completion.
To mitigate this bottleneck, we developed and tested Machine2 (M2)—a compact, gantry-style robotic tool that remotely connects an optical test probe inside an FDH, allowing a single technician to perform bidirectional testing independently.
M2 was designed to retrofit into a commonly deployed 288-port Clearfield FDH used in rural and small-town networks. The available space in front of the patch panel—approximately 9.5 × 28 × 4 inches—constrained the design to a flat Cartesian mechanism capable of navigating between ports and inserting a standard SC connector. Despite the simple design, integrating M2 into an unmodified FDH in the field proved more challenging than expected. Several real-world constraints shaped the redesign.
 |
 |
| FDH cabinet. Space to fit an automated switch | M2 installed for dry-run testing |
Space and geometry constraints: The patch panel occupies roughly 80% of the available volume, leaving only a narrow strip for motors, electronics, and cable routing. This forced compromises in pulley placement, leadscrew length, and motor orientation, limiting motion and requiring multiple iterations. The same constraints also limited battery size, making energy efficiency a primary design concern.
Port aiming: The patch panel is composed of cassettes with loosely constrained SC connectors. Small variations in connector position led to unreliable insertions. After repeated attempts, small misalignments accumulated, rendering the system ineffective without corrective feedback.
Communications reliability: A specialized cellular modem intended for IoT applications performed poorly for command-and-control. Message latency ranged from 1.5 seconds to over 12 seconds – and in some cases minutes – making real-time control impractical. In rural areas of Connecticut and Vermont, cellular coverage was also inconsistent or absent. Thus, the effort was abandoned between 2022 and 2024.
When the project resumed, an unexpected solution emerged. A low-cost consumer mobile hotspot proved more reliable than the specialized modem when cellular signal was available, providing predictable latency and stable Wi-Fi connectivity inside the FDH—even with the all-metal cabinet door closed and locked.
To further reduce latency, we explored using the fiber under test itself as a communication channel, a kind of temporary orderwire. When a two-piece Optical Loss Test Set (OLTS) is connected across an intact fiber, the devices indicate link readiness via an LED. By tapping this status signal, M2 can infer when a technician at the far end disconnects the meter and automatically connects to the next port. While this cue-based mode is limited, it enables near-zero-latency coordination and rapid testing of multiple ports without spoken or typed commands, which proved effective for common field workflows.
A second breakthrough came from addressing port aiming with vision. Standard computer-vision techniques such as edge detection were sufficient to micro-adjust the probe position at individual ports. To detect and avoid dust caps, M2 also uses a lightweight edge-ML[5] model trained to recognize caps under varying illumination. Using only 30 positive and 30 negative training images, the model correctly detected caps in over 80% of cases.
In our experience, lightweight vision models proved sufficient for practical field tasks, suggesting that accessibility—not sophistication—may drive adoption of automation in outside-plant environments.
| M2’s simplified vision sequence to account for nonuniformity of connectors | ||
 |
 |
 |
| Camera view: clipped to region of interest. Rough position | Processed view adjust -12px left, -16px up | Processed view after micro-adjusting |
What building M2 revealed:
- Overcoming communications issues led to an intriguing idea: optical background communication, where modulated laser light subtly changes ambient illumination inside the FDH that a camera can detect and extract instructions.
- M2 also proved useful beyond testing. For example, in a verify-as-you-splice workflow, M2 can lase a specific fiber as confirmation before splicing. Interactive port illumination and detection allow a single technician to troubleshoot complex situations.
The comparison below is illustrative and reflects observed workflows rather than controlled benchmarking.
Illustrative comparison of testing workflows in our experience
| Human helper (remote) | M2 | |
| Connect next port | 1–1.5 s | 2.5–4 s |
| Connect random / distant port | 8–24 s | ~11–30 s |
| Ease of deployment | Requires flat ground, fair weather, ground-level FDH | ~15 min setup; requires software familiarity |
| Functionality | Highly adaptable | Limited to 2–3 functions |
| Economics | Inefficient for small networks | Well-suited for small and medium networks |
| Independence factor | Low; requires two people | High; largely weather-independent |
| Best use | Variable builds, high adaptability | Repetitive builds, independent workflows |
Early insights for OSP vendors and standards
Building M2 revealed two broader lessons relevant to operators and vendors. First, there are now practical opportunities for automation to enter outside-plant workflows following developments in the power industry and datacenters[6]. Second, infrastructure design choices can facilitate this transition.
More spacious or reconfigurable FDH cabinets would simplify retrofitting active devices. Standardized attachment points on cabinets, terminals and pluggable components would allow mechanized or automated fiber management, reducing the risk of damage in dense installations.
Fiducial marks are among the lowest-cost adaptations. QR marks conveying dimensions and part architecture would help machines determine part orientation and position easily. Although these are common in the industry, it may be time to adopt them more broadly in telecom infrastructure maintenance.
Aerial terminals may benefit the most from machine-friendly design. Standardized port spacing and swing-out or hinged caps would significantly simplify autonomous or remotely assisted connections. Such cooperative interfaces could enable standoff connections without requiring a technician to climb a pole, improving safety and reducing access costs. Retrofitting aerial infrastructure to make it robot-friendly has been recommended[7] by the power industry and is also needed in the broadband utilities.
Conclusion
A growing gap is emerging between rapidly evolving data-center infrastructure and the more traditional telecom networks downstream. As fiber density increases, testing, activation, and maintenance of last-mile networks are likely to become bottlenecks. One way ISPs and vendors can future-proof outside-plant infrastructure is by proactively incorporating automation- and robot-friendly design features. M2 is one practical example that helps inform how such transitions might begin.
Short video clip from our early field trial in Massachusetts:
https://youtube.com/shorts/MiDoQd_S6Kw
References:
[1] IEEE ComSoc Technology blog post, Dec 23 2025, How will fiber and equipment vendors meet the increased demand for fiber optics in 2026 due to AI data center buildouts? ↩
[2] U.S. Dept. of Commerce Office of Inspector General, “NTIA Broadband Programs: Semiannual Status Report,” Washington, DC, USA, Rep. no. OIG-25-031-I, Sept. 24, 2025. ↩
[3] for an overview of an FTTH architecture see: Fiber Optic Association (FOA), FTTH Network Design Considerations and Fiber Optic Association (FOA), FTTH and PON Applications ↩
[4] Corning Optical Communications, “Corning Recommended Fiber Optic Test Guidelines,” Hickory, NC, USA, Application Engineering Note LAN-1561-AEN, Feb. 2020. ↩
[5] Refer to tools available for easy to use edge computing by Edge Impulse. ↩
[6] See state of the art indoor optical switches like ROME from NTT-AT and G5 from Telescent. ↩
[7] Andrew Phillips, “Autonomous overhead transmission line inspection robot (TI) development and demonstration,” IEEE PES General Meeting, 2014. ↩
About the Author:
Said Yakhyoev is a fiber optic technician with LightStep LLC in Colorado and a developer of the experimental Machine2 (M2) platform for automating fiber testing in outside-plant networks.
The author acknowledges the use of AI-assisted tools for language refinement and formatting.
VC4 Advances OSS Transformation with an Efficient and Reliable AI enabled Network Inventory System
By Juhi Rani assisted by IEEE Techblog editors Ajay Lotan Thakur and Sridhar Talari Rajagopal
Introduction:
This year, 2025, VC4 [a Netherlands Head Office (H/O) based Operational Support System (OSS) software provider] has brought sharp industry focus to a challenge that many experience in telecom. Many operators/carriers still struggle with broken, unreliable, and disconnected inventory systems. While many companies are demoing AI, intent-based orchestration, and autonomous networks, VC4’s newly branded offering, Service2Create (or S2C as it’s known to some), is refreshingly grounded. Also as we have learnt very quickly, bad data into AI is a “no-no”. None of the orchestration and autonomous networks, will work accurately if your OSS is built on flawed data. The age-old saying “Garbage in, Garbage out” comes to mind.
VC4’s platform, Service2Create (S2C), is a next-generation OSS inventory system that supports the evolving needs of telecom operators looking to embrace AI, automate workflows, and run leaner, smarter operations. Service2Create is built from over two decades of experience of inventory management solutions – IMS. By focusing on inventory accuracy and network transparency, S2C gives operators a foundation they can trust.
Inventory: The Most Underestimated Barrier to Transformation
In a post from TM Forum, we observed that operators across the world are making huge investments in digital transformation but many are slowed by a problem closer to the ground: the inability to know what exactly is deployed in the network, where it is, and how it’s interconnected.
VC4 calls this the “silent blocker” to OSS evolution.
Poor mis-aligned inventory undermines everything. It breaks service activations, triggers unnecessary truck rolls, causes billing mismatches, and frustrates assurance teams. Field engineers often discover real-world conditions that don’t match what’s in the system, while planners and support teams struggle to keep up. The problem doesn’t just stop with network data.
In many cases, customer records were also out of date or incomplete… and unknown inventory can also be a factor. Details like line types, distance from the central office, or whether loading coils were present often didn’t match reality. For years, this was one of the biggest issues for operators. Customer databases and network systems rarely aligned, and updates often took weeks or months. Engineers had to double-check every record before activating a service, which slowed delivery and increased errors. It was a widespread problem across the industry and one that many operators have been trying to fix ever since.
Over time, some operators tried to close this gap with data audits and manual reconciliation projects, but those fixes never lasted long. Networks change every day, and by the time a cleanup was finished, the data was already out of sync again.
Modern inventory systems take a different approach by keeping network and customer data connected in real time. They:
- Continuously sync with live network data so records stay accurate.
- Automatically validate what’s in the field against what’s stored in the system.
- Update both customer and network records when new services are provisioned.
In short, we’re talking about network auto-discovery and reconciliation, something that Service2Create does exceptionally well. This also applies for unknown records, duplicate records and records with naming inconsistencies/variances.
It is achieved through continuous network discovery that maps physical and logical assets, correlates them against live service models, and runs automated reconciliation to detect discrepancies such as unknown elements, duplicates, or naming mismatches. Operators can review and validate these findings, ensuring that the inventory always reflects the true, real-time network state. A more detailed explanation can be found in the VC4 Auto Discovery & Reconciliation guide which can be downloaded for free.
Service2Create: Unified, Reconciled, and AI-Ready
Service2Create is designed to reflect the actual, current state of the network across physical, logical, service and virtual layers. Whether operators are managing fiber rollout, mobile backhaul, IP/MPLS cores, or smart grids, S2C creates a common source of truth. It models infrastructure end-to-end, automates data reconciliation using discovery, and integrates with orchestration platforms and ticketing tools.
To make the difference clearer here is the table below shows how Service2Create compares with the older inventory systems still used by many operators. Traditional tools depend on manual updates and disconnected data sources, while Service2Create keeps everything synchronized and validated in real time.
Comparison between legacy inventory tools and Service2Create (S2C)
| Feature | Legacy OSS Tools | VC4 Service2Create (S2C) |
|---|---|---|
| Data reconciliation | Manual or periodic | Automated and continuous |
| Inventory accuracy | Often incomplete or outdated | Real-time and verified |
| Integration effort | Heavy customization needed | Standard API-based integration |
| Update cycle | It takes days or weeks | Completed in hours |
| AI readiness | Low, needs data cleanup | High, with consistent and normalized data |
What makes it AI-ready isn’t just compatibility with new tools, it’s data integrity. VC4 understands that AI and automation only perform well when they’re fed accurate, reliable, and real-time data. Without that, AI is flying blind.
Built-in Geographic Information System (GIS) capabilities help visualize the network in geographic context, while no/low-code workflows and APIs support rapid onboarding and customization. More than software, S2C behaves like a data discipline framework for telecom operations.
Service2Create gives operators a current, trusted view of their network, improving accuracy and reducing the time it takes to keep systems aligned.
AI is Reshaping OSS… But only if the Data is Right
AI is driving the next wave of OSS transformation from automated fault resolution and dynamic provisioning to predictive maintenance and AI-guided assurance. But it’s increasingly clear: AI doesn’t replace the need for accuracy; it demands it.
In 2025, one common thread across operators and developers was this: telcos want AI to reduce costs, shorten response times, and simplify networks. According to a GSMA analysis, many operators continue to struggle as their AI systems depend on fragmented and incomplete datasets, which reduces overall model accuracy.
VC4’s message is cutting through: AI is only as useful as the data that feeds it. Service2Create ensures the inventory is trustworthy, reconciled daily with the live network, and structured in a way AI tools can consume. It’s the difference between automating chaos and enabling meaningful, autonomous decisions.
Service2Create has been adopted with operators across Europe and Asia. In national fiber networks, it’s used to coordinate thousands of kilometers of rollout and maintenance. In mixed fixed-mobile environments, it synchronizes legacy copper, modern fiber, and 5G transport into one unified model.
Designed for Operational Reality
VC4 didn’t build Service2Create for greenfield labs or ideal conditions. The platform is designed for real-world operations: brownfield networks, legacy system integrations, and hybrid IT environments. Its microservices-based architecture and API-first design make it modular and scalable, while its no/low-code capabilities allow operators to adapt it without long customization cycles. See the diagram below.
S2C is deployable in the cloud or on-premises and integrates smoothly with Operational Support System / Business Support System (OSS/BSS) ecosystems including assurance, CRM, and orchestration. The result? Operators don’t have to rip and replace their stack – they can evolve it, anchored on a more reliable inventory core.
What Industry Analysts are Saying
In 2025, telco and IT industry experts are also emphasizing that AI’s failure to deliver consistent ROI in telecom is often due to unreliable base systems. One IDC analyst summed it up: “AI isn’t failing because the models are bad, it’s failing because operators still don’t know what’s in their own networks.”
A senior architect from a Tier 1 European CSP added, “We paused a closed-loop automation rollout because our service model was based on inventory we couldn’t trust. VC4 was the first vendor we saw this year that has addressed this directly and built a product around solving it.”
This year the takeaway is clear: clean inventory isn’t a nice-to-have. It’s step one.
Looking Ahead: AI-Driven Operations Powered by Trusted Inventory
VC4 is continuing to enhance Service2Create with capabilities that support AI-led operations. Currently, S2C is enhanced with AI-powered natural language interfaces through Model Context Protocol (MCP) servers. This creates a revolutionary way for users to access their data and makes it also easier for them to do so. Simply ask for what you need, in plain language, and receive instant, accurate results from your systems of record.
The S2C platform now offers multiple synchronized access methods:
- Natural Language Interface
- Ask questions in plain language: “Show me network capacity issues in Amsterdam”
- AI translates requests into precise system queries
- No training required – productive from day one
- Direct API Access via MCP
- Programmatic access using Language Integrated Query (LINQ) expressions
- Perfect for integrations and automated workflows
- Industry-standard authentication (IDP)
- S2C Visual Platform
- Full-featured GUI for power users
- Parameterized deeplinks for instant component access
- Low/no-code configuration capabilities
- Hybrid Workflows
-
- Start with AI chat, graduate to power tools
- AI generates deeplinks to relevant S2C dashboards
Export to Excel/CSV for offline analysis
-
What It All Comes Down To
Digital transformation sounds exciting on a conference stage, but in the trenches of telecom operations, it starts with simpler questions. Do you know what’s on your network? Can you trust the data? Can your systems work together?
That’s what Service2Create is built for. It helps operators take control of their infrastructure, giving them the confidence to automate when ready and the clarity to troubleshoot when needed.
VC4’s approach isn’t flashy. It’s focused. And that’s what makes it so effective – a direction supported by coverage from Subseacables.net, which reported on VC4’s partnership with AFR-IX, to automate and modernize network operations across the Mediterranean.
………………………………………………………………………………………………………………….
About the Author:
Juhi Rani is an SEO specialist at VC4 B.V. in the Netherlands. She has successfully directed and supervised teams, evaluated employee skills and knowledge, identified areas of improvement, and provided constructive feedback to increase productivity and maintain quality standards.
Juhi earned a B. Tech degree in Electronics and Communications Engineering from RTU in Jaipur, India in 2015.
……………………………………………………………………………………………………………………………………………………………………..
Ajay Lotan Thakur and Sridhar Talari Rajagopal are esteemed members of the IEEE Techblog Editorial Team. Read more about them here.
Emerging Cybersecurity Risks in Modern Manufacturing Factory Networks
By Omkar Ashok Bhalekar with Ajay Lotan Thakur
Introduction
With the advent of new industry 5.0 standards and ongoing advancements in the field of Industry 4.0, the manufacturing landscape is facing a revolutionary challenge which not only demands sustainable use of environmental resources but also compels us to make constant changes in industrial security postures to tackle modern threats. Technologies such as Internet of Things (IoT) in Manufacturing, Private 4G/5G, Cloud-hosted applications, Edge-computing, and Real-time streaming telemetry are effectively fueling smart factories and making them more productive.
Although this evolution facilitates industrial automation, innovation and high productivity, it also greatly makes the exposure footprint more vulnerable for cyberattacks. Industrial Cybersecurity is quintessential for mission critical manufacturing operations; it is a key cornerstone to safeguard factories and avoid major downtimes.
With the rapid amalgamation of IT and OT (Operational Technology), a hack or a data breach can cause operational disruptions like line down situations, halt in production lines, theft or loss of critical data, and huge financial damage to an organization.
Industrial Networking
Why does Modern Manufacturing demand Cybersecurity? Below outlines a few reasons why cybersecurity is essential in modern manufacturing:
- Convergence of IT and OT: Industrial control systems (ICS) which used to be isolated or air-gapped are now all inter-connected and hence vulnerable to breaches.
- Enlarged Attack Surface: Every device or component in the factory which is on the network is susceptible to threats and attacks.
- Financial Loss: Cyberattacks such as WannaCry or targeted BSOD Blue Screen of Death (BSOD) can cost millions of dollars per minute and result in complete shutdown of operations.
- Disruptions in Logistics Network: Supply chain can be greatly disarrayed due to hacks or cyberattacks causing essential parts shortage.
- Legislative Compliance: Strict laws and regulations such as CISA, NIST, and ISA/IEC 62443 are proving crucial and mandating frameworks to safeguard industries
It is important to understand and adapt to the changing trends in the cybersecurity domain, especially when there are several significant factors at risk. Historically, it has been observed that mankind always has had some lessons learned from their past mistakes while not only advances at fast pace, but the risks from external threats would limit us from making advancements without taking cognizance.
This attitude of adaptability or malleability needs to become an integral part of the mindset and practices in cybersecurity spheres and should not be limited to just industrial security. Such practices can scale across other technological fields. Moreover, securing industries does not just mean physical security, but it also opens avenues for cybersecurity experts to learn and innovate in the field of applications and software such as Manufacturing Execution System (MES) which are crucial for critical operations.
Greatest Cyberattacks in Manufacturing of all times:
Familiarizing and acknowledging different categories of attacks and their scales which have historically hampered the manufacturing domain is pivotal. In this section we would highlight some of the Real-World cybersecurity incidents.
Ransomware (Colonial Pipeline, WannaCry, y.2021):
These attacks brought the US east coast to a standstill due to extreme shortage of fuel and gasoline after hacking employee credentials.
Cause: The root cause for this was compromised VPN account credentials. An VPN account which wasn’t used for a long time and lacked Multi-factor Authentication (MFA) was breached and the credentials were part of a password leak on dark web. The Ransomware group “Darkside” exploited this entry point to gain access to Colonial Pipeline’s IT systems. They did not initially penetrate operational technology systems. However, the interdependence of IT and OT systems caused operational impacts. Once inside, attackers escalated privileges and exfiltrated 100 GB of data within 2 hours. Ransomware was deployed to encrypt critical business systems. Colonial Pipeline proactively shut down the pipeline fearing lateral movement into OT networks.
Effect: The pipeline, which supplies nearly 45% of the fuel to the U.S. East Coast, was shut down for 6 days. Mass fuel shortages occurred across several U.S. states, leading to public panic and fuel hoarding. Colonial Pipeline paid $4.4 million ransom. Later, approximately $2.3 million was recovered by the FBI. Led to a Presidential Executive Order on Cybersecurity and heightened regulations around critical infrastructure cybersecurity. Exposed how business IT network vulnerabilities can lead to real-world critical infrastructure impacts, even without OT being directly targeted.
Industrial Sabotage (Stuxnet, y.2009):
This unprecedented and novel software worm was able to hijack an entire critical facility and sabotage all the machines rendering them defunct.
Cause: Nation-state-developed malware specifically targeting Industrial Control Systems (ICS), with an unprecedented level of sophistication. Stuxnet was developed jointly by the U.S. (NSA) and Israel (Unit 8200) under operation “Olympic Games”. The target was Iran’s uranium enrichment program at Natanz Nuclear Facility. The worm was introduced via USB drives (air-gapped network). Exploited four zero-day vulnerabilities in Windows systems at that time, unprecedented. Specifically targeted Siemens Step7 software running on Windows, which controls Siemens S7-300 PLCs. Stuxnet would identify systems controlling centrifuges used for uranium enrichment. Reprogrammed the PLCs to intermittently change the rotational speed of centrifuges, causing mechanical stress and failure, while reporting normal operations to operators. Used rootkits for both Windows and PLC-level to remain stealthy.
Effect: Destroyed approximately 1,000 IR-1 centrifuges (~10% of Iran’s nuclear capability). Set back Iran’s nuclear program by 1-2 years. Introduced a new era of cyberwarfare, where malware caused physical destruction. Raised global awareness about the vulnerabilities in industrial control systems (ICS). Iran responded by accelerating its cyber capabilities, forming the Iranian Cyber Army. ICS/SCADA security became a top global priority, especially in energy and defense sectors.
Upgrade spoofing (SolarWinds Orion Supply chain Attack, y.2020):
Attackers injected malicious pieces of software into the software updates which infected millions of users.
Cause: Compromise of the SolarWinds build environment leading to a supply chain attack. Attackers known as Russian Cozy Bear, linked to Russia’s foreign intelligence agency, gained access to SolarWinds’ development pipeline. Malicious code was inserted into Orion Platform updates, released between March to June 2020 Customers who downloaded the update installed malware known as SUNBURST. Attackers compromised SolarWinds build infrastructure. It created a backdoor in Orion’s signed DLLs. Over 18,000 customers were potentially affected, including 100 high-value targets. After the exploit, attackers used manual lateral movement, privilege escalation, and custom C2 (command-and-control) infrastructure to exfiltrate data.
Effect: Breach included major U.S. government agencies: DHS, DoE, DoJ, Treasury, State Department, and more. Affected top corporations: Cisco, Intel, Microsoft, FireEye, and others FireEye discovered the breach after noticing unusual two-factor authentication activity. Exposed critical supply chain vulnerabilities and demonstrated how a single point of compromise could lead to nationwide espionage. Promoted the creation of Cybersecurity Executive Order 14028, Zero Trust mandates, and widespread adoption of Software Bill of Materials (SBOM) practices.
Spywares (Pegasus, y.2016-2021):
Cause: Zero-click and zero-day exploits leveraged by NSO Group’s Pegasus spyware, sold to governments. Pegasus can infect phones without any user interaction also known as zero-click exploits. It acquires malicious access to WhatsApp, iMessage or browsers like Safari’s vulnerabilities on iOS, including zero-days attacks on Android devices. Delivered via SMS, WhatsApp messages, or silent push notifications. Once installed, it provides complete surveillance capability such as access to microphones, camera, GPS, calls, photos, texts, and encrypted apps. Zero-click iOS exploit ForcedEntry allows complete compromise of an iPhone. Malware is extremely stealthy, often removing itself after execution. Bypassed Apple’s BlastDoor sandbox and Android’s hardened security modules.
Effect: Used by multiple governments to surveil activists, journalists, lawyers, opposition leaders, even heads of state. The 2021 Pegasus Project, led by Amnesty International and Forbidden Stories, revealed a leaked list of 50,000 potential targets. Phones of high-profile individuals including international journalists, associates, specifically French president, and Indian opposition figures were allegedly targeted which triggered legal and political fallout. NSO Group was blacklisted by the U.S. Department of Commerce. Apple filed a lawsuit against NSO Group in 2021. Renewed debates over the ethics and regulation of commercial spyware.
Other common types of attacks:
Phishing and Smishing: These attacks send out links or emails that appear to be legitimate but are crafted by bad actors for financial means or identity theft.
Social Engineering: Shoulder surfing though sounds funny; it’s the tale of time where the most expert security personnel have been outsmarted and faced data or credential leaks. Rather than relying on technical vulnerabilities, this attack targets human psychology to gain access or break into systems. The attacker manipulates people into revealing confidential information using techniques such as Reconnaissance, Engagement, Baiting or offering Quid pro quo services.
Security Runbook for Manufacturing Industries:
To ensure ongoing enhancements to industrial security postures and preserve critical manufacturing operations, following are 11 security procedures and tactics which will ensure 360-degree protection based on established frameworks:
A. Incident Handling Tactics (First Line of Defense) Team should continuously improve incident response with the help of documentation and response apps. Co-ordination between teams, communications root, cause analysis and reference documentation are the key to successful Incident response.
B. Zero Trust Principles (Trust but verify) Use strong security device management tools to ensure all end devices are in compliance such as trusted certificates, NAC, and enforcement policies. Regular and random checks on users’ official data patterns and assign role-based policy limiting full access to critical resources.
C. Secure Communication and Data Protection Use endpoint or cloud-based security session with IPSec VPN tunnels to make sure all traffic can be controlled and monitored. All user data must be encrypted using data protection and recovery software such as BitLocker.
D. Secure IT Infrastructure Hardening of network equipment such switches, routers, WAPs with dot1x, port-security and EAP-TLS or PEAP. Implement edge-based monitoring solutions to detect anomalies and redundant network infrastructure to ensure least MTTR.
E. Physical Security Locks, badge readers or biometric systems for all critical rooms and network cabinets are a must. A security operations room (SOC) can help monitor internal thefts or sabotage incidents.
F. North-South and East-West Traffic Isolation Safety traffic and external traffic can be rate limited using Firewalls or edge compute devices. 100% isolation is a good wishful thought, but measures need to be taken to constantly monitor any security punch-holes.
G. Industrial Hardware for Industrial applications Use appropriate Industrial grade IP67 or IP68 rated network equipment to avoid breakdowns due to environmental factors. Localized industrial firewalls can provide desired granularity on the edge thereby skipping the need to follow Purdue model.
H. Next-Generation Firewalls with Application-Level Visibility Incorporate Stateful Application Aware Firewalls, which can help provide more control over zones and policies and differentiate application’s behavioral characteristics. Deploy Tools which can perform deep packet inspection and function as platforms for Intrusion prevention (IPS/IDS).
I. Threat and Traffic Analyzer Tools such as network traffic analyzers can help achieve network Layer1-Layer7 security monitoring by detecting and responding to malicious traffic patterns. Self-healing networks with automation and monitoring tools which can detect traffic anomalies and rectify the network incompliance.
J. Information security and Software management Companies must maintain a repo of trust certificates, software and releases and keep pushing regular patches for critical bugs. Keep a constant track of release notes and CVEs (Common Vulnerabilities and exposures) for all vendor software.
K. Idiot-Proofing (How to NOT get Hacked) Regular training to employees and familiarizing them with cyber-attacks and jargons like CryptoJacking or HoneyNets can help create awareness. Encourage and provide a platform for employees or workers to voice their opinions and resolve their queries regarding security threats.
Current Industry Perspective and Software Response
In response to the escalating tide of cyberattacks in manufacturing, from the Triton malware striking industrial safety controls to LockerGoga shutting down production at Norsk Hydro, there has been a sea change in how the software industry is facilitating operational resilience. Security companies are combining cutting-edge threat detection with ICS/SCADA systems, delivering purpose-designed solutions like zero-trust network access, behavior-based anomaly detection, and encrypted machine-to-machine communications. Companies such as Siemens and Claroty are leading the way, bringing security by design rather than an afterthought. A prime example is Dragos OT-specific threat intelligence and incident response solutions, which have become the focal point in the fight against nation-state attacks and ransomware operations against critical infrastructure.
Bridging the Divide between IT and OT: Two way street
With the intensification of OT and IT convergence, perimeter-based defense is no longer sufficient. Manufacturers are embracing emerging strategies such as Cybersecurity Mesh Architecture (CSMA) and applying IT-centric philosophies such as DevSecOps within the OT environment to foster secure by default deployment habits. The trend also brings attention to IEC 62443 conformity as well as NIST based risk assessment frameworks catering to manufacturing. Legacy PLCs having been networked and exposed to internet-borne threats, companies are embracing micro-segmentation, secure remote access, and real-time monitoring solutions that unify security across both environments. Learn how Schneider Electric is empowering manufacturers to securely link IT/OT systems with scalable cybersecurity programs.
Conclusion
In a nutshell, Modern manufacturing, contrary to the past, is not just about quick input and quick output systems which can scale and be productive, but it is an ecosystem, where cybersecurity and manufacturing harmonize and just like healthcare system is considered critical to humans, modern factories are considered quintessential to manufacturing. So many experiences with cyberattacks on critical infrastructure such as pipelines, nuclear plants, power-grids over the past 30 years not only warrant world’s attention but also calls to action the need to devise regulatory standards which must be followed by each and every entity in manufacturing.
As mankind keeps making progress and sprinting towards the next industrial revolution, it’s an absolute exigency to emphasize making Industrial Cybersecurity a keystone in building upcoming critical manufacturing facilities and building a strong foundation for operational excellency. Now is the right time to buy into the trend of Industrial security, sure enough the leaders who choose to be “Cyberfacturers” will survive to tell the tale, and the rest may just serve as stark reminders of what happens when pace outperforms security.
References
- https://www.cisa.gov/topics/industrial-control-systems
- https://www.nist.gov/cyberframework
- https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa99
- https://www.cisa.gov/news-events/news/attack-colonial-pipeline-what-weve-learned-what-weve-done-over-past-two-years
- https://www.law.georgetown.edu/environmental-law-review/blog/cybersecurity-policy-responses-to-the-colonial-pipeline-ransomware-attack/
- https://www.hbs.edu/faculty/Pages/item.aspx?num=63756
- https://spectrum.ieee.org/the-real-story-of-stuxnet
- https://www.washingtonpost.com/world/national-security/stuxnet-was-work-of-us-and-israeli-experts-officials-say/2012/06/01/gJQAlnEy6U_story.html
- https://www.kaspersky.com/resource-center/definitions/what-is-stuxnet
- https://www.malwarebytes.com/stuxnet
- https://www.zscaler.com/resources/security-terms-glossary/what-is-the-solarwinds-cyberattack
- https://www.gao.gov/blog/solarwinds-cyberattack-demands-significant-federal-and-private-sector-response-infographic
- https://www.rapid7.com/blog/post/2020/12/14/solarwinds-sunburst-backdoor-supply-chain-attack-what-you-need-to-know/
- https://www.fortinet.com/resources/cyberglossary/solarwinds-cyber-attack
- https://www.amnesty.org/en/latest/research/2021/07/forensic-methodology-report-how-to-catch-nso-groups-pegasus/
- https://citizenlab.ca/2023/04/nso-groups-pegasus-spyware-returns-in-2022/
- https://thehackernews.com/2023/04/nso-group-used-3-zero-click-iphone.html
- https://www.securityweek.com/google-says-nso-pegasus-zero-click-most-technically-sophisticated-exploit-ever-seen/
- https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing
- https://www.blumira.com/blog/social-engineering-the-human-element-in-cybersecurity
- https://www.nist.gov/cyberframework
- https://www.dragos.com/cyber-threat-intelligence/
- https://mesh.security/security/what-is-csma/
- https://download.schneider-electric.com/files?p_Doc_Ref=IT_OT&p_enDocType=User+guide&p_File_Name=998-20244304_Schneider+Electric+Cybersecurity+White+Paper.pdf
- https://insanecyber.com/understanding-the-differences-in-ot-cybersecurity-standards-nist-csf-vs-62443/
- https://blog.se.com/sustainability/2021/04/13/it-ot-convergence-in-the-new-world-of-digital-industries/
About Author:
Omkar Bhalekar is a senior network engineer and technology enthusiast specializing in Data center architecture, Manufacturing infrastructure, and Sustainable solutions with extensive experience in designing resilient industrial networks and building smart factories and AI data centers with scalable networks. He is also the author of the Book Autonomous and Predictive Networks: The future of Networking in the Age of AI and co-author of Quantum Ops – Bridging Quantum Computing & IT Operations. Omkar writes to simplify complex technical topics for engineers, researchers, and industry leaders.
