1 Introduction↩︎

To promote the development and operation of international railways, the EU introduced the ertms [1] to establish interoperable signaling, communication, and train management systems.

ertms enables a number of technologies like standardized signaling, ota communication, and ato. Having first become mandatory for new high-speed networks in 2002 [2], and for regular railways in 2004 [3], ertms has seen mixed adoption rates ranging from full deployment in Belgium and Luxembourg to a coverage of less than 1% in Germany [4].

ertms has even expanded beyond the borders of the EU to countries like Australia or Thailand², indicating global trust in the responsible era. The era published the first specification draft in 1996 [1] and subsequently updated it, most recently as “Baseline 4” in 2023 [5]. Nevertheless, this long legacy raises the question to what extent cybersecurity has been part of the standardization process.

In the past decade, various attacks on railway infrastructure have occurred across multiple countries, typically in the form of dos or the release of personal information [6]. Legacy cyber-physical systems, in particular, are vulnerable to low-cost attacks, as was the case with Polish trains being remotely halted by broadcasting a stop command over the radio in 2023 [7]. Apart from attacks carried out for personal gain or targeted service disruptions, concerns about exploitation in military warfare are on the rise amidst heightened geopolitical tensions. While the EU migrating its signaling and train management to highly computerized systems is a necessary step in expanding and unifying its rail networks, the relatively dated nature of ertms, compared to the rapid pace of cybersecurity developments, calls for a closer investigation of the status quo. The contributions of this paper are:

1. We adapt and apply a modular cybersecurity risk assessment approach to systematically model and evaluate ertms.

2. We derive/compare the cybersecurity risk profiles of current/future ertms configurations, identifying the assets that expose the largest attack surface.

We summarize related research in 2 and explain the core concepts of ertms in 3, which are relevant to the system model (5) and risk analysis (7). 4 describes our approach to modeling and analyzing ertms. The identified threats and controls are described in 6. The results of our analysis are shown in 7 and discussed in 8. 9 concludes our findings.

2 Related Work↩︎

This section summarizes the existing literature using the following trichotomy: cybersecurity of generic railway infrastructure, of ertms, and risk analysis.

Railway Security: Academic and industrial work agrees that the growing digitalization and connectivity of railway ot increases the cyberattack surface of a strategically critical infrastructure [8]–[11]. Surveys highlight safety–security co-engineering, simulation and modeling, and the use of ai and blockchain as main research trends, while pointing to gaps in validation, lte/5G security, cybersecurity implementation, and quantitative risk management [10], [12]. Technical contributions focus on network-level protections such as segregation via firewalls/gateways, idss, dpi, ai-based detection, and strong encryption, but also stress practical constraints arising from long asset lifetimes, geographical dispersion, and vendor lock-in, and therefore advocate risk-based and cost-aware security engineering [9], [11]–[14]. At the normative level, CENELEC TS 50701 and the recent EU Rail System-Pillar specifications provide life-cycle guidance, generic threat scenarios, and baseline cybersecurity requirements for signaling and interlocking systems [9], [11], [15]–[19]. Our work complements this horizontal view with an independent, technology-aware risk analysis, including explicit attack trees and detailed assessments of frmcs and ato.

ERTMS Security: Cybersecurity analyses of ertms concentrate mainly on its communication and cryptographic mechanisms. Early work on EuroRadio’s “Safety Layer” over gsmr exposed weak cryptographic primitives (3DES) and problematic key-management practices, and suggested more robust designs [20]. Subsequent studies analyzed denial-of-service and jamming against gsmr, resource-exhaustion and prng attacks, and again questioned key management, while calling for systematic vulnerability assessments [21], [22]. A second line of work focuses on EuroBalises: simulation-based studies showed that missing integrity protection and remotely modifiable firmware can enable manipulation of automatic train halting; countermeasures include retrofitted authentication tags and anomaly detection [23]. Tests in related cbtc systems confirmed that low-cost equipment suffices to jam balise telegrams and also highlighted risks in Wi-Fi-based intra-vehicular communication [24]. More recent contributions discuss system-level mitigations for future ertms evolutions, in particular frmcs, recommending centralized “overarching security mechanisms” (such as socs, mdm, and a sector-specific pki and dns) as well as cryptographic agility, continuous mediation, and ai-based observability and “sustained visibility” for already deployed assets [25], [26]. These works mostly address individual components or mechanisms; in contrast, we analyze the complete ertms, from legacy gsmr and EuroBalises to frmcs and ato, within a unified risk framework. Cybersecurity Risk Analysis: Methodologically, our work builds on established security risk-assessment approaches. In the automotive domain, Wolf et al.derive risk levels by combining cem-style attack potentials with damage estimates based on adjusted sil levels and attack trees [27], [28]. Eichler et al.generalize this into the mora framework, which supports scalable, function-oriented, and technology-aware analyses [29]. It has been applied before to similar complex use cases, such as autonomous driving [30]. For railways, prior work includes safety-focused risk models [31] and approaches that jointly consider safety and security interactions [32]. Only a few studies apply cybersecurity risk assessment specifically to ertms: Bloomfield et al.sketch a methodology for ertms-based systems but disclose limited results, while other work concentrates on single mechanisms such as 3DES in EuroRadio or secure ertms architectures and key management [33]–[35]. Existing literature thus either remains high-level or focuses on narrowly scoped technical issues. We close this gap by applying mora to the full ertms specification, including new standardizations such as frmcs, and by publishing explicit attack trees and detailed, system-wide risk profiles instead of only presenting a methodology.

3 Background↩︎

This section explains the current state of ertms standards in the scope of this analysis. It introduces the components, interfaces, and cryptographic mechanisms that later form the system model in 5.

European Train Control System: Within ertms, the etcs signaling and control system has the most direct impact on passenger safety. It ensures that no two trains enter the same track segment simultaneously; we consider specification version 4.0.0 [36]. ETCS defines four operational levels: level 0 (no ETCS on the ts), level “ntc” (legacy systems connected via a stm), level 1 (ETCS train supervision with data from EuroBalises, EuroLoops, rbcs, and rius), and level 2 (continuous radio communication with rbcs, with EuroBalises mainly providing positional data; EuroLoops and rius are not used) [36]–[38]. EuroBalises and EuroLoops are spot and semi‑continuous track devices that transmit wayside information to the obu via inductive coupling, while rbcs and rius provide radio-based “infill” information [36]–[38]. The pivotal datum is the ma, which authorizes a train to proceed up to an eoa or loa; mas can be extended but not revoked, only cooperatively shortened [36]. Additional data includes emergency stops, temporary speed restrictions, gradients, and further track conditions. Balise linking triggers an emergency halt if expected balises or loops are not detected. This may be suppressed near known interference sources via bmm and vbc [36], [39]. The etcs obu supervises speed and can apply brakes but not traction, which remains with the driver or ato. Position is computed mainly from odometry referenced to balises, with gnsss used only as time sources [36], [40]. GSM-R and FRMCS: Today, radio communication between train and rbcs/rius uses gsmr, a dedicated mobile network operating in circuit- and packet‑switched modes; packet mode relies on standard tcp/ip, with the EuroRadio module resolving rbc/riu addresses via dns [41]. A “Safety Layer” supplements GSM with traffic encryption and integrity protection using three symmetric keys: KTRANS (transport), KMAC (authentication) and KSMAC (session). Fresh KSMAC keys are derived from KMAC and nonces via 3des, and a 64‑bit cbc-mac provides integrity [41]. The upcoming frmcs replaces GSM‑R with a 5G-based system that offers inherent authentication and encryption, plus TLS-protected end-to-end communication. dns is again used for ip resolution [41], [42].

Automatic Train Operation: ato is an optional subsystem enabling (semi-)autonomous driving and automatic station stops. The ATO obu receives its data exclusively over frmcs from the trackside ATO system. sps describe infrastructure segments (stop points, speed profiles, tunnels, platforms), while a jp combines multiple sps with additional infrastructure and timetable constraints. Internally, the ATO obu contains three modules: ttsm, ssem (respecting ETCS speed supervision), and atsm (accurate stopping at defined points). Their speed recommendations are combined by taking the minimum, and ATO directly controls both traction and brakes, while also managing door opening/closing according to dwell times and platform data [39]. ETCS remains the safety authority and can override ATO via braking.

Key Management: ERTMS defines a distributed key management architecture for KTRANS and KMAC [43], [44]. Each entity belongs to a key management domain served by a kmc, which generates and distributes KMAC and handles inter-domain requests. Keys can be provisioned via an off-line, out-of-band interface (using 3des and a cbc-mac, with unclear initial secret installation) [43] or via an on-line TLS-protected channel that relies on KTRANS and a pki for certificate-based distribution [36], [44], [45]. With full transition to frmcs, legacy KMAC/KSMAC usage is phased out and all cryptographic material is to be managed by a sector-wide pki [45].

4 Methodology↩︎

The methodology follows four basic steps:

1. Literature Review: Identify relevant specification documents and survey existing research on ertms, to obtain a detailed understanding.

2. System Modeling: Construct an abstract model of the ertms.

3. Risk Analysis: Perform a risk analysis of the derived system.

4. Validation: Compare the results with related work.

The majority of the ertms specification is publicly accessible on era’s website. It is split into multiple documents called “subsets”. Due to the large number of these subsets, compiling the information they contain requires substantial effort in cross-referencing the documents. After careful consideration, the previously described mora framework has been chosen for the risk analysis for the following reasons: Its iterative and modular nature is well-suited for the scale of ertms, as granularity can be adapted based on early findings. Establishing the toe ensures completeness with respect to the selected model and threats, minimizing subjectivity and bias (though not guaranteeing completeness for the real-world system, which depends on the analyst’s abstractions). To tackle the scope of the specification in the risk analysis, the following approach to mora was chosen:

1. Creation of toe: The system model is formalized into the toe by identifying system components, connections, and used technologies. Data flows for each connection are modeled at the chosen level of granularity.

2. Function Assignment: The data is grouped into “functions” based on their purposes and effects. Any datum can be part of multiple functions. Based on the established data flows, the components and connections are automatically mapped to the same functions.

3. Quantification of Security Goals: For each function, the impairment of Confidentiality, Integrity, and Availability is assessed across four damage classes aligned with ISO/SAE 21434 [46]: Safety, Financial, Legal (also covering Privacy), and Operational. Each combination of function and impairment constitutes a security goal. Following mora, damages are assessed per function at worst-case severity, as any compromise of a given security goal produces the same downstream consequences regardless of the specific attack vector.

4. Threat Establishment: Threats are identified using a subset of stride (spoofing, tampering, information disclosure, and dos; repudiation and elevation of privileges are subsumed by spoofing and tampering as ertms relies predominantly on physical domain separation, and forged messages inherently deny authentic origin) applied to components or connections. Each threat is rated with a rap following cem [27] across five categories: Elapsed Time, Required Expertise, Knowledge of toe, Window of Opportunity, and Required Equipment. According to cem [27], the rap levels stem from summed category scores: 0-9 (Basic), 10-13 (Enhanced-Basic), 14-19 (Moderate), 20-24 (High), and \(\geq\)​25 (Beyond High).

5. Defining Controls: Different controls that can secure the system are identified through an iterative process. We begin with the set of controls stemming directly from the ertms specification and our literature analysis. For each unaddressed threat, further literature is reviewed to identify applicable countermeasures. Next, we identify threats that render some control ineffective; e.g., gaining access to a private key renders a secure channel protected by that key ineffective. Controls beyond those steps are not considered.

6. Compiling Attack Trees: For each threat, an attack tree is built recursively. The root represents the threat, and children are “preparation threats” weakening controls protecting against it. Subtrees that share the same root are duplicated, while paths whose rap is fully dominated by a shorter path are pruned.

7. Risk Estimation: The combined required attack potential of each of the attack trees is calculated by summing each path and multiplying it by the damage levels of the broken security goals, yielding a “risk level” for the tree.

8. Evaluation of Controls: Finally, the risks are recalculated for different sets of active controls, to gain an understanding of the effectiveness of various countermeasures. This can then be compared with the claims made by the designers of these controls and other researchers.

5 System Model↩︎

This section describes the developed system model as formalized in mora’s toe. The identified components can be segregated into four broader categories.

At the core of the ob we find the etcs obu, which interfaces with all the other components within a train. For our purposes, we consider the dmi, the ato obu, a representative stm, the ord, the EuroRadio module, and the vehicle interface [36]. Some of the abstraction choices include omitting distinct communication modules for EuroBalises and EuroLoops and merging the frmcs functionality into EuroRadio. All ob components are connected to the etcs obu via a physical Ethernet network running PROFINET [36], [40]. Historically, mvb and can have been used, but we ignore this in our model, as they are no longer permitted in new vehicles. Additionally, the ato obu has its own Ethernet connections to the EuroRadio, the dmi, and the vehicle interface (possibly multiple, but this distinction is irrelevant to our analysis).

Our model’s ts comprises four train communication systems: the EuroBalise, the EuroLoop, the rbc, and the riu. It is sufficient to model only one instance of each component. We choose not to model any further components, like leus, ntc ts, or the interlocking backbone, as these are beyond the scope of ertms. For the same reason, we do not model any internal connections on the ts [36]. The ts interfaces transmit messages to the ob via four channels: induction between the EuroBalise and the etcs obu, respectively, the EuroLoop, gsmr between the rbc and the EuroRadio, as well as an equivalent connection with the riu. We ignore frmcs here, and view it as a control instead (see 6) [36].

Some services in ertms are accessed via the Internet: pki, dns resolver, and ato ts. We also include a gateway connecting the gsmr network to the Internet. We form one tcp connection from the pki to the gateway, the rbc, the riu, and the ato ts. The dns resolver connects to the gateway via udp. The train’s Internet connectivity is modeled as a gsmr connection between the EuroRadio and the gateway [39], [41], [45].

We define two components relevant to km: a local and an external kmc. The local kmc is connected redundantly via tcp and oob to the rbc, the riu, and the external kmc. Both kmcs interface with the pki over tcp [43], [44], [47].

Lastly, a gnss component with an interface to the etcs obu is included for some configurations. 1 illustrates all components and their connections.

None

The data units transferred on each connection were extracted from the relevant specification documents [36], [41], [43]–[45], [47]–[52]. We omit listing them and instead focus on the identified functions; we define one function related to traction control, one to brake systems, one to mas, two to the dmi, three to various status reports, five to different track information, one to key management and one to certificate management, three to mode and level transitions, one for door control, as well as one for odometry, current time, version negotiation, communication establishment and termination, logging, acknowledgements, eoi, error reporting, safe radio supervision, vbc and balise linking, emergency stops, and ntc each, for a total of \(37\) functions.

The compromise of the majority of these functions’ security goals is associated with a Very High or High damage level, as it may lead to consequences ranging from section blockages to level-crossing accidents resulting in injuries or fatalities. Security goals with Moderate and Low damage levels relate to moderate train delays, e.g., due to a broken ma shortening, or passenger comfort, e.g., due to a compromise of air conditioning. Table 1 lists all functions with their security goals and assigned damage severity in each class. For example, the integrity of the function ma yields Very High safety damages, as authorizing a train to move into an occupied block can lead to collisions between trains. This also applies to the High financial damages caused through potential collisions between trains. Operational damages arise from attacks on the integrity or availability of the ma function—e.g., spoofing a blocked signal or dropping authorization messages—which can prevent train movement authorizations to free blocks, causing significant delays and network blockages.

6 Controls and Threats↩︎

This section presents the threats ([sec:threats-basic,sec:threats-advanced]) and controls ([sec:controls-basic,sec:controls-advanced]) identified through our methodology, progressing from basic to advanced. Threats are organized by the underlying technology or communication interface identified in the system model (5). For each technology of a connection and component, stride categories are applied (4, step 4), informed by known vulnerabilities from the literature. Social engineering is a cross-cutting vector that affects oob key management procedures. values follow cem [27]; unless stated otherwise, repeated attacks on cryptographic primitives reduce the rap to Basic, since broken keys can be reused.

6.1 Basic Threats↩︎

Magnetic Induction (EuroBalise and EuroLoop): The easiest technology to threaten in ertms is the magnetic induction used by EuroBalise and EuroLoop telegrams. Disruption of this communication requires only makeshift equipment [53], and long stretches of the track lack physical protection, resulting in a Basic rap. To spoof telegrams, custom equipment on the tracks can imitate a balise, though an expert level of knowledge and bespoke equipment may be necessary. Furthermore, the attacker may need to spend extended time around the railroad, which could raise suspicion. The rap rating of this threat is Moderate. An alternative spoofing approach involves replay attacks as suggested by Lim et al. [23]. We consider this to be as difficult as the fake balise threat, yielding a Moderate rap. Another concern raised by Lim et al. [23] is firmware modification. Although the specification states that such “test interfaces” are “not required to be integrated in the operational equipment” [37], we still consider firmware reflashing in our analysis. Both physical debug and remote interfaces can be used, creating two potential threats. In either case, bespoke tools and expert knowledge may be required due to vendor-specific equipment. Both threats receive a High rap. Information disclosure is not analyzed here, since telegram data are not secret and their effects can be observed externally.

Ethernet (On-Board Communication): Breaking the availability of an Ethernet conduit is trivial; severing the cable prevents data flow. This is done in negligible time, though physical presence is required, resulting in a Basic rap. Sniffing can be executed with similar difficulty. However, specialized equipment may be necessary to reconnect the cable while allowing data interception. The rap remains Basic. Lastly, we consider data integrity. Spoofing on an Ethernet network has the same prerequisites as sniffing, since a physical device must be patched into the network. We raise the expertise level to proficient, since knowledge of layer-2 spoofing is required. However, the rap does not increase beyond Basic. We do not separately evaluate tampering, since combining the availability and spoofing threats achieves the same goal.

: ip spoofing is trivial and ranks lowest in each category, earning a Basic rap rating. Again, we do not deem it necessary to analyze tampering attacks separately. Compromising the confidentiality of ip traffic via sniffing requires an on-path position. For our purposes, we consider a malicious network infrastructure operator. We assume it takes about a week for an attacker with expert knowledge to influence routing protocols in the desired way. The knowledge of toe should be assumed to be restricted at least, since the ip addresses and ports used are not publicly documented. The necessary equipment should be at least specialized, if not bespoke. The total rap equates to Moderate. Disrupting IP traffic availability can be achieved either by an on-path attacker dropping packets (analogous to the sniffing threat) or via large-scale ddos attacks. The emergence of “ddos as a Service” providers enables automated botnet-based flooding for monetary compensation [54], requiring only restricted TOE knowledge. The resulting rap is Enhanced-Basic, potentially lower if cost estimates of $10/h are accurate [55].

: Due to the prevalence of gsm in mobile communication, equipment for sniffing, jamming, and spoofing is readily available. The knowledge of the toe ranges from public to restricted, depending on the details, such as the phone numbers used. Each of these three threats can be executed ad hoc if the attacker is adjacent to the track. The resulting rap is Basic irrespective of the expertise level.

: Morong et al. [56] demonstrated the ease of gnss jamming, requiring only a few watts of transmission power, and calculated the jam range to be tens of kilometers, requiring no specialized equipment, no sensitive knowledge, and no time investment. The resulting rap is Basic. Attacking the integrity of gnss is more involved, as correctly spoofing the transmission requires expert understanding of the involved mathematics and signal theory [57]. Furthermore, given more advanced receivers capable of discerning the direction of the incoming signal, the positioning of the antennas must be more deliberate, and the equipment must be at least specialized. Still, the instantaneous long-range nature of the threat means the rap does not exceed Enhanced-Basic. Tampering with the gnss signal or the satellites themselves is infeasible or overly complex compared to the jam-and-spoof approach. Information disclosure is not considered, since gnss data is public.

Social Engineering: In general, the adversary might need to be hired by the respective company to gain physical access to the train (estimated time: 1 month). Since details of the km procedures at the firm are needed, the required toe knowledge is restricted. Similarly, the window of opportunity is ranked as difficult. The total rap is High. For repeated attacks, the time required is reduced to under a day, since the person on the inside only needs to get through the hiring process once, reducing the rap to Moderate.

6.2 Basic Controls↩︎

Controls Inherent to the Model: To simplify the model (5), some of the system properties are expressed as controls. Firstly, the lack of ato can be viewed as a control, since functions associated with automatic driving cannot be exploited when they are not implemented. This control raises the rap of threats related to ato to Beyond High. Similarly, using etcs exclusively in level 2 removes the EuroLoop and the riu from the model and limits data transmitted by the EuroBalise to location references [36]. Lastly, we model frmcs as a control on gsmr technology, since it fully replaces the legacy standard. The control protects against threats to confidentiality and integrity by significantly increasing the time, expertise, and resources required to break state-of-the-art cryptographic primitives, resulting in a rap of Beyond High [25].
Mandatory Controls: The ertms specifications contain some mandatory protective measures. At the ob Ethernet level, the PROFINET standard is used. However, it does not introduce any cybersecurity measures and instead relies on “defense in depth”. For our use case, we consider a properly separated network, as recommended by PROFINET and ertms [40]. We assume that all safety-relevant Ethernet cables are physically difficult for normal passengers to access, thereby increasing the window of opportunity to difficult [58]. Nearly all communication over ip, like between the train and the pki, is TLS-secured. We assume this has the same effect on ip as frmcs does on gsmr [39]. One notable exception is dns, which uses unencrypted udp datagrams. Lastly, gsmr extends the osi network model by a “safety layer”. Despite its wording, this layer is responsible for traffic encryption, and the 3des primitive used in this layer is considered outdated (see [sec:background-gsmr]) [20], [59]–[61]. For our analysis, we estimate that the safety layer increases the rap of threats to gsmr’s confidentiality and integrity to Enhanced-Basic.
Optional Controls: Two optional safety-related concepts in ertms apply to cybersecurity. Firstly, balise linking, described in [sec:background-etcs], can be used as a countermeasure against threats to telegram availability. While it does not change the rap, the control transforms safety-related damages into train delays through induced emergency halts [36]. Note that balise linking has no effect on other integrity attacks like modified firmware or spoofing of balises. Secondly, the ob’s “safe radio supervision” monitors unannounced interruptions of ota communication. Upon loss of signal, the train either halts or fails to respond, depending on the configuration [36]. Hence, we consider setting the reaction to a trip (or normal braking) as a control on gsmr’s availability with the same transformative property as balise linking. Moreover, the ob Ethernet network specification mentions that “security functions are expected on higher layers to ensure end-to-end security” [40], though it is not clear how these are to be implemented while maintaining interoperability. We model this as a control that raises the rap of confidentiality and integrity threats on Ethernet to Beyond High.

6.3 Further Controls↩︎

Existing Literature: Plenty of research suggests various forms of jamming detection and the use of an ids [20], [23]–[26]. Regrettably, these recommendations tend to be vague, especially regarding the system’s response to an alarm. For this reason, we choose not to model these controls. The proposal by Lim et al. to introduce macs to the telegram format offers a unique approach to hardening the interface without breaking backward compatibility [23]. They suggest reusing the 12-bit scrambling mechanism [37] (a shift-register seeded by a short random value) using derived keys from a shared secret to protect the confidentiality and integrity of balise telegrams [23]. While the proposal is creative, we have doubts about its resilience against cyberattacks. Firstly, the short length of the macs allows for computationally feasible collisions. Forging telegrams can still prove challenging, as the scrambling can be seen as encryption. However, the telegrams are very short, and scrambling was never intended for this use. Additionally, the plaintext could be inferred by observing the rolling stock’s reaction. Based on these concerns, we calculate the rap increase of threats to telegram confidentiality and integrity to Enhanced-Basic.
Original Suggestions: Based on early risk indicators, we have composed a few simple controls against threats seen in 6.1. The relatively low security of oob key management, balise debug interfaces, and gnss leads us to believe that disabling these mechanisms should be considered. Prohibition of “off-line” key management [43] eliminates all discussed social engineering threats. Disabling physical and remote debug interfaces protects balise firmware from modification. Accurate ob time-keeping without reliance on gnss mitigates attacks on this system. Protected lxs should serve as a second layer of defense in case of etcs compromise. Transferring the responsibility to stop at lxs to road vehicles eliminates the danger of trains not being able to halt there in time. Since the TLS control does not apply to dns, its integrity remains vulnerable, leading to massive delays in the best case and advanced impersonation attacks in the worst case. We suggest using dnssec to eliminate this threat. Lastly, we believe that balise linking, in its current state, is easily circumvented by fake balises and replay attacks. We propose extending this measure to support an (authenticated) doe. In short, the train should react to unannounced balises in the same way as to missed balises, e.g., by tripping. This strategy protects against threats to the integrity of telegrams (other than firmware modification) by transforming safety-related damage scenarios into delay-related ones.

6.4 Further Threats↩︎

Considering all controls, we identify one novel threat: balise linking can be broken by triggering the bmm track condition. This is possible through attacks on the integrity of telegrams or gsmr, but one can also provoke its legitimate issuance, e.g., by scattering large metallic masses along the tracks that interfere with the magnetic field without affecting drivability. We model this as spoofing a bmm datum originating from the dmi. The rap is Moderate, since the attacker needs extended presence at the track and precise calibration of the amount of metal. Other controls are already affected by threats from 6.1, which we reflect by assigning the affected controls to the functions’ security goals, so that their compromise disables the controls. We identified three such relationships. Breaking the confidentiality or integrity of cmp breaks the controls TLS, dnssec, and frmcs. Similarly, breaking the confidentiality or integrity of km breaks the gsmr safety layer. The control balise linking depends on the availability or integrity of vbc. There are other functions whose compromise can serve as an entry point to more sophisticated attacks, which we leave for future research (see 9).

7 Evaluation↩︎

Through our methodology, we identified a total of \(191\) risks. We focus on the most substantial ones. With the most basic control set, i.e., only 6.2 and no ato, \(17\) risks have a Low risk level, \(44\) Moderate, \(62\) High, and \(68\) Very High. Much of the Very High category stems from the insecurity of EuroBalises, since various forms of spoofing, tampering, and jamming of this technology may easily lead to fatalities. Threats to gsmr and ob Ethernet buses pose the same danger, except for the edge case of precisely timed cable cuts, which we consider unrealistic. dos attacks on the ip layer are also ranked as Very High due to the potential to temporarily halt the entire rail service, e.g., in a scenario where a kmc or the pki becomes unavailable. A similar effect can be hypothesized for spoofing and tampering of gnss. Tampering may also lead to life-threatening injuries, should the ob clock drift enough to significantly overrun an loa.

When all optional ertms controls from 6.2, including frmcs, are employed, the numbers of risks in each category shift to \(17\)/\(82\)/\(44\)/\(48\), respectively. However, only risks related to ob Ethernet and gsmr spoofing are fully mitigated³, i.e., reduced to Moderate risk. While balise linking and safe radio supervision prevent jamming attacks from causing severe injuries, they instead result in service disruptions, since the controls respond by applying brakes (damage transformation from safety to operational damages). The combination of low rap and potential line-wide disruptions means the effective risk level remains unchanged. Lastly, tampering of telegrams, attacks on gnss, and ddos remain entirely unaddressed. The reader is reminded that the decrease in Very High risk attacks from \(68\) to \(48\) does not imply full mitigation of the underlying threats, since multiple attack trees may share the same root threat.

Introducing suggestions from 6.3 shifts the classification to \(17\)/\(89\)/\(58\)/\(27\). Only attacks on gnss are fully mitigated, which explains the low increase of the Moderate category’s cardinality. The three main threats to telegram integrity (replay attacks, fake balises, and firmware reflashing) remain possible (albeit with an increased rap). However, their damage is transformed from train collisions into delays and cancellations, much as discussed for jamming attacks. Due to the non-trivial rap, the relevant risk level is reduced from Very High to High. The jamming and ddos attacks remain problematic at the Very High level.

The three control groups are analyzed once more with the inclusion of an “etcs level 2 only” control, simulating a complete phase-out of levels \(0\), ntc, and 1. With only mandatory controls, the risk counts are \(17\)/\(106\)/\(33\)/\(35\). Including the optional controls in the specifications, we obtain \(17\)/\(126\)/\(23\)/\(25\). Finally, enabling all controls yields \(17\)/\(129\)/\(36\)/\(9\). In each case, the stark risk reduction is due to the reduced role of EuroBalises. Still, they are used for train positioning, possibly enabling signal and buffer stop overruns that result in severe injuries by gradually shifting the ob’s determined location. This is classified as Very High. Implementing the linking doe measure suggested in [sec:controls-advanced-original] reduces the risk to High by transforming the damages to train delays. The \(9\) remaining Very High risks refer to previously discussed jamming and ddos attacks, which can disrupt the service with relative ease. A visualization of the effects of the various control groups on the risk taxonomy is shown in 2.

None

Lastly, we consider the activation of ato. This is only valid in conjunction with frmcs, since ato over gsmr is not allowed. In each case, we observe only one additional High risk level attack, namely cutting the Ethernet cable between the ato obu and the vehicle interface at just the right moment to inhibit the deactivation of traction. Realistically, this is not concerning, as the etcs obu’s braking system overrides ato, which our model does not capture [39]. The ato’s low effect on the risks stems from the fact that, if an attacker compromises ob bus connections or the frmcs network, they can cause catastrophic damage by compromising train brakes even without ato. With the inclusion of ato, the attacker could additionally apply full throttle, but that does not change the risk level. Furthermore, the attack surface on ato is smaller, as all its data is encrypted by TLS.

8 Discussion↩︎

The results show that a minimal ertms implementation has several vulnerabilities that can lead to fatalities. While additional safety measures defined in the standards, including the upcoming frmcs, appear to have a significantly positive effect on the estimated security, many concerns remain regarding dos and EuroBalise tampering. Additional controls from other researchers and this paper address these deficiencies by strengthening wireless interfaces. Nevertheless, the lack of security in telegrams remains a persistent problem. Restricting to etcs level 2 results in a drastic security improvement by eliminating most EuroBalises’ responsibilities, yet attacks on gnss and telegram forgery remain unaddressed. The ertms standard appears to be the weakest link in its cybersecurity defenses, which we attribute to the slow pace of ot system standardization. Even with academic countermeasures, the system’s reliability remains vulnerable to remote dos attacksconsistent with real-life attacks on railway infrastructure. Further defenses must be added to ensure uninterrupted operation by avoiding single points of failure using redundant communication, decentralizing control systems, and enabling v2v communication.

9 Conclusion and Future Work↩︎

In this paper, we have performed a risk analysis of the ertms suite of standards by systematically translating the specification documents into an abstract system model and subsequently estimating risks using the mora framework. By comparing the risk profiles of current and future ertms configurations, we identified legacy components, particularly EuroBalises and GSM-R, as the primary source of risk. Fully transitioning to etcs level 2 and deploying frmcs significantly improves the cybersecurity posture. Jamming and ddos remain among the highest risks due to low raps.

mora allows flexible handling of ertms’s complexity due to its iterative and modular nature and ensures completeness with respect to the model and selected threats, minimizing subjectivity and bias. This work combines function-level security goals for robustness and defensibility of results with technology-based, asset-level threats to achieve complete coverage.

We have identified several limitations in applying mora to the railway domain: (1) Identified risks are classified as having the highest risk level due to the direct effect that train operations have on human safety. (2) Damage transformation (e.g., converting safety hazards into delays) often fails to lower the risk classification when the rap of the attacks is relatively low. (3) Some risks are only reduced to the Moderate level, even if the corresponding attacks are determined to be no longer possible. (4) Summarizing by count of attack trees may inflate threats with many paths. (5) The lack of temporal dependencies between attack-tree nodes renders circular dependencies unresolvable.

A railway-centric risk matrix addresses the points (1)–(3) as a natural advancement. Further extensions include expanding the model beyond ertms, increasing the granularity of specific subsystems (e.g., the attack surface of frmcs), and validating identified risks through experiments. Results of the risk assessment can be used by the industry to advance ertms cybersecurity.

References↩︎

---

1. These authors contributed equally to this work.
   This is the extended version of the paper accepted at ARES 2026 CPRA.↩︎

2. see https://www.ertms.net/deployment-world-map/, Accessed: 2026-06-08↩︎

3. Raw output suggests that gsmr spoofing is possible if ip sniffing is done beforehand, as the former breaks TLS encryption and the latter breaks the gsmr safety layer. This is a shortcoming of the tooling, which omits dependencies (here, circular) between attack steps, so we ignore this risk.↩︎