Skip to content
Independent reference on the Future Railway Mobile Communication System

Design · 3.8

Cybersecurity and trust boundaries

Time: about 13–16 minutes including the task; estimate

Guiding question: How does a threat become a testable protective measure?

Learning objective: You connect protection needs, trust boundaries and recovery tests.

Prerequisites: Previous lessons through 3.7, particularly the case file developed there.

A maintenance account changes the service

Talbahn maintains group configurations remotely. A compromised maintenance account could change assignments so Niko reaches the wrong participants. Radio coverage and MCPTT software might continue working technically. Protection must therefore also cover management, identities and changes.

An asset to protect is something whose impairment should be prevented or limited. Here it is correct and available group assignment. A threat describes a possible harmful action, such as an unauthorised change. It identifies what could happen to the asset. A vulnerability is a characteristic that facilitates that action, for example a shared account without sufficient access restrictions. It gives an attacker an exploitable opportunity.

Risk connects the possible impact with an assessment of the conditions and probability of occurrence. This assessment depends on the system and its use. Talbahn therefore does not assign a generic risk level solely from a technology's name.

A chain of demonstrable measures

Step Talbahn example
Protection need Authorised changes only; traceable and recoverable group assignments
Attack opportunity Stolen maintenance access changes participants
Prevention Individual accounts, strong authentication, limited rights, controlled approval
Detection Log changes with person, time and affected object
Response Block access, assess impact, restore an approved state under control
Evidence Attempt an unauthorised change; test rejection, logging and recovery

Least Privilege means giving an account only the rights needed for its task. A maintenance account intended to read measurements therefore does not automatically need permission to change groups. Zero Trust describes an approach that explicitly verifies access rather than granting it solely because of an apparently trusted network location. NIST SP 800-207 explains this supplementary approach; it does not replace a railway-specific assessment. [S34]

Frameworks address different subjects

CLC/TS 50701 places cybersecurity in the life cycle of railway applications. The IEC 62443 series provides foundations for risk assessment, system protection, components and secure development, among other things. Which parts apply depends on the system boundary and responsibilities. [S14, S26]

3GPP TS 33.180 addresses the security architecture of Mission Critical services. It is relevant to MCX, but alone does not cover every maintenance organisation and vehicle access point. EN 50159 addresses safety-related communication over transmission systems. S27 substantiates the published 2026 edition through the official EVS catalogue. Its validity date of 1 September 2026 concerns the Estonian adoption; it is not a general European application date. The project's applicable national edition and transition rules are checked separately. EN 50159 is therefore not a general substitute for cybersecurity requirements. EN 50126 connects the required RAMS assessment to the life cycle. [S25, S27, S15]

NIS2 concerns duties of certain entities under the European legal framework, including relevant transport actors. Applicability and specific duties must be determined by jurisdiction and national implementation. Mentioning NIS2 is neither a product certificate nor a technical test requirement for every individual FRMCS device. [S28]

Recovery is part of protection too

Authentication verifies a participant's claimed identity. For example, it establishes whether a login actually belongs to the stated maintenance account. Authorisation determines which actions that identity may perform. It restricts access to approved functions. A validly logged-in person therefore cannot automatically change every configuration.

In the case file, each measure receives an owner and a check. Talbahn also considers expired access rights, lost management connections and controlled return to an approved state. A protective mechanism that unintentionally blocks the intended service indefinitely also needs defined handling.

A trust boundary needs concrete data flows

A trust boundary separates areas with different access or administration assumptions. In FRMCS it may lie between application and gateway, between operator organisations or at public access. Talbahn draws the identities, configuration data, signalling and user data crossing it. A single box labelled “encrypted” does not explain who authenticates the counterpart or authorises a change.

Recovery specifies how current permissions and key states are established. Restoring old configuration must not silently reactivate withdrawn rights. The test therefore covers service use and correct protection state, not merely a powered-on platform. [S25]

Check your understanding

The supplier offers encryption as the complete answer to manipulated group assignments. What is missing?

Model answer

Encryption can protect content on a transmission path. It does not automatically prevent a change through an authorised or stolen management account. Identity verification, restricted change permissions, controlled approval, logging and recovery are needed, with appropriate tests. Evidence must include the management path and its effect on the service.

What to remember

A protective measure is assessed against a specific risk and its demonstrated effect.

Your Talbahn case file

Connect possible manipulation of group assignments to protective measures, owners and a recovery test.

Sources

  • S14 · CLC/TS 50701: Railway applications – Cybersecurity

    CLC/TS 50701: Railway applications – Cybersecurity

    Version: 2023, catalogue edition · Checked: 2026-10-11

    Scope: Railway cybersecurity life cycle and relationship to RAMS.

    Limitations: Catalogue and public publisher information reviewed; paid full text not reviewed completely. No clause-level conformity claimed.

    Used in: 3.8

  • S15 · EN 50126-1: Generic RAMS process

    EN 50126-1: Generic RAMS process

    Version: 2017 + A1:2024, BSI edition · Checked: 2026-10-11

    Scope: RAMS process framework over the life cycle.

    Limitations: Catalogue and scope only; no complete review of the paid standard. Determine national adoption and project edition separately.

    Used in: 1.8, 2.21, 3.8, 3.14

  • S25 · 3GPP TS 33.180 / ETSI TS 133 180: Security of the MC service

    3GPP TS 33.180 / ETSI TS 133 180: Security of the MC service

    Version: 16.13.0, February 2026 · Checked: 2026-10-11

    Scope: Security architecture of Mission Critical services.

    Limitations: Explicit teaching reference; cross-check newer release branches and the specific project baseline separately.

    Used in: 1.8, 2.21, 3.8

  • S26 · IEC: Overview of the IEC 62443 series

    IEC: Overview of the IEC 62443 series

    Version: Public overview · Checked: 2026-10-11

    Scope: Organisation and technology over the life cycle; system and component scope.

    Limitations: The series has multiple parts. No blanket applicability of all parts or full-text review of all standards is claimed.

    Used in: 3.8

  • S27 · EN 50159:2026: Safety-related communication in transmission systems

    EN 50159:2026: Safety-related communication in transmission systems

    Version: EN 50159:2026; EVS-EN 50159:2026 valid from 1 September 2026 · Checked: 2026-10-11

    Scope: Public catalogue: published edition and scope of safety-related communication.

    Limitations: Catalogue evidence, not review of the paid full text. The EVS date concerns Estonian adoption. Check national edition, transitions and project applicability separately.

    Used in: 3.8

  • S28 · Directive (EU) 2022/2555 – NIS2

    Directive (EU) 2022/2555 – NIS2

    Version: 14 December 2022; official legal act · Checked: 2026-10-11

    Scope: Scope and transport sector in Annex I; organisational cybersecurity duties.

    Limitations: Check the specific entity and national implementation. Not an FRMCS product certificate; not automatically applicable in Switzerland.

    Used in: 3.8

  • S34 · NIST SP 800-207: Zero Trust Architecture

    NIST SP 800-207: Zero Trust Architecture

    Version: August 2020 · Checked: 2026-10-11

    Scope: Principles of explicit access verification.

    Limitations: Supplementary to railway-specific foundations, not their replacement.

    Used in: 3.8

Shared source register

Your progress is stored in this browser on this device.