A Deep Technical Study of Vulnerabilities, Secure Communication Protocols, and the Application of IEC 62351-4 to Digital Substation Messaging

Abstract

IEC 61850, the cornerstone of modern digital substations, uses the Manufacturing Message Specification (MMS) for client-server communications. As a comprehensive and extensible protocol suite, IEC 61850 enables powerful data modeling and efficient communication across intelligent electronic devices (IEDs), human-machine interfaces (HMIs), and control centers. However, the increased reliance on TCP/IP networking, vendor interoperability, and remote access capabilities has also expanded the protocol’s attack surface.

This article explores the cybersecurity implications of MMS-based IEC 61850 communications and evaluates how IEC 62351-4 introduces robust protections to address authentication, integrity, and confidentiality requirements. The discussion includes deep protocol analysis, threat vectors, cryptographic countermeasures, implementation recommendations, and performance considerations in substations where real-time operation and security must coexist.

Introduction to IEC 61850 and MMS

IEC 61850 defines a unified communication framework for substation automation. Its layered architecture includes:

• Abstract Communication Service Interface (ACSI): Protocol-agnostic interface for data access
• MMS (Manufacturing Message Specification): Implements the ACSI services for client-server messaging
• TCP/IP and Ethernet: Transport layers used for communications across IEDs and SCADA systems

MMS enables operations such as Read, Write, ReportControl, Command, LogQuery, and more. These messages are exchanged between engineering workstations, SCADA clients, protection relays, and IEDs.

Originally, MMS and IEC 61850 offered no built-in security. All control and monitoring actions—such as tripping a breaker or querying protection settings—could be spoofed or intercepted. This lack of security became a pressing issue with the rise of networked substations, remote access, and sophisticated adversaries capable of exploiting protocol weaknesses.

Threat Landscape for MMS Communications

The IEC 61850/MMS layer is vulnerable to a wide range of threats:

Message Spoofing

Attackers who gain network access can forge MMS messages, particularly Write or Control commands, to mimic legitimate clients. Because early implementations of IEC 61850 lack built-in message authentication, an attacker can impersonate an operator or engineering station. This spoofing can result in unauthorized actions like opening circuit breakers or changing protection settings—leading to equipment damage, service interruption, or even safety risks.

Man-in-the-Middle (MITM) Attacks

In a MITM attack, adversaries position themselves between communicating devices and intercept the MMS traffic. Since IEC 61850 was not originally encrypted, the attacker can alter messages in transit, feeding incorrect data to SCADA operators or engineering systems. This could result in misleading situational awareness or manipulated control decisions. A particularly dangerous variant involves injecting malicious configuration updates without the operator realizing the breach.

Replay Attacks

Replay attacks exploit the stateless nature of some MMS operations. Attackers capture legitimate messages and resend them to repeat a prior valid command—like toggling a control output. Without sequence counters or timestamps to track freshness, these duplicate commands appear valid to the receiver, resulting in unintended device behavior and potentially repeated disruptions.

Unauthorized Access

If devices do not enforce authentication and authorization, attackers with network access may connect directly to IEDs. Through valid MMS operations like Read, GetNameList, or FileOpen, they can extract sensitive configuration data or deploy malicious firmware. Without role-based restrictions, even non-critical users could gain control privileges if they present a valid but unrestricted client identity.

Denial-of-Service (DoS)

IEDs and control systems typically have limited resources for processing requests. Attackers can craft malformed MMS packets or flood the network with high-volume queries, causing legitimate services to time out or become unresponsive. These attacks are especially disruptive during commissioning or emergency response, when high system availability is critical.

IEC 62351-4: Security Framework for MMS and ACSI

IEC 62351-4 defines the security mechanisms for MMS over TCP/IP, targeting the client-server communications in IEC 61850 and its abstract interface (ACSI). The standard introduces a multi-layered defense model comprising transport layer protection, cryptographic authentication, role-based access control, and session integrity.

TLS-Based Transport Protection

IEC 62351-4 mandates the use of TLS as a foundational requirement to protect MMS over TCP/IP. TLS establishes a secure channel that encrypts all communications, preventing adversaries from reading or modifying traffic. The handshake process authenticates both client and server using digital certificates, reducing the risk of impersonation. Moreover, TLS ensures integrity by using cryptographic hashes to detect message tampering.

The standard recommends TLS version 1.2 or higher, aligning with modern security practices. Cipher suites such as AES-GCM provide authenticated encryption, combining confidentiality and integrity in a single operation. Elliptic-curve Diffie-Hellman (ECDHE) enables forward secrecy, ensuring that compromise of long-term keys doesn’t expose past sessions—a vital feature for protecting long-lived substation devices.

Mutual Authentication via Certificates

Both client and server endpoints are required to authenticate using X.509 certificates. The verification process includes:

• Certificate signature validation against a trusted Certificate Authority (CA)
• Certificate revocation checking (via CRL or OCSP)
• Matching certificate identities to roles (e.g., SCADA operator, protection relay, commissioning tool)

Role-Based Access Control (RBAC)

RBAC in IEC 61850, as defined in IEC 62351-8, assigns permissions based on predefined roles rather than individual users. This model simplifies administration and improves scalability. Each role—such as Viewer, Operator, Engineer, or Commissioning Tool—is granted specific rights aligned with its function. For example, an Operator may be allowed to issue control commands but not alter IED settings.

Role assignments are bound to the client’s certificate, meaning the identity and role are cryptographically verified during the TLS handshake. This tight integration prevents privilege escalation—even if an attacker manages to connect to the device, they can only execute operations allowed by their role. Enforcement happens directly within the IED’s security stack, ensuring access control decisions are made locally and quickly.

Secure Associations and Session Management

Once TLS is established, an ACSI Association is created. IEC 62351-4 requires:

• Session integrity tracking
• Freshness verification (via sequence numbers or session IDs)
• Binding of authenticated identities to sessions

If a session is interrupted or suspicious activity is detected, devices may force re-authentication or close the session entirely.

Implementation Architecture

To integrate IEC 62351-4 in substation networks, several architectural elements are recommended:

Certificate Management Infrastructure

Establishing a robust Public Key Infrastructure (PKI) is a prerequisite for secure IEC 61850 deployments. Utilities must operate or contract a trusted Certificate Authority (CA) responsible for issuing, signing, and revoking certificates. These certificates validate the identity of SCADA clients, engineering stations, and IEDs.

To streamline deployment and reduce human error, automated enrollment protocols like SCEP (Simple Certificate Enrollment Protocol) or EST (Enrollment over Secure Transport) are recommended. These allow devices to request and renew certificates without manual intervention. Revocation mechanisms, such as Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP), must be in place to ensure compromised identities can be quickly disabled.

IED Security Stack Enhancements

IEDs must support:

• TLS termination and certificate validation
• MMS over TLS (port 102)
• Access control enforcement for MMS operations
• Logging and audit trail for security-relevant events

Resource-constrained IEDs may require hardware cryptographic acceleration or external proxies.

Network Design Considerations

A secure MMS deployment requires careful network segmentation. Substation LANs should be organized into VLANs that separate control, engineering, and monitoring functions. Firewalls and layer-2/3 filtering should restrict MMS traffic to approved endpoints. Engineering workstations, for instance, should only communicate with IEDs during scheduled maintenance windows.

Deep Packet Inspection (DPI) firewalls can further enhance security by inspecting MMS/TLS payloads to detect malformed or unauthorized traffic. In environments with legacy systems, TLS proxy devices can be introduced to enforce encryption without replacing all IEDs. Limiting network exposure to the public internet and applying strict IP whitelisting are also best practices

Interoperability and Conformance Testing

Given the complexity of TLS integration, conformance testing is critical. IEC 62351-100-4 defines test cases for verifying:

• Proper TLS handshake and cipher negotiation
• Certificate validation behavior
• Access control enforcement by role
• Session timeout and re-authentication mechanisms

Independent certification programs can validate vendor compliance and help identify interoperability gaps before deployment.

Performance Considerations

TLS Overhead

While TLS adds latency due to handshake and encryption, modern IEDs and processors can complete handshakes in under 100 ms and maintain high-throughput encrypted sessions.

TLS session resumption and long-lived connections mitigate performance impacts. AES-GCM cipher suites provide both speed and integrity.

Control Operation Timing

Time-critical operations, such as breaker tripping, are typically handled via GOOSE or SV, not MMS. Nevertheless, TLS encryption must not significantly impact normal control or configuration tasks via MMS.

IEC 62351 allows optimization such as:

• Offloading cryptographic tasks to hardware
• Persistent TLS connections
• Streamlined access control checks

Summary of Best Practices

To effectively secure IEC 61850/MMS communications:

• Mandate TLS for all MMS traffic using IEC 62351-4 and 62351-3 profiles
• Deploy mutual authentication via X.509 certificates
• Use role-based access control to restrict MMS operations based on identity
• Monitor and audit all MMS connections and actions
• Integrate certificate management with utility PKI infrastructure
• Perform conformance testing using IEC 62351-100-4 test suites

Conclusion

Securing MMS-based IEC 61850 communications is essential for the trustworthiness and safety of digital substations. IEC 62351-4 provides a technically robust and scalable security model by integrating TLS, mutual authentication, and fine-grained access control. These protections, when properly implemented and tested, ensure that substation devices operate securely in increasingly interconnected and threat-prone environments.

In Part 4 of this series, we will turn to TASE.2/ICCP, the protocol of choice for utility control center interconnection, and explore how IEC 62351-6 secures this vital communication layer.

MZ Automation has released IEC 60870-5-101/104 version 2.4.1, the latest update to our IEC 60870-5-101/104 C source code library.

This release focuses primarily on security, stability, and reliability. It addresses the vulnerabilities reported during recent weeks, including several issues affecting ASDU parsing, TLS certificate validation, message-length validation, and server communication.

Version 2.4.1 is not intended as a major feature release. However, it also includes a limited number of minor improvements and API additions.

Vulnerability Fixes

The release contains several important security corrections:

• Added message-length validation when parsing Information Object Addresses within ASDUs and information objects.
• Fixed an out-of-bounds read in the decoder for ASDU type S_IT_TC_1
  (LIB8705-305, GHSA-f5xp-w6f3-vvrv).
• Fixed a TLS certificate-validation bypass affecting the mbedTLS 2.28 integration when allowOnlyKnownCertificate=true and validateChain=false
  (LIB8705-304, GHSA-fc2j-39h7-c7v9).
• Removed the unencrypted TLS_RSA_WITH_NULL_SHA256 cipher suite from the default TLS configuration for both mbedTLS 2.28 and 3.6
  (LIB8705-303).
• Added validation of the ASDU Variable Structure Qualifier field against the expected payload size when creating an ASDU from a buffer
  (GHSA-7v97-jmwv-w5j7).

Users are strongly encouraged to update to version 2.4.1, particularly when IEC 60870-5-101/104 is used in network-connected or security-sensitive environments.

Additional Improvements

Version 2.4.1 also introduces several smaller improvements:

• Added a mutex to protect Certificate Revocation List updates and access during runtime for the mbedTLS 2.28 and 3.6 integrations
  (LIB8705-307).
• Added the previously missing IntegratedTotalsForSecurityStatistics_getAID function.
• Added checks to determine whether an ASDU type permits multiple information objects before information objects are added to or read from an ASDU.
• Improved TLS renegotiation handling for mbedTLS 2.28 by driving renegotiation and processing timeouts through TLSSocket_tick, allowing precise time-based renegotiation intervals.
• Added validation of the user-provided index passed to CS101_ASDU_getElement.
• Added the TLSConfiguration_setMaxCertificateSize function and an optional maximum certificate-size check during the TLS handshake.
• Fixed the BufferFrame implementation
  (LIB8705-313).

Other Bug Fixes

The release also resolves the following functional and stability issues:

• Fixed a CS104 server issue where switching connections without stopping the old connection could cause retransmissions to be sent out of order over the new connection
  (LIB8705-283).
• Fixed a potential deadlock in the CS104 server thread.
• Fixed a potential memory leak during TLS renegotiation when the peer certificate must be stored.
• Corrected the Cause of Transmission used by the CS101/104 client and master when sending a read command
  (LIB8705-270).

Important Compatibility Notice

Customers using the secure authentication module must update it to the latest version when upgrading to IEC 60870-5-101/104 2.4.1 to ensure compatibility.

Updating to Version 2.4.1

Commercial customers with an active Maintenance and Support agreement can obtain the new release through the MZ Automation customer portal or via the official GitHub.

Because this release addresses multiple reported vulnerabilities, we recommend reviewing existing deployments and planning the update as soon as possible.

More information and updates can be found on our other platforms:

YouTube: https://www.youtube.com/@MZAutomation2014

LinkedIn: https://www.linkedin.com/company/mz-automation-gmbh/