Protection and lifecycle of communication services

A call works: who was allowed to change it?

Talbahn's pilot trial carries speech. Later, someone changes group assignments without authorisation. The radio connection remains intact, but the call no longer reaches the intended people. Functionality alone is therefore insufficient.

Security protects systems and information against unauthorised access and manipulation. In this example, it should prevent or reveal unauthorised changes to group assignments. Safety, here functional or operational safety in the relevant system context, concerns avoiding unacceptable risks to people and operations. It considers the possible consequences of malfunction in use. A manipulated assignment is initially a security event; its operational effect may become relevant to safety. Both perspectives must work together without equating their evidence.

Availability over the life cycle

RAMS stands for Reliability, Availability, Maintainability and Safety. The framework considers these together over a railway system's life cycle. Availability is the ability to provide a required function under specified conditions when needed. Two modems, or a percentage without those conditions, do not describe this adequately. EN 50126 provides a railway-specific process framework. [S15]

For Talbahn, what matters is whether Lea and Niko can use their agreed service. A server can be powered on while incorrect permission prevents that service. Repair time, maintenance windows and common failure causes therefore also belong in the assessment.

Select sources by task

Standards and regulations answer different questions:

For EN 50159, S27 points to the published 2026 edition. The national edition and transition rules applicable to a project are established separately.

NIS2 is not a technical FRMCS product standard. Its actual applicability depends on the entity, jurisdiction and national implementation, among other things. The other documents do not become binding simply by being named either. Project context determines the applicable scope. A more detailed allocation follows in 3.8 and 3.14.

Security functions throughout the service lifecycle

Service identity, profile and keys are not needed only at installation. Identity management verifies service users, configuration determines intended behaviour and key management provides required protection information. Authentication checks a claimed identity; authorisation decides permitted use. Both differ from mere mobile-network registration. [S25]

Talbahn tests three lifecycle cases: a new authorised user, withdrawn permission, and recovery after failure of a shared management function. New and existing sessions may be affected differently. Record behaviour for the implementation rather than assuming that every key service must be contacted again for each voice packet.

Check your understanding

Why does a second radio connection not fix manipulated group assignments?

Model answer

Both connections may use the same incorrect assignment. The fault then lies in a shared service or management function. Additional transport supplies neither correct permissions nor an independent assignment.

Additional application

Why test both new and existing sessions after recovery?

Model answer

Dependencies on identity, configuration and key management may differ by state. Powered-on servers do not prove full restoration of correct service and permission states.

What to remember

Protection, availability and safety need appropriate, separate evidence.

Your Talbahn case file

Add an asset to protect, a common failure cause and a suitable test to the mixed communication chain. Use these in the final assessment.