- By Benson Hougland
- October 25, 2023
- Opto 22
- Feature
Summary
Built-in security options help users build a more secure network for connected automation. This feature originally appeared in the AUTOMATION 2023: Cybersecurity & Connectivity ebook published in September.

Sharing operational data from industrial equipment can improve decision making from the shop floor to the executive suite. But cybersecurity is a constant worry. Industrial systems and data are essential, sensitive and must be protected. How can newer industrial automation hardware help users protect their systems and still get important data to on-premises and cloud-based software and services?
For all computer networks, security is a complex issue that changes based on the organization and its system. As systems evolve, security requirements change and grow. Building flexible security into the system design is key.
To address security’s complex, changing nature, users must understand security risks, environment and the security tools at hand. Security experts recognize several elements of system security, including physical security, policies and procedures, and network security
For network security, newer industrial edge controllers and input/ output (I/O), like Opto 22’s groov EPIC and groov RIO, help users meet requirements in ways that used to be impossible in automation, except by using industrial computers (IPCs), servers, or securityspecific network appliances. Designed from the ground up to help build distributed systems, edge controllers and edge I/O provide the tools and methods necessary to make systems as secure as possible from a network access standpoint, while maintaining the flexibility required for specific applications.
Key cybersecurity features that edge controllers and I/O are helping to popularize include user authentication, connection encryption, firewalls, network zoning and outbound communications.
User authentication
Controlling who can access a device and exactly what each user can do with it is a vital part of cybersecurity. Just like laptops or bank accounts, edge controllers and edge I/O can require users to identify themselves using a unique username and password before they can do anything else (Figure 1). These devices typically provide services for creating and managing users as well as related parameters like session timeouts. Security-conscious edge devices avoid the use of a default username and password that someone might be able to guess or look up on the Internet
Edge controllers may provide different access levels for administrators, developers, operators, API calls and so on, then allow those user rights to be assigned to authorized people or software services. Authentication may happen through either a username/ password combination or an API token.
When limiting access to the edge device in this way, consider it as part of a total security system that includes other best practices like requiring that authorized users change their passwords every three months or securing the control equipment in a locked cabinet with keys accessible to a limited number of personnel.
If a site manages user accounts through a lightweight directory access protocol (LDAP) service (for example, Microsoft Active Directory Service), users may be able to work with their IT department to configure edge devices to connect to the LDAP server, authenticate a user and help determine which services a user can access. For simple setups, use the LDAP server to authenticate users and give them default local permissions.
For systems with a larger number of users or more complex user management, just map an LDAP group to a specific set of permissions.
Connection encryption
Authentication services tell a server that a user or piece of software is authorized to access the server’s resources. Encryption—another important security feature—protects data so that it is unreadable by anyone who does not have the decryption keys. SSL/TLS [Secure Sockets Layer and its newer version, Transport Layer Security] use security certificates consisting of a private key and a public key to encrypt the traffic between the client and the server.
Security certificates are also a way that clients can verify a server’s identity so that when a client tries to connect, it can be assured it is communicating with the correct server and not an impostor (Figure 2). Industrial edge controllers can use this infrastructure to prevent incoming and outgoing data from being observed by unknown third parties—what is called a man-in-the-middle attack.
X.509 is a standard format for public key certificates and can be used by edge controllers and edge I/O to secure client connections to servers (client SSL) and from clients to the device’s secure server (server SSL). SSL/TLS certificates can be device-generated, self-signed, or registered publicly through a Certificate Authority (CA).
For example, each groov EPIC processor and each groov RIO module comes with a unique certificate (called a self-signed server SSL certificate) to enable encrypted communication between its internal web applications and web browsers on computers and mobile devices. However, users might want to use a certificate signed by a third-party CA for any of the following situations:
- To allow access to the edge device by many more users and through many devices (like computers, smartphones and tablets).
- To allow remote access to the edge device via REST API calls, OPC UA clients, or other inbound communications.
- To allow communication to travel through the Internet.
A Certificate Authority is a trusted organization that vouches for a server’s identity on users’ behalf. CA-signed certificates relieve users of the work of installing certificates on all the clients connected to an edge device.
When a server certificate is installed on the edge device and a client device attempts to connect, a certificate exchange validates the connection between them. So long as the client stays connected directly to the controller on a secure connection (using https, for example), the data they share is protected from a man-in-the-middle attack.
Firewalls
Firewalls are critical in securing data communications, and since edge controllers and I/O are designed for distributed communication, embedded firewalls are becoming a required feature (Figure 3).
A firewall on a network or a device acts like the doors in a building. The door on a building’s main entrance often swings in to allow entry, and a security guard or receptionist checks IDs and regulates who is allowed to enter. Emergency exit doors swing out only. They’re locked from the outside for security, but people inside the building can easily get out if they need to.
With a firewalled network or device, communications can occur outbound to external servers or services, just like people can leave through the emergency exit doors of a building. But communications attempting to come in are rejected, just like people can’t come in through the locked emergency exits. These inbound communications are permitted only through a specific network port that’s been opened to allow them, and only with the right encryption and credentials—again, like entering through a building’s main entrance door, but only if they have an ID and an appointment to visit someone inside.
Edge controllers and edge I/O with a device firewall help provide security by stopping unsolicited traffic from accessing automation networks, software applications and connected devices. Typically, the only traffic the edge device should allow back through is responses to traffic that originated from the controller’s software. Device-originated connections are considered trustworthy because their origin is known.
However, a device firewall typically provides configurable security options. For example, each network interface on groov EPIC—the two Ethernet interfaces, the wireless interface, and the virtual private network (VPN) interface—has its own firewall settings. Users can set specific firewall rules for each interface, for trusted networks (where unsecured ports are open), and untrusted networks (where only encrypted, authenticated ports should be open).
Network zoning
A key concept in the ISA/IEC 62443-3 specification on industrial cybersecurity is zoning—keeping networks isolated to prevent unauthorized access to data. Industrial edge devices can help by providing independent interfaces that isolate trusted networks from untrusted networks.
- A trusted network is any network where users know exactly who has access to it, for example, the OT network where existing programmable logic controllers (PLCs) and I/O reside.
- An untrusted network is any network where users don’t know who has access to it, like an IT network or the Internet.
For example, groov EPIC is not a router, which functions to join two networks together. Instead, it keeps trusted networks and untrusted networks apart, separating them into zones (Figure 4). This default configuration eliminates any chance of unsecured devices on one network interface being exposed to the others.
However, for users who need to access an edge controller or edge I/O from an untrusted network (for example, if they are using the Internet or a corporate LAN), edge devices can also support VPN tunneling, which allows disparate networks to be bridged through secure connections to a shared VPN server.
An industrial edge device with built-in VPN support (Figure 5) can connect to VPN servers as a client on an outbound, device-originated connection (so no open inbound ports on the device are required). Additionally, by configuring the edge device as a host, it can provide remote access to its own software services. Then, any other VPN client (like a PC or mobile device) can securely log into the VPN server using a valid account or client configuration file. Once connected, the client can reach the edge device’s software applications.
By default, VPN access to an edge controller or I/O provides access only to software running on that device, not to any other devices connected to the controller via other network interfaces. However, if users want to allow access to devices in another network zone, some edge controllers allow the use of port redirection (Figure 6) to create temporary conduits between various network interfaces.
For example, perhaps there is a PLC on a trusted OT network that must be reached from another network to make changes using the PLC’s own proprietary software (for example, Logix software from Rockwell Automation connecting to an Allen-Bradley PLC). With port redirection, users can designate a specific port on one network interface to permit traffic to pass through to an IP address and port on the network interface connected to the PLC.
Best practice is to block all unsecured network ports (like Modbus/ TCP port 502) on untrusted network interfaces. However, a VPN tunnel created on an untrusted network interface allows only authenticated, encrypted data communications over that interface, so only authorized users can gain access.
In this scenario, just configure a port redirect—a conduit—from the VPN tunnel interface established on the untrusted network zone to the trusted network zone, where the unsecured PLC is. This conduit should be enabled only on demand and for a limited time period.
Outbound communications
As mentioned, an edge device is inherently more secure and requires less configuration when it uses outbound data communications, rather than having to open ports to receive connection requests. Should a malicious actor (human or software) obtain enough information to send a connection request to the device, it could exploit an open port in the firewall to grant itself control or read sensitive information. Restricting communications to outbound services means the firewall can be buttoned up tight, eliminating this vulnerability completely.
VPN, already explored here, is one example of device-originating, outbound communication that an industrial edge device might provide, but there are many others. Traditional automation activities like talking to remote I/O or polling Modbus/TCP devices require only outbound connections. More exciting still, RESTful calls to web services, posting data to SQL databases, and performing publish-subscribe communications over MQTT are also outbound communications that an industrial edge device can provide.
Note that protocols like MQTT and VPN provide the option to persist these outbound connections so that bidirectional communication is still possible within this security framework.
New strategies, new options
Traditional approaches to securing automation networks like air gapping, VLANs, or IP filtering naturally complicate efforts to build connected systems and democratize operational data. By contrast, industrial edge controllers and edge I/O offer a granular approach that embeds essential security functions directly into a user’s process, maintaining a defense-in-depth strategy without restricting communication options or scalability.
This article is not intended to be a comprehensive guide to ICS security. However, when used in combination and as part of a larger security strategy, the functions outlined here—user authentication, connection encryption, firewalls, network zoning and outbound communications—can significantly restrict access to critical control functions and sensitive data.
Importantly, these security functions now available in industrial edge devices are already prevalent throughout IT network infrastructure, making them highly compatible with existing security elements and helping to bridge the gap between IT and OT systems.
For more information, explore the full “groov Products Cybersecurity Design and Best Practices Technical Note” from Opto 22.
This feature originally appeared in the AUTOMATION 2023: Cybersecurity & Connectivity ebook published in September.
About The Author
Benson Hougland is vice president of marketing and product strategy at Opto 22. With 30 years of experience in information technology and industrial automation, Hougland drives product strategy for Opto 22 automation and control systems, which connect and secure the real world of OT with the systems and networks of IT and cloud. He speaks at trade shows and conferences, including IBM Think, ARC Forum and ISA. His 2014 TEDx Talk introduces non-technical people to the IoT.
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..
Subscribe