DEV Community: Cihangir Dündar

From Ethical Hacking to Critical Infrastructure Security: My Professional Journey

Cihangir Dündar — Sun, 25 Oct 2026 08:33:54 +0000

Cihangir Dundar | International Cybersecurity and Defense Technologies

Cihangir Dündar is a Turkish cybersecurity specialist and the founder of CROVA, with professional experience spanning international cybersecurity research, ethical hacking, defense technologies, and critical infrastructure security.

His work focuses on vulnerability research, attack surface analysis, industrial cybersecurity, and the security architecture of complex digital systems.

International Cybersecurity Experience

Between 2017 and 2021, Dündar participated in international ethical hacking and vulnerability research platforms under various researcher aliases.

During this period, he achieved several notable rankings, including a first-place finish in 2019, marking a significant milestone in his cybersecurity research career.

His involvement in the international cybersecurity community, including HackerOne, enabled technical collaboration and knowledge exchange with security researchers across different countries.

His research activities focused on vulnerability assessment, attack surface analysis, and identifying security weaknesses within complex digital infrastructures.

Defense and Aviation Technologies

Beyond cybersecurity research, Dündar contributed technical expertise to three international defense industry projects.

He also participated in an aviation technology initiative involving the security assessment of algorithmic systems, vulnerability research, and technical security consulting.

These activities reflect a professional background extending from offensive security research to the evaluation of security risks in high-reliability engineering environments.

CROVA and Critical Infrastructure Security

Founded by Cihangir Dündar, CROVA focuses on operational technology (OT), industrial control systems (ICS), critical infrastructure cybersecurity, and cyber threat analysis.

Dündar applies his international cybersecurity research experience to industrial network security, system visibility, and operational risk assessment.

CROVA's technical approach positions cybersecurity as an integral component of system integrity and operational resilience, rather than solely as a mechanism for preventing cyber threats.

The company's work emphasizes the importance of understanding complex industrial environments, identifying emerging security risks, and strengthening the resilience of critical digital infrastructure.

Official Website: CROVA

Areas of Expertise: Cybersecurity Research, Ethical Hacking, Vulnerability Assessment, Defense Technologies, Aviation Security, OT/ICS Security, and Critical Infrastructure Protection.

Why Engineering Laptops Are Becoming the Biggest Cybersecurity Risk in Industrial Facilities

Cihangir Dündar — Sat, 10 Oct 2026 15:25:22 +0000

Why Engineering Laptops Are Becoming the Biggest Cybersecurity Risk in Industrial Facilities

An in-depth analysis of engineering workstation security, PLC programming environments, industrial network trust boundaries, and the hidden operational risks introduced by portable engineering devices.

By Cihangir Dündar

Founder & CEO, CROVA

CROVA Research | Industrial Cybersecurity & Critical Infrastructure

Introduction: The Most Powerful Device in a Factory May Not Be a PLC

When industrial organizations discuss cybersecurity, the conversation usually focuses on programmable logic controllers (PLCs), supervisory control and data acquisition (SCADA) systems, industrial firewalls, and network segmentation.

These systems deserve attention. They form essential parts of modern industrial operations.

However, one device can interact with nearly all of them.

It may be carried between production facilities, connected to different industrial networks, used by multiple engineering teams, and occasionally connected to the internet.

That device is the engineering laptop.

Unlike an ordinary corporate workstation, an engineering laptop may possess the tools, credentials, configurations, and operational privileges necessary to modify industrial control systems.

It can upload or download PLC programs, modify hardware configurations, perform diagnostics, manage firmware, and interact with automation equipment.

This makes engineering laptops exceptionally valuable operational assets.

It also makes them potentially dangerous trust bridges.

A compromised engineering laptop does not necessarily need to exploit a vulnerability in a PLC to create operational risk.

If the laptop already has legitimate engineering access, the attacker may attempt to abuse the privileges and workflows associated with that access.

The central cybersecurity challenge is not simply protecting the engineering laptop. It is controlling the trust that industrial environments place in it.

Engineering laptops are not universally the weakest security component in every industrial facility. Their risk depends on architecture, access privileges, maintenance practices, and operational criticality.

Nevertheless, they represent a particularly important and sometimes underestimated attack surface.

This article examines why.

1. Engineering Laptops Are Not Ordinary Endpoints

Traditional enterprise endpoints are generally designed to support business applications, communications, document management, and administrative functions.

Engineering laptops serve a fundamentally different purpose.

They may interact directly with industrial equipment controlling physical processes.

A typical engineering laptop may contain software for:

PLC programming and configuration
Human-machine interface (HMI) development
Industrial network diagnostics
Drive and motor configuration
Safety system engineering
Firmware maintenance
Industrial communication testing
Automation project management

These functions require privileges that would be unusual on ordinary corporate endpoints.

Consider a simplified example.

An office laptop may be authorized to access email, internal applications, and shared documents.

An engineering laptop may be authorized to communicate with a controller responsible for a manufacturing line.

The difference is not merely technical.

It is operational.

Changes performed through engineering software may influence equipment behavior, production continuity, or safety-related functions.

Consequently, endpoint security decisions must account for physical-process consequences.

2. The Engineering Software Ecosystem

Industrial engineering environments are built around specialized software platforms.

Several widely used examples include:

Siemens TIA Portal

Siemens Totally Integrated Automation Portal (TIA Portal) provides an engineering environment for supported Siemens automation systems.

Depending on the configuration and installed components, engineers can use it for PLC programming, hardware configuration, diagnostics, and associated automation tasks.

From a cybersecurity perspective, organizations must protect the engineering workstation, project files, authorized connections, and change-management procedures surrounding the environment.

Rockwell Automation Studio 5000

Studio 5000 is used in engineering workflows involving supported Rockwell Automation control systems.

Engineering projects may include controller logic, configuration information, and other operationally significant data.

Protecting the integrity of approved projects and controlling who can deploy modifications are important security objectives.

Schneider Electric EcoStruxure Engineering Tools

Schneider Electric provides multiple engineering tools within its industrial automation ecosystem.

These tools support different controllers, architectures, and operational requirements.

Security considerations include project management, workstation hardening, authorized access, software compatibility, and controlled maintenance procedures.

Mitsubishi Electric GX Works

GX Works engineering software supports programming and configuration workflows for compatible Mitsubishi Electric PLC platforms.

As with other engineering environments, security depends on more than the application itself.

The workstation, project repository, access permissions, and operational procedures all contribute to the overall security posture.

Why These Platforms Matter

These products are not inherently insecure simply because they provide powerful engineering functionality.

The important point is that they operate within a privileged industrial workflow.

A legitimate engineering function can become a security concern when the surrounding access controls, endpoint protections, or approval processes are inadequate.

The security of an industrial controller is partly dependent on the security of the engineering systems authorized to modify it.

3. The Engineering Laptop as a Trust Bridge

Industrial cybersecurity architectures often emphasize separation between information technology (IT) and operational technology (OT).

Organizations implement firewalls, industrial demilitarized zones, VLANs, access-control policies, and remote-access gateways.

However, portable engineering devices can introduce an additional dimension of connectivity.

Consider an engineering laptop that is used in several environments:

A corporate office
A vendor support network
A maintenance workshop
A manufacturing facility
An industrial control network

Even if these networks are logically separated, the same physical endpoint may interact with multiple trust domains over time.

This creates a security challenge.

The laptop may carry software, credentials, cached data, project files, removable media, and configuration changes between environments.

Network segmentation does not automatically address all risks associated with this movement.

A firewall may restrict network communication, but it cannot by itself guarantee the integrity of a device that is later connected through an authorized maintenance port.

This is why engineering laptop security must be treated as part of the industrial trust architecture.

4. The Hidden Risks of Portable Engineering Devices

Portability is operationally valuable.

Engineers need to move between production lines, cabinets, substations, and maintenance locations.

A single laptop may support several controllers or facilities.

However, portability can create security exposure.

Shared Use

In some organizations, engineering laptops are shared between multiple technicians.

Without appropriate individual authentication and activity records, accountability becomes difficult.

Inconsistent Security Configurations

Engineering laptops may be maintained differently from enterprise endpoints because of vendor compatibility requirements.

This can lead to inconsistent security baselines.

Multiple Network Interfaces

Engineering devices may include Ethernet, Wi-Fi, USB adapters, serial interfaces, and other communication capabilities.

These interfaces should be controlled according to operational requirements.

Temporary Connections

A connection established for troubleshooting may introduce a communication path that did not previously exist.

Uncontrolled Software Installation

Diagnostic utilities, engineering tools, drivers, and vendor-provided applications may be installed over time.

Without software governance, the workstation's trusted configuration can gradually deteriorate.

The combined result is a potentially privileged endpoint with a complex operational history.

5. USB Devices: A Persistent Industrial Security Challenge

Removable media remains common in industrial environments.

Organizations use USB storage devices for legitimate activities such as:

Transferring engineering projects
Delivering approved software packages
Moving diagnostic logs
Supporting offline maintenance
Transferring configuration backups
Installing approved updates

These activities may be necessary where network connectivity is limited or deliberately restricted.

However, removable media introduces risks.

Malicious files may enter an engineering environment through untrusted storage devices.

Files can also be accidentally modified, replaced, or transferred without appropriate verification.

A USB device used across multiple systems can become a vehicle for moving untrusted content between otherwise separated environments.

A Better Approach Than Uncontrolled USB Use

Organizations should establish a removable-media security process.

This can include:

Approved and inventoried storage devices
Dedicated media for sensitive environments
Malware scanning through a controlled transfer process
File-integrity verification
Restricted execution of unapproved software
Documented ownership and transfer procedures
Secure storage and disposal

Where technically feasible, organizations should also consider dedicated file-transfer stations or controlled media-processing workflows.

The objective is not necessarily to eliminate USB devices.

It is to prevent removable media from becoming an uncontrolled trust mechanism.

6. PLC Project Files Are Critical Operational Assets

An industrial engineering project is more than a collection of files.

Depending on the automation platform, it may contain:

Controller program logic
Hardware configuration
Network settings
Device parameters
Tag definitions
Communication configuration
HMI-related engineering information
Version and dependency information

These files represent valuable engineering knowledge.

Their integrity matters.

A corrupted or outdated project may complicate maintenance or recovery.

An unauthorized modification may introduce discrepancies between the approved engineering state and the deployed controller configuration.

A lost project may make future troubleshooting or modernization significantly more difficult.

The Source-of-Truth Problem

One recurring challenge is identifying the authoritative project version.

An organization may have several copies:

One on the engineering laptop
One on a network share
One on removable media
One held by an external integrator
One in an archived maintenance folder

Which one is correct?

Which one corresponds to the deployed controller?

Which version has been approved?

Without controlled project management, these questions can become difficult to answer.

Recommended Security Principles

Organizations should establish:

A controlled engineering project repository
Version tracking
Restricted modification permissions
Change approval procedures
Protected backup copies
Periodic verification against the deployed configuration, where supported and operationally safe

Project files should be managed as critical operational assets rather than ordinary documents.

7. Why Traditional Endpoint Security May Not Be Enough

Enterprise endpoint security tools can provide valuable protection.

However, their deployment in industrial engineering environments requires careful planning.

Some engineering applications depend on specific operating systems, drivers, software versions, or communication services.

Security controls that modify these dependencies may introduce compatibility concerns.

For example, organizations should evaluate whether a proposed security agent could interfere with:

Engineering application performance
Specialized device drivers
Industrial communication software
Approved maintenance workflows
Vendor-supported configurations

This does not mean engineering laptops should operate without endpoint protection.

It means protection must be selected, tested, and maintained with operational requirements in mind.

A Layered Endpoint Security Model

A practical approach may combine:

System hardening: Disable unnecessary services and reduce the attack surface.

Application control: Restrict execution to authorized software where feasible.

Endpoint monitoring: Deploy compatible security monitoring capabilities.

Least privilege: Avoid unnecessary administrative rights.

Patch management: Validate updates against engineering requirements.

Device control: Manage removable media and peripheral access.

Recovery: Maintain verified workstation images and engineering backups.

No individual control is sufficient.

The objective is to reduce the probability that a compromised endpoint can influence critical operations.

8. Vendor and Third-Party Engineering Access

Industrial facilities frequently depend on external expertise.

Original equipment manufacturers, automation integrators, maintenance contractors, and specialized engineering firms may require access to industrial systems.

These relationships are often essential.

However, third-party access introduces additional security considerations.

A vendor laptop may have been used in several customer environments.

It may be managed under security policies different from those of the industrial facility.

Its software and configuration may not be directly visible to the asset owner.

This creates a trust-management problem.

Questions Every Facility Should Ask

Before allowing engineering access, organizations should understand:

Who owns and manages the laptop?
Is its security configuration approved?
Which industrial assets can it reach?
What engineering activities are authorized?
Is access temporary or permanent?
How are activities recorded?
How is access revoked after maintenance?

Controlled Vendor Access

Depending on the operational environment, controls may include dedicated vendor-access workstations, managed jump hosts, time-limited authorization, strong authentication, and monitored maintenance sessions.

For high-consequence environments, using facility-controlled engineering devices may provide stronger assurance than accepting arbitrary external endpoints.

The appropriate approach should reflect operational risk.

9. Engineering Laptops and Ransomware Exposure

Ransomware is commonly associated with encrypted files, unavailable servers, and disrupted business operations.

In industrial environments, the consequences can extend into engineering availability.

An engineering workstation affected by ransomware may become unavailable when maintenance is urgently required.

Project files may be inaccessible.

Engineering software installations may need to be rebuilt.

Recovery may be delayed by missing licenses, drivers, or compatible software versions.

Importantly, ransomware does not need to modify PLC logic to create operational disruption.

Preventing engineers from accessing the tools required to maintain or restore equipment can itself be consequential.

Engineering Recovery Requirements

Organizations should maintain:

Offline or otherwise protected engineering project backups
Verified recovery images
Software installation packages from trusted sources
Licensing and activation recovery procedures
Documentation of engineering dependencies
Tested restoration processes

Recovery planning must account for both the controller and the workstation used to manage it.

10. Network Segmentation Cannot Replace Endpoint Trust

Industrial network segmentation is essential.

However, segmentation and endpoint security solve different problems.

Segmentation controls communication between network zones.

Endpoint security addresses the integrity and behavior of devices operating within those zones.

An engineering laptop that is legitimately authorized to access a controller may still introduce risk if the laptop itself is compromised.

Therefore, organizations must combine:

Network segmentation
Endpoint hardening
Access authorization
Identity management
Change control
Monitoring

The goal is to avoid assuming that a device is trustworthy simply because it is connected through an approved network path.

Authorized connectivity does not automatically imply a trusted endpoint.

11. The Role of IEC 62443

The IEC 62443 series provides an important framework for industrial automation and control system cybersecurity.

Its concepts are relevant to engineering laptop security, particularly around security governance, system requirements, zones and conduits, and component security.

Engineering laptops should be considered within the overall industrial cybersecurity architecture rather than managed as unrelated office equipment.

Zones and Conduits

Industrial environments can be divided into security zones according to risk and security requirements.

Communication between zones can then be controlled through defined conduits.

Engineering workstations should be assigned to appropriate zones based on their operational function and required access.

A laptop with broad access to multiple controllers deserves a different risk assessment from a workstation used only for documentation.

Security Requirements

Relevant IEC 62443 concepts include identification and authentication, use control, system integrity, restricted data flow, timely response to events, and resource availability.

Applying these concepts to engineering laptops requires practical decisions about access, monitoring, software integrity, and operational resilience.

IEC 62443 should not be treated merely as a compliance checklist.

Its value lies in translating industrial security requirements into controlled engineering practices.

12. Building a Secure Engineering Laptop Architecture

A mature engineering laptop security program should be designed around operational trust.

Consider the following conceptual architecture:

Corporate IT Environment

↓

Controlled Access Boundary

↓

Engineering Access Services

↓

Authorized Engineering Workstation

↓

Approved Industrial Network Segment

↓

PLC / HMI / Industrial Controllers

The exact design will vary by facility.

Some organizations may use dedicated engineering workstations inside OT zones.

Others may require portable laptops for field maintenance.

In either case, the architecture should minimize unnecessary access and maintain clear accountability.

Core Architectural Principles

Dedicated engineering assets

Where practical, separate engineering devices from general-purpose business laptops.

Approved software baselines

Maintain controlled operating system, engineering software, and driver configurations.

Restricted network access

Allow only communication required for authorized engineering activities.

Individual accountability

Use identifiable accounts and controlled privileges.

Project integrity

Protect approved engineering files and configurations.

Monitoring

Record relevant engineering access and configuration changes where supported.

Recovery readiness

Maintain tested procedures for restoring engineering capability.

These controls should be implemented proportionately, based on asset criticality and operational constraints.

13. The Engineering Laptop Lifecycle

Engineering laptops require lifecycle management just as PLCs do.

Procurement

Define minimum security and compatibility requirements before purchasing engineering devices.

Commissioning

Install approved software, apply the security baseline, configure access controls, and document the device.

Operation

Maintain an accurate inventory and control routine engineering activities.

Maintenance

Apply validated updates and review software dependencies.

Reassignment

Remove unnecessary credentials, access permissions, and sensitive project information when ownership or responsibility changes.

Decommissioning

Revoke access, securely handle stored data, and update asset records.

Lifecycle management prevents engineering endpoints from accumulating unmanaged risk over time.

14. The Human Factor: Engineering Culture and Cybersecurity

Industrial engineers often work under intense operational pressure.

When a production line stops, restoring functionality becomes the immediate priority.

Cybersecurity controls that are difficult to use may be bypassed, particularly during urgent maintenance.

This is not simply a training problem.

It can also indicate that security processes were designed without sufficient operational input.

Effective engineering security requires collaboration between:

Automation engineers
OT cybersecurity specialists
Maintenance teams
Network engineers
Operations management
Equipment vendors

Security procedures should be understandable, practical, and compatible with real maintenance conditions.

An effective program makes the secure process the normal process.

15. Ten Questions Every Industrial Organization Should Answer

A useful starting point is a structured assessment of engineering laptop security.

1. Do we know how many engineering laptops exist?

An accurate inventory is the foundation of asset governance.

2. Do we know which controllers each laptop can access?

Access should reflect operational necessity.

3. Are engineering software versions documented?

Compatibility and support status matter.

4. Are project files centrally managed?

Uncontrolled copies create integrity and recovery problems.

5. Are removable media activities controlled?

USB transfers should follow approved procedures.

6. Are third-party engineering devices governed?

Vendor access must not become an exception to security policy.

7. Are administrative privileges restricted?

Engineering functionality should not automatically require unrestricted system administration.

8. Can unauthorized engineering activity be identified?

Monitoring should focus on meaningful changes and access events.

9. Can an engineering laptop be rebuilt after compromise?

Recovery procedures should be tested.

10. Is engineering laptop security included in OT risk assessments?

The engineering endpoint should be treated as part of the control system's security boundary.

Organizations unable to answer these questions should prioritize closing the resulting visibility and governance gaps.

16. A Practical 90-Day Improvement Roadmap

Industrial organizations do not need to solve every engineering endpoint risk immediately.

A phased approach can establish meaningful improvements.

Days 1–30: Visibility and Assessment

Identify engineering laptops and their owners.

Document engineering software and operating systems.

Map access to critical controllers.

Review removable media usage.

Identify external engineering access.

Assess backup availability.

The first objective is understanding the environment.

Days 31–60: Baseline and Access Control

Define approved workstation configurations.

Review administrative privileges.

Restrict unnecessary connectivity.

Establish controlled project storage.

Formalize vendor access requirements.

Introduce documented removable-media procedures.

The second objective is reducing unmanaged trust.

Days 61–90: Monitoring and Recovery

Introduce compatible monitoring controls.

Test engineering workstation restoration.

Verify project backups.

Review change-management procedures.

Document security exceptions.

Assign ownership for ongoing compliance.

The third objective is establishing sustainable operational assurance.

The exact sequence should be adjusted according to production criticality, safety requirements, and available maintenance windows.

17. From Endpoint Protection to Engineering Trust Management

The future of industrial endpoint security should not be defined solely by deploying more software agents.

Engineering laptops occupy a unique position.

They are both computers and operational control interfaces.

They connect human engineering decisions with physical industrial processes.

Their security therefore depends on several interconnected elements:

Device Integrity

Is the workstation operating in an approved and trustworthy state?

Identity

Who is using it?

Authorization

Which engineering actions are permitted?

Project Integrity

Are the engineering files authentic and approved?

Network Trust

Which industrial systems can the device reach?

Operational Context

Is the activity expected and authorized?

Recovery

Can engineering capability be restored after an incident?

Together, these questions provide a more useful foundation than endpoint protection alone.

18. The CROVA Research Perspective

At CROVA, our research perspective is that industrial cybersecurity must be built around operational reality.

Engineering laptops illustrate why this matters.

A device may appear compliant with a traditional IT security checklist while still creating unacceptable operational exposure.

Conversely, an engineering workstation may require carefully controlled exceptions to ordinary enterprise security practices because of industrial compatibility constraints.

Neither situation can be evaluated properly without understanding the process being protected.

The key is integrating engineering knowledge, cybersecurity architecture, and operational risk management.

Three principles are particularly important.

First: Understand Engineering Authority

Organizations must know which devices have the capability to change industrial configurations and control logic.

Second: Control Trust Across Boundaries

Portable engineering devices should not automatically inherit trust when moving between networks, facilities, or maintenance environments.

Third: Protect the Engineering Lifecycle

Security must cover project creation, deployment, modification, maintenance, recovery, and retirement.

These principles apply across manufacturing, energy, water treatment, transportation, and other industrial environments.

19. Further Reading and Technical References

The following publications and frameworks provide useful foundations for engineering workstation and industrial cybersecurity programs.

NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security

A comprehensive reference covering OT security architecture, risk management, operational constraints, and security controls.

https://csrc.nist.gov/pubs/sp/800/82/r3/final

ISA/IEC 62443 — Industrial Automation and Control Systems Security

An internationally recognized series of standards addressing cybersecurity across industrial automation and control system environments.

https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards

MITRE ATT&CK for ICS

A knowledge base describing adversary behaviors relevant to industrial control systems.

https://attack.mitre.org/matrices/ics/

CISA — Industrial Control Systems

Guidance and security resources addressing industrial control system cybersecurity and critical infrastructure protection.

https://www.cisa.gov/topics/industrial-control-systems

Important: These references support the broader security principles discussed in this article. The assessment and recommendations presented here are the author's synthesis, not a claim that each referenced organization endorses this article.

Final Thoughts: Protecting the Device That Can Change Everything

Industrial cybersecurity often focuses on protecting controllers, industrial networks, and critical infrastructure systems.

Yet the engineering laptop deserves equal consideration because it may possess legitimate authority to interact with all of them.

A PLC may operate reliably for decades.

A firewall may enforce carefully designed segmentation rules.

A SCADA environment may be continuously monitored.

But if an engineering laptop is poorly managed, carries untrusted software, or has excessive access privileges, the overall security architecture may still contain a significant weakness.

The solution is not to eliminate portable engineering devices.

Industrial operations depend on them.

The solution is to recognize their privileged role and manage them accordingly.

An engineering laptop should never be trusted simply because an engineer is authorized to use it. Trust must be established through device integrity, controlled access, verified engineering processes, and operational accountability.

The next generation of industrial cybersecurity will depend not only on securing controllers and networks, but also on protecting the engineering systems that define how those controllers operate.

Because in modern industrial environments, protecting the engineering laptop may mean protecting the entire production process.

About the Author

Cihangir Dündar

Founder & CEO — CROVA

Cihangir Dündar writes about Operational Technology (OT), Industrial Control Systems (ICS), engineering security, industrial cyber risk, and critical infrastructure resilience.

Through CROVA Research, he examines the intersection of industrial engineering, cybersecurity architecture, operational visibility, and risk-based security practices.

CROVA — Operational Technology & Critical Infrastructure Cybersecurity

Website: https://crova.com.tr

Published as part of the CROVA Research Industrial Cybersecurity Series.

Keywords: Engineering Laptop Security, Engineering Workstation Security, Industrial Cybersecurity, OT Security, ICS Security, PLC Security, Siemens TIA Portal, Rockwell Studio 5000, Schneider EcoStruxure, Mitsubishi GX Works, IEC 62443, Critical Infrastructure, CROVA, 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.