DEV Community: Cihangir Dündar

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.