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.
Top comments (0)