ICCP/TASE.2 protocol security, explained

ICCP grew out of the Electric Power Research Institute's Utility Communications Architecture (UCA) program in the early 1990s, when a Utility Communications Specification working group submitted the protocol to IEC Technical Committee 57, which standardized it as the IEC 60870-6 series. The core document, IEC 60870-6-503 ("TASE.2 Services and protocol"), is described by IEC as specifying "a method of exchanging time-critical control centre data through wide-area and local-area networks," with companion documents covering the functional profile (60870-6-702), the object models that define what data ICCP can carry (60870-6-802), and transport profiles (60870-6-601 and TS 60870-6-602). Unlike field-level protocols such as Modbus or DNP3, which typically run between a control center and field devices, ICCP's job is control-center-to-control-center: exchanging real-time measurements, control operations, scheduling and accounting data, and event notifications between utilities, regional transmission organizations, independent system operators and non-utility generators that otherwise have no reason to trust each other's networks.

ICCP's only native data-security mechanism is a bilateral table — a configuration object on each ICCP server that defines which specific data points a given remote peer is authorized to read or write. EPRI's own 2001 assessment is direct about the limits of that mechanism: "ICCP provides access control via bilateral tables maintained on an ICCP server. This is the only data security service provided within ICCP." There is no protocol-level encryption and no cryptographic authentication of the peer at the other end of the link. Idaho National Laboratory's 2008 common-vulnerabilities report for control systems warned that "unencrypted ICCP communication... may provide many opportunities for an attacker to intercept, understand, and alter the data," and a decade later Pacific Northwest National Laboratory's PNNL-26729 (2017) assessment called ICCP "an unprotected protocol" exposed to integrity violation, interception or alteration, spoofing and eavesdropping by anyone able to reach the link.

The fix exists on paper: IEC 62351-4 ("Profiles including MMS") defines security profiles specifically for ICCP and IEC 61850, layering the TLS-based transport security specified generically in IEC 62351-3 on top of the base protocol, along with certificate-based mutual authentication — an implementation the industry calls "Secure ICCP." Sandia National Laboratories documented early Secure ICCP integration work as far back as 2007 (SAND2007-3345). Yet PNNL's 2017 assessment still described Secure ICCP as "rarely implemented if at all," and NERC's own January 2026 Critical Infrastructure Protection Roadmap confirms the gap hasn't closed at the industry level, stating plainly that "legacy protocols, such as DNP3, ICCP, and Modbus often traverse unencrypted links that fall outside the current CIP-012 scope." In other words, the standards-based mitigation has existed for roughly two decades without becoming the default.

Public vulnerability records for ICCP are implementation bugs, not protocol flaws. CISA has published several ICS advisories for specific vendors' ICCP stacks — ICSA-22-249-01 (CVE-2022-38138) against Triangle Microworks' IEC 60870-6/ICCP/TASE.2 library, ICSA-13-240-01 against Triangle MicroWorks' SCADA Data Gateway, and ICSA-22-272-01 / ICSA-23-059-02 against Hitachi Energy's ICCP stack — all denial-of-service or memory-corruption issues in a particular vendor's code rather than a weakness in the IEC 60870-6 specification itself. No publicly documented real-world cyberattack has been attributed to exploiting ICCP specifically: the public technical reports on the 2015 Ukraine grid attack and the CRASHOVERRIDE/Industroyer malware describe other protocols and attack paths, not ICCP. The protocol's documented risk profile is structural — a 30-year-old control-center link with no mandatory encryption — rather than a track record of confirmed breaches through it.

No current NERC CIP standard names ICCP explicitly. CIP-005-7 (Electronic Security Perimeter) and CIP-006-6 (Physical Security) regulate any routable connection generically through External Routable Connectivity and Electronic Access Point requirements, and CIP-012-1 — the standard that specifically governs communications between control centers, ICCP's actual use case — likewise contains no reference to the protocol by name. ICCP is, however, called out explicitly in non-binding NERC guidance, including the CIPC's "Security Guidelines for the Electricity Sector: Control System Electronic Connectivity" and the 2026 CIP Roadmap cited above, both of which treat ICCP links between separate trust domains as needing perimeter protection even though the mandatory standards are written protocol-agnostically.

SoftWSP's OT network assessments passively identify which protocols — ICCP included — are actually carrying control-center traffic across a facility's or utility's network segment, whether Secure ICCP's TLS extension is actually in use, and where unmanaged or unencrypted links create risk, without requiring any agent installed on existing control-center equipment. See OT Snapshot for how that passive read works.

This guide is based on the IEC 60870-6-503 publication page, EPRI's and the national labs' (INL, PNNL, Sandia) own technical reports on ICCP security, CISA's published ICS advisories, NERC's current CIP-005-7/CIP-006-6/CIP-012-1 standard text and its January 2026 CIP Roadmap, all fetched or read directly for this guide. It is not a substitute for a current NERC CIP compliance review and does not constitute a penetration-test report against any specific ICCP deployment.