Encryption for Industrial Control Systems: A Survey of Application-Level and Network-Level Approaches in Smart Grids

Abstract

Industrial Control Systems (ICS) are fundamental to the operation, monitoring, and automation of critical infrastructure in sectors such as energy, water utilities, manufacturing, transportation, and oil and gas. According to the Purdue Model, ICS encompasses tightly coupled OT and IT layers, becoming increasingly interconnected. Smart grids represent a critical class of ICS; thus, this survey examines encryption and relevant protocols in smart grid communications, with findings extendable to other ICS. Encryption techniques implemented at both the protocol and network layers are among the most effective cybersecurity strategies for protecting communications in increasingly interconnected ICS environments. This paper provides a comprehensive survey of encryption practices within the smart grid as the primary ICS application domain, focusing on protocol-level solutions (e.g., DNP3, IEC 60870-5-104, IEC 61850, ICCP/TASE.2, Modbus, OPC UA, and MQTT) and network-level mechanisms (e.g., VPNs, IPsec, and MACsec). We evaluate these technologies in terms of security, performance, and deployability in legacy and heterogeneous systems that include renewable energy resources. Key implementation challenges are explored, including real-time operational constraints, cryptographic key management, interoperability across platforms, and alignment with NERC CIP, IEC 62351, and IEC 62443. The survey highlights emerging trends such as lightweight Transport Layer Security (TLS) for constrained devices, post-quantum cryptography, and Zero Trust architectures. Our goal is to provide a practical resource for building resilient smart grid security frameworks, with takeaways that generalize to other ICS.

1. Introduction

Industrial Control Systems (ICS) are specialized groups of systems designed to monitor, control, and automate industrial processes across critical infrastructure sectors, including energy, manufacturing, water treatment, transportation, and chemical processing. ICS environments are engineered for high availability, reliability, and real-time operation, with safety and process integrity taking precedence over traditional Information Technology (IT) security considerations. As illustrated by the Purdue Model [1] in Figure 1, the reference architecture that organizes ICS into hierarchical levels from the physical process up to enterprise IT—ICS encompasses tightly coupled Operational Technology (OT) and IT layers, and its increasing interconnectedness underscores the importance of secure communication. Various components within the ICS ecosystem have evolved over the years [2].

1.1. Core Components of ICS

• Remote Terminal Unit (RTU): RTUs interact directly with field sensors, collect data, and send it to supervisory systems. They can also perform basic operations, such as shutting valves and switching sensors on or off.
• Programmable Logic Controller (PLC): PLCs have functions similar to RTUs but are more advanced. They perform complex operations, directly control sensors, send data to supervisory systems, and can connect to HMIs.
• Human–Machine Interface (HMI): HMIs present data collected from RTUs and PLCs to human operators in a logical format. They provide alarms, notifications, and graphical information for operational analysis and decision making.
• Historian: This component functions as a database, storing data from field devices for future querying and analysis. Users can generate reports, analyze trends, and optimize processes using historical data.
• Supervisory Control and Data Acquisition System (SCADA): The central intelligence of the ICS, often implemented as proprietary software or embedded systems, manages all of the above components.

In power-system deployments, many of these functions are provided by Intelligent Electronic Devices (IEDs) within substations and field area networks, which tie the generic ICS stack directly to grid operations.

1.2. ICS Architecture and the Purdue Model

The Purdue Model has been the foundational architecture for ICS since its introduction in 1992. Before its adoption, ICS deployments lacked standardization and often involved a variety of loosely connected devices.

As shown in Figure 1, the architecture is divided into hierarchical levels. Level 3 marks the boundary between OT and IT. This level typically hosts remote access servers and cybersecurity tools such as firewalls, proxies, intrusion detection/prevention systems (IDS/IPS), and data diodes to protect lower ICS layers. Attacks or disruptions at or below this level can have catastrophic consequences for critical infrastructure. In the energy sector, these layers map onto control centers, substations, field area networks, and end devices, providing the structural backbone for smart grid communications.

1.3. Convergence of IT and OT

Industrial Internet of Things (IIoT) and Industry 4.0 [3] are recent phenomena that have profoundly transformed the landscape by accelerating the digitization of ICSs. A key outcome of this shift is the convergence of IT and OT, enabling enhanced integration and interoperability between systems that were previously siloed or minimally connected. IIoT and Industry 4.0 have introduced a wealth of data-driven capabilities, offering real-time insights and intelligence that empower informed decision-making and operational optimization. This technological convergence, which can be classified into process, data, and physical domains, has led to proactive strategies such as predictive maintenance, smart inventory management, and cybersecurity enhancement [4,5].

The modern ICS architecture enables seamless communication and continuous data exchange across previously siloed components, enhancing agility and resilience in industrial operations. However, this increased connectivity significantly broadens the surface of cyber attacks, extending beyond traditional IT devices. The growing dependence on remote access for monitoring and management further amplifies these risks [6]. Legacy systems, often not designed with this integration in mind, become vulnerable to new forms of disruption. Securing this expanded threat landscape is essential to protect critical infrastructure and prevent potentially devastating operational interruptions. These trends are especially pronounced in the smart grid, where utilities interconnect control centers, substations, distributed energy resources, advanced metering infrastructure, and field sensors over public or shared networks.

1.4. Smart Grid as a Critical ICS Domain and Scope of This Survey

Among ICS, the smart grid is particularly critical due to its scale, real-time constraints, and exposure to heterogeneous and sometimes untrusted networks. Accordingly, this survey focuses on encryption for smart grid communications while noting that the lessons generalize to other ICS. We consider protocol-level protections (DNP3, IEC 60870-5-104, IEC 61850, ICCP/TASE.2, Modbus, OPC UA, MQTT) and network-level mechanisms (VPNs, IPsec, MACsec). Our evaluation emphasizes security, performance, and deployability in legacy and heterogeneous environments, along with operational challenges such as real-time constraints, key management, interoperability, and alignment with sector guidance (e.g., NERC CIP, IEC 62351, IEC 62443).

Existing surveys on cybersecurity in ICS and smart grids provide valuable reviews of prevalent threats, relevant standards, and defensive mechanisms [7]. Nonetheless, most of these works either address encryption merely as one security mechanism among many or concentrate on a single protocol family or stack layer, without systematically integrating protocol-level and network-layer protections within a coherent, system-wide smart grid perspective. In contrast, the present review is explicitly focused on encryption mechanisms for smart grid communications and analyzes them as a cross-layer design problem spanning the OT and IT boundary.

In contrast to previous work that considers protocol-level or network-level security largely in isolation, we present a comprehensive analysis of encryption mechanisms. Specifically, we systematically map protocol-level protections (e.g., DNP3, IEC 60870-5-104, IEC 61850, ICCP/TASE.2, Modbus, OPC UA, MQTT) and network-level mechanisms (e.g., VPNs, IPsec, MACsec) onto representative smart grid topologies, indicating where these mechanisms are typically deployed and how they interact. We then comparatively evaluate application-level and network-level encryption with respect to security guarantees, performance characteristics, and practical deployability, and examine their alignment with NERC CIP, IEC 62351, and IEC 62443 requirements and recommendations. The objective of this survey is to deliver an integrated, system-wide analysis of encryption practices and deployment constraints in contemporary smart grid environments and to derive insights transferable to other classes of ICS.

The remainder of this paper is organized as follows. Section 2 introduces core encryption concepts and their role in ICS and smart grid environments. Section 3 examines network level encryption. Section 4 surveys application level mechanisms, covering legacy protocols with security overlays. Section 5 compares application-level and network-level encryption along criteria such as scope, performance, and deployability, and summarizes the trade-offs. Section 6 outlines research directions that follow from these challenges, and Section 7 concludes the paper.

2. Encryption in ICS Environment

Encryption is a cybersecurity measure that transforms readable data (plaintext) into an unreadable format (ciphertext), which can only be reversed by decryption using authorized cryptographic keys [8]. This technique safeguards sensitive information both at rest and in transit, playing a critical role in maintaining data confidentiality, which is one pillar of the CIA triad (confidentiality, integrity, and availability) [9]. Encryption also supports integrity and authenticity through message authentication codes and digital signatures, enabling detection of unauthorized modifications during transmission. Depending on the method used (symmetric or asymmetric), the same or different keys are used to decrypt the data. Symmetric encryption employs a single key for both encryption and decryption, while asymmetric encryption uses a pair of keys: a public key for encryption and a private key for decryption [10].

As discussed in the architecture section, ICSs were designed as isolated environments with limited security considerations. However, the shift toward increased connectivity, integration with enterprise IT networks, and the adoption of open TCP/IP and grid communication protocols (e.g., DNP3, IEC 60870-5-104, IEC 61850, ICCP/TASE.2) has exposed ICS environments to a broader range of cyber threats [11]. These changes, while improving operational efficiency, have also introduced vulnerabilities that threat actors can exploit. As a result, encryption has become one of the key cybersecurity tools and an essential layer of defense in modern ICS architectures, helping to mitigate the growing risks to critical infrastructure. This is especially true in the smart grid, where utilities interconnect control centers, substations, field sensors, Advanced Metering Infrastructure (AMI), and Distributed Energy Resource (DER) across public or shared networks.

Encryption can be applied at different levels of the TCP/IP stack, which includes the application, transport, network, and data-link layers. In this survey, we categorize these methods into two main groups: protocol-bound (or application-layer) protections and network-layer protections. Protocol-bound protections are specific to certain ICS protocols and are configured at the endpoints, or the devices that communicate directly. Examples include Modbus/TCP over TLS and IEC 60870-5-104 over TLS. In contrast, network- and link-layer protections such as IPsec, MACsec, and TLS-based VPNs are configured on devices such as gateways, routers, or switches. They secure the entire communication path or segment, regardless of the specific application protocols used.

Although TLS is a transport-layer protocol, we use these terms based on how they are deployed and the trust boundaries they create, rather than changing the definitions of the OSI or TCP/IP models. In smart grid systems, these encryption methods protect communication links, including those between control centers and substations, communication with IEDs, AMI backhaul, Distributed Energy Resource (DER) integrations, and data exchanges between utilities. This paper reviews recent implementations and research in both categories, focusing on communications between OT and IT, as well as field-area and wide-area communications.

In the remainder of this survey, we assume an attacker who can passively eavesdrop on, and actively inject or modify traffic on untrusted or shared networks that interconnect control centers, substations, AMI head-ends, DER sites, and external users. We also consider the possibility of compromised nodes or malicious insiders with access to substation LANs or DMZ segments. We assume that standard primitives and keys, when correctly deployed, are not broken, while operational misconfiguration and key-management weaknesses remain realistic risks. Architecturally, we assume topologies consistent with the Purdue based ICS view in Figure 1 and the smart grid communication paths shown in Figure 2, including control center substation links, intra-substation LANs, AMI backhaul, DER integrations, and inter-utility connections. Arrows in Figure 2 indicate logical encrypted communication channels rather than physical data-flow direction. Operationally, systems are engineered for high availability and tight latency budgets, and often include legacy or resource-constrained devices that support only lightweight cryptography. These assumptions underlie the discussion in Section 3, Section 4 and Section 5 of when protocol-bound encryption or network or link layer protections are more suitable.

3. Network-Level Encryption

In this survey, network-level encryption refers to mechanisms that secure communication channels at the network (IP) and data-link layers, as well as TLS-based VPN overlays that protect entire channels independently of the application protocol. This survey focuses on smart grid communications and offers lessons applicable to other ICS. We cover VPNs, IPsec, and MACsec and map them to common grid paths such as control center to substation, substation Local Area Network (LAN), and wide-area backhaul. These mechanisms protect interdevice, internetwork, and intersite traffic without changing application protocols or system architectures. As shown in Figure 2, they support host-to-host, network-to-network, and site-to-site protection.

3.1. Virtual Private Networks (VPNs) in Smart Grid Communication

VPNs are a foundational technology for cybersecurity in smart grid communication systems. They function by creating secure, encrypted tunnels over untrusted networks, such as the public internet or shared cellular infrastructure. These tunnels are used to facilitate secure remote access and inter-site communication among geographically dispersed components, including substations, control centers, distributed energy resources (DERs), and various field devices. The primary goal of a VPN in this context is to ensure the confidentiality, integrity, and authentication of all data in transit. As illustrated in Figure 2, VPNs can be deployed as host-to-host, network-to-network, or site-to-site connections to match grid topologies. In smart grid deployments, the two most common types of VPNs are IPsec-based, which operate at the network layer for site-to-site connections, and TLS-based VPNs (often called “SSL VPNs,” although SSL itself is deprecated), which function at the transport or application layer and are ideal for remote user access.

3.1.1. Advantages

The main advantage of using VPNs in a smart grid is creating a secure communication channel over public networks. They offer strong data confidentiality through AES encryption (commonly AES-GCM), ensure data integrity with hashing algorithms such as SHA-2 or AEAD modes, and authenticate endpoints to prevent unauthorized access using X.509 certificates or pre-shared keys. Modern deployments also enable perfect forward secrecy via Diffie–Hellman or ECDHE. This is essential for utilities that use cloud services, work with third-party vendors, or manage geographically dispersed grid assets via remote access [12]. Additionally, VPNs help segment networks, isolating critical control system traffic from other activities and enforcing least-privilege access to OT resources.

3.1.2. Limitations

VPNs, while beneficial, have limitations. A major concern is the performance impact of encryption, which adds latency and affects real-time applications. In practice, observed latency depends on cipher suites, hardware offload, and tunnel design; TLS-based remote-access VPNs can introduce more overhead than IPsec tunnels. Managing large-scale VPN deployments can be complex and resource-intensive due to key distribution and policy enforcement. In addition, a VPN concentrator can be a single point of failure, disrupting all communications if it fails, unless high-availability clustering and redundant paths are used. Split-tunneling configurations also require careful risk assessment to avoid accidental exposure of OT assets.

3.1.3. Usage

In smart grid applications, VPNs are used in key scenarios. IPsec VPNs facilitate persistent, site-to-site connections, linking central control centers with regional substations for secure SCADA data transmission and inter-utility data exchange. TLS-based VPNs are ideal for on-demand connections, allowing remote operators to monitor grid status and field technicians to maintain devices using mobile tablets, typically through a lightweight client or browser portal, all without complex software installation [13].

3.2. IPsec and MACsec for Layered Grid Security

IPsec (Internet Protocol Security) and MACsec (Media Access Control Security) provide a layered approach to securing smart grid communications. Operating at Layer 3 (network layer), IPsec provides end-to-end security for IP packets, offering encryption, integrity protection, and authentication across both utility-owned and public routed networks. In contrast, MACsec operates on Layer 2 (data link layer), securing Ethernet frames on local area networks. It encrypts traffic and protects against tampering and replay without altering higher-layer protocols, using IEEE 802.1AE with key agreement via 802.1X MKA [14]. Using both in tandem allows for comprehensive security, with IPsec protecting wide-area traffic and MACsec securing local, high-speed links within environments like substations.

3.2.1. Advantages

The primary advantage of this layered strategy is its comprehensive nature. IPsec is ideal for securing wide-area communications between substations, control centers, and field devices. MACsec’s key advantage is its lightweight and transparent operation, making it perfectly suited for time-sensitive, intra-substation traffic like GOOSE (Generic Object-Oriented Substation Events) and Sampled Values (SV) in IEC 61850 systems, where low latency is critical. With proper hardware support, MACsec adds minimal latency while preserving existing L2 designs.

3.2.2. Limitations

Each protocol has different limitations. IPsec implementation can be complex, requiring careful key management, firewall configuration, and Network Address translations (NAT) traversal mechanisms, while also introducing processing overhead and latency. Multicast and broadcast traffic may require special consideration under IPsec. MACsec’s primary limitation is its scope; it is designed for local Ethernet segments [15] and does not scale across wide-area routed networks, restricting its use to intra-substation or campus-level communication. MACsec also requires switch and endpoint support for IEEE 802.1AE and MKA.

3.2.3. Usage

In smart grid architectures, IPsec is frequently deployed to secure wide-area links used by Energy Management Systems (EMS), protect IEC 61850 communications over IP, and encrypt advanced metering infrastructure (AMI) backhaul traffic. MACsec is increasingly used within substation LANs to secure communications among IEDs, protection relays, and switchgear controllers [16].

3.3. Segmentation and Encrypted Tunneling in Grid Architecture

Network segmentation and encrypted tunneling are core strategies for securing smart grid architectures by dividing the network into distinct security zones. These zones, such as the control center, substation LANs, and field area networks, have restricted access and clear boundaries, often using Demilitarized Zones (DMZs) to isolate O) from corporate IT systems. Segmentation is also used for effective resource allocation [17]. Segmentation can be guided by ISA/IEC 62443 “zones and conduits,” which define policy boundaries and approved communication paths. To securely bridge these segments, encrypted tunnels (e.g., IPsec, GRE over IPsec, or VXLAN with MACsec) are used to protect data in transit across shared or untrusted infrastructure. Further granularity is achieved with micro-segmentation, which uses technologies like software-defined networking (SDN) and network access control (NAC) to enforce communication policies at the individual device level.

3.3.1. Advantages

This approach significantly minimizes the network’s attack surface and enhances protection of the environment [18]. By containing traffic within zones, segmentation prevents the lateral movement of threats like advanced persistent threats (APTs). It is a foundational component of a Zero Trust architecture, as it enforces the principle of least privilege, ensuring devices and applications can only communicate with explicitly authorized resources. This controlled communication model greatly improves security against both external and insider threats, including supply chain attacks.

3.3.2. Limitations

The primary limitation is complexity. Designing, implementing, and maintaining a robust segmentation strategy requires significant expertise in networking and cybersecurity. Misconfigured firewall rules or access control lists can inadvertently block critical operational traffic, impacting grid reliability, or create security gaps that attackers can exploit. The implementation can also incur costs associated with advanced hardware, such as next-generation firewalls and software for NAC or SDN.

3.3.3. Usage

In a typical utility, segmentation is used to create a De-Militarized Zone (DMZ) that separates the business IT network from the critical OT control network. In dynamic OT environments, software-defined segmentation is increasingly deployed [19]. Within the OT environment, encrypted IPsec tunnels are used to connect remote substations back to a central control center over a public carrier network. Micro-segmentation is applied within a substation to isolate protection and control IEDs from maintenance or monitoring devices, ensuring that a compromised device in one part of the network cannot impact critical protection functions.

4. Application-Level Encryption

Application-level encryption, in this survey, refers to security mechanisms that are integrated directly into the specific ICS communication protocols. This is a functional definition: the underlying primitive may reside at the application or transport layer in the OSI/TCP/IP stack. For example, Modbus/TCP over TLS or IEC 60870-5-104 over TLS are treated as application-level protections in our classification because the TLS session is established per protocol and terminates at the communicating devices, whereas TLS-based VPNs are discussed as network-level overlays in Section 3. In ICS environments, legacy protocols such as Modbus/TCP, DNP3, and IEC 60870-5-104 only gain confidentiality and strong endpoint authentication when encryption is integrated into their protocol-specific data structures or bound to their endpoints in this way. By providing encryption at this level, as shown in Figure 3, protection can be tailored to ICS semantics while remaining end-to-end across untrusted networks.

4.1. Securing Legacy Protocols

4.1.1. Modbus/TCP with TLS Layer

Modbus/TCP is one of the most widely adopted communication protocols in ICS and smart grid environments, including substations and SCADA environments. The Modbus family includes serial variants (Modbus RTU over RS-485/RS-422/RS-232) and an IP variant (Modbus/TCP). Under TCP, Modbus uses a client–server model rather than the legacy master–slave terminology. It is an open communication protocol that operates over TCP/IP networks and, in its original form, was specified without native security mechanisms, so Modbus/TCP transmits messages in plaintext, making it highly susceptible to cyber threats such as unauthorized command execution [20], denial-of-service (DoS) attacks, replay attacks, and man-in-the-middle (MITM) attacks. In the 2010s, the SunSpec DER Cybersecurity work group proposed security enhancements to encapsulate Modbus/TCP traffic within TLS tunnels. In this extended version, known as Modbus/TCP with TLS, all communication between endpoints is encrypted, and mutual authentication is achieved using X.509 digital certificates.

Advantages: The main advantage of Modbus/TCP with TLS is that it provides a standards-based security layer, ensuring integrity and supporting authentication [21]. It leverages widely deployed TLS 1.2/1.3 libraries, making integration feasible in modern ICS and smart grid systems. This extension mitigates common attacks such as packet sniffing, spoofing, and session hijacking, while maintaining interoperability with existing TCP/IP infrastructure. Mutual TLS (mTLS) enables device identity at scale and supports perfect forward secrecy with ECDHE.

Limitations: The integration of TLS introduces computational overhead and latency, which can be problematic in time sensitive smart grid operations. Certificate management adds administrative complexity, particularly in large scale deployments involving thousands of devices. Legacy Modbus devices may also lack TLS compatibility, requiring hardware upgrades or the deployment of secure gateways. Recent measurements of SunSpec Modbus/TCP over TLS on embedded controllers report that enforcing TLS increases average per-request latency from around 1 ms to approximately 1.6–1.8 ms, depending on the cipher suite [21]. Session resumption and hardware offload can help, but careful tuning is required to meet timing constraints.

Usage: In smart grid environments, Modbus/TCP with TLS is typically used to secure communication between field devices, such as RTUs and PLCs, and the SCADA system located in the control center. Encapsulating Modbus messages within TLS ensures that critical operational data, such as monitoring and control commands, remains confidential and authenticated across untrusted networks. A good example of the Modbus/TLS implementation for renewable distributed generation was demonstrated [21] using SunSpec Modbus, showing acceptable performance across varied connectivity and latency scenarios.

4.1.2. DNP3

The Distributed Network Protocol version 3 (DNP3) is commonly used in SCADA systems for power transmission and distribution [22,23]. It facilitates reliable communication between control centers, substations, and field devices, with a focus on telemetry and automation. However, the original DNP3 lacks native encryption, authentication, and integrity validation, sending messages in plaintext, which exposes it to vulnerabilities like interception and unauthorized command injection. Despite its useful timestamping and reporting features, DNP3 is unsuitable for untrusted or Internet-connected environments without additional security measures in place. This highlights the need for secure enhancements, such as DNP3 Secure Authentication (SA).

Advantages: DNP3 is highly reliable for SCADA operations, offering efficient communication, support for event-driven data reporting, and robust time synchronization. It is an open standard widely supported by vendors, ensuring interoperability across devices and systems. Its ability to handle asynchronous and unsolicited messages is particularly useful in grid automation and monitoring applications.

Limitations: The lack of inherent security in the legacy protocol makes DNP3 vulnerable to multiple cyberattacks, including data tampering, replay attacks, and unauthorized command execution. Implementing DNP3-SA mitigates some risks but introduces additional computational overhead, configuration complexity, and a need for careful key and certificate management. Legacy infrastructure may not support DNP3-SA without hardware or firmware upgrades.

Usage: In modern smart grids, DNP3 is mainly used for communication between RTUs, IEDs, and SCADA control centers [24]. The protocol is widely used for real-time monitoring, status updates, and control signals in distribution automation systems. With the implementation of DNP3-SA, these communications gain enhanced integrity and authentication, making them suitable for deployments where secure and reliable operations are critical.

4.1.3. DNP3 with Secure Authentication (IEEE 1815)

DNP3 has been enhanced through the IEEE 1815 standard by introducing DNP3 Secure Authentication (SA) to address security shortcomings [25]. SA adds a challenge–response mechanism that provides origin authentication and message integrity for selected operations using symmetric keys (e.g., HMAC) and, in later profiles, optional public-key credentials for entity authentication. SA mitigates spoofing and replay through counters and freshness checks; it does not encrypt telemetry or control payloads. Because payloads remain in plaintext, SA should be combined with transport protection (e.g., TLS or IPsec) when confidentiality is required. Despite added key management complexity, DNP3-SA significantly improves resistance to unauthorized control manipulation in fielded systems [25,26].

Advantages: DNP3-SA introduces a standards-based security enhancement without necessitating a complete redesign of existing DNP3 infrastructure. It effectively authenticates critical control commands, mitigates replay and spoofing attacks, and provides a scalable framework for integrating cryptographic mechanisms, all while maintaining compatibility with legacy DNP3 devices.

Limitations: Telemetry remains unencrypted, which enables traffic analysis. Key management and certificate handling introduce complexity, especially in large-scale deployments. Additionally, the selective authentication approach increases computational overhead, which may challenge resource-constrained devices in real-time operations.

Usage: In smart grid environments, DNP3-SA is commonly used to secure command and control traffic between substations, IEDs, and SCADA control centers. It ensures that only authenticated commands are executed by field devices, thereby enhancing the reliability and trustworthiness of grid control operations. Confidentiality, if required, is provided by an additional transport layer such as TLS or IPsec.

4.1.4. IEC 60870-5-104 with TLS Integration

IEC 60870-5-104 (IEC 104) is a protocol commonly used in telecontrol systems for electrical substations and control centers. However, it lacks built-in encryption and authentication, making it vulnerable to network attacks. To enhance security, IEC 104 is often encapsulated within TLS [27,28], providing encrypted messages and mutual authentication through X.509 certificates. Implementations typically follow IEC 62351-3 TLS profiles for power-system protocols. This integration protects against eavesdropping, man-in-the-middle (MITM) attacks, and tampering. For devices without native TLS support, secure gateways or protocol wrappers can provide encrypted tunnels.

Advantages: Integrating TLS with IEC 104 provides strong end-to-end security by ensuring confidentiality, message integrity, and authentication. It utilizes widely adopted TLS libraries and certificate infrastructures, making it interoperable with modern security systems. This approach enables utilities to maintain their existing IEC 104 infrastructure while significantly enhancing cybersecurity resilience against contemporary threats.

Limitations: The addition of TLS introduces computational and latency overhead, which can impact performance in latency-sensitive grid operations. Managing X.509 certificates across distributed systems adds administrative complexity, particularly for large-scale deployments with numerous field devices. Furthermore, legacy hardware may require upgrades or the use of TLS-enabled gateways to achieve compliance.

Usage: In smart grid deployments, IEC 60870-5-104 with TLS is primarily used to secure communication between substations, RTUs, and the control centers. By encrypting payloads and authenticating connections, it safeguards telemetry and control messages transmitted over public or shared networks. This integration is particularly critical in wide-area monitoring and control applications, where reliability and secure communication are essential for grid stability and resilience.

4.1.5. IEC 61850 with Secure Transport (TLS/MACsec/IEC 62351-6)

IEC 61850 is a key standard for substation automation and communication among IEDs in smart grids. It outlines standardized data models and communication services, such as GOOSE and MMS, ensuring interoperability for real-time power system control and monitoring. While it supports high-speed communication, early implementations had limited security. To address cybersecurity risks, MMS over TCP/IP is commonly protected with TLS (per IEC 62351-3). GOOSE and Sampled Values operate at Layer 2; their protection is specified in IEC 62351-6 (message authentication and integrity), and many deployments use MACsec to secure the underlying Ethernet segments. When GOOSE/SV traffic must traverse routed networks, tunneling (e.g., GRE over IPsec) is used cautiously to meet latency budgets.

Advantages: TLS for MMS and IEC 62351-6/MACsec for GOOSE/SV provide strong security guarantees, ensuring confidentiality, integrity, and device authentication across IEC 61850 communications. These mechanisms are standards-based and widely supported, making them interoperable and suitable for large-scale deployments. These overlays allow utilities to leverage existing IEC 61850 infrastructures while achieving compliance with security requirements outlined in IEC 62351.

Limitations: Securing IEC 61850 introduces challenges, particularly in latency-sensitive environments. High-speed multicast services such as GOOSE can be impacted by added processing delays if protection is not implemented with hardware support or if tunneled over routed links. Certificate management and key distribution across large numbers of IEDs and substations increase operational complexity. MACsec and IEC 62351-6 require switch and endpoint capabilities that may not be present in legacy equipment.

Usage: In smart grid environments, IEC 61850 with secure transport is primarily used to protect communications between IEDs, protection relays, and substation automation systems, as well as between substations and central control systems. TLS typically secures MMS client–server exchanges, while MACsec and IEC 62351-6 protect intra-substation GOOSE/SV. When traffic extends beyond the substation, careful tunneling is applied to maintain timing requirements.

4.1.6. ICCP (TASE.2) with TLS/IPsec Overlays

The Inter-Control Center Communications Protocol (ICCP), standardized as TASE.2 under IEC 60870-6, is a high-level protocol used for exchanging real-time operational data between utility control centers over wide-area networks (WANs) [29,30]. It is critical for grid coordination, state estimation, and monitoring of transmission and distribution systems. However, the original ICCP specification does not include native encryption, authentication, or integrity validation, leaving communications exposed to interception, spoofing, or unauthorized manipulation. To address these gaps, ICCP is commonly secured using overlay mechanisms such as TLS or IPsec. TLS provides end-to-end encryption and mutual authentication at the application level, while IPsec operates at the network layer and can leverage hardware acceleration for high-throughput secure tunnels.

Advantages: Securing ICCP with TLS or IPsec ensures full encryption, message integrity, and endpoint authentication, providing strong defenses against eavesdropping, replay attacks, and data tampering. TLS is relatively straightforward to implement in software environments and is compatible with most vendor systems, while IPsec is well-suited for high-performance or hardware-accelerated deployments. Both approaches facilitate compliance with cybersecurity standards and regulatory requirements for protecting critical infrastructure.

Limitations: The use of TLS or IPsec introduces additional complexity in managing digital certificates, cryptographic keys, and security policies, especially in multi-vendor environments. Legacy systems without support for these overlays may require secure gateways, adding cost and integration effort. Moreover, the encryption overhead can lead to increased latency and processing requirements in bandwidth-constrained or resource-limited systems.

Usage: Within smart grid operations, ICCP secured with TLS or IPsec is primarily used for secure data exchange between regional or national control centers, transmission operators, and balancing authorities. It facilitates real-time sharing of operational status, load forecasts, and contingency data over WANs, ensuring the integrity and confidentiality of mission-critical information necessary for grid coordination and stability.

4.2. Secure-by-Design Protocols

• OPC UA: Native Encryption and Authentication. OPC UA (Open Platform Communications Unified Architecture) is a modern, platform-independent communication protocol widely adopted in industrial automation and smart grid environments. Unlike retrofitted legacy protocols, OPC UA is secure-by-design, embedding robust cryptographic protections into its core architecture. It supports asymmetric cryptography (e.g., RSA, ECC) for mutual authentication and secure session establishment, and symmetric encryption algorithms like AES for protecting message payloads. Integrity and authenticity are ensured using digital signatures and HMACs. With secure communication profiles enabled, encryption is fully active, providing resilience against man-in-the-middle, replay, and impersonation attacks. OPC UA also supports certificate-based trust models, user-level authorization, and operates securely over various transport layers (TCP, HTTPS, WebSockets). In constrained deployments, selecting lighter-weight security profiles and enabling session resumption can reduce overhead.
• MQTT over TLS: Secure Publish-Subscribe Messaging. MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe protocol well-suited for constrained and asynchronous environments such as IoT and smart grid telemetry. The base MQTT specification does not include native encryption or authentication, but security can be effectively added by operating it over TLS. In this configuration, MQTT over TLS enables full encryption of message payloads and broker authentication, along with mutual authentication through X.509 certificates or pre-shared keys. This protects against eavesdropping, data tampering, and replay attacks. While this overlay introduces additional session setup time and resource demands, it significantly enhances security in deployments such as smart meters, data concentrators, and SCADA gateways. Broker-side authorization (topic ACLs) is essential to prevent unauthorized publish/subscribe actions.
• IEC 62351: Security Framework for Legacy Protocols. IEC 62351 is a comprehensive cybersecurity standard designed to secure legacy communication protocols in power system automation, including ICCP (TASE.2), DNP3, and IEC 60870-5-101/104. Rather than replacing these protocols, IEC 62351 provides a layered framework for integrating security features such as encryption, authentication, and integrity validation. It supports TLS, IPsec, and SSH for securing data in transit, and introduces public key infrastructure (PKI), digital signatures, and role-based access control. Relevant parts include IEC 62351-3 (TLS for TCP-based protocols), IEC 62351-4 (MMS), and IEC 62351-6 (GOOSE/SV). While its integration improves interoperability and preserves legacy infrastructure, challenges remain in certificate lifecycle management, computational cost, and vendor-specific implementation gaps. Nevertheless, IEC 62351 is critical in enabling secure communication within smart grid ecosystems that still rely on established protocols.

4.3. TLS in ICS

While TLS 1.2/1.3 ensures strong encryption and mutual authentication, ICS devices face challenges due to resource constraints and handshake latency. Certificate management must also be streamlined. In practice, prefer AEAD cipher suites (e.g., AES-GCM or ChaCha20-Poly1305), enable session resumption, and avoid legacy SSL/TLS versions. Where very low latency is required, consider TLS-PSK profiles with careful key management. Hardware offload on gateways can help meet timing budgets in substations and field area networks.

5. Comparison of Encryption Mechanisms

After reviewing various encryption mechanisms in the previous sections, it is important to compare them more systematically to highlight their respective strengths and limitations. Each of these approaches offers unique pros and cons depending on the operational context of ICS deployments. In what follows, we focus on ICS with the smart grid as the primary application domain and use the layering shown earlier in Figure 2 and Figure 3.

Table 1. Encryption possibilities in ICS environment across TCP/IP layers.

TCP/IP Layer	Encryption Possibilities	Common ICS Examples
Application Layer	Protocol-specific encryption (e.g., encrypting payload data within the protocol itself)	OPC UA with built-in encryption; MQTT over TLS; Modbus/TCP over TLS; IEC 60870-5-104 over TLS; DNP3 Secure Authentication (integrity/authentication
Transport Layer	End-to-end encryption via TLS or DTLS	HTTPS for HMIs; OPC UA over HTTPS; generic TLS/DTLS client–server sessions
Network Layer	IPsec (ESP or AH modes)	Secure site-to-site VPN between control centers
Data Link Layer	Link-layer encryption (e.g., MACsec, proprietary industrial Ethernet security)	MACsec in modern switches (e.g., intra-substation GOOSE/SV segments)

summarizes representative encryption mechanisms available at each TCP/IP layer in typical ICS environments, illustrating where protocol-bound and network/link-layer protections commonly reside. For clarity, in this survey we treat TLS bound to specific ICS protocols (e.g., Modbus/TCP over TLS or IEC 60870-5-104 over TLS) as application-level (protocol-bound) protection, because the TLS session terminates at the ICS endpoints and is configured per application, whereas TLS used to implement remote-access VPNs is considered a network-level overlay. This is purely a functional classification; TLS itself remains a transport-layer protocol in the TCP/IP stack.

After reviewing various encryption mechanisms in the previous sections, it is important to compare them more systematically to highlight their respective strengths and limitations. Each of these approaches offers unique pros and cons depending on the operational context of ICS deployments. In what follows, we focus on ICS with the smart grid as the primary application domain and use the layering shown earlier in Figure 2 and Figure 3. Table 1 summarizes representative encryption mechanisms available at each TCP/IP layer in typical ICS environments, illustrating where protocol-bound and network/link-layer protections commonly reside. For clarity, TLS bound to specific protocols (e.g., Modbus/TCP or IEC 60870-5-104) is treated as application-level protection, while TLS used as a remote-access VPN is considered a network-level overlay.

Application-level encryption provides granular control by securing specific data fields or messages, providing end-to-end confidentiality even across untrusted networks. This makes it particularly useful for protecting sensitive commands or authentication processes. It also enables origin authentication and integrity checks within the protocol context; for example, DNP3 Secure Authentication adds integrity and command authentication, although it does not encrypt payloads. Network-level encryption, on the other hand, protects traffic at the IP or Ethernet layer (IPsec or MACsec), providing broad protection without requiring modifications to legacy devices or applications. While less selective, it is easier to implement across diverse ICS environments.

Compatibility and deployment complexity are also key differentiators. Application-level encryption often requires cryptographic libraries, protocol modifications, or firmware updates, which can be challenging for resource-constrained or legacy systems. Network-level approaches, such as VPNs, IPsec, and MACsec, are generally easier to deploy and require fewer changes to applications. This makes them a practical choice for retrofitting security into heterogeneous infrastructures where mixed vendors and devices coexist. MACsec does require switch and endpoint support for IEEE 802.1AE and MKA, which can limit use in older substations.

Performance and scalability considerations further influence adoption. Application-level encryption can impose higher computational burdens on endpoints, potentially disrupting latency-sensitive operations like protection relay signaling. Network-level encryption, while generally lighter per packet, covers all traffic uniformly and can add latency due to encapsulation and tunnel processing; hardware offload and careful topology design reduce this impact. Scalability favors network-level solutions, as they can secure entire sites or communication paths, whereas application-level methods may face challenges without standardized protocol support.

Regulatory compliance and operational requirements also guide the choice. Application-level encryption aligns with standards such as IEC 62351, which define protocol-specific protections; however, ensuring cross-vendor adoption is challenging. Network-level encryption supports compliance with frameworks such as NERC CIP by providing auditable standardized protections at the IP and Ethernet layers (e.g., IPsec VPNs and MACsec). In practice, hybrid designs are common: protocol-level protection for mission-critical exchanges and network-level encryption for broader communication flows.

The above comparisons between the two types of encryption available in the ICS environment are listed in

Table 2. Comparative analysis of application-level vs. network-level encryption.

Criteria	Application-Level Encryption	Network-Level Encryption
Scope of Protection	Protects specific data fields, messages, or files at the application layer	Protects all IP packets (IPsec) or Ethernet frames (MACsec) in transit across links and paths
Granularity	Allows selective encryption of sensitive data	Encrypts all traffic between nodes
End-to-End Security	Yes, maintains encryption across all hops, including intermediary systems	Typically no; encryption often terminates at VPN/IPsec gateways or L2 boundaries [31]
Legacy System Compatibility	Limited; may require application or firmware changes	Yes, generally compatible; no changes needed in applications or legacy devices (MACsec requires IEEE 802.1AE/MKA support)
Deployment Complexity	High; requires code integration, cryptographic libraries, and protocol adaptation	Moderate to low; can be deployed using existing infrastructure like VPN appliances or firewalls and L2-capable switches
Performance Overhead	On-device encryption on RTU/PLC hardware typically adds ≈10–20% CPU/QPS overhead and about 10% throughput loss versus no encryption, while proxy-based Modbus/TCP encryption can reduce throughput by up to ∼60% under heavy load [32].	Per-packet processing is lighter and can be offloaded to routers or gateways; VPN benchmarks on constrained hardware still report tens of Mbps of throughput, with overhead mainly driven by cipher choice and CPU capacity rather than the VPN concept itself [31].
Key and Cert Management	Complex; unique keys may be required for each application or message type	Centralized management possible for network devices; still requires robust PKI infrastructure
Latency Impact	Per-request latencies of 0.1–0.2 ms for on device stream cipher encryption and ≈1.6–1.8 ms for Modbus/TCP over TLS (roughly 50% slower than plain Modbus/TCP) [33], while lightweight schemes such as YASIR et al. add only a few tens of byte times per message [34].	Measurements of SSL VPN tunnels in cloud-based SCADA deployments show encryption adding about 1 ms to end-to-end latency, with most delays still in the 20–50 ms range; WAN distance and routing dominate over cryptographic cost [34].
Scalability	Difficult to scale without standardization or protocol-specific support	More scalable for broad, site-to-site or device group communication
Regulatory Alignment	Depends on protocol implementation (e.g., IEC 62351); harder to standardize	Easier to demonstrate compliance via standardized IPsec VPNs or MACsec; TLS-based remote access can complement
Use Cases	Securing sensitive control commands, authentication, selective field-level protection	Securing all traffic between zones (e.g., control center to substation, remote access tunnels)
Examples	TLS in OPC UA, DNP3 Secure Authentication (integrity/authentication), Modbus/TCP with TLS [35]	IPsec VPNs, MACsec in substations [36], GRE over IPsec for routed overlays

. It depicts the roles of IPsec and MACsec at the network and data-link layers, respectively, and distinguishes them from protocol-bound TLS.

6. Research Directions

The merging of IT and OT in ICS, especially within the smart grid, has increased the risk of cyberattacks. This makes where to place encryption an important design choice that affects the entire system, not just a technical decision. As discussed in Section 3, Section 4 and Section 5, there is not just one best option for encryption; application-level and network-level encryption have different advantages and disadvantages. These include differences in latency, deployment complexity, legacy compatibility, and regulatory alignment. This is especially important when using multiple protocols, such as Modbus/TCP, DNP3, IEC 60870-5-104, IEC 61850, and ICCP, in mixed environments.

To address these issues, below we discuss the six possible research directions.

6.1. Comparative Analysis of Application-Level vs. Network-Level Encryption

An important direction for future research is the comparative analysis of application-level and network-level encryption in realistic ICS testbeds across multiple metrics, including performance (e.g., execution time at nodes), throughput, latency overhead, and security. Such analyses can help utility service providers determine which encryption techniques are most appropriate for different data types and application scenarios.

Application-level encryption provides data confidentiality and integrity protection directly at the source, before data leaves the application. This allows for fine-grain integration and supports end-to-end security even across intermediate, untrusted networks. However, the downside is that application-level encryption often requires significant changes to existing software, including the integration of cryptographic libraries, key management systems, and possibly hardware accelerators. These modifications can be particularly challenging in legacy ICS systems that have limited computational resources, proprietary firmware, or outdated communication protocols. Comparative studies should quantify latency (average and 99th percentile), jitter, throughput, CPU and memory footprints on endpoints, handshake and rekey times, failover behavior, and certificate lifecycle overhead for each protocol profile (e.g., Modbus/TCP over TLS, IEC 60870-5-104 over TLS, DNP3 with Secure Authentication).

The network-level encryption, on the other hand, such as IPsec, MACsec, and VPNs, operate at lower layers of the OSI model. They secure entire communication channels, regardless of application. These solutions are often easier to deploy across heterogeneous systems because they do not require modification of application code or devices. It provides a significant advantage, as retrofitting security into legacy ICS environments is much easier. However, network-level encryption does not provide end-to-end security in scenarios where the traffic is decrypted only at intermediate nodes (e.g., VPN endpoints or firewall proxies), potentially exposing plaintext data to lateral movement or insider threats. Studies should also evaluate MTU effects, tunnel overhead, path changes, and the benefits of hardware offload for IPsec and MACsec in substations.

Researchers can develop standardized benchmarks and simulation environments to evaluate metrics such as performance overheads, scalability, and integration. These metrics can be measured in various ICS architecture simulations such as substations, power generation plants, control centers, etc. Test environments that openly and reproducibly replicate the topologies and substation LANs depicted in Figure 2 will facilitate equivalent comparisons among different vendors and system configurations.

6.2. Hybrid Encryption Architectures

Another promising research direction is the exploration of hybrid encryption strategies that combine both application and network-level protections. Inspired by defense-in-depth principles of NIST [37], these hybrid implementations aim to secure data across the entire communication stack. For instance, a system might use TLS encryption for SCADA messages at the application level while also routing all traffic through an IPsec VPN tunnel for added network-layer protection. While such architectures offer enhanced security, they introduce performance and management complexities that must be evaluated and optimized through future research.

The use of advanced key management schemes can be explored, along with the impact they can have on large-scale deployments. Research must focus on optimizing these configurations to strike a balance between security and performance without compromising operational reliability. Priority topics include cross-layer tuning for latency-sensitive traffic (e.g., IEC 61850 GOOSE/SV), coordinated rekey schedules, session resumption policies, TLS-PSK vs. certificate-based authentication for constrained devices, and the interaction between MACsec at Layer 2 and IPsec/TLS across routed links.

6.3. Protocol-Specific Adaptations and Security Extensions

As mentioned in the paper, many ICS protocols (Modbus, DNP3, IEC 104) were not originally designed with encryption in mind. The retrofitting of these protocols with TLS or secure authentication layers is a rich area for further innovation. Future research should focus on the development of lightweight encryption standards or modular security overlays tailored to each protocol’s architecture. Furthermore, experimental evaluations in live or emulated environments could reveal the operational constraints these adaptations impose on field devices, particularly in terms of message throughput, latency, and fault tolerance. For DNP3, work should explore pairing DNP3 Secure Authentication (integrity and origin authentication) with transport confidentiality when needed; for IEC 61850, research should study IEC 62351-6 protections for GOOSE/SV alongside MACsec on substation LANs; for IEC 60870-5-104 and Modbus/TCP, TLS profiles and certificate policies merit tuning for utilities’ timing budgets.

Efforts such as IEC 62351 already offer security extensions for several legacy protocols, but adoption remains limited due to interoperability and integration challenges. Research into simplifying and standardizing these extensions—while ensuring backward compatibility—would be highly beneficial for the broader ICS community. Interoperability plugfests, conformance tools, and reference configurations that match Table 2 use cases can lower adoption barriers.

6.4. Post-Quantum Cryptography in ICS

One of the key emerging technologies, quantum computing, necessitates forward-looking research into post-quantum cryptographic (PQC) algorithms for ICS. Given the long life cycles of ICS equipment, systems deployed today may still be in operation when quantum computers become practical. PQC algorithms such as lattice-based or hash-based key encapsulation [38] and signatures must be evaluated for feasibility within the constrained environments of RTUs and PLCs. Identifying quantum-resistant protocols with minimal computational requirements will be critical to ensuring long-term confidentiality and authentication in ICS. Hybrid classical–PQC modes, certificate size and handshake latency, firmware footprint, bandwidth limits on field links, and migration planning aligned with utility maintenance windows are key areas to study.

6.5. Key and Identity Management at Scale

Encryption efficacy depends on scalable key and identity management. Research should address automated provisioning, renewal, and revocation for large fleets of IEDs and gateways; role- and device-based authorization; secure manufacturing enrollment; and offline or intermittently connected sites. Comparative evaluations of PKI topologies, trust-list distribution for OPC UA, and credential escrow for field maintenance can help utilities operationalize cryptography without increasing outage risk.

6.6. Operational Visibility Under Ubiquitous Encryption

As more traffic is encrypted, defenders need methods to maintain situational awareness without breaking confidentiality. Promising directions include metadata- and flow-based monitoring, encrypted telemetry for health signals, integrity-only modes where appropriate, and privacy-preserving inspection at defined trust points. Studies should quantify how segmentation (Figure 2) and protocol-layer protections (Figure 3) affect detectability of misuse and how to design logging, time synchronization, and incident response that remain effective when payloads are opaque.

7. Conclusions

Encryption remains vital in protecting ICS communications, especially in smart grid operations where control centers, substations, AMI, and DERs exchange data over shared or untrusted networks. Both application-level and network-level techniques have their merits and trade-offs. As ICSs continue to evolve within increasingly interconnected environments, ensuring secure communication has become a paramount concern. This survey has examined the current landscape of encryption technologies deployed in ICS, categorizing them into application-level and network-level approaches, with the smart grid as the primary application domain and lessons that extend to other ICS. Each method presents unique advantages and trade-offs in terms of deployment complexity, performance, protection granularity, and compatibility with legacy systems. While application-level encryption offers fine-grained control and end-to-end confidentiality, it often requires intrusive changes and significant computational resources. Network-level encryption, on the other hand, is more feasible for retrofitting into existing infrastructure but may not offer complete protection across all communication paths, particularly when tunnels terminate at intermediate gateways.

The authors acknowledge the critical need for ongoing research to address unresolved challenges in this domain. Future work will focus on comparing encryption approaches in live or emulated ICS environments, with representative smart grid topologies and metrics such as average and 99th-percentile latency, jitter, throughput, endpoint CPU and memory load, handshake and rekey times, failover behavior, and certificate lifecycle cost. Additionally, research will investigate the applicability of post-quantum cryptographic schemes and the effectiveness of such methods in resource-constrained ICS environments, alongside scalable key and identity management for large fleets of IEDs and gateways and operational visibility when most traffic is encrypted. By advancing these areas, the authors aim to contribute to the design of secure, resilient, and performance-aware smart grid cybersecurity frameworks with guidance that generalizes to other ICS.