Cyber Security for IEC Protocols Series Part 3: Securing IEC 61850 and MMS

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.

IEC 60870-5-101/104 Version 2.4.1 Released: Important Security and Stability Update

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/

Cyber Security for IEC Protocols Series Part 2

Securing IEC 60870-5-101 and IEC 60870-5-104

A Technical Exploration of Threats, Countermeasures, and IEC 62351-5 Implementation for Telecontrol Protocols

Abstract

IEC 60870-5-101 and IEC 60870-5-104 are foundational telecontrol protocols used extensively in power system SCADA environments. Originally designed in an era with limited cybersecurity awareness, these protocols rely on open serial and IP-based communication, making them highly susceptible to a range of cyber threats including message injection, spoofing, replay, and denial-of-service (DoS) attacks.

This article provides a comprehensive examination of the cybersecurity challenges associated with IEC 60870-5-101 and 104. It delves into the structure and operation of both protocols, outlines their inherent vulnerabilities, and introduces the security architecture defined in IEC 62351-5. We explore the cryptographic mechanisms, authentication models, replay protection, implementation recommendations, and performance considerations in depth, offering practical recommendations for enhancing protocol-level security in real-world SCADA systems.

Introduction

In many national and regional grid infrastructures, IEC 60870-5-101 (serial) and IEC 60870-5-104 (TCP/IP) continue to serve as critical communication standards for telemetry and remote control. Their longevity, simplicity, and interoperability have made them a favored choice in Europe, Asia, and parts of the Middle East.

However, this operational ubiquity has also become a cybersecurity liability. Neither protocol was designed with built-in security—no encryption, no authentication, and no integrity checks. This lack of protection enables attackers with access to the network (or even to serial lines in substations) to intercept or manipulate traffic, falsify commands, or disrupt operations.

To address these gaps, IEC 62351-5 was created as a security extension primarily targeting the IEC 60870-5-101/104 protocol family, but its mechanisms have also been adopted by other protocols, most notably DNP3, which references it and provides protocol-specific adaptations for secure authentication. It defines mechanisms for ensuring message integrity, origin authentication, and optional confidentiality features. These enhancements are designed to be retrofitted into existing deployments or natively supported by compliant devices.

Protocol Overview and Security Deficiencies

IEC 60870-5-101: Serial Telecontrol Communication

IEC 60870-5-101 operates over serial links (RS-232, RS-485), using a structured frame format for transmitting process information such as analog values, binary inputs, and control commands. While reliable in isolated environments, it lacks any mechanism for:

  • Detecting modification or tampering
  • Preventing eavesdropping
  • Defending against replay or injection

Attackers with physical access to cabling or serial terminal servers can inject control commands, disrupt remote terminal unit (RTU) responses, or spoof legitimate devices.

IEC 60870-5-104: TCP/IP-Based Communication

IEC 60870-5-104 transports the same Application Protocol Data Units (APDUs) over TCP/IP, enabling wide-area communication via Ethernet and IP networks. This increases exposure to modern cyberattack techniques such as:

  • Man-in-the-Middle (MITM) attacks via ARP spoofing or DNS hijacking
  • TCP session hijacking or injection
  • Reconnaissance and fingerprinting of RTUs and master stations
  • Unencrypted credentials for user-level authentication in some extensions

Without encryption or message-level protection, all traffic, including critical controls, is susceptible to interception and manipulation.

Security Enhancements in IEC 62351-5

IEC 62351-5 introduces a security layer for 101/104 based on cryptographic Message Authentication Codes (MACs), replay detection, and optional confidentiality features. These enhancements are designed to be retrofitted into existing deployments or natively supported by compliant devices.

Secure Frame Format

IEC 62351-5 defines a secure APDU format that wraps the original 101/104 message in a security envelope. This envelope includes:

  • Security Header: Identifies the sender and includes a security control field
  • MAC Field: Contains a cryptographic checksum calculated over the message and header using a shared secret or certificate-based key
  • Optional Encryption: Symmetric encryption may be applied to the entire payload using AES (Advanced Encryption Standard), depending on use case

Message Integrity and Origin Authentication

Each message is cryptographically signed using a MAC algorithm such as HMAC-SHA256, ensuring that any tampering or forgery will be detected by the recipient. Origin authentication is achieved because only trusted peers possess the keys needed to compute valid MACs.

Replay Protection via Sequence Numbers

Replay attacks are mitigated using a monotonic counter fields embedded in the security header. Each valid message must have a higher sequence number than the last accepted message. Implementations must persist these counters across reboots to avoid reuse of old messages.

Key Management and Cryptographic Agility

IEC 62351-5 supports multiple key management models:

  • Static shared secrets: Suitable for small deployments with manual provisioning
  • X.509 Certificates and PKI: Recommended for scalable and secure deployments

A-Profile and T-Profile Security: TLS vs Application Layer Authentication

The security framework for IEC 60870-5-101/104 is formally defined by two complementary standards:

  • IEC 62351-5, which specifies generic message authentication using HMAC and session keys
  • IEC 60870-5-7, which details protocol-specific adaptations (e.g., ASDU types and message segmentation)

Security mechanisms can be grouped into two profiles:

  • T-profile security refers to the use of TLS (Transport Layer Security), defined in IEC 62351-3, to secure CS 104 at the transport layer
  • A-profile security refers to application layer message authentication, as standardized in IEC 60870-5-7 and supported in IEC 62351-5

T-profile provides confidentiality and authentication at the transport level (TCP/IP), while A-profile secures individual IEC messages (ASDUs), making it applicable to both CS 101 and CS 104, even in serial or hybrid environments.

Message Authentication and HMAC Usage

A-profile security uses HMAC (Hash-based Message Authentication Codes) to ensure message authenticity and integrity. The HMAC is calculated over critical application data using a secret session key shared between the sender and receiver. This ensures that only trusted endpoints can validate and accept critical messages (e.g., control commands).

Key features:

  • Different session keys are used per direction (monitoring vs control)
  • Session keys are updated periodically and exchanged over the same channel using a symmetric update key
  • Non-critical messages may remain unauthenticated for performance reasons

Challenge/Reply and Aggressive Mode Authentication

A-profile supports two authentication modes:

  • Challenge/Reply (two-pass): Used when a device needs to verify a received critical message. The device issues a challenge, and the sender replies with an HMAC based on the message and challenge data.
  • Aggressive Mode (one-pass): Faster unilateral method that appends an HMAC directly to the message. It requires an initial challenge/reply exchange to initialize shared challenge data.

Both modes aim to minimize bandwidth while maintaining trust, with Aggressive Mode favored in time-sensitive environments like CS 101-based control loops. Under normal circumstances communication goes into aggressive mode after the first challenge/reply cycle. The challenge/reply cycle has to be done immediately after a session key change.

IEC 60870-5-7: Protocol Adaptation and ASDU Mapping

IEC 60870-5-7 provides the protocol-specific mappings required to implement A-profile security in CS 101 and 104:

  • Defines new security ASDUs (e.g., S_CH_NA_1 for Challenge, S_AR_NA_1 for Aggressive Reply)
  • Introduces segmentation fields for security messages exceeding maximum ASDU size
  • Maps security states and transitions into the IEC 60870-5 finite state model

These definitions allow security messages to coexist with legacy protocols without breaking interoperability.

Edition Differences: 2013 vs 2023/2025

Two editions of A-profile security are currently recognized:

  • Edition 1 (2013):
    • Introduced basic HMAC authentication supports multi-user sessions with individual keys
    • Optional RBAC via session-based user identities
  • Edition 2 (2023/2025) (Draft):
    • Adds optional encryption of application dataEnforces single-user sessions for stricter controlIncorporates RBAC from IEC 62351-8 with defined role-permission mappingsIncompatible ASDU types vs Edition 1 (non-interoperable)
    • Multicast support for CS 101 unbalanced modes

Deployment Considerations and Performance Impact

Retrofits vs Native Support

Legacy RTUs and IEDs often lack the computational power or memory to process cryptographic functions. To mitigate this:

  • Security proxies or bump-in-the-wire devices can be used to offload security processing
  • Gateway appliances can act as secure concentrators, handling key management and enforcing policies

New devices should ideally support native 62351-5 capabilities, including MAC generation/verification, counter persistence, and cryptographic configuration.

Real-Time Constraints

The introduction of cryptographic operations must not violate the real-time characteristics of SCADA systems. IEC 62351-5 therefore emphasizes:

  • Low-latency MAC algorithms (e.g., HMAC with hardware acceleration)
  • Deterministic execution times
  • Offloading security processing to non-blocking threads or hardware modules

Compatibility and Interoperability

All security mechanisms are optional and must be negotiated between peers. Backward compatibility with unsecured devices must be explicitly managed:

  • Security Profiles define which features are enabled for each connection
  • Systems may operate in mixed mode, allowing secure and non-secure peers to coexist

Integration with TLS and Network Layer Security

While IEC 62351-5 provides application-layer protection, IEC 62351-3 complements it by specifying TLS as the preferred transport layer security mechanism for IEC 60870-5-104. Key integration points include:

  • TLS Mutual Authentication using certificates
  • Encrypted TCP channels
  • Fallback modes for non-TLS peers

TLS ensures confidentiality and connection integrity, while IEC 62351-5 ensures message-level authenticity and replay protection. For maximum security, both should be implemented in tandem.

Testing, Validation, and Compliance

IEC 62351-5-compliant systems must be rigorously tested for:

  • MAC validation and rejection of forged frames
  • Replay detection under attack conditions
  • Key rollover and certificate revocation support
  • Latency and jitter impact on SCADA timing
  • Interoperability between vendors

Certification programs and third-party security evaluations are encouraged to ensure robustness across heterogeneous deployments.

Summary and Best Practices

Securing IEC 60870-5-101/104 is a critical priority for utilities relying on legacy telecontrol infrastructure. IEC 62351-5 provides a flexible yet rigorous framework for message integrity, origin authentication, and replay protection. Key recommendations include:

  • Use TLS where possible for 104-based communication
  • Deploy MAC-based authentication and replay counters as per 62351-5
  • Implement gateway-based security when end devices cannot support cryptography
  • Use certificate-based key management for scalable trust models
  • Regularly update security policies and validate implementation conformance

Conclusion

IEC 62351-5 bridges the gap between legacy telecontrol protocols and modern cybersecurity requirements. Through its well-defined message authentication, replay protection, and key management frameworks, it offers a path to secure even the most entrenched SCADA systems. By embracing these standards, utilities can significantly reduce the attack surface of their operational networks while maintaining real-time performance and compatibility.

Looking Forward

In the next part of this series, we will explore Security for IEC 61850/MMS, a client-server protocol at the heart of digital substations, and how IEC 62351-4 brings critical protections to the foundation of substation automation.

IEC 61850 Protocol Library v1.6.1 Now Available

We at MZ Automation are happy to announce we have just released an update of our IEC 61850 Protocol Library. This update includes multiple enhancements across client connection handling, Sampled Values Control Block support, and many more updated in the .NET API, making it even easier for engineers and system integrators to build robust, interoperable solutions for substation automation and related energy applications.

What’s New in IEC 61850 Library v1.6.1?

Enhanced Client Connection Management

  • ClientConnection_abort: Allows a server application to actively terminate a client connection.
  • ClientConnection_claimOwnership and ClientConnection_release: Enable programmatic access to client connections outside of standard callback functions. (LIB61850-488)

Extended .NET API for IEC 61850

  • Support for SVControlBlock: Enables configuration and handling of Sampled Value messages in .NET-based systems.
  • RBAC-ready access control: New callback interfaces allow custom restrictions on external access to the IEC 61850 data model—critical for role-based access control.
  • LogStorage function wrapper added for server-side logging via the IEC61850ServerAPI.
  • MMS Data Encoding/Decoding: Functions MmsValue_encodeMmsData and MmsValue_decodeMmsData allow direct handling of MMS binary content.
  • TLS enhancements: TLS-related functions added to improve secure communication. (LIB61850-486)
  • Server Log Service support now available via the .NET API. (LIB61850-461)
  • Improved data model representation: MmsVariableSpecification class extended with additional properties. (LIB61850-460)
  • Resolved logging issue in example projects log_client and log_server.

Improved IEC 61850 Engineering Tools

  • New .NET Tools: Static and dynamic model generation tools are now available in .NET (Java versions still included for compatibility).
  • SCLParser: Now available as a standalone tool—load and parse SCL (Substation Configuration Language) models for direct use with the library.
  • MmsError_toString function added to simplify MMS error handling. (LIB61850-423)
  • Sampled Values (SV) Publisher Update
  • Added support for the optional gmIdentity field in SV messages for improved interoperability with time synchronization sources.

Version 1.6.1 is available to all customers with an active maintenance and service contract.

Please feel free to contact our sales team directly if you have any questions about this update or any of our other products.

ICCP/TASE.2 Library: New Release Brings Security and Runtime Flexibility

We are proud to announce the latest release of the ICCP/TASE.2 Library, featuring a broad set of improvements in security, runtime configuration, interoperability, and developer usability. This update ensures compliance with modern security protocols, improved flexibility in system design, and easier integration across platforms like Java and .NET.

Whether you’re modernizing an existing control system or developing a new one from scratch, this release provides the tools you need to build secure, efficient, and interoperable applications using the TASE.2 standard.

Customers with an active maintenance and service subscription can download the latest update from our customer portal. If you need assistance with accessing your account, please get in touch with our support team.

Highlights of Version 2.4.0

ICCP/TASE.2 Library Enhancements to Dataset Transfer Sets
The library now allows both objectChange and intervalTimeout to be used simultaneously when bufferTime is set to 0. This enhancement provides more accurate and flexible dataset reporting—especially valuable in systems requiring near real-time updates without delay buffering.

Configurable Outstanding MMS Calls for ICCP/TASE.2 Client
A new function, Tase2_Client_setMaxOutstandingCalls, has been added (LIBTASE2-1768). This allows developers to configure the maximum number of outstanding MMS calls on the client side, providing better traffic management and scalability for systems with higher communication loads.

.NET 7 Support for ICCP/TASE.2 Library
The library now includes updated project files compatible with .NET 7, allowing developers to build and integrate ICCP/TASE.2 applications within the latest Microsoft development environment.

Support for mbedtls 3.6 with TLS 1.2 and TLS 1.3
We’ve added support for mbedtls 3.6, which includes compatibility with both TLS 1.2 and TLS 1.3 (LILBTASE2-1744). This ensures that applications built with the ICCP/TASE.2 Library can meet modern security standards while maintaining high performance.

Legacy TLS Compatibility with mbedtls 2.28
For environments where older TLS versions are required, optional support for mbedtls 2.28 remains available. This allows users to maintain legacy connections while gradually transitioning to newer TLS versions.

Legacy STASE Security Support via ALSConfiguration
The update introduces support for STASE (A-profile security), which can now be configured using ALSConfiguration objects (LIBTASE2-1715). This ensures compatibility with older systems still requiring this type of legacy security while maintaining the flexibility to update in the future.

Runtime reconfiguration of TLS and ALS settings
TLS and ALS settings can now be updated during runtime. Rather than requiring an application restart, the configuration objects can be replaced dynamically, allowing administrators to update certificates, protocols, or ciphers on the fly. This offers significant operational flexibility, especially in live systems.

ICCP/TASE.2 Java API Enhancements
The Java API has been expanded with a wrapper for Tase2_Client_connectEx, giving developers greater control over client connection parameters. In addition, the update includes Java GUI example applications—a simple client and server—to help users get started more quickly with the Java interface of the ICCP/TASE.2 Library.

Transfer Set Structure Based on Server Version
The library now adapts the transfer set structure according to the TASE.2 version and edition of the server it’s communicating with (LIBTASE2-1741). This improves interoperability with servers running different versions of the protocol, making integration more seamless in heterogeneous environments.

Updated mbedtls Versions Included
This release includes:

  • mbedtls 2.28.10
  • mbedtls 3.6.3

These updated libraries ensure continued access to upstream security patches, better performance, and broader compatibility with modern systems.

Please feel free to visit our ICCP/TASE.2 Library product page for documentation, licensing, and support options.

iccp protocol iec 60870

Introducing lib60870 C#/.NET Version 2.3.0: Enhanced Functionality and Improved Performance

We are pleased to announce the release of lib60870 C#/.NET version 2.3.0, bringing significant improvements and new features to enhance performance, flexibility, and compliance with IEC 60870-5 standards. This update introduces enhanced redundancy options, expanded TLS support, and multiple refinements to communication behavior, ensuring a more robust and adaptable solution for our users.

Customers with an active maintenance and service subscription can download the latest update from our customer portal. If you need assistance with accessing your account, please contact our support team.

Key Updates in Version 2.3.0

Improved Compatibility and Flexibility

  • The library target has been updated to .NET Standard 2.0, increasing compatibility across different .NET environments.
  • Copy constructors have been added for message types in the monitoring direction to streamline data handling.
  • TLS version selection is now user-configurable, allowing for greater flexibility.
  • Support for TLS 1.3 has been added, ensuring compliance with the latest encryption standards.
  • The CS104 client now allows users to set the local IP address and TCP port, improving redundancy support.

Enhanced Performance and Fixes

  • CS101 slave: Improved behavior in unbalanced mode when the FCB bit did not change (L870NET-21).
  • CS104 server: Strengthened connection management with refined stop-state handling (L870NET-22).
  • CS104 server: Enhanced robustness by ensuring proper connection closure upon receiving an S message in an inactive state (L870NET-23).
  • CS101 balanced link layer: Improved synchronization by sending a request-status-of-link before calling reset-of-remote-link (L870NET-25).
  • CS101 unbalanced master: Fine-tuned response timing with a controlled delay before repeating request-status-of-link (L870NET-26).
  • CS104 slave: Strengthened validation with enhanced IOA checking of received commands where IOA is fixed to 0 (L870NET-28).
  • CS104 slave: Refined compliance with IEC 60870-5-604:2016-5.3.2.70 by optimizing STOPDT-ACT behavior (L870NET-29).

Advanced Features for Greater Control

  • Master connection states (Stopped, Started, and Unconfirmed Stopped) are now explicitly managed (L870NET-32).
  • The ASDU queue is now divided into high and low priority, ensuring that critical messages are processed efficiently (L870NET-33).
  • CS104 Client Connection State has been implemented for improved connection monitoring (L870NET-34).
  • Improved handling of normalized and scaled values with additional test cases to ensure reliability.
  • The file handler now verifies Cause of Transmission (COT) for FileTransfer operations, preventing misinterpretations.
  • Unconfirmed messages are now processed before stopping a connection, reducing potential data loss.
  • The ASDU queue has been refactored, ensuring smoother message prioritization and bug fixes in high-priority ASDU handling.

Upgrade Today!

This release strengthens lib60870 C#/.NET as a powerful and flexible solution for implementing IEC 60870-5-based communication. We encourage all users to upgrade to version 2.3.0 to take advantage of the latest enhancements and improved reliability.

For further details, technical documentation, and implementation guidance, please visit our website or reach out to our support team.

Announcing the Latest Update to Our IEC 60870-5 Library – Version 2.3.3

At MZ automation, we continuously strive to enhance the performance, reliability, and security of our products. We’re excited to announce the release of version 2.3.3 of our IEC 60870-5 library, packed with new features and critical fixes designed to meet the evolving needs of our customers.

What’s New in Version 2.3.3?

Advanced TLS Security Features

  • Support for TLS 1.3: When using mbedTLS 3.6, the library now supports the latest TLS 1.3 standard, ensuring the highest level of security.
  • Cipher Suite Selection: Users can now select specific TLS cipher suites, enabling tailored security configurations.

Protocol Enhancements

CS104 Slave Updates:

  • Commands with IOA fixed to 0 are now validated, addressing LIB8705-101.
  • Improved compliance with IEC 60870-5-604:2016 test case 5.3.2.70 (LIB8705-97) by ensuring S messages are sent only after receiving STOPDT-ACT when unconfirmed I messages are pending.
  • CS101 Slave in Unbalanced Mode: Updated behavior for the FCB bit to ensure correct operation (LIB8705-104).
  • Default Behavior Changes:
    • Support for C_TS_NA_1 in CS104 is now disabled by default, simplifying configurations.
  • Time Handling Improvements: Monotonic time is now used for timers when the platform supports it (LIB8705-87).

Stability and Performance Fixes

CS104 Connection Enhancements:

  • Resolved a potential deadlock issue when sending commands/ASDUs (LIB8705-52, #134).
  • Fixed a race condition where the connection could close unexpectedly if initiated by the peer (#147).
  • Resolved a lock-release issue in error cases (LIB8705-138).

CS104 Server Fixes:

  • Addressed invalid read errors during MasterConnection_deactivate calls (LIB8705-54).
  • Resolved server-side connection closures when receiving S messages in an inactive state (LIB8705-55).

Other Fixes:

  • Corrected initialization issues in StepCommand_create (I651CL-22).
  • Fixed test pattern issues for TestCommand (I651CL-25).
  • Resolved an issue where the k parameter from user configuration was not applied.
  • Enhanced handling of the pending unconfirmed stopped state (LIB8705-83).

Why Upgrade to Version 2.3.3?

This release represents a significant step forward in security, compliance, and stability. With support for TLS 1.3, customizable security settings, and critical bug fixes, version 2.3.3 ensures that your systems are not only reliable but also future-proof.

Whether you’re deploying IEC 60870 solutions in a mission-critical environment or optimizing communication across industrial systems, this update delivers the tools you need for success.

How to Get the Update

Existing customers with a valid Maintenance & Support (M&S) contract can download the latest version of the IEC 60870 library directly from our customer portal. If you’re not currently subscribed to M&S, please contact us to renew your contract and gain access to this and future updates.

We’re Here to Help

If you have questions about this update or need assistance with integration, don’t hesitate to reach out. At MZ automation, we’re committed to supporting your industrial automation needs.

Upcoming Release: IEC 61850 Server Simulator

We are thrilled to announce that in just a few weeks, MZ automation will be launching an innovative new tool for the IEC 61850 protocol: the IEC 61850 Server Simulator. This powerful tool is designed to streamline testing and development processes in environments that require precise control over Intelligent Electronic Device (IED) operations.

What Makes the IEC 61850 Server Simulator Stand Out?

  • Intuitive User Interface: Navigating the complexities of IEC 61850 has never been easier. The simulator features an intuitive graphical user interface (GUI) that simplifies the simulation of IEDs as servers. Whether you’re loading CID, ICD, SCD, or IID files, the GUI offers seamless management of Data Sets, Control Blocks, Data Objects, and more.
  • Dynamic Control and Monitoring: With real-time insights into server operations, the simulator gives you full control over simulations. You can make dynamic changes to data attributes and server parameters for precise testing and development, while easily monitoring connected clients, subscribed Report Controls, and managing server configurations.
  • Enhanced Testing Capabilities: The simulator allows you to streamline testing processes, from automating data attributes to managing write access configurations. Use the Group View feature for efficient monitoring of selected data attributes, and update DAI (data attribute information) in real-time using MMS communication with the Predefined Values Editor.
  • Comprehensive Server Management: Manage non-client IED servers with ease using the simulator’s robust Server Management interface. Set local IP addresses, manage TCP ports, and configure TLS for enhanced security. The Server Configuration Window enables optimization of server settings, including report buffer sizes, for greater control over server operations.

Why Choose MZ automation’s IEC 61850 Server Simulator?

At MZ automation GmbH, we are committed to providing easy-to-use, intuitive tools that help engineers succeed. The IEC 61850 Server Simulator is designed to support your company’s testing and development goals by making your processes more efficient and manageable. Whether you are ensuring protocol compliance, testing new configurations, or optimizing system performance, this simulator is your trusted companion.

Explore the capabilities of this powerful tool and see how it can enhance your operations. Stay tuned for the official release!

Introducing the IEC61850 ICD Designer – Now Available

We are excited to announce the release of the 61850 ICD Designer, the latest tool from MZ automation GmbH. This powerful software is designed to simplify the creation and management of Intelligent Electronic Device (IED) models, ensuring full compliance with the IEC 61850 standard.

Why Choose the 61850 ICD Designer?

Our 61850 ICD Designer has been crafted with the needs of modern engineers and technicians in mind. Its robust features and intuitive interface offer unmatched efficiency and reliability for all your IED configuration tasks.

Key Features and Benefits:

  • User-Friendly Interface: The tool’s modern, intuitive interface simplifies navigation and configuration. With drag-and-drop functionality, setting up your IED models is quick and seamless, reducing both time and effort.
  • Comprehensive File Management: Easily create, modify, and extend ICD and other SCL files. This flexibility gives you the tools needed to meet any project challenge.
  • Enhanced Data Type Template Management: Create and manage data type templates within the IEC61850 protocol. The tool supports adding and editing templates based on the NSD document version and revision, making it highly adaptable for various projects.
  • Advanced Error and Warning Messaging: The error and warning messaging system identifies potential issues, ensuring your models stay fully compliant with IEC61850 standards and minimizing the risk of costly mistakes.

Optimize Your IED Configuration Process

Built for both efficiency and reliability, the 61850 ICD Designer is the ideal tool for professionals looking to streamline their IED configuration processes. Whether you’re starting a new project or managing existing systems, this tool provides the advanced features and intuitive interface needed for success.

To learn more about the 61850 ICD Designer and how it can transform your operations, visit our company website.

Introducing IEC 61850 Library V1.6.0 – Now Available

We’re excited to announce the release of IEC 61850 Library V1.6.0, which brings several key improvements and new features aimed at enhancing functionality and security. This version has been developed to meet the latest standards, ensuring optimal performance and compliance.

Key Enhancements:

  • Reworked array handling: Every array element is now a separate ModelNode instance.
  • New access control features: Supporting IEC 62351-8 compliant Role-Based Access Control (RBAC).
  • TLS 1.3 support: Available when compiled with mbedtls 3.6, while mbedtls 2.28 can still be used.

New Features:

  • IED Server:
    • Additional callbacks for controlling external access to the data model (for RBAC implementation).
    • Write access handler for array elements (LIB61850-437).
    • New function: IedServer_handleWriteAccessForDataObject.
    • Retrieve the timestamp of received commands with ControlAction_getT (LIB61850-422).
    • Configuration options to make RCB elements read-only (LIB61850-404).
  • IED Client:
    • Added function: IedClientError_toString.
    • New asynchronous functions for handling RCB values: IedConnection_setRCBValuesAsync and IedConnection_getRCBValuesAsync (LIB61850-334).
  • Java Tools: Now support timestamp Val elements.
  • .NET API: Added SetReportSetting and GetReportSetting functions to IedServerConfig (LIB61850-404).

Security Enhancements:

  • TLS 1.3: Improved support, ensuring secure communication channels.

Additional Beta Features:

  • Support for R-GOOSE and R-SV.
  • SNTP client code.

Please note that IEC 61850 Library V1.6.0 is not backward compatible with previous versions. If you’re upgrading, you’ll need to regenerate static model code and adapt dynamically generated data models for the new array element structure.

If you prefer not to publish your own source code due to GPLv3 licensing requirements, a commercial license is available. Contact us via our company website for pricing and further details.

For a detailed overview of all the new features, changes, and technical information, visit the official release notes on our company website.