In the world of industrial cybersecurity, we often pride ourselves on applying defense-in-depth strategies to our Operational Technology (OT) infrastructure. We layer controls across servers, applications, and networks with precision and purpose. But when it comes to the very systems that control physical processes, those same principles are often left at the door.
Why?
I’d contest that it is mostly overlooked due to PLCs being outside the typical OT security team’s wheelhouse. OT security professionals tend to focus on familiar security capabilities, assuming these controls are adequate, and leave control systems to the automation engineers.
The PLC Security Paradox
PLCs are the backbone of industrial operations. They are responsible for automating the industrial process and maintaining a safe state throughout the facility. However, they are often neglected or addressed through methods that are inefficient and have limited effectiveness against the most plausible threats.
There’s persistent cultural hesitation around PLC security. Concerns about downtime, effectiveness, operability, legacy equipment, and vendor compatibility often stall progress before it starts. But this reluctance is costing us.
By avoiding PLC security, we’re missing out on opportunities to improve operational resilience, reduce downtime, and enhance safety. The good news? You don’t have to boil the ocean. You just have to get started to begin reaping the benefits.
Yes, It Can be Complicated, But That’s No Excuse
It’s true: many PLC ecosystems are fragmented. Different vendors, firmware versions, and hardware generations make a holistic approach and standardization difficult. Some devices support modern security features; others don’t. But that shouldn’t stop you from evaluating what’s possible today and planning for what’s needed tomorrow.
Even in a fragmented ecosystem, there will typically be a couple of top vendors and similar models that can be the strategic focal point. Organizational hardware strategies are continuing to consolidate over time, which creates opportunities to align short-term and long-term PLC security capabilities with an operational framework that is both effective and maintainable. PLC vendors have been making great strides in the last decade to provide practical security capabilities for their ecosystems, many of which can be centrally administered.
Missing the Mark
In my experience, most organizations that attempt to approach PLC security are focused on reducing the attack surface for external threat actors. This typically manifests in a generic hardening checklist focused on lowest common denominator capabilities as the program is focused on a checklist that can be used across all vendors (e.g., disable unused ports, disable the web interface, PLC password). OT security practitioners and automation engineers frequently rely on options that are immediately apparent within configuration software when addressing heterogeneous environments, often viewing these as the sole solutions.
The problem with this approach is that it typically has minimal to no impact on reducing the incidents caused by well-intentioned insiders. Maintenance and automation teams typically don’t even know the features that were hardened even exist. Some of the more likely and impactful scenarios are a PLC fails and the latest program file wasn’t backed up, maintenance makes a programming or configuration change to fix an immediate problem that unknowingly compromises the integrity of the code, or a perhaps a SCADA/HMI engineer is trying to upload a copy of the PLC program file to test out their screens in the lab yet they inadvertently download to the PLC, thus bringing down operations. Unfortunately, your hardening checklists will not reduce the likelihood or impact of such events.
While I won’t say that one shouldn’t consider configuration hardening, as there is some merit, but the reality is that this is putting the cart before the horse instead of focusing on foundational security capabilities that can be reasonably maintained and will effectively reduce the attack surface for both external and internal (i.e., intentional and unintentional, threat actors).
Where to Begin: Start with What Matters Most
Automated Backup & Change Monitoring
To immediately address gaps in your PLC security program without the complexities of evaluating every available solution, I’d strongly advise beginning by implementing an automated PLC backup platform to ensure recovery capabilities following any incident. Such platforms provide immediate and measurable benefits across the organization, regardless of vendor diversity, industry sector, facility type, or system criticality. Given that failures arising from hardware malfunctions, human error, or cyber threats are inevitable, reliance on manual backup processes exposes organizations to unnecessary risks. In contrast, automated solutions safeguard essential code and enable prompt restoration of operations.
Implementing an automated PLC backup platform increases confidence in the integrity and availability of your backups, dramatically reducing both downtime and operational disruption when code restoration is needed. These systems do more than just safeguard your program files, they also provide automated change detection, alerting you when the PLC code deviates from the most recent backup. This usually include detailed logs, capturing who accessed the PLC, what actions were taken, and when and where changes occurred, boosting accountability and auditability. Even if you already have an OT Network Intrusion Detection System (NIDS), a PLC backup platform will enhance your ability to detect changes through active means while nearly all NIDS solutions are limited to the network traffic that they are able to monitor, leading to network monitoring gaps that do not detect changes made by users directly connected to the PLCs.
For your automation teams, automated backup platforms offer a reliable and protected code repository, saving valuable time by streamlining the search for the latest files, supporting change management activities, and preserving vital code comments and tag names that might otherwise be lost. There are a number of robust, centralized systems available on the market today (e.g., AssetCentre, Octoplant) that support a diverse range of PLC models, vendors, and firmware versions, making this an achievable step regardless of the diversity or complexity of your environment.
Access Controls
If there were a second foundational capability on which I would focus, it would be implementing PLC access control. In my experience, many organizations at least have some semblance of automation engineering (full read/write) and maintenance (limited write) roles where the automation teams handle the more complex problems and maintenance teams are providing the day-to-day activities where limited write capabilities are needed. The majority of the incidents that I’ve seen impacting either production or the integrity of the PLC code have come by way of well-intentioned insiders, usually on the maintenance team, that have tried to solve a problem that they were not qualified to solve. I have personally seen this result in unplanned downtime, loss of revenue due to inaccurate flow calculations, damaged equipment, unsafe safety program modifications, and environmental spills.
While many organizations already employ traditional access controls where only specific users are permitted to log into the engineering workstations, this does not limit the risk exposure described above as both engineering and maintenance personnel leverage the same applications to interact with the PLCs for their job responsibilities. To adequately address this gap, we need to focus on implementing role-based access control (RBAC) for our PLCs. While it is not well known, the good news is that many PLC vendors are RBAC capable and can integrate with common identity providers (e.g., Active Directory) while being centrally administered.
Understand that unless you are a single PLC vendor environment, you will most likely not be reasonably able to apply access controls to your entire PLC ecosystem. Start by understanding your assets, each vendor’s access control capabilities and limitations, your riskiest PLCs, PLC procurement strategy, and the level of effort needed to implement and administer the access control solutions. This will typically lead to identifying one or two PLC vendors that have adequate security capabilities which align with the long-term procurement strategy. Depending on the vendors, capabilities, and risk, this may be as simple as focusing on applying RBAC to the remote access engineering workstations for your top vendors or a full-blown RBAC environment that protects most of your PLCs, even from users directly connected to the PLC via a serial connection.
We apply RBAC to most of our OT environment, so organizations should at least be considering applying the same principle to arguably our most critical assets.
Additional Controls
The top two controls listed above are not the only PLC controls that vendors offer today, albeit they are the most universally applicable and effective. Depending on an organization’s risk exposure and use cases, there are reasons to consider pursuing a more holistic approach to PLC security. I’ve briefly listed a couple of other security capabilities below for reference:
- PLC System Logs: Capture user actions and system events for auditing. This is very vendor dependent and time intensive to implement effectively.
- PLC Configuration Hardening: Disable unused ports and services to reduce attack surface. This is focused on reducing the attack surface from external threat actors with varying levels of effectiveness.
- Microsegmentation & Encryption: Protect and encrypts communications between PLCs and devices communicating with PLCs. There is very hardware dependent and, if you have a NIDS tool in place, you will most likely lose the ability to inspect the traffic.
- Secure PLC Coding: Apply best practices like modular code, input validation, and plausibility checks to reduce exposure. This is a great practice to put into place, but it is forward thinking, difficult to define and deploy on existing PLCs, and typically outside of the cybersecurity team’s sphere of influence.
Building a Practical PLC Security Program
There’s no “one-size-fits-all” solution for PLC security. Organizations must balance impact, feasibility, and sustainability when deciding which controls to implement. Most organizations today rely solely on administrative controls which are good practices but are mere “honor systems” without technical enforcement. If you are looking to develop a PLC security program that goes beyond automated backup and recovery capabilities, you will need to balance security and operability while not trying to bite off more than you can chew.
- Focus on Problem Solving: Identify specific cyber or functional problems (e.g., automation, operations, safety issues) you’re trying to solve, seeking synergy in solutions across different groups.
- Engage Stakeholders: Meet with automation, operations, and safety groups to understand their operational flow, challenges, and long-term roadmaps. Solutions must work within their environment.
- Identify Practical Solutions: Prioritize impactful and maintainable solutions. For instance, automated backups and change monitoring supports a diverse vendor environment and offers higher business value than hardening, which often has minimal impact and many variations across PLC types.
- Focus Your Scope: Don’t attempt to “boil the ocean” by trying to do everything at once. Focus on the best solutions, which support where the organization is headed, what has the greatest impact, and what is maintainable.
- Plan for Longevity: Define operational activities, provide sufficient documentation (especially for staff turnover), and appropriately staff the organization with skilled individuals to ensure long-term success. Without proper support, efforts will degrade.
The most common operational barriers to implementing PLC security include cultural resistance from automation groups, attempts that are too broad in scope, and a lack of understanding of the operational environment.
My advice is to focus on future direction, not try to address all vendors, and implement only what’s possible to maintain.
By adopting a thoughtful, practical, and well-supported approach to PLC security, organizations can move beyond basic protection and build truly resilient operational environments.
Developing a PLC security program that meets business objectives requires expertise in engineering, operations, industry standards, and OT cybersecurity practices. The integration of these areas forms the cornerstone of Armexa’s staff and sets us apart from large consulting firms that may have only read the IEC/ISA 62443 suite of standards. If you’re looking to strengthen your OT cybersecurity or explore how Armexa can support your PLC security efforts, Contact Us.
by Josh Ruff
