ICCP TASE.2 post-quantum encryption: how to protect links

ICCP TASE.2 post-quantum encryption means protecting inter-control-centre links that run IEC 60870-6-503 with key exchange that resists quantum computers, usually hybrid ML-KEM (FIPS 203) combined with a classical algorithm. It matters because Secure ICCP today depends on classical TLS key exchange, and recorded sessions could be decrypted years later.

Transmission operators, reliability coordinators, generators and neighbouring utilities exchange ICCP data continuously, often over the same links for decades. This article explains where that exposure sits, what IEC 62351-4 can and cannot do today, and how to choose between upgrading native TLS and adding an encryption gateway.

Is ICCP TASE.2 traffic between control centres vulnerable to harvest now, decrypt later?

Yes, both plain and TLS-protected ICCP is exposed. If the traffic is recorded today, it can be decrypted once a cryptographically relevant quantum computer exists, because the session keys were agreed with RSA or elliptic-curve Diffie-Hellman.

ICCP is an application protocol, not a transport. TASE.2 covers services and protocols (IEC 60870-6-503), a functional profile for application service in end systems (IEC 60870-6-702), and object models (IEC 60870-6-802), and TASE.2 heavily relies on Manufacturing Message Specification (MMS). Many links still run MMS over the ISO transport on TCP with no encryption, relying on private circuits or MPLS for separation. Those links have no protection against recording at all.

Links that use Secure ICCP are better protected against today’s adversaries, but the threat model is different with quantum computers. Mosca formalised the HNDL risk as follows: if an adversary intercepts encrypted data today and a CRQC becomes operational before the data loses sensitivity, the data is compromised. The bulk ciphers used in TLS are not the weak point. The handshake is: a recorded RSA or ECDHE exchange is what a future quantum computer would attack to recover the session key.

Inter-utility links make good recording targets. They cross carrier networks, peering points and sometimes the public internet. They use well-known protocol signatures. They also stay in service for very long periods, so one tap point can capture years of traffic.

What ICCP data exchanged between utilities needs long-term confidentiality?

Real-time analogue values age quickly, but much of what travels over ICCP stays sensitive for a decade or longer. That includes schedules, outage plans, transfer accounts, network topology and the bilateral tables themselves. Because one session key protects everything on an association, the link needs to be protected for its most long-lived content.

ICCP functionality is grouped into conformance blocks, and the blocks a link uses largely decide its confidentiality horizon. Operators should map their bilateral tables against this rough classification:

How does IEC 62351-4 secure ICCP and can it use hybrid ML-KEM?

IEC 62351-4 secures MMS-based protocols, including ICCP, with a transport profile that uses TLS as defined in IEC 62351-3 and with application-level authentication. Its published TLS profiles specify classical key exchange. Hybrid ML-KEM is technically compatible with the TLS 1.3 path, but it is not yet a standardised option in the profiles.

The two layers of Secure ICCP

The IEC 62351 family provides security mechanisms for energy-sector protocols including IEC 60870-6 (ICCP for inter-control center communication). For MMS, IEC 62351-4 defines a transport profile (T-profile), where the ISO transport runs inside TLS, and an application profile (A-profile), which carries peer authentication in the association setup. Later editions also add an end-to-end application-layer security option. At the lower layers, the standard defines how to wrap protocols within TLS 1.2 or higher (with TLS 1.3 support added in the 2022 revision).

IEC 62351-3 constrains the TLS profile itself: cipher suites, mandatory mutual certificate authentication, certificate revocation handling and session key renegotiation. Authentication relies on an X.509 PKI, typically one that is shared or cross-certified between the two operators.

Where hybrid ML-KEM fits

ML-KEM replaces the key agreement step and leaves the rest of TLS unchanged. FIPS 203 standardizes ML-KEM, a lattice-based key encapsulation mechanism intended to serve as a PQ alternative to the key agreement functionality of classical Diffie-Hellman. In TLS 1.3, hybrid groups combine ML-KEM with an elliptic-curve exchange, so the session stays secure as long as either component holds. NIST is cautious about the new algorithm, stating: “At present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.” That caution is the main reason to use hybrid mode rather than pure ML-KEM on critical links.

There are two limits. First, hybrid key exchange in TLS is defined for TLS 1.3, and many Secure ICCP deployments still run TLS 1.2 profiles. Second, an implementation that adds a key exchange group not listed in the IEC 62351-3 edition it claims to follow is stepping outside its tested profile. Interoperability testing between partners then becomes the operator’s responsibility.

Can existing Secure ICCP implementations be upgraded to post-quantum TLS?

Sometimes, but rarely by configuration alone. An upgrade needs TLS 1.3 and hybrid ML-KEM support in the cryptographic library inside the ICCP or MMS stack, a vendor release that exposes it, and the same change on the partner’s side of every bilateral link.

When assessing an existing installation, the questions that decide feasibility are:

• Where the TLS code comes from. Some ICCP servers link a general-purpose TLS library that can be updated. Others embed a certified or frozen stack that only the vendor can change, often on a multi-year release cycle tied to the energy management system.
• The protocol version. A TLS 1.2-only stack needs a move to TLS 1.3 first. This affects renegotiation behaviour, which IEC 62351-3 treats in detail, so the change is more than a library swap.
• Who is on the other end. Hybrid key exchange only takes effect if both peers support the same group. A transmission operator with dozens of ICCP partners will run mixed classical and hybrid links for years.
• Validation and change control. Changes to the ICCP server in a control centre usually need factory or site acceptance testing. Each regression test cycle adds months.
• Certificates. Hybrid key exchange can be added while keeping RSA or ECDSA certificates, because harvest now, decrypt later threatens confidentiality and not authentication. Post-quantum certificates (ML-DSA) can be a later phase, but the PKI should be planned now.

The cybersecurity products, services, and protocols will need updates, and organizations must identify where vulnerable algorithms are used and plan to replace or update them. For ICCP, that inventory has to cover every association listed in every bilateral agreement, not only the servers themselves.

Should ICCP links be protected with an encryption gateway or native TLS?

Native TLS gives end-to-end protection that follows the standard but depends on vendor roadmaps and on both partners. A network-layer encryption gateway can add hybrid post-quantum key exchange to a link now, without touching the ICCP servers. Many operators will layer the two rather than choose one.

The layered design works like this: keep or introduce IEC 62351-4 TLS inside, so the ICCP peers still authenticate each other, and run that traffic through a post-quantum tunnel between sites. A recording of the outer tunnel then gives a future quantum attacker nothing to work with, even if the inner TLS stays classical until the vendor catches up.

As one example of the gateway approach, QPN encrypts at Layer 3 with hybrid key agreement, combining a classical part with ML-KEM into one session key and renewing both handshakes every two minutes. It sits next to existing firewalls and routers, and no software is installed on the equipment behind it. Gateways like this protect data in transit only. They do not replace the firewall, ICCP-aware monitoring or endpoint hardening in the control centre.

When do ICCP operators need post-quantum key exchange?

Long-lived ICCP data needs it now. Regulators and standards bodies are converging on deadlines between 2030 and 2035, and ICCP links stay in service far longer than typical IT systems. NIST puts it directly: “Organizations should treat the migration to PQC as a current operational priority”.

NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035. Executive Order 14412 accelerated this timeline, requiring federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures. Utilities are not federal agencies, but their ICCP vendors serve both markets and will plan around these dates.

In North America, NERC CIP-012-1 requires Responsible Entities to mitigate the risk of unauthorized disclosure and modification of Real-time Assessment and Real-time monitoring data transmitted between Control Centres. It does not prescribe algorithms, so whether quantum resistance belongs in that plan is an internal risk decision. The ICCP data most exposed to harvest now, decrypt later (schedules, outage plans, Block 8 objects) often falls partly outside that defined scope anyway.

What does a practical migration plan for ICCP links look like?

Start with an inventory of associations and data, protect the most exposed links at the network layer, and line up native hybrid TLS with partner and vendor release cycles. The steps below fit around typical control-centre change windows.

1. List every ICCP association. Record the partner, transport path (private circuit, MPLS, internet), current security (none, TLS 1.2, TLS 1.3) and the conformance blocks used.
2. Classify each link by confidentiality horizon. Use the bilateral table, not the link name. Links that carry Block 8 objects or full model exchanges go first.
3. Close plaintext gaps. Unencrypted links over shared carriers are the most urgent. A post-quantum tunnel between sites can protect them while the Secure ICCP project is planned.
4. Ask vendors specific questions. Ask about TLS 1.3, which hybrid ML-KEM groups are supported, which FIPS 203 parameter sets, and how the change will be validated against IEC 62351-3 profiles.
5. Coordinate bilaterally. Add post-quantum readiness to the bilateral agreement and certificate-exchange process, the same way cipher suites and certificate authorities are already agreed.
6. Plan signatures separately. Schedule ML-DSA certificates and PKI changes as a second phase, before the 2035 disallowance.

For links that run over the public internet or need to work during carrier outages, check how any tunnelling layer behaves when the link fails. QPN, for example, never falls back to unencrypted traffic and retries automatically after a line failure. That is the behaviour a control-centre link needs: it should fail closed and recover without manual intervention.