Zero Trust Security Begins Inside the Controller

Industrial operations are rapidly moving towards digitalisation, and control systems are no exception. Instead of relying solely on dedicated Programmable Logic Controllers (PLCs), more organisations are adopting Soft PLCs implemented on Industrial PCs (IPCs) running Windows or Linux. While this shift offers efficiency and flexibility, it also demands a redefinition of security boundaries. As controllers evolve into complex software platforms rather than standalone hardware, external defences alone are no longer sufficient to mitigate new risks.

Why Soft PLCs Are Becoming Essential

Control is no longer the exclusive domain of dedicated Programmable Logic Controllers (PLCs). By deploying PLC functionality as software on Industrial PCs (IPCs), Soft PLCs are becoming increasingly widespread. On standard x86/ARM platforms, controller images can be easily deployed, backed up, and restored, simplifying maintenance.

With real-time kernels such as PREEMPT_RT and Xenomai, or real-time extensions for Windows, control loop jitter can be tightly managed. Deterministic communication technologies such as Time-Sensitive Networking (TSN) and EtherCAT further strengthen process reliability. A single Industrial PC (IPC) can consolidate control, Human Machine Interface (HMI), and data gateway (OPC UA, MQTT) functions, reducing space and energy consumption. Virtualisation and containerisation also enable integration with digital twins and remote maintenance systems. Most importantly, with stricter security regulations such as IEC 62443 and NIS2, software-based controllers that support continuous updates are proving far more advantageous for security readiness.

How Soft PLCs Are Implemented

The most common approach combines an Industrial PC (IPC), an operating system (Windows/Linux), and a Soft PLC runtime. By optimising real-time extensions and fieldbus master stacks (e.g. EtherCAT, PROFINET), this setup achieves determinism comparable to conventional Programmable Logic Controllers (PLCs).

Alternatively, a hypervisor may be used to separate real-time control tasks into a dedicated Virtual Machine (VM) and allocate HMI or data processing to a non-real-time VM, thus ensuring both performance and security boundaries. More advanced models use Virtual PLCs (VPLCs) or containers, enabling centralised deployment and management. For applications requiring Functional Safety (FS), separate hardware such as a Safety PLC or relay is used, while the Soft PLC handles standard control and connectivity, keeping safety and operational functions clearly apart.

Multiple Roles on a Single Industrial PC

An Industrial PC (IPC) running a Soft PLC typically hosts a wide range of functions simultaneously:

• Soft PLC runtime for sequence, motion, and robotic control
• Human Machine Interface (HMI) and Engineering Workstation (EWS) agents for monitoring and logic deployment
• Industrial communication stacks such as EtherCAT, PROFINET, and Modbus/TCP
• Data gateways such as OPC UA servers, MQTT brokers, and historians
• Security and management agents for asset identification, integrity checks, patching, backup, and access control

Because real-time control and operational management coexist on one platform, relying only on perimeter devices such as firewalls is not enough. Bypass routes are always possible — for example, an engineer connecting a laptop directly to the Industrial PC (IPC).

Shifting Security Inside the Controller

The conventional approach of placing an OTAC Trusted Access Gateway (TAG) inline between a switch and a Programmable Logic Controller (PLC) remains valid. However, in a Soft PLC environment where the controller itself is an Industrial PC (IPC), embedding the security boundary directly inside the controller with an OTAC Trusted Access Gateway (TAG) is more natural and more robust.

When a user attempts to access a sensitive service such as a programming port or write permissions via OPC UA, OTAC Trusted Access Gateway (TAG) challenge–response authentication is triggered within the controller. Access is granted only if authentication succeeds, and then only for a specific session and limited duration. If authentication fails or expires, access is immediately revoked.

This method blocks physical bypass attempts such as temporary cable connections. Furthermore, authentication is only executed at session establishment, not during real-time traffic, and by isolating tasks to separate CPU cores the risk of jitter is minimised. Even in offline environments, pre-issued policies and one-time codes enable controlled maintenance during network separation or outages.

How OTAC Differs from PKI and OTP

Public Key Infrastructure (PKI) and Virtual Private Networks (VPNs) are powerful for encryption and channel protection but introduce significant operational burdens in Operational Technology (OT) environments, such as certificate lifecycle and revocation list management.

Standard One-Time Passwords (OTPs), meanwhile, can theoretically generate identical codes for multiple users, meaning they cannot uniquely identify a user. They only prove that someone holds the secret at that moment, and thus must always be combined with an identifier such as a username.

OTAC
, by contrast, generates a one-time dynamic code that ties together the context of the user, the session, and the specific action being attempted. This enables re-authentication precisely at the moment of a critical change, implementing a stronger Zero Trust model where downloads, parameter changes, or forced overrides all require renewed verification.

Alignment with International Standards

Embedding the OTAC Trusted Access Gateway (TAG) within the controller aligns well with IEC 62443 Foundational Requirements. It directly supports SR 1.x (Identification and Authentication Control) and SR 2.x (Use Control), while also providing a strong basis for SR 3.x (System Integrity), SR 5.x (Restricted Data Flow), and SR 6.x (Timely Response to Events). Achieving a given Security Level (SL) requires a full system assessment, but embedded access control through the OTAC Trusted Access Gateway (TAG) provides the technical foundation to meet such requirements effectively.

The Starting Point for Security Must Be Inside the Controller

The move to Soft PLCs is more than a software transition — it requires a redefinition of security boundaries. Relying solely on external barriers is no longer sufficient. High-risk tasks such as programme downloads and parameter changes must be governed by session- and context-aware OTAC Trusted Access Gateway (TAG) authentication at the controller boundary itself. Inline OTAC Trusted Access Gateway (TAG) deployments remain valid for existing lines, but for systems adopting Soft PLCs, embedded OTAC Trusted Access Gateway (TAG) solutions should be the default choice. Just as controllers have evolved into software, so too must their security begin from within.