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
Your progress is stored in this browser on this device.