ISA Unveils Top 20 Secure PLC Coding Practices for OT Cybersecurity

Industrial control systems are under siege. As ransomware groups and nation-state actors increasingly pivot from IT networks to operational technology, programmable logic controllers — the unglamorous workhorses of factory floors, water utilities, and energy grids — have become prized targets. Yet for decades, the cybersecurity community had no dedicated, vendor-neutral framework for writing secure PLC code. That gap has now closed.

Why PLC Security Demands Its Own Rulebook

The project, backed by the ISA Global Cybersecurity Alliance (ISAGCA) and led by security experts Sarah Fluchs and Vivek Ponnada, makes a provocative and persuasive argument: the nuances of PLCs should be treated as features, not bugs, when designing security controls.

Unlike traditional IT software, PLCs operate in hard real-time, interface directly with physical machinery, and use specialized programming languages — ladder logic, function block diagrams, and structured text — that bear little resemblance to Python or Java. Input validation in a PLC isn't just about preventing SQL injection; it's about verifying that a pressure sensor reading is physically plausible before opening a relief valve.

The framework maps each practice to established standards including ISA/IEC 62443, MITRE ATT&CK for ICS, and MITRE CWE, ensuring it slots directly into existing risk management and compliance workflows.

From a Water Utility Engineer's Insight to a Global Standard

The Top 20 Secure PLC Coding Practices trace their origin to a single session at the S4x20 conference, where Jake Brodsky, a veteran engineer from a major water utility, shared practical tips he had accumulated over decades of making PLCs more resilient, maintainable, and secure. The session resonated so profoundly that S4 organizers elevated it into a formal community project.

What followed was a rare example of grass-roots industry collaboration: approximately 70 contributors from asset owners, systems integrators, vendors, and security researchers collaborated to refine, debate, and validate the practices. Version 1.0 was released on June 15, 2021, under one of the most permissive open-source licenses in the industrial sector — explicitly encouraging free use, modification, and distribution.

What the Top 20 Framework Covers

The practices are grouped into thematic categories that reflect the unique operational realities of PLC environments. They are designed for the engineers and technicians who program and maintain PLCs — not cybersecurity specialists — making adoption practical rather than theoretical.

Click to Explore: Key Categories of Secure PLC Coding Practices

Code Integrity & Modularity

• Modularize PLC code into independently testable function blocks to improve maintainability and limit blast radius during compromise.
• Track operating modes — alarm operators immediately if a PLC is not in RUN mode, as this may indicate unauthorized code changes.
• Use checksums and code integrity verification where PLCs support it, creating tamper-evident environments.
• Leave operating logic in the PLC wherever possible, reducing dependency on external SCADA or HMI commands that can be spoofed.

Input Validation & Plausibility Checking

• Validate inputs based on physical plausibility — a tank level cannot jump from 10% to 90% in one scan cycle.
• Instrument for plausibility checks at critical decision points in the control sequence.
• Use PLC flags as sanity checks to cross-verify redundant signals before executing safety-critical operations.

Secure Communications & Access Control

• Restrict engineering access through physical key switches and software-enforced authorization levels.
• Validate HMI/SCADA commands within the PLC itself rather than trusting upstream data blindly.
• Implement safe-state fallback routines for loss of communication scenarios.

Anomaly Detection & Resilience

• Monitor scan cycle timing — deviations can indicate code injection or denial-of-service attacks.
• Embed runtime self-diagnostics that alert operators to unexpected program behavior.
• Design deterministic failure modes that default to safe physical states.

Features, Not Bugs: The Philosophical Shift

Perhaps the most consequential contribution of the project is its reframing of PLC characteristics that IT security practitioners have historically viewed as weaknesses. Deterministic scan cycles, limited processing power, and constrained communication protocols — long dismissed as obstacles to implementing conventional cybersecurity — are recast as inherent security advantages when properly harnessed.

A PLC's predictable execution model makes anomalous behavior easier to detect. Its narrow, well-defined function set provides a naturally small attack surface. The challenge has never been that PLCs are inherently insecure — it's that the industry lacked a systematic methodology for leveraging their intrinsic strengths.

Practical Adoption: What Asset Owners, Integrators, and Vendors Should Do

The Top 20 list is not a compliance checklist — and its authors are emphatic about what it is not. It is not a testing standard, a certification scheme, or a regulatory requirement. Rather, it is a consciousness-raising tool designed to make security an explicit consideration in every PLC programming decision.

Who Should Use the Top 20 — and How?

Asset Owners: Incorporate the Top 20 into internal programming standards and contractor specifications. Use it as a basis for code review checklists during commissioning and major modifications.

Systems Integrators: Build the practices into standard code libraries and reusable function blocks. Train programming teams to treat the Top 20 as baseline hygiene, not optional enhancements.

PLC Vendors: Evaluate whether existing product features support each practice. Where gaps exist, consider whether firmware enhancements or application-note guidance could bridge them. Several major vendors are already aligning development roadmaps with the framework.

Alignment with Global Standards

Each of the 20 practices is explicitly mapped to relevant clauses in ISA/IEC 62443-3-3 (system security requirements), ISA/IEC 62443-4-2 (component security requirements), and ISA/IEC 62443-4-1 (secure product development lifecycle). This alignment means organizations already pursuing 62443 conformance can integrate the Top 20 without duplicating effort.

Additionally, practices are cross-referenced against MITRE ATT&CK for ICS techniques — including T0844 (Program Organization Units) and TA002 (Execution) — providing defenders with a clear line of sight from coding practice to threat mitigation.

FAQ: Common Questions About the Top 20 Framework

Q: Is the Top 20 list vendor-specific?
No. The practices are deliberately vendor-neutral and apply across all major PLC platforms. Application notes provide vendor-specific implementation guidance where helpful.

Q: Does adopting the Top 20 guarantee security?
No single framework guarantees security. The Top 20 is a layer of defense-in-depth — it complements network segmentation, access controls, and monitoring rather than replacing them.

Q: How is the project governed?
The project is hosted by ISAGCA at plc-security.com and operates under an open, community-driven model. Anyone may propose new practices or refinements to existing ones.

Q: Are there plans for a Version 2.0?
The project maintains a living candidate list of additional practices. As community validation matures, updates to the core document are expected — though the project prioritizes stability and practical adoption over rapid iteration.

The Road Ahead: From Awareness to Adoption

A year after publication, the Top 20 has already reshaped procurement conversations across the industrial automation sector. Forward-thinking asset owners now reference it in tender documents. Integrators report that the framework gives engineers a common vocabulary for discussing security during project execution — something that had been conspicuously absent.

The real test, however, lies in widespread adoption across the estimated 15 million PLCs operating globally. Many of these controllers runlegacy code that predates any formal security consideration. Retrofitting the Top 20 into brownfield environments will require sustained investment — but the alternative, as recent ICS-targeted attacks demonstrate, is far costlier.