During a recent assessment exercise for a leading metro operator in India, I was able to observe many aspects of railway and metro cybersecurity up close. As with any other critical infrastructure, railways need to operate at a very unique level of security that takes into account operational vulnerabilities, threat landscape, OEM-related challenges and compliance mandates.

In 2026, the stakes aren't just about losing data (they never were, infact). Instead, they are about ensuring kinetic safety which means that a bit-flip in a SCADA system doesn't lead to a SPAD (Signal Passed at Danger). In today’s blog post we articulate a strategic framework for securing Railway OT while moving well beyond compliance into true resilience.

Before we move forward, don’t forget to check out our previous post on How EU Utilities Should Inventory Modbus and IEC-based PLCs here.

The Railway OT reality: Looking beyond the initial layers

Traditional IT sees security through the lens of CIA (Confidentiality, Integrity, Availability). In railway OT, we use RAMS (Reliability, Availability, Maintainability, Safety). If a security control (such as for instance, a firewall) causes a 200ms latency spike in an ETCS (European Train Control System) packet, it can trigger an emergency brake which is essentially a "fail-safe" mode. This could lead to some operational challenges that have to be dealt with on their own.   

Overlooked aspects and unique challenges associated with railway cybersecurity

• Geographic sprawl: Unlike a factory, rail assets are distributed over thousands of miles. A "Signaling House" in a remote area is a physical and digital entry point.

• Shadow OT: Maintenance crews often install unauthorized 4G/5G modems for remote diagnostics to avoid traveling to field sites. These bypass every perimeter defense.

• Protocol fragility: Legacy serial-to-IP converters and older protocols (like Profibus or unencrypted VHF) often crash if hit with a standard IT vulnerability scan.

• Supply chain challenges: With supply chains crisscrossing the globe, some of the supply chains branches could being in questionable geographies or may traverse them or the chains may themselves with vulnerable to supply chain poisoning

• OT security is an unattended detail

• Varying state of connectivity

Why institutional guardrails fail

Traditional IT-driven security programs typically fail in rail for three specific reasons:

• Philosophy bias: IT teams prioritize patching "high" CVEs. OT experts know that patching a 30-year-old interlocking is high-risk; we prefer Virtual Patching at the network edge. Further, IT security teams are not fluent in OT security.

• Active scanning pitfalls: Standard security tools use "Active Probing." On a rail network, this can flood a PLC (Programmable Logic Controller) and cause a "Freeze-in-State" failure.

• Governance silos: The CISO often speaks a different language than the RAMS Engineer. Without a "Safety-Security Sync," security measures are often vetoed by safety boards.

The TS 50701-based risk and security assessment

Let us now look at CLC/TS 50701, the gold standard for railway cybersecurity. Unlike generic frameworks, it integrates directly with the EN 50126 lifecycle.

Phase 1: System under Consideration (SuC)

We don't assess "the railway." We define specific SuCs that have unique attributes:

• On-board: TCMS (Train Control & Management System), PIS (Passenger Info).

• Trackside: Interlocking, Balises, RBC (Radio Block Center).

• Central: Traffic Management Systems (TMS), SCADA.

Phase 2: Zones and conduits

We map the environment into manageable "Security Zones" based on criticality.

• Zone 1 (Safety-Critical): Signalling & Interlocking (SL-4).

• Zone 2 (Operational): CCTV, PA systems (SL-2).

• Zone 3 (Public): Passenger Wi-Fi (SL-1).

Vulnerability and risk analysis

We use STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to evaluate each conduit.

The Implementation Roadmap (24-Month Strategy)

Supply chain Security: The "Bill of Materials" policy

You are only as secure as your weakest vendor. Our supply chain policy now mandates:

• SBOM (Software Bill of Materials): Vendors must provide a machine-readable list of every library in their code.

• HBOM (Hardware Bill of Materials): Identifies the origin of physical chips and components to mitigate "Backdoor" risks.

• VEX (Vulnerability Exploitability eXchange): Instead of just listing CVEs, vendors must provide VEX files stating if a vulnerability is actually exploitable in the rail context.

Justifying the economics: Reducing per-passenger cybersecurity and kinetic risk

In rail, we justify spending through a Fatalities and Weighted Injuries (FWI) metric.

Traditionally:

$$Risk = Frequency \times Consequence$$

In the cyber-physical era, we calculate the Cyber-FWI Reduction:

• The Model: We map a "worst-case" cyber scenario (e.g., remote switch manipulation) to its potential FWI impact.

• The justification: If an investment of $2M$ in Zero Trust Architecture reduces the probability of a $50-fatality$ event by $30\%$, the ROI is calculated against the VPF (Value of Preventing a Fatality), which is currently ~$3.2M per person in most developed rail markets.

• The outcome: Security is no longer a "cost center"; it is a safety insurance policy that protects the brand's social license to operate.

No amount of technology can replace the "Dispatcher’s Gut." We must train operators to recognize the relevant Cyber-Induced Anomalies. If a signal behaves "oddly" but the system says it's "Green," the human must have the authority to initiate a manual override without fear of performance penalties.

This draft is designed to be inserted as a Cybersecurity Annex or Schedule within a Rolling Stock Supply Agreement. It moves away from vague "best effort" language and mandates specific technical deliverables aligned with CLC/TS 50701 and IEC 62443.

Railway OT cybersecurity requirements

1. General compliance and governance

1.1. Standards Adherence: The Supplier shall design, develop, and deliver the Rolling Stock in full compliance with CLC/TS 50701 (Railway applications – Cybersecurity) and the IEC 62443-4-1/4-2 standards for secure product development.

1.2. Security Level (SL) Target: The Supplier shall demonstrate that the "System under Consideration" (SuC) meets a minimum Security Level 2 (SL-2) for non-critical systems and SL-4 for Safety-Critical systems (e.g., TCMS, Braking, Signaling), as defined by the Purchaser’s Risk Assessment.

2. Mandatory security deliverables

2.1. Software Bill of Materials (SBOM): For every software component (including firmware, OS, and third-party libraries), the Supplier shall provide an SBOM in a machine-readable format (e.g., CycloneDX or SPDX). This shall be updated with every software release.

2.2. Hardware Bill of Materials (HBOM): The Supplier shall disclose the country of origin and manufacturer for all critical communication and processing hardware (CPUs, Network Switches, 5G Gateways).

2.3. Vulnerability Disclosure (VEX): The Supplier shall provide Vulnerability Exploitability eXchange (VEX) files alongside the SBOM, stating whether specific CVEs (Common Vulnerabilities and Exposures) are exploitable within the railway's specific operational context.

3. Secure design and interface control

3.1. Network segmentation: The Supplier shall ensure physical or logical (VLAN/VPN) separation between:

• Safety-critical networks (Train Control)

• Operational networks (CCTV, PIS)

• Public networks (Passenger Wi-Fi)

3.2. Unidirectional traffic: Data flow from Safety-Critical zones to Operational/Public zones must be mediated by a hardware-enforced Unidirectional Gateway (Data Diode) or a stateful firewall with strictly defined "Allow-Lists."

3.3. Hardening: All Industrial Control Systems (ICS) and HMIs shall be "hardened," including the removal of unnecessary services, closing unused ports (USB/Ethernet), and disabling default credentials.

4. Lifecycle and vulnerability management

4.1. Patching warranty: The Supplier shall guarantee the availability of security patches for the entire "Design Life" of the Rolling Stock (e.g., 30 years).

4.2. Incident response: In the event of a "Critical" vulnerability (CVSS score 9.0+), the Supplier shall provide a mitigation plan within 72 hours and a validated patch within 30 days.

4.3. Virtual patching support: Where a physical patch is not feasible due to RAMS (Safety) re-certification requirements, the Supplier shall provide signatures for Network Intrusion Prevention Systems (IPS) to provide "Virtual Patching."

5. Access and audit rights

5.1. Remote access: Any remote maintenance access (e.g., for "Predictive Maintenance") must be Requested, Logged, and Time-Limited. Multi-Factor Authentication (MFA) is mandatory for all vendor remote sessions.

5.2. Right to audit: The Purchaser (or a designated third party) reserves the right to perform annual Penetration Testing and Source Code Audits on representative train sets at the Supplier's facility or on-site.

Key considerations

• Tackle the "30-year problem": Most IT contracts end after 5 years. The above approach binds the vendor for the rail asset's actual lifespan.

• It avoids "CVE Noise": By requiring VEX, you stop the vendor from ignoring vulnerabilities while also preventing them from wasting time on bugs that don't affect the specific rail configuration.

• It protects the genuine "Air-Gap": Specifically mandating Data Diodes prevents the "flat network" issue where a compromised Wi-Fi router allows access to the brakes.

Talk to our TS 50701 expert and discuss your railway security challenges here.

Download the ICS Security for transportation and logistics risk assessment guide

Get your IEC 62443 and NIS2 Compliance Checklist here.

Download: Incident Response Plan Template for Critical Infrastructure Cybersecurity