Post-quantum encryption for railway signalling: what to know

Post-quantum encryption for railway signalling means protecting the links that carry interlocking, train control, traction power SCADA and maintenance traffic with key exchange that stays secure against a future cryptographically relevant quantum computer. The goal is to do this without touching the EN 50159 safety layer or its timing guarantees.

Rail sits in an awkward position. Signalling is certified against CENELEC safety standards built around long asset lifecycles. Meanwhile the networks underneath, such as IP backhaul, leased lines, public carriers and cloud-hosted maintenance tools, keep changing. This article explains where the quantum risk actually sits and how the standards that already govern rail communication shape a post-quantum migration.

Are railway signalling and traction power SCADA links at risk from quantum computers?

Yes, but not evenly. The direct risk is to public-key cryptography (RSA, Diffie-Hellman, elliptic curves) used for key exchange, certificates and remote access around rail OT. Symmetric safety codes are much less exposed.

Signalling and train control

ETCS illustrates the split. UNISIG’s specifications state that data transmission links implemented over open transmission systems are inherently vulnerable as unauthorised access cannot be excluded, so it is important to guarantee the integrity and authentication of messages sent over a non-trusted transmission medium, and ERTMS/ETCS applications use cryptographic techniques with secret keys to achieve this. Shor’s algorithm does not break secret-key MACs. A quantum computer would still threaten what surrounds them: certificate-based online key management, VPNs between radio block centres and control centres, and engineering access to interlockings.

Traction power SCADA

Traction substations are often supervised over IEC 60870-5-104 or similar protocols. These have no native encryption, so protection depends entirely on the conduit. Here the main concern is “harvest now, decrypt later”: traffic recorded today could be decrypted once a quantum computer exists. Topology, addressing and credentials captured on an open link keep their value for years. Rail assets also stay in service a long time. As Fabiana Da Pieve of the European Commission put it, “devices deployed today remain in the field for decades”.

The threat context is not hypothetical:

• The transport sector accounted for 8% of events with significant impact reported under the NIS2 Directive in 2025 (ENISA Threat Landscape 2026, September 2026).
• In ENISA’s 2025 dataset, targeting was concentrated on railway (31.9%) and air (30.4%) (ENISA, September 2026).
• Ransomware attacks on transport almost doubled, rising from 13% in 2021 to 25% in 2022 (ENISA, March 2023).

ENISA also notes that railway and maritime transport are categorised as being in the risk zone, notably due to their reliance on heterogenous systems.

How does EN 50159 relate to encrypting rail communication over open networks?

EN 50159 is a safety standard, not a security standard. It defines how safety-related equipment detects corrupted, repeated, delayed or masqueraded messages, and it assumes that open networks may be attacked.

EN 50159 sorts transmission systems into three categories. Category 3 covers open networks where unauthorised access cannot be ruled out. UNISIG describes it as the category having the highest safety risk. ETCS was designed for exactly this case: communication over a Category 3 [EN-50159] open transmission system is protected through an identification and authentication dialogue followed by MAC-protected messages.

The standard lists seven threats: repetition, deletion, insertion, resequencing, corruption, delay and masquerade. It answers them with defences such as sequence numbers, timestamps, time-outs, source and destination identifiers, safety codes and cryptographic techniques. A post-quantum tunnel underneath the safety layer adds confidentiality and an extra integrity check. It does not replace any of these defences.

How does CLC/TS 50701 apply IEC 62443 zones and conduits to rail encryption?

CLC/TS 50701 brings the IEC 62443 zone and conduit model into the railway lifecycle. Encryption belongs on the conduits, meaning the communication paths between zones, and its required strength follows from each zone’s target security level.

The specification was developed by CENELEC TC9X WG 26. It is based on different sources: IEC 62443 (SL vector, risk assessment, cybersecurity requirements), EN 50126 (life-cycle, threat log, cybersecurity case, SecRACs), CSM-RA (risk acceptance principles), and it is being developed into an international standard. EU-Rail’s System Pillar notes that SecRACs are defined in TS 50701 (draft: IEC 63452).

ENISA’s railway zoning guidance turns this into concrete steps. One of them is to assign a minimum-security level target (SL-T) to each security zone. In practice, post-quantum encryption fits in as follows:

• Map the conduits that leave a trusted boundary. Examples are interlocking to control centre over carrier IP, substation RTU to SCADA master, and vendor remote access. Each one is a candidate for a quantum-safe tunnel.
• Write the cryptographic requirement into the conduit specification, not into the safety component. That way algorithms can be updated without reopening the safety approval.
• Record crypto-agility as a SecRAC. The equipment behind the conduit should not have to change when the post-quantum algorithm does.

Researchers working on Deutsche Bahn’s interlocking architecture point out that in contrast to the zones, IEC 62443-3-3 does not contain guidance on how to secure conduits. This gap makes an explicit conduit-level cryptographic policy important.

Can post-quantum VPN tunnels meet safety-related latency requirements in rail?

Generally yes, as long as the design keeps the post-quantum cost out of the per-packet path. ML-KEM key agreement happens at session setup and re-key. Once a session is running, packets are protected with symmetric ciphers whose cost does not change with a post-quantum handshake.

The latency risk in rail comes less from average delay and more from three edge cases that interact with EN 50159 time-outs:

• Re-key behaviour. If traffic stalls while the tunnel renegotiates keys, the safety layer may see it as a delay threat and drop the connection to a safe state. Check that rekeying does not interrupt traffic on the data path.
• Packet size. Post-quantum public keys and ciphertexts are kilobyte-scale. On narrowband radio or older backhaul this can cause fragmentation during the handshake. Test with the real MTU of each bearer.
• Recovery after a line failure. Tunnel re-establishment should finish well within the window in which the safety application tries to reconnect. Otherwise a short outage can turn into a longer operational disruption.

One example of how a gateway can handle this: Quantum Network’s QPN gateway uses a hybrid key agreement that combines a classical part with ML-KEM (FIPS 203) into one session key. Both handshakes renew every two minutes, payload is encrypted with ChaCha20-Poly1305, and every packet is checked with a Poly1305 tag. The connection never falls back to unencrypted traffic, and it retries automatically after a line failure. Whichever gateway is used, latency should be measured on the actual route under load and checked against each application’s safety time-outs, not taken from a datasheet.

What do NIS2 and the EU PQC roadmap require of rail infrastructure managers?

NIS2 imposes binding risk-management and reporting duties. The EU PQC roadmap sets a coordinated migration timetable that Member States are expected to turn into national plans. Together they make quantum-safe protection of rail OT links a planning matter for this decade.

The NIS2 Directive (EU) 2022/2555 lists rail infrastructure managers and railway undertakings in Annex I under transport. Article 21(2)(h) requires policies and procedures on cryptography and, where appropriate, encryption. Article 23 sets staged incident reporting deadlines. According to ENISA, 73% of the targeted organisations are essential and important entities as per the NIS2 definition (ENISA Threat Landscape 2026).

The EU Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography builds on Commission Recommendation (EU) 2024/1101. The EU Member States, supported by the Commission, adopted the Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography in June 2025. Transport is named explicitly among the high-risk use cases.

The roadmap also recommends hybrid and crypto-agile approaches. The Commission’s guidance stresses that traditional schemes must NOT be weakened along the way. Outside the EU, NIST takes a parallel line: under the transition timeline in NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier. That matters for suppliers and for equipment certified against US cryptographic standards.

How should a rail operator sequence a post-quantum migration?

Start with the conduits that cross open or third-party networks and carry long-lived or control-critical data. Then move inward. Leave certified safety components alone until their regular renewal cycle.

1. Inventory by conduit, not by device. For each CLC/TS 50701 conduit, record the transport (carrier IP, public internet, private fibre, radio), the key exchange used and who manages the keys.
2. Rank by exposure and shelf life. Interlocking-to-control-centre links over carrier networks, traction SCADA backhaul and vendor remote access usually come first.
3. Add quantum-safe tunnels at conduit boundaries. Gateways that encrypt at Layer 3 protect legacy protocols without installing software on certified equipment. Decide per path whether the tunnel sits in front of or behind the existing firewall, depending on whether that firewall still needs to inspect the traffic. This is the deployment model Quantum Network’s QPN follows: it sits alongside existing firewalls and routers.
4. Test against safety time-outs. Include re-key, failover and degraded-bearer scenarios in factory and site acceptance tests.
5. Plan for algorithm change. Make sure update channels work in air-gapped and isolated signalling networks, and that changing the post-quantum algorithm does not require a new safety approval.

A tunnel protects data in transit only. It does not harden the interlocking, RTU or engineering workstation behind it, and it is no defence against denial-of-service attacks on the bearer. Those controls stay within the wider IEC 62443 programme that CLC/TS 50701 already requires.