CODESYS Runtime Security Guide: User Management, Encryption and Patching in Practice

The CODESYS Control runtime runs inside controllers from many device manufacturers, so its user management, encryption and update settings decide who can download logic to those controllers, and a runtime commissioned with protection relaxed lets anyone on the network do it. This guide covers the customer-side settings that matter: device user management and its default groups, the Access Rights model, the runtime security policy for encrypted communication, encrypted and signed applications, project protection, the network ports the runtime exposes, audit logging, and how patching works when updates reach you through your device manufacturer. It is for automation engineers, OT security leads and system integrators who commission or maintain CODESYS-based controllers. General PLC hardening is covered in the PLC Security Guide; this page goes deeper on CODESYS itself. Menu names and defaults differ between CODESYS versions and device manufacturers' builds, so confirm each setting against the documentation for your runtime version.

This is an independent guide from NHI Mgmt Group, based on CODESYS's public documentation as of November 2026. It is not sponsored or reviewed by the CODESYS Group. Product features change, so confirm settings against CODESYS's current documentation.

Key takeaways

• Keep device user management enforced. From CODESYS Control SL 3.5 SP17 it is enforced by default; on 3.5 SP14 to SP16 runtimes you must enable and enforce it yourself, and disabling it leaves the controller open to anyone on the network.
• Grant rights to groups, and use the four defaults deliberately. Administrator, Developer, Service and Watch map to administration, programming, backup and restore, and read-only monitoring; most people need Service or Watch, not Developer.
• Set the runtime security policy to Enforced encryption. CODESYS labels this option recommended; it protects credentials and logic in transit, and a controller certificate managed through the CODESYS Security Agent avoids 30-day trust prompts.
• Sign and encrypt applications with certificates. Signing lets the controller accept only applications from trusted sources; CODESYS documents dongle-only encryption as no longer secure.
• Patch through two channels. CODESYS publishes advisories with PDF and CSAF files, but most fixes reach you as a device manufacturer firmware update, so track both and keep the runtime off untrusted networks while you wait.

How the CODESYS runtime is built and why it matters

CODESYS is an IEC 61131-3 development system and runtime. The CODESYS Control runtime is licensed to device manufacturers, who build it into their controllers, edge devices and industrial PCs; CODESYS also offers soft PLC variants such as CODESYS Control for Linux SL. Three consequences follow for security owners.

• One runtime, many brands: the same user management, encryption and port behaviour applies across controllers sold under different names, so a CODESYS advisory may affect devices that do not mention CODESYS on the front panel. Ask each OT supplier whether their controller runs CODESYS and which runtime version.
• Version decides defaults: enforced user management, encrypted communication and exportable encrypted user databases all arrived in specific 3.5 service packs. An estate with mixed runtime versions has mixed baselines.
• Updates go through the manufacturer: the CODESYS advisories page states that whether and when device manufacturers adopt a recommended update depends on their own technical assessment. Your patch timeline is the manufacturer's, not CODESYS's.

Device user management

Controllers that support device user management require a user name and password for every client: the Development System, CODESYS HMI, PLCHandler, the OPC DA server and OPC UA clients. The Security Whitepaper states that passwords are sent encrypted and stored on the controller as scrypt hashes.

Versions and enforcement

Enabling user management needs at least a CODESYS V3.5 SP16 development system. The policy is set in the Device User Management area of the Change Runtime Security Policy dialog, with the options Optional user management and Enforced user management.

First administrator

1. Set communication to encrypted first (Communication Settings tab or the Security Screen), so the new credentials are not sent in clear.
2. Open the controller's device editor, go to Users and Groups and select the Synchronization button.
3. Confirm the prompt to activate device user management.
4. In Add Device User, create the first account. Only the Administrator group is offered.
5. Log on with it in the Device User Logon dialog, then create named operational users and keep the administrator account for administration only.

The whitepaper recommends commissioning only in a secure environment, from installation until the first administrator exists, because until then the first client to connect sets the credentials.

Default groups

Access Rights model

• Groups only: permissions are granted to groups, never to individual users, and every user belongs to at least one group.
• Four actions: Add/Remove, Modify, View and Execute, each explicitly granted, explicitly denied or neutral (inherited from the parent).
• Deny by default: anything not explicitly granted somewhere in the hierarchy is denied, except View, which is granted to every group on the Device runtime object and on the file system root "/".
• Objects worth reviewing: under Runtime objects, Device contains Logger, PlcLogic, PLCShell, RemoteConnections, Settings (including Security Settings), UserManagement and X509. Restrict PLCShell and X509 to administrators, and check file system rights on "/" because View is granted there by default.
• Custom groups: new groups get their own runtime object under UserManagement, which lets you build a restricted administrator group, for example one that manages Watch users but not Developer users.

Passwords, lockout and the user database

• Password policy: enabled by default ([CmpUserMgr] with SECURITY.UserMgmt.PasswordPolicy=ENABLED); CODESYS advises against disabling it.
• Login lock: enabled by default for the Administrator group with a lock duration of 3600 seconds; review Maximal Retries and Lock duration and consider extending the lock to other groups.
• First-login change: set "change required at first login" for every account an integrator creates on your behalf.
• Export and import: from V3.5 SP16 the user database exports to a password-protected *.dum2 file. Importing completely overwrites the controller's user management, so treat these files and their passwords as privileged secrets and keep a signed-off copy as the recovery baseline.
• Recovery is a reset: the documented way to remove active user management is to switch to Optional and run Reset Origin Device, which deletes it and leaves the controller open. Keep a break-glass administrator in a vault so a forgotten password never forces this. See the Break-Glass Account Guide.

Encrypted communication and certificates

CODESYS uses TLS 1.2 between the development system and the controller. The Change Runtime Security Policy dialog (device editor, Communication Settings, Device menu) offers three options: Enforced encryption (recommended), Optional encryption and No encryption. CODESYS strongly advises against disabling encryption.

• Controller certificate: with enforced encryption a controller without a certificate cannot be logged into. The CODESYS Security Agent (Devices tab of the Security Screen) is the recommended way to manage controller certificates. Creating certificates from the PLC Shell is documented but marked as not recommended.
• Trust decisions: on first connection the engineer can install the controller certificate as trusted locally or accept it for the session; a certificate installed this way is valid for only 30 days and lands in the Windows store under Controller Certificates. Brief engineers to check the device before accepting, and replace these with managed certificates.
• Global enforcement on the workstation: on the Security Screen's User tab, select Enforce encrypted communication in the Security Level group, so engineers cannot connect to any controller in clear by mistake.
• Interactive login: where the hardware supports it, interactive login confirms the target controller by button, serial number or LED before connecting, which prevents downloads to the wrong device.

Signed and encrypted applications and protected projects

On the Security Screen User tab, "Enforce signing of downloads, online changes and boot applications" and "Enforce encryption of downloads, online changes and boot applications" make certificate protection the default for every project on that workstation. Turn both on for engineering workstations used on production lines. Signing is the higher priority: it is what stops a modified program from being accepted, the core of ATT&CK for ICS T0843 Program Download and T0889 Modify Program.

Operating mode, ports and network exposure

Operating mode

The runtime supports three operating modes: Debug (the default, all online commands allowed), Locked and Operational, which blocks unintended access to the running application. With user management active, switching modes can be restricted to specific users. Run production controllers in Operational and record mode changes as change events (T0858 Change Operating Mode).

Ports

The Security Whitepaper lists the ports the runtime and its components use:

The whitepaper also recommends a small trusted network locked off from common access, firewalls that filter in both directions between company and machine networks, VPN tunnels for links between networks, and treating fieldbus traffic as unencrypted. Integrators must protect any other ports they open, such as FTP or maintenance shells. Searchable controllers on the internet match T0883 Internet Accessible Device; see the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide and the OT Remote Access Guide.

Patching CODESYS-based controllers

1. Know what you run: record for each controller the manufacturer, model, firmware and embedded CODESYS runtime version, plus the development system version on each engineering workstation.
2. Subscribe to both sources: the CODESYS security advisories page publishes each advisory as PDF and CSAF, and device manufacturers publish their own advisories. CSAF files can feed an automated matching process against your inventory. See the ICS Advisory Triage and OT Vulnerability Management Guide.
3. Patch the development system promptly: CODESYS distributes the Development System directly and its patch versions fix vulnerabilities, so engineering workstations can usually move faster than controllers.
4. Ask the manufacturer for timing: for controller runtimes, obtain the manufacturer's firmware that contains the fixed CODESYS version, and its compatibility notes.
5. Apply workarounds meanwhile: advisories include workarounds; most rely on enforced user management, encryption and network restriction, which this baseline already provides.
6. Test and back up: take a backup with the Service role's backup function, test on a spare or simulated controller, schedule during a planned stop, and keep the previous firmware and boot application for rollback.

Where identity fits

Every client of the runtime is an identity: engineers, HMIs, OPC UA clients, historians and the PLCHandler-based applications that read and write tags. Machine clients often get a shared Developer account because it works first time. Give each machine client its own account in a custom group with only the rights it needs, usually View and Execute on specific objects, store its credentials in a vault rather than in HMI project files, and rotate them when integrators leave. See the Device and IoT Identity Guide.

Detection and measurement

The runtime Audit-Log records logins, failed attempts, user management changes and application actions, and can write to the PLC shell, SysLog or log files with an optional ring buffer. Forward it by SysLog to a collector in the OT DMZ and correlate with passive network monitoring of ports 1740 to 1743 and 11740. See the OT Network Security Monitoring Guide.

Metrics

• Enforcement coverage: percentage of CODESYS controllers with enforced user management and enforced encryption.
• Signed applications: percentage of production applications signed with a trusted certificate.
• Shared accounts: number of accounts used by more than one person or machine client (target zero).
• Patch latency: days from manufacturer firmware release to installation, tracked separately for engineering workstations and controllers.
• Unexplained downloads: program downloads with no matching change ticket.

Rolling it out

1. Inventory: list controllers, runtime versions, current policies, users and groups, and which ports are reachable from where.
2. Workstations first: update the development system, install the Security Agent, and turn on Enforce encrypted communication and enforced signing on the Security Screen.
3. Pilot one line: during a planned stop, set Enforced encryption and Enforced user management on one controller, create named users in the default groups, and confirm HMI, OPC UA and historian connections still work. Export the *.dum2 baseline.
4. Roll back if needed: keep the previous boot application and user database export; if a client fails, restore the export rather than relaxing the policy, and fix the client's account.
5. Extend: apply to remaining controllers line by line, add signing, then move to Operational mode and SysLog forwarding.

Decision guidance: a small site with a few controllers can rely on default groups, Security Agent certificates and manual review of exports. A large estate should define custom groups per role, use a site CA for controller and signing certificates, script inventory from CSAF advisories, and put user database exports under change control. Where a runtime is older than 3.5 SP14, isolation is the main control until it is replaced.

Common failure patterns

• Policy set to Optional during commissioning and never changed: the controller behaves as if it had no user management. Check the policy at site acceptance.
• Everyone in Developer: technicians who only need backup and restore can change logic. Use Service and Watch.
• One shared integrator account: nobody knows who downloaded what, and the password leaves with the integrator. Use named accounts and first-login password changes.
• Accepting certificates without checking: 30-day trust prompts train engineers to click through. Manage controller certificates through the Security Agent.
• Waiting for the manufacturer and doing nothing: firmware with the fix may take months. Apply the advisory's workarounds and restrict ports 1740 to 1743, 11740 and 1217 now.
• Resetting to recover a password: Reset Origin Device removes protection entirely. Keep a vaulted break-glass administrator.

Framework mapping

For the standard itself, see the IEC 62443-3-3 and 4-2 Security Levels Guide and the NIST SP 800-82 OT Security Guide.

Practitioner checklist

• Record the embedded CODESYS runtime version for every controller and the development system version for every workstation.
• Set Enforced user management and Enforced encryption on every controller that supports them.
• Create the first administrator only on an isolated network, then use named accounts in Developer, Service and Watch.
• Restrict PLCShell, X509, Security Settings and UserManagement objects to administrators, and review file system rights.
• Manage controller certificates with the CODESYS Security Agent and stop relying on 30-day trust prompts.
• Sign production applications with a certificate and enforce signing on engineering workstations.
• Restrict ports 1740 to 1743 UDP, 11740 TCP and 1217 TCP to the engineering zone; disable plain HTTP WebVisu.
• Run production controllers in Operational mode and forward the Audit-Log by SysLog.
• Track CODESYS and manufacturer advisories, patch workstations promptly and controllers through manufacturer firmware.
• Keep an encrypted *.dum2 export and a vaulted break-glass administrator for each controller.

Standards and references

• CODESYS Group: CODESYS Security Whitepaper
• CODESYS Group: User Management on the PLC
• CODESYS Group: Handling User Management on the PLC
• CODESYS Group: Encrypting Communication and Changing the Security Policy
• CODESYS Group: Encrypting and Signing Applications
• CODESYS Group: Security Advisories
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: PLC Security Guide · OT Security Guide · ICS Advisory Triage and OT Vulnerability Management Guide · OT Network Security Monitoring Guide · IEC 62443 Guide