DEV Community: Cihangir Dündar

Industrial Cyber Range & Automation: Building the "Ot Alanı" Architecture

Cihangir Dündar — Mon, 14 Sep 2026 05:54:41 +0000

Introduction
In the realm of Operational Technology (OT) and Industrial Control Systems (ICS), security testing, simulation, and automation operate under fundamentally different constraints than traditional IT environments. You cannot simply apply standard enterprise patching or rapid testing methodologies without risking physical infrastructure, human safety, or continuous industrial processes.

To address these challenges within the CROVA ecosystem, we designed and implemented a specialized operational framework and automation layer we call the "Ot Alanı". This architecture bridges the gap between raw industrial telemetry and automated response mechanisms, providing a controlled environment for validation, threat simulation, and operational oversight.

Architecture Overview
The "Ot Alanı" framework is built around a modular, decoupled architecture designed to handle high-frequency industrial data while maintaining strict isolation boundaries.

[ Industrial Protocols (Modbus / IEC 104) ]
│
▼
[ Ingestion & Telemetry Layer ]
│
▼
[ Core Automation & Analysis Engine ]
│
┌─────────┴─────────┐
▼ ▼
[ Automated Remediation ] [ Threat Simulation ]

Ingestion & Telemetry Layer
Industrial environments speak specialized protocols—such as Modbus TCP, Profinet, and IEC 60870-5-104. The ingestion layer acts as a secure intermediary, parsing raw telemetry packets from Programmable Logic Controllers (PLCs) and Remote Terminal Units (RTUs) without introducing jitter or timing disruptions into the control loop.
Core Automation & Analysis Engine
At the heart of the framework lies the execution engine. It evaluates incoming state changes against predefined security baselines and threat intelligence feeds. When an anomaly is detected, the engine triggers automated playbooks designed to isolate affected segments or log high-fidelity forensic data.
Isolation & Safety Boundaries
Because safety is paramount in critical infrastructure, "Ot Alanı" incorporates strict network segmentation rules and virtualized safety loops. This ensures that experimental security orchestrations or automated testing scripts never directly compromise live, production-grade actuators or sensors.

Technical Implementation & Core Pipeline
To demonstrate how the automation pipeline handles state validation and automated triggers, consider the following baseline Python module used within our orchestration framework:

Python
import time
import logging
from typing import Dict, Any

logging.basicConfig(
level=logging.INFO,
format="%(asctime)s [%(levelname)s] %(name)s: %(message)s"
)
logger = logging.getLogger("OtAlaniEngine")

class OTAutomationPipeline:
def init(self, node_id: str, threshold: int = 80):
self.node_id = node_id
self.threshold = threshold

def fetch_telemetry(self) -> Dict[str, Any]:
    # Simulating telemetry fetch from industrial sensors/PLCs
    # In production, this interfaces with secure industrial brokers.
    return {
        "node_id": self.node_id,
        "status": "SECURE",
        "load_metric": 65,
        "active_connections": 12
    }

def execute_pipeline(self) -> None:
    logger.info(f"Initializing audit and automation cycle for node: {self.node_id}")
    telemetry = self.fetch_telemetry()

    current_load = telemetry.get("load_metric", 0)

    if current_load > self.threshold:
        logger.warning(f"High load anomaly detected on {self.node_id}! Metric: {current_load}")
        self.trigger_isolation_protocol()
    else:
        logger.info(f"Node {self.node_id} state is stable. Load: {current_load}%. Flow continuing.")

def trigger_isolation_protocol(self) -> None:
    logger.error(f"CRITICAL: Isolating node {self.node_id} to prevent potential lateral movement or system failure.")
    # Automated containment logic goes here

if name == "main":
pipeline = OTAutomationPipeline(node_id="ICS-PLC-CLUSTER-01", threshold=80)

# Continuous monitoring loop simulation
for _ in range(3):
    pipeline.execute_pipeline()
    time.sleep(2)

Key Engineering Challenges and Solutions
Building and scaling an OT-focused automation layer brings unique engineering hurdles:

Latency and Determinism: Industrial processes rely on precise timing. Heavy logging or blocking API calls can disrupt control loops. To mitigate this, our pipeline uses asynchronous event loops and non-blocking IO operations wherever possible.

State Consistency across Distributed Nodes: Maintaining a unified source of truth across geographically dispersed industrial sites requires robust state synchronization protocols and localized fallback caching.

Safety-First Automation: Unlike IT systems where automated remediation can restart services freely, OT automation must prioritize fail-safe and fail-secure states, ensuring that automated scripts cannot accidentally shut down critical power, water, or manufacturing processes.

Inside an OT DMZ: Why a Firewall Alone Is Not Enough

Cihangir Dündar — Mon, 24 Aug 2026 16:46:14 +0000

Inside an OT DMZ: Why a Firewall Alone Is Not Enough

In many industrial environments, cybersecurity architecture is summarized with a simple statement:

“We have a firewall between IT and OT.”

That sounds reassuring.

But a firewall alone does not create an OT security architecture.

Between enterprise IT networks and industrial control systems lies one of the most important—and frequently misunderstood—areas of industrial cybersecurity:

The OT DMZ.

Often associated with Level 3.5 of the Purdue Model, the Industrial Demilitarized Zone is not simply another network segment.

It is a controlled boundary between two environments with fundamentally different priorities.

Enterprise IT is designed around information, users, applications, and business services.

OT is designed around physical processes, deterministic control, availability, and safety.

The OT DMZ exists because directly connecting these two worlds creates unnecessary risk.

But building an effective OT DMZ requires much more than placing a firewall between them.

What Is an OT DMZ?

An OT DMZ is an intermediate security zone positioned between enterprise IT and industrial OT networks.

Its purpose is to prevent unnecessary direct communication between the two environments.

A simplified architecture may look like this:

Enterprise IT → Firewall → OT DMZ → Firewall → OT Network

This creates an important architectural principle:

IT systems should not communicate directly with critical industrial assets unless there is a clearly defined operational requirement.

Instead, services that need to exchange information between IT and OT can be positioned or mediated through the DMZ.

The DMZ becomes a controlled exchange point.

Why Direct IT-to-OT Connectivity Is Dangerous

Modern industrial organizations need information from production environments.

ERP platforms may need production data.

Business intelligence systems may require operational metrics.

Security teams may require logs.

Engineers may require remote support.

Vendors may occasionally need maintenance access.

The business requirement is legitimate.

The problem begins when convenience creates direct connectivity.

A workstation inside the corporate network should generally not have unrestricted communication with a PLC controlling a production process.

A vendor laptop should not receive permanent network-level access to an entire control environment simply because occasional maintenance is required.

Connectivity should follow operational necessity.

Not convenience.

The OT DMZ Is a Trust Boundary

One useful way to understand an OT DMZ is to stop thinking about it as a network segment.

Think of it as a trust boundary.

Systems above the boundary belong primarily to the enterprise environment.

Systems below the boundary belong to the operational environment.

The DMZ controls how trust moves between them.

That means every communication path should answer several questions:

Why does this connection exist?
Which system initiates it?
Which destination is required?
Which protocol is necessary?
Is the connection permanent?
Can it be monitored?
What happens if the source system is compromised?

If these questions cannot be answered, the communication path probably deserves further review.

Why One Firewall Is Often Not Enough

A common industrial architecture places one firewall between enterprise and control networks.

This creates segmentation.

But segmentation alone does not necessarily create strong isolation.

A more mature architecture separates the environments through controlled zones.

Conceptually:

Enterprise Network

↓

Enterprise Firewall

↓

Industrial DMZ

↓

OT Firewall

↓

Industrial Operations

This provides an additional layer where cross-boundary services can be terminated, inspected, authenticated, or proxied before reaching operational systems.

The objective is not adding firewalls for the sake of adding firewalls.

The objective is reducing direct trust.

What Belongs Inside an OT DMZ?

There is no universal list.

Every industrial environment has different operational requirements.

However, several types of services are commonly considered for DMZ placement.

These may include:

Jump servers
Remote access gateways
Patch or update staging services
Security monitoring infrastructure
Log collection systems
Data replication services
File transfer mechanisms
Authentication intermediaries
Application proxies

The critical principle is that the DMZ should contain services that mediate communication rather than simply extending one network into another.

Jump Servers and Controlled Engineering Access

Remote engineering presents a major architectural challenge.

An engineer may need access to systems inside the OT environment.

Giving an engineering laptop direct network access from enterprise IT into the control network creates unnecessary exposure.

A controlled jump architecture provides an intermediate access point.

Instead of:

Engineer Laptop → PLC

the architecture may conceptually become:

Engineer → Controlled Access → Jump Host → Authorized OT Asset

This allows organizations to apply additional controls around privileged engineering access.

Depending on operational requirements, these controls may include:

Strong authentication
Role-based access
Session authorization
Time-limited access
Logging
Session monitoring

The objective is not making engineering difficult.

It is making privileged access deliberate and observable.

Vendor Access Requires Special Attention

Industrial facilities depend heavily on external vendors.

OEMs.

System integrators.

Automation contractors.

Maintenance providers.

Equipment manufacturers.

These organizations may legitimately require remote access.

But vendor access should never automatically mean persistent access.

A mature environment should understand:

Which vendor has access
Which assets they can reach
Why access is required
When access is permitted
Who approves the session
Whether the account is still necessary

One of the most dangerous forms of industrial connectivity is forgotten connectivity.

A temporary remote-access solution created years ago can quietly become permanent infrastructure.

Historian Architecture and Data Flow

Industrial historians illustrate why DMZ architecture matters.

Organizations frequently need production information outside the control environment.

The easy solution is allowing enterprise applications to query an OT historian directly.

The better architectural question is:

Does enterprise IT actually need direct access to the OT historian?

In many architectures, controlled replication or intermediary services can reduce direct cross-boundary communication.

The security objective is straightforward:

Move the required information without unnecessarily extending trust.

This principle applies far beyond historians.

It applies to almost every IT/OT integration.

Data Direction Matters

Not all communication carries the same risk.

A system retrieving production information is different from a system capable of sending commands toward an industrial controller.

Organizations should therefore understand not only which systems communicate, but also in which direction meaningful control can flow.

This distinction becomes particularly important when designing data exchange between operational and enterprise environments.

For some high-consequence environments, organizations may consider architectures designed to enforce highly restricted or one-way data flows where operational requirements justify them.

Architecture should reflect consequence.

The Problem With “Any-to-Any”

One of the clearest warning signs in network security is an overly broad rule.

In OT environments, rules permitting large network ranges to communicate freely can undermine the purpose of segmentation.

Firewall policies should ideally reflect actual operational requirements.

Instead of asking:

“What traffic should we block?”

a stronger design question is:

“What communication does this process actually require?”

This moves the architecture toward explicit communication rather than inherited trust.

Allowlisting Communication

Industrial environments often have an advantage that enterprise environments do not.

Their communication patterns can be relatively predictable.

A PLC may communicate with the same HMI.

A historian may receive information from known sources.

An engineering workstation may interact with specific controllers.

This predictability makes communication allowlisting particularly valuable.

Where operationally feasible, the architecture can permit expected communication while restricting unnecessary paths.

This does not eliminate risk.

But it significantly improves control over the environment.

Monitoring the Boundary

A DMZ should not become a blind zone.

Because it sits between IT and OT, activity within this boundary can provide valuable security context.

Organizations should understand:

Authentication activity
Remote sessions
New communication paths
Failed connection attempts
Unexpected services
Configuration changes
Privileged activity

The objective is not collecting every possible log.

The objective is obtaining enough visibility to understand meaningful changes at the IT/OT boundary.

Asset Inventory Must Include the DMZ

Asset inventories frequently focus on PLCs, HMIs, switches, servers, and engineering workstations inside the production network.

DMZ infrastructure deserves the same attention.

Organizations should know:

Which systems exist
Who owns them
What function they perform
Which network zones they connect
Which software they run
Who administers them
Which dependencies they have

An undocumented server inside the OT DMZ can become a serious architectural blind spot.

Identity Becomes Part of Segmentation

Traditional segmentation focuses primarily on IP addresses, ports, and protocols.

Modern industrial environments increasingly require another dimension:

Identity.

Knowing that a connection originates from an approved IP address may not be enough.

Organizations may also need to understand:

Who initiated the connection
Which role they have
Whether the access was approved
Whether the session occurred during an authorized window
Whether the account belongs to an employee or vendor

Network segmentation and identity controls increasingly need to work together.

The DMZ Must Not Become a Second IT Network

There is another common mistake.

Organizations create an OT DMZ and gradually fill it with services.

Over time, the DMZ becomes increasingly complex.

More applications.

More accounts.

More integrations.

More remote-access tools.

More exceptions.

Eventually, the security boundary itself becomes difficult to understand.

An OT DMZ should therefore be intentionally minimal.

Every service placed there should have a clear purpose.

Complexity creates operational and security debt.

Architecture Must Follow Operational Consequence

Not every factory requires the same architecture.

Not every PLC carries the same consequence.

Not every industrial process requires identical isolation.

A small manufacturing facility and a national electricity control environment have fundamentally different risk profiles.

Architecture should therefore consider:

Operational criticality
Safety consequences
Production impact
Recovery capability
Regulatory requirements
Remote-access requirements
Business dependencies

Security architecture should be proportional to operational consequence.

Beyond the Purdue Model

The Purdue Model remains extremely useful for understanding industrial segmentation.

But modern environments increasingly include:

Cloud services
Industrial IoT
Remote operations
Centralized SOC platforms
External analytics
Vendor ecosystems
Edge computing

These technologies do not always fit neatly into traditional hierarchical diagrams.

That does not make segmentation obsolete.

It makes trust relationships even more important.

Modern OT architecture should understand both:

Where a system is located

and

What that system is trusted to do.

The CROVA Perspective

At CROVA, we view the OT DMZ not simply as a network layer but as an operational security boundary.

Its purpose is not to isolate OT from the modern world.

Industrial environments need data exchange, remote maintenance, analytics, monitoring, and enterprise integration.

The challenge is enabling those capabilities without creating uncontrolled trust relationships.

A strong OT DMZ therefore combines:

Segmentation
Controlled access
Operational visibility
Identity
Monitoring
Explicit communication paths
Engineering awareness

The objective is not maximum isolation.

The objective is controlled connectivity.

Final Thoughts

An OT DMZ is not created simply by installing another firewall.

It is created by understanding how information, access, and trust move between enterprise and operational environments.

A mature architecture should be able to answer:

Who can cross the boundary?

Which systems can they reach?

Why is the connection necessary?

How long should it exist?

Can the activity be observed?

What happens if one side becomes compromised?

If those questions cannot be answered, the organization may have segmentation—but not necessarily an effective security boundary.

Industrial cybersecurity is not about disconnecting operations from everything.

It is about ensuring that every connection has a reason.

And every reason has a control.

About the Author

Cihangir Dündar
Founder & CEO, CROVA

CROVA Research focuses on Operational Technology (OT), Industrial Control Systems (ICS), industrial cybersecurity, operational resilience, and critical infrastructure security.

Secure PLC Lifecycle Management

Cihangir Dündar — Mon, 17 Aug 2026 06:03:55 +0000

Secure PLC Lifecycle Management: Security Does Not Begin After Deployment

A Programmable Logic Controller can remain inside an industrial facility for fifteen, twenty, or even thirty years.

During that time, almost everything around it may change.

Engineers change.

Engineering workstations are replaced.

Firmware evolves.

Network architectures expand.

Remote access is introduced.

SCADA systems are modernized.

Vendors change.

Production requirements change.

Yet the PLC may continue controlling the same physical process every second of every day.

This creates an important cybersecurity reality:

PLC security is not a configuration problem. It is a lifecycle problem.

Organizations cannot secure a controller once, place it into production, and assume that its security posture will remain unchanged for the next decade.

A secure PLC environment must be managed from initial engineering design to final decommissioning.

The PLC Lifecycle Is Longer Than the Cybersecurity Lifecycle

Enterprise IT infrastructure is replaced relatively frequently.

Industrial control equipment is different.

A PLC may remain operational far beyond the lifecycle of:

The operating system used to configure it
The original engineering workstation
The engineering software version
The network architecture around it
The cybersecurity technologies deployed at commissioning
The engineers who originally designed the system

This creates what could be called security drift.

The controller may continue functioning perfectly while the assumptions under which it was originally deployed gradually become obsolete.

Operational reliability can therefore hide cybersecurity debt.

A device that has operated without failure for fifteen years is not automatically a device that can safely operate under today's connectivity and threat conditions.

Stage 1: Security Must Begin During Engineering

PLC security should begin before the controller reaches production.

During the design and engineering phase, organizations should already understand:

What physical process the PLC will control
Which systems must communicate with it
Which engineering workstation will manage it
Which protocols are required
Which remote connections are necessary
What operational consequence would follow from its failure
How configuration and logic will be backed up
How recovery will be performed

This is where cybersecurity and engineering architecture must meet.

Adding security after commissioning is significantly more difficult than designing security into the environment from the beginning.

Stage 2: Establish a Trusted Baseline

Before a PLC enters normal operation, the organization should establish a known and documented baseline.

This baseline may include:

PLC model and hardware revision
Firmware version
Network configuration
Authorized communication paths
Engineering software version
Approved project file
Controller configuration
Backup location
Responsible engineering personnel
Date of commissioning

The objective is simple:

Know what "normal" looks like before attempting to detect what is abnormal.

Without a trusted baseline, future investigations become significantly more difficult.

If an engineer discovers a configuration difference three years later, the organization should be able to determine whether that difference was authorized.

Stage 3: Protect the Engineering Source of Truth

One of the most overlooked questions in PLC security is:

Where is the authoritative engineering project stored?

The running controller is not enough.

Organizations need a trusted source of truth for engineering configurations and control logic.

Depending on the platform, engineering environments may involve tools such as:

Siemens TIA Portal
Rockwell Automation Studio 5000
Schneider Electric EcoStruxure
Mitsubishi Electric GX Works

Project files should not exist as uncontrolled copies distributed across engineering laptops, USB devices, personal folders, and old maintenance computers.

A mature environment should know:

Which project version is approved
Who changed it
When it changed
Why it changed
Whether the deployed controller matches the approved engineering state

This turns project management into a cybersecurity control.

Stage 4: Treat Engineering Workstations as Part of the PLC

From a security perspective, the PLC does not exist alone.

The engineering workstation is effectively part of its trust boundary.

An engineering workstation may have legitimate authority to:

Modify controller logic
Change hardware configurations
Perform diagnostics
Manage firmware
Upload or download projects
Modify communication parameters

That makes engineering access fundamentally different from ordinary workstation access.

Organizations should therefore treat engineering systems as privileged OT assets.

A hardened PLC connected to an unmanaged engineering laptop is not a hardened system.

The security of the controller depends partly on the security of the tools authorized to modify it.

Stage 5: Control Changes, Not Just Access

Access control answers:

Who is allowed to interact with this system?

Change management answers another critical question:

What were they allowed to change, and why?

Industrial environments need both.

PLC modifications should be traceable through a controlled engineering process.

A mature change process should capture:

Requested modification
Engineering justification
Responsible engineer
Approval
Testing
Implementation date
Updated project version
Updated backup
Validation after deployment

This is not bureaucracy for its own sake.

It creates operational memory.

Months or years later, engineers should not have to guess why a piece of logic changed.

Stage 6: Firmware Management Requires Operational Context

Firmware management in OT cannot simply copy enterprise patch-management practices.

A firmware update may affect:

Controller behavior
Engineering compatibility
Communication modules
Safety certifications
Vendor support
Production availability

For that reason, the question should not simply be:

"Is newer firmware available?"

The better questions are:

Why is the update required?
Is the current version affected by a relevant risk?
Is the new version approved for this environment?
Has compatibility been validated?
Is rollback possible?
Is a verified backup available?
What happens if the update fails?

PLC lifecycle management requires risk-based decisions rather than automatic updates.

Stage 7: Network Architecture Changes Over Time

A PLC commissioned ten years ago may originally have communicated with only a few local systems.

Years later, that same controller may indirectly become connected to:

SCADA platforms
Historians
Manufacturing Execution Systems (MES)
Remote maintenance infrastructure
Central monitoring platforms
Enterprise analytics
Vendor support environments

The PLC did not change.

Its exposure did.

This is why network architecture must be periodically reassessed throughout the PLC lifecycle.

Segmentation designed during commissioning should not be assumed to remain appropriate forever.

Stage 8: Remote Access Changes the Trust Model

Remote engineering and vendor support can provide enormous operational value.

They also change the security model.

Once remote connectivity is introduced, organizations must understand:

Who can establish remote sessions
Which assets can be reached
When access is permitted
How authentication is controlled
Whether sessions are monitored
How vendor accounts are managed
How temporary access is removed

Remote access should be treated as a controlled operational capability rather than a permanent network convenience.

A connection created for emergency maintenance should not silently become permanent infrastructure.

Stage 9: Backup Is Not Recovery

Many organizations say:

"We have PLC backups."

That statement alone is not enough.

A backup has operational value only when it can actually support recovery.

Organizations should understand:

When the backup was created
Which controller it belongs to
Which firmware it expects
Which engineering software can open it
Whether passwords or required credentials are available
Whether dependencies are documented
Whether restoration procedures have been tested

A ten-year-old project file stored somewhere on a network share is not necessarily a recovery strategy.

Backup management must include verification and recoverability.

Stage 10: Monitor for Operationally Meaningful Change

Traditional cybersecurity monitoring frequently focuses on malware, suspicious authentication, and network anomalies.

Those signals remain important.

But PLC environments require additional operational context.

Security teams should also care about questions such as:

Did an engineering connection occur unexpectedly?
Did communication behavior change?
Was a configuration modified outside an approved maintenance window?
Did a previously stable asset begin communicating with a new system?
Has the engineering environment changed?

The goal is not simply generating more alerts.

The goal is identifying changes that matter to operations.

Stage 11: Understand Obsolescence Before It Becomes an Emergency

Industrial equipment eventually reaches end-of-support or end-of-life.

Organizations should know this before a failure or security incident forces an emergency decision.

Lifecycle inventories should therefore track:

Hardware support status
Firmware support status
Engineering software compatibility
Replacement availability
Vendor lifecycle announcements
Migration dependencies

An obsolete PLC does not automatically mean an insecure PLC.

But unmanaged obsolescence creates risk.

The difference is whether the organization understands and actively manages that risk.

Stage 12: Secure Decommissioning Matters

PLC security does not end when the controller stops controlling production.

Decommissioned industrial devices may still contain:

Network configuration
Project information
Device identifiers
Operational parameters
Engineering metadata

Organizations should therefore maintain a controlled decommissioning process.

Asset inventories must be updated.

Remote access rules must be removed.

Associated engineering documentation must be archived appropriately.

Replacement systems must be incorporated into the new lifecycle baseline.

The lifecycle ends only when the organization has deliberately closed it.

The Real Security Boundary Is Larger Than the PLC

A useful way to think about PLC security is to stop viewing the controller as an isolated box.

The real security boundary includes:

PLC + Engineering Workstation + Project Files + Network + Remote Access + Firmware + Backups + People + Procedures

A weakness in any one of these areas can affect the security and resilience of the entire control environment.

This is why buying a "secure PLC" cannot solve PLC security by itself.

The surrounding lifecycle determines whether that security can be maintained.

A Practical PLC Lifecycle Model

Organizations can structure PLC lifecycle security around seven core questions:

1. IDENTIFY

What PLCs exist, where are they, and what processes do they control?

2. BASELINE

What hardware, firmware, configuration, logic, and communication represent the approved state?

3. PROTECT

Who can access the controller and which engineering systems are trusted?

4. CONTROL

How are logic, firmware, configuration, and network changes authorized and documented?

5. MONITOR

Can meaningful deviations from the approved operational state be identified?

6. RECOVER

Can the organization restore the controller and its engineering environment after failure or compromise?

7. RETIRE

Can obsolete equipment be replaced and removed without leaving unmanaged access, configurations, or documentation behind?

If an organization cannot confidently answer these questions, it does not yet have complete PLC lifecycle security.

Security Should Follow the Asset for Its Entire Life

The most dangerous assumption in industrial cybersecurity may be:

"It has been running for years, so it is fine."

Operational stability is not the same as cybersecurity resilience.

A controller may remain physically unchanged while the world around it changes completely.

New networks.

New vendors.

New remote connections.

New engineering systems.

New threats.

New business requirements.

Secure PLC lifecycle management exists to manage that change.

Final Thoughts

PLC security does not begin when a vulnerability is discovered.

And it does not end when a firewall is installed.

It begins when the system is designed.

It continues through commissioning, operation, maintenance, engineering changes, firmware decisions, network evolution, backup, recovery, and modernization.

And it ends only when the asset is securely retired.

The strongest PLC security programs therefore do not ask only:

"Is this controller secure today?"

They ask:

"Can we maintain trust in this controller throughout its entire operational life?"

That is the real challenge of secure PLC lifecycle management.

About the Author

Cihangir Dündar
Founder & CEO, CROVA

CROVA Research focuses on Operational Technology (OT), Industrial Control Systems (ICS), industrial cybersecurity, operational resilience, and critical infrastructure security.

Why PLC Security Is Still the Weakest Link in Critical Infrastructure

Cihangir Dündar — Thu, 06 Aug 2026 15:25:44 +0000

Why PLC Security Is Still the Weakest Link in Critical Infrastructure

Industrial cybersecurity has advanced significantly over the past decade.

Organizations now invest heavily in Security Operations Centers (SOC), Zero Trust architectures, Endpoint Detection and Response (EDR), Security Information and Event Management (SIEM), and Threat Intelligence platforms.

Despite these improvements, one critical component continues to present unique cybersecurity challenges inside industrial environments:

The Programmable Logic Controller (PLC).

PLCs are the digital brains of industrial operations.

They control motors, pumps, valves, conveyors, turbines, compressors, robotic systems, and countless other industrial processes that modern society depends on every day.

Power generation.

Water treatment.

Oil and gas.

Manufacturing.

Transportation.

Food production.

Almost every critical infrastructure sector depends on PLCs.

Protecting them is no longer only an engineering responsibility.

It has become a national cybersecurity priority.

Understanding the Role of a PLC

Unlike enterprise servers or office computers, PLCs interact directly with the physical world.

Every decision made by a PLC may affect an industrial process.

A PLC can:

Start or stop production lines
Control pressure inside pipelines
Regulate water flow
Monitor industrial sensors
Control electrical equipment
Coordinate robotic manufacturing cells

If an office computer fails, productivity may decrease.

If a PLC behaves unexpectedly, physical consequences may occur.

That difference changes everything.

Why PLC Security Is Different

Many cybersecurity controls developed for enterprise IT environments assume that systems can be:

Patched frequently
Rebooted regularly
Replaced every few years
Continuously scanned
Automatically updated

Industrial environments rarely operate this way.

PLCs often remain operational for fifteen or even twenty years.

Maintenance windows are limited.

Production cannot simply stop because a security update is available.

Operational continuity always comes first.

Cybersecurity must adapt to operations—not the other way around.

The Engineering Workstation Is Part of PLC Security

One of the biggest misconceptions in industrial cybersecurity is treating PLCs as isolated devices.

In reality, engineering workstations often represent one of the most important parts of PLC security.

Platforms such as:

Siemens TIA Portal
Rockwell Studio 5000
Schneider Electric EcoStruxure
Mitsubishi GX Works

are used to configure controllers, modify control logic, upload firmware, create backups, and deploy engineering changes.

Protecting PLCs therefore also means protecting the engineering systems that manage them.

If engineering workstations are compromised, operational integrity may also be affected.

USB Devices Remain a Practical Challenge

Industrial environments frequently rely on removable media.

Firmware updates.

Project transfers.

Offline engineering.

Vendor support.

Configuration backups.

These operational requirements make USB devices difficult to eliminate completely.

Instead of banning removable media, organizations should establish secure operational procedures including:

Approved engineering USB devices
Malware scanning
Device accountability
Restricted engineering permissions
Documented operational processes

Security should support operations while reducing unnecessary risk.

Network Segmentation Matters

PLCs should never be treated like ordinary enterprise devices.

Industrial controllers require carefully designed network architectures that separate operational systems from enterprise environments whenever appropriate.

Effective segmentation helps organizations:

Reduce unnecessary communication
Limit lateral movement
Improve monitoring
Simplify incident response
Support operational resilience

Segmentation is not simply a networking decision.

It is a cybersecurity strategy.

Visibility Before Protection

Many organizations ask:

"How do we protect our PLCs?"

A better question is:

"Do we know every PLC inside our environment?"

Effective PLC security begins with visibility.

Organizations should understand:

Every PLC model
Firmware versions
Engineering dependencies
Network communications
Operational criticality
Backup status

You cannot effectively protect assets you do not fully understand.

Change Management Is Cybersecurity

Not every industrial incident begins with a cyberattack.

Undocumented engineering changes.

Incorrect PLC logic.

Configuration mistakes.

Firmware inconsistencies.

These operational issues can create significant production risks.

Strong change management processes reduce both cybersecurity risk and operational errors.

Every modification should be documented.

Every backup should be verified.

Every engineering change should be traceable.

Building Resilient PLC Security

No single security product can protect industrial controllers.

Resilient PLC security combines:

Operational visibility
Secure engineering practices
Network segmentation
Access control
Secure backup strategies
Continuous monitoring
Engineering collaboration
Risk-based decision making

Technology alone is never enough.

Industrial cybersecurity succeeds when engineering and cybersecurity work together.

The Future of PLC Security

Industrial environments continue to evolve.

Remote operations.

Cloud connectivity.

Industrial IoT.

Predictive maintenance.

Digital transformation.

These technologies create tremendous business value.

They also expand the attack surface surrounding industrial controllers.

Organizations that treat PLC security as an engineering issue alone may overlook important cybersecurity risks.

Organizations that treat PLC security as an IT problem alone may overlook operational realities.

The future belongs to organizations that successfully integrate engineering knowledge with cybersecurity strategy.

Final Thoughts

PLCs remain at the center of industrial automation.

Protecting them requires far more than installing another security product.

It requires understanding industrial operations, engineering workflows, operational priorities, and the unique characteristics of critical infrastructure.

Cybersecurity should never interrupt industrial operations.

It should strengthen them.

Because protecting a PLC ultimately means protecting the essential services that modern society depends upon every day.

About the Author

Cihangir Dündar

Founder & CEO, CROVA

CROVA Research publishes technical articles focused on Operational Technology (OT), Industrial Control Systems (ICS), Industrial Cybersecurity, and Critical Infrastructure Security.

Why PLC Security Remains One of the Biggest Challenges in Industrial Cybersecurity

Cihangir Dündar — Sun, 02 Aug 2026 07:49:51 +0000

The Purdue Model Is Not Dead—But It Is No Longer Enough

Cihangir Dündar — Fri, 31 Jul 2026 13:55:20 +0000

The Purdue Model Is Not Dead—But It Is No Longer Enough

For more than two decades, the Purdue Enterprise Reference Architecture has been one of the most influential frameworks in industrial cybersecurity.

It introduced a structured way of separating enterprise IT from industrial control systems through multiple network layers, helping organizations reduce risk by limiting unnecessary communication between operational assets and business systems.

For many years, this approach worked remarkably well.

However, industrial environments have changed dramatically.

Remote maintenance, cloud connectivity, Industrial Internet of Things (IIoT), predictive maintenance platforms, centralized monitoring systems, vendor access solutions, and digital transformation initiatives have fundamentally changed how industrial networks operate.

The Purdue Model has not become obsolete.

But relying on it alone is no longer enough.

Why the Purdue Model Was So Successful

The Purdue Model introduced a simple but powerful principle.

Separate operational systems from enterprise systems.

Each network level has a different responsibility.

Communication should be controlled, monitored, and minimized.

This architecture significantly reduced the attack surface inside industrial environments.

Even today, these principles remain valuable.

Modern Industrial Networks Look Different

Today's industrial facilities rarely operate as isolated environments.

Organizations increasingly depend on:

Remote engineering support
Cloud analytics
Centralized SOC monitoring
Predictive maintenance platforms
Third-party vendor connectivity
Industrial IoT devices

These technologies create operational value.

They also create new communication paths that the original Purdue Model was never designed to describe.

Security Is No Longer Only About Segmentation

Network segmentation remains important.

However, modern industrial cybersecurity requires much more.

Organizations must also understand:

Which assets exist
How systems communicate
Who has remote access
Which engineering workstations control production
Which assets are most critical to operations

Without operational visibility, segmentation alone provides only partial protection.

Operational Visibility Changes Everything

The most resilient industrial organizations continuously monitor their operational environment.

Visibility enables security teams to understand:

Industrial assets
Communication patterns
Configuration changes
Remote engineering activity
Operational anomalies

Security decisions become more informed because they are based on operational reality rather than assumptions.

Engineering Must Become Part of Cybersecurity

Industrial cybersecurity cannot succeed without engineering teams.

Automation engineers understand production.

Cybersecurity teams understand threats.

Operations understand business priorities.

Real resilience emerges when these disciplines work together.

Technology alone cannot replace operational knowledge.

The Future of Industrial Cybersecurity

The future will not be defined by abandoning the Purdue Model.

Instead, organizations will build upon its principles while introducing:

Continuous asset visibility
Risk-based monitoring
Secure remote access
Engineering-aware security
Operational resilience
Threat-informed architecture

The question is no longer:

"Do we follow the Purdue Model?"

The better question is:

"How do we evolve beyond it while preserving its strengths?"

Final Thoughts

The Purdue Model remains one of the most important architectural concepts ever introduced into industrial cybersecurity.

Its core principles still provide tremendous value.

But modern operational environments require additional capabilities that extend beyond traditional segmentation.

Industrial cybersecurity is evolving from static architecture toward continuous operational awareness.

Organizations that successfully combine both approaches will be significantly better prepared for the next generation of industrial cyber threats.

About the Author

Cihangir Dündar

Founder & CEO, CROVA

CROVA Research publishes technical articles on Operational Technology (OT), Industrial Control Systems (ICS), Industrial Cybersecurity, and Critical Infrastructure Security.

Why Traditional Cybersecurity Fails in OT and ICS Environments

Cihangir Dündar — Tue, 28 Jul 2026 15:09:49 +0000

Why Traditional Cybersecurity Fails in OT and ICS Environments

For years, cybersecurity strategies have been built around traditional IT environments. Firewalls, endpoint protection, antivirus software, identity management, and security awareness programs have become standard practice for protecting enterprise networks.

However, Operational Technology (OT) and Industrial Control Systems (ICS) operate under completely different conditions.

Their primary mission is not protecting information.

Their mission is keeping physical processes running safely, reliably, and continuously.

This difference changes everything.

An office network outage may interrupt business operations for several hours.

An incident affecting a power plant, water treatment facility, manufacturing line, pipeline, or transportation system may interrupt essential services, damage expensive equipment, or create risks for human safety.

This is why applying traditional IT security strategies directly to OT environments is often not enough.

In some cases, it can even increase operational risk.

Understanding the Difference Between IT and OT

Although IT and OT are becoming increasingly connected, they were designed with completely different objectives.

Traditional IT systems focus on:

Protecting information
Business applications
User devices
Enterprise services

Operational Technology focuses on:

Industrial processes
Physical equipment
Production continuity
Operational safety

An IT administrator may accept rebooting a server during maintenance.

An OT engineer may not have that option.

Stopping an industrial controller—even for a short period—can interrupt production, affect process stability, or require complex restart procedures.

The environment itself changes the security strategy.

Why Traditional Security Models Become Insufficient

Many security products were designed assuming that systems can be patched regularly, restarted when necessary, or temporarily disconnected from the network.

Industrial environments rarely operate under these assumptions.

OT environments often contain:

Legacy operating systems
Vendor-specific hardware
Long equipment lifecycles
Strict availability requirements
Continuous production processes

For this reason, security decisions must always consider operational impact.

A technically correct security control may still be operationally unacceptable.

The Cost of Treating OT Like IT

Organizations frequently attempt to extend their existing IT security policies directly into industrial environments.

While this simplifies management, it may introduce new operational challenges.

Examples include:

Scheduled patching during production
Security software consuming controller resources
Aggressive network scanning affecting industrial communications
Automatic security updates without operational validation

The objective is not to avoid cybersecurity.

The objective is applying cybersecurity without disrupting industrial operations.

Critical Infrastructure Changes the Rules

Critical infrastructure organizations operate under unique responsibilities.

Electricity.

Water.

Oil and gas.

Manufacturing.

Transportation.

Ports.

Healthcare.

These environments support services that societies depend on every day.

Cybersecurity is no longer only about protecting digital assets.

It is also about maintaining operational continuity and reducing physical risk.

A Different Security Philosophy

Industrial cybersecurity requires a different mindset.

Instead of asking:

"How do we secure every device?"

The first question becomes:

"How do we maintain safe and continuous operations while reducing cyber risk?"

This leads to different priorities:

Operational visibility
Asset understanding
Risk-based segmentation
Continuous monitoring
Incident readiness
Engineering collaboration
Operational resilience

Technology alone cannot achieve these objectives.

People, processes, and engineering knowledge are equally important.

The CROVA Perspective

At CROVA, we believe industrial cybersecurity should begin with operational understanding.

Technology should support operations—not interrupt them.

Protecting industrial environments requires understanding how systems behave, how engineers operate, and how critical infrastructure delivers essential services every day.

Mission-grade OT cyber operations are built on visibility, operational awareness, engineering collaboration, and continuous risk management.

The goal is not simply detecting cyber threats.

The goal is protecting operational continuity.

Final Thoughts

The convergence of IT and OT continues to accelerate.

Digital transformation, remote operations, industrial connectivity, and modern automation are creating new opportunities—but also expanding the cyber threat landscape.

Organizations that continue treating OT environments like traditional IT networks will increasingly face unnecessary operational risk.

Industrial cybersecurity deserves its own strategy.

Because industrial environments operate differently.

And security strategies should reflect that reality.

Thank you for reading.

If you are interested in Operational Technology (OT), Industrial Control Systems (ICS), Critical Infrastructure Security, or industrial cyber operations, I will be sharing additional technical articles and research through this profile.