Secure programming techniques for PLC

Posted date 02/02/2023
Image of a programmable logic controller

The programming of PLCs is a fundamental part of the initial phases when building and designing industrial plants. About that environment, the company will base all its operations in that environment making the configuration of these controllers a critical element. When it comes to programming these devices there are a series of steps and best practices that take advantage of the native functionalities available and that involve little or no need to resort to a PLC programmer, protecting the device in a simple way with minimum spend on resource.

Picture PLC, modules and HMI systems

- PLC, modules and HMI systems.-

The PLCs used in industrial control systems (ICS) have proven capable of replacing most mechanical relays and timers for control systems based on electric circuits as well as battery sequences.

With the emergence of Industry 4.0 and the need to complete industrial automation tasks repeatedly, quickly and reliably, the implementation of PLCs has undergone substantial improvement when it comes to collecting data from devices, processing the data and executing the different programmed tasks. To perform the programmed functions, PLCs have different modules or sections, including the central processing unit (CPU) the input and output modules, the power source and the programming unit.

Their operation is simple. First, the operator executes a programme using the software to establish the instructions and actions to be carried out on receiving the signals from the sensors or internal variables in the PLC itself. After processing the signals and the execution of the code programmed by the operator, the robot activates the output to the final devices. The set of these operations, together with the execution of routines (internal review and error review), output updates, communications and diagnostics comprise the SCAN cycle, also defined as the automated execution cycle. After the execution of the SCAN cycle, the PLC resumes operations and starts the cycle again.

Picture PLC execution cycle 

- PLC execution cycle -

Programming languages and software

The programming languages in the automation industry, and more specially in PLC devices, allow us to create a series of instructions of order sequences, the aim of which is to express processes in a simple way to be carried out by the robot methodically, reliably, and quickly.

The IEC 61131-3 standard covers these programming languages and defines five possibilities: 

  • Sequential Function Chart (SFC): refers to the use sequential function blocks for programming.
  • Functional Block Diagram (FBD): refers to the use sequential function blocks for programming.
  • Ladder Diagrams (LD): relay diagram language also called ladder languages.
  • Structured Text (ST): high-level programming language similar to C or Pascal.
  • Instructions list (IL or STL): assembler programming language.

The programming languages SFC, FBD and LAD are visual languages, that is, they are structured using graphic symbols while programming languages ST, IL and STL are formed by lists of sentences.

It is important to choose the most appropriate language for automation, depending on the function carried out with the aim of simplifying the code and reducing the potential vectors of attack.

Picture programming languages in a PLC

- Programming languages in a PLC - 

Secure coding of a PLC

As has been mentioned over the course of the article, there are different aspects that allow for improvement of PLC security with minimal effort on the part of the robot or the programmer. Explained below are a number of different methods for the secure coding of a PLC:

  • One of the main options that simplifies the PLC process when it comes to reviewing errors and codes is code segmentation. We recommend separating the functions where possible, as this will allow you to review the code quickly in the event of faults or possible code injection attacks on the part of a malicious agent.
  • The segmentation of code also allows us to differentiate between inputs and outputs and thus eliminate paired and exclusive inputs and outputs. Within this separation of inputs and outputs, it is recommendable to conduct an independent configuration for the START and STOP signals, the system restart timers and the signals in some industrial processes, such as the ADVANCE and REVERSE and OPEN and CLOSE. This reduction in paired signals will allow for a significant reduction of vulnerabilities when it comes to launching an attack on two exclusive variables or fast switching in actuators, thanks to the implementation of delay timers, which use minimal resource and boast a simple configuration.
  • One of the segmentations that must be carried out should be the introduction of a segment that allows us to check the execution times of the robot through the use of functions belonging to the software of the PLC itself. The implementation of this code will allow us to check maximum, minimum and regular values during the secure functioning of the robot so that , in the event of alteration of the normal values, in subsequent situations, we can easily detect a change in the coding. A variation of 5% with respect to the standard functioning values or enter a minimum value (0 ms) in the SCAN cycle would represent an alteration in the code and, therefore, the exploitation of a potential vulnerability. These values are also available together with the use of the memory, in the diagnostic values of the PLC itself.

Screenshot PLC execution Time.

- PLC execution Time -

  • Linking to the previous section and with the communications of the SCAN cycle, and more specifically the communications with HMI devices, they must be codified for the maximum possible number of operations are executed, reducing the load on the HMI and, therefore, the possible number of vulnerabilities. What's more, the checking of the values introduced by the operator in the HMI must be checked by the PLC to determine whether the slogan introduced is between admissible values.
  • Another important aspect when it comes to implementing secure coding for a PLC is the correct programming of the operating modes. Maintaining a PLC in RUN mode for as long as possible reduces the possibilities of changes being made to the programming by a malicious agent. What’s more, it will be difficult to detect a changes through the visualisation in diagnostics of a stop in the execution of the SCAN cycle. The use of the PROGRAM mode mist be limited as it allows changes to be made to programming very easily.
  • Finally, one of the best practices that can be implemented to retain secure coding of a PLC, and which is not very common among programmers, is the disabling of the unnecessary or unused communication ports and protocols. An analysis of the communications from the PLC to the different devices that will allow us to specify what ports and protocols are necessary, disabling any unnecessary ones, and therefore eliminating a possible vector of attack.


PLCs were first used in the 1960s. In those days, there only function as to improve the provisions provided by control systems based on relays and contactors. They were generally used on a small scale and a high level of security was not necessary.

Today, there is exponential growth in IoT devices (Internet of Things), industrial processes and, above all, control devices like PLCs. This contrasts sharply the increasing need for everything to be interconnected, which may lead to increased vulnerabilities, both for equipment and the industrial communications used in different processes.

It is worth highlighting that a PLC many have certain weaknesses, but as detailed previously, there are many practices or coding actions that allow the administrator to configure the code and software of the robot to improve the level of security, reducing or preventing any attack on the code. Following the above advice, continued reporting is crucial for alerts and events and implementation of the latest versions of libraries (for operating logic) and the latest version of the firmware used by the robot.