Join our Newsletter — 33% off our NHI Course
Home› Guides› ETCS, ERTMS and Train Radio Security Guide: protecting…
Guide OT & IoT Security

ETCS, ERTMS and Train Radio Security Guide: protecting Euroradio, key management and FRMCS migration

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 14 November 2026 17 min read
On this page

The security of a modern European railway depends on cryptographic keys, certificates and radio links that most cyber teams have never looked at, because they sit inside the signalling safety case. ERTMS combines ETCS cab signalling and train protection with GSM-R radio, and ETCS movement authorities travel between the radio block centre (RBC) and the train over that radio, protected by the Euroradio protocol and keys issued by a Key Management Centre (KMC). The 2023 CCS TSI specification set adds TLS and a public key infrastructure (PKI) for ERTMS end-to-end security and on-line key management, and the sector is preparing to move from GSM-R to the 5G-based FRMCS. It is written for infrastructure managers, railway undertakings and signalling security architects. Zoning and rail regulation are in the Rail Cybersecurity Guide (TS 50701) and are not repeated here; this page is defensive and stays at the architecture and operations level.

Key takeaways

  • Euroradio gives integrity, not secrecy. The SUBSET-037-2 safety layer authenticates peers and protects messages with a triple-key DES-based MAC, but it defines no confidentiality service and leaves replay, delay and sequencing protection to the ATP application.
  • Keys are the crown jewels. Every RBC and on-board unit holds KMAC authentication keys from its Home KMC; whoever controls the KMC and key distribution controls which trains and RBCs can talk.
  • The new security layer is TLS plus PKI. SUBSET-146 v4.0.0 requires mutually authenticated TLS 1.2 and 1.3 (1.3 preferred), X.509 certificates issued over CMP, CRL checks at least every 24 hours and fail-secure behaviour, and it separates security from safety so security can be updated without re-approving the safety case.
  • Radio availability is a safety and service risk. Cryptography cannot stop jamming or GSM-R obsolescence; plan detection, degraded-mode operations and the FRMCS migration together.
  • Operate it like a PKI programme. Certificate renewal, revocation, time synchronisation, KMC hardening and supplier access are day-to-day operational controls, not one-off project deliverables.

The ERTMS components that matter for security

ERA describes ERTMS as a single European signalling and speed control system made up of ETCS, GSM-R and operating rules. ETCS is the cab-signalling system with automatic train protection; GSM-R provides voice for drivers and signallers and the data bearer for ETCS, particularly at Levels 2 and 3. The current specification set is CCS TSI Implementing Regulation (EU) 2023/1695, as amended by Implementing Regulation (EU) 2026/693 of 19 March 2026, whose Appendix A lists ETCS Baseline 4 Release 1, GSM-R B1 MR1, FRMCS B0 and ATO B1 specifications.

ComponentRoleSecurity-relevant interfaces
European Vital Computer (EVC) and on-board unitSupervises speed and movement authority on the trainEuroradio or TLS sessions to the RBC; key or certificate store; maintenance and diagnostic ports
Radio block centre (RBC)Issues movement authorities to trains (ETCS Level 2)Euroradio to trains; RBC to RBC handover (SUBSET-098); interlocking and traffic management links
Radio infill unit (RIU) and Eurobalise / EuroloopTrackside transmission of data to passing trainsTelegram engineering data; physical access along the line
Key Management Centre (KMC)Generates and distributes KMAC keys within its KM domainOff-line key management (SUBSET-038, SUBSET-114); on-line key management (SUBSET-137); KMC to KMC links
ERTMS PKIIssues X.509 certificates for TLS-based ERTMS securityCMP enrolment, CRL and OCSP services (SUBSET-146)
GSM-R and FRMCS networksVoice and data bearerRadio interface, core network, APNs for ETCS and key management

The ERTMS Security Core Group (ESCG) of the EEIG ERTMS Users Group analysed the Eurobalise, Euroloop, RIU, RBC, KMC, ETCS on-board, on-line key management PKI and Euroradio PKI as zones, using a method that implements IEC 62443 and TS 50701, and set a target security level of SL-T 4 for most of them. GSM-R and FRMCS, driver voice and ATO were postponed in that analysis, which is a reminder to assess the radio layer explicitly rather than assume it was covered.

How Euroradio protects ETCS messages

SUBSET-037 (EuroRadio FIS, version 4.0.0 in the current Appendix A) splits into Part 1 (communication layer and coordination function), Part 2 (safety layer) and Part 3 (FRMCS interface). The safety layer in Part 2 is the part security teams most need to understand.

  • What it protects against: message integrity violation and insertion of new messages by unauthorised users of the transmission channel. Deletion, replay, delay and wrong sequencing are defined as threats, but SUBSET-037-2 places protection against them on the ATP application.
  • The MAC: a 64-bit CBC-MAC per ISO/IEC 9797-1 with padding method 1, described in the specification as single DES with a modified MAC algorithm 3, in which the last block is enciphered with K1, deciphered with K2 and enciphered with K3. The key is a 192-bit triple key.
  • Key hierarchy: KTRANS transport keys protect key management; KMAC authentication keys (also written KAB) are shared between an on-board unit and an RBC; KSMAC session keys are derived for each safe connection from two 64-bit random numbers contributed by the peers.
  • Peer authentication: a three-pass exchange (AU1, AU2, AU3, with an optional AR) authenticates both ends, a direction flag prevents reflection, key validity is checked against UTC before the connection is established, and connection set-up is bounded by a 40-second timer.
  • What it does not do: the safety layer defines no confidentiality service, and user data are carried transparently. Anyone who can receive the radio bearer may be able to read message content, even though they cannot forge it without the keys.

The consequence: the whole system rests on keeping KMAC keys secret and correctly scoped, and because the design is symmetric and DES-based, the sector's direction is the TLS and PKI layer described next.

Key management: off-line, on-line and the KMC

Each KMAC entity (an ETCS on-board unit, an RBC or an RIU) has exactly one Home KMC, which manages its key entries. A KM domain is one KMC and the entities that use it, and KMCs exchange key operations with each other so that a train from one domain can run on another domain's lines.

SpecificationScopeSecurity points for operators
SUBSET-038 Offline key management FISOff-line key management between KMCs and entitiesPhysical media handling, courier and installation procedures, staff vetting, transport key protection
SUBSET-114 KMC-ETCS Entity Off-line KM FISOff-line interface from a KMC to ETCS entitiesInstallation records per entity, removal of keys from decommissioned units
SUBSET-137 On-line Key Management FFFISOn-line distribution between KMCs and from a KMC to KMAC entitiesRuns over TLS on TCP/IP with security per SUBSET-146; on-board entities initiate connections; a separate APN from ETCS operations; KMS listens on TCP port 7912

SUBSET-137 defines the operations a KMC can perform remotely: Add Keys, Delete Keys, Delete All Keys, Update Key Validity Periods, Update Key Entities, Check Key Database (checksum-based), Report Key Update Status and Request Key Operation. Each is high impact: a rogue Delete All Keys would stop safe connections, and a rogue Add Keys could admit an unauthorised entity. Treat the KMC and its operators as a privileged access tier: dedicated hardened workstations, dual control for key ceremonies and bulk operations, hardware security modules for key generation and storage, and full audit of every operation. The general practice is in the Cryptographic Key Management Guide.

The ESCG notes that KMC requirements fall in the future TSI as security moves to TLS and PKI, which shifts risk to the PKI rather than removing it.

The TLS and PKI security layer (SUBSET-146)

SUBSET-146 ERTMS End-to-End Security (UNISIG, issue 4.0.0) specifies the security layer for ETCS, ATO and on-line key management over open transmission systems. It covers security only: the safety layer sits above it and applies only to ATP, which lets security be updated without re-approving the safety rating of the application. It does not apply to ETCS over GPRS, which stays on the Euroradio stack.

AreaSUBSET-146 requirementWhat to check in your deployment
ProtocolTLS 1.2 and 1.3 both supported, 1.3 preferred; no 0-RTT, session resumption, renegotiation or compressionSupplier conformance evidence; configuration baselines on RBC, OBU and KMS
AuthenticationMutual authentication and integrity always; payload encryption optional by risk analysisRecord the risk decision on encryption per application
Cipher suites and curvesECDHE with AES-256-GCM for TLS 1.2; AES-256-GCM and ChaCha20-Poly1305 for TLS 1.3; secp256r1 default, brainpoolP256r1 for backwards compatibility; RSA keys 3072 bitsDisable anything outside the profile; plan for post-quantum review as a future change
EnrolmentCMP (RFC 4210/4211) over HTTP; first request authenticated by a passphrase of at least 16 characters or a valid device certificateWho generates, holds and destroys initial passphrases
LifetimeRecommended validity 6 months, renewal 1 month before expiry, alarm on failed renewalAlarm routing to a staffed function; renewal success rate
RevocationCRLs updated immediately on status change and downloaded at least every 24 hours; OCSP optional except in certain variantsRevocation runbook for a lost or compromised OBU
Failure behaviourFail-secure: TLS failures block communication; a CRL timeout raises an alarm onlyOperational impact of mass certificate failure; tested recovery
Time and loggingNTPv4 time to about one second; errors reported over syslog (RFC 5424) on TLS (RFC 5425), retained locally for 90 daysSIEM ingestion and parsing; time source protection
Pre-shared keysTLS-PSK kept only for compatibility with SUBSET-137 v1.0.0; not recommended for new implementationsInventory of PSK use and an exit date

Fail-secure behaviour is the right safety posture, but it turns PKI health into train availability. An expired intermediate certificate or an unreachable enrolment service can stop trains as effectively as an attack. The PKI needs safety-critical resilience: redundant CAs, monitored expiry, tested recovery and an offline root. See the PKI Basics Guide and the mTLS Guide.

Europe's Rail Joint Undertaking System Pillar published its Cybersecurity Migration Guideline (version 1.1, released 23 March 2026) to help apply its cybersecurity specifications alongside the 2023 CCS TSI. Points relevant here: pre-shared keys stay only for backward compatibility within an existing KM domain and are prohibited for new implementations and KMS to KMS links; the KMS must be updated before a new Baseline 4 RBC or EVC is used with it; the PKI should provide an OCSP responder for as long as on-line key management requests one; TLS is used on 5G radio, not GSM; and railways are responsible for providing shared cybersecurity services, which third parties may operate.

Train radio: GSM-R today, FRMCS next

GSM-R has been deployed across Europe since 2000 and is fully defined in ETSI standards. ERA's report on the evolution of railway radio explains why it must be replaced: it rests on mid-1990s technology, general supplier support is guaranteed only until at least 2030 (some contracts require 2035), and it lacks capacity for wider ETCS, digitalisation and ATO. The sector expects full migration to take 8 to 10 years, with 5G the preferred technology for FRMCS, which separates applications from radio bearers over IP.

  • Read and forge are different risks: Euroradio blocks forged movement authorities but does not hide content, so treat GSM-R traffic as observable by a capable adversary.
  • Availability is the main radio risk: jamming or interference denies service rather than forging commands. ETCS supervises the radio connection and applies a defined reaction when contact is lost, so a jamming event shows up as safe but disruptive train stops. ERA also flags coexistence with public 3G and 4G networks as a critical interference issue. See the Physical Layer and Wireless Jamming Guide.
  • Voice and legacy analogue radio: safety functions that trust any sender can be abused without breaching a network, as the Polish radio-stop incident described in the Rail Cybersecurity Guide showed. Inventory every function that can be triggered over voice or analogue channels.
  • FRMCS changes the trust model: IP bearers, possible use of public or hybrid networks ("network as a service") and app-based railway functions bring a wider attack surface and mainstream 5G security controls. ETCS over FRMCS uses SUBSET-037-3 and the SUBSET-146 profile in its Annex A.4: OBU and RBC TLS roles, CRL-only revocation and no pre-shared keys.
  • Bundle security with the migration: ERA's report records supplier advice that cybersecurity upgrades should be part of the on-board FRMCS migration to avoid separate revision cycles, and suggests examining whether security upgrades can sit outside the ETCS safe application to allow faster patching.

Where identity fits

ERTMS is one of the largest non-human identity estates in transport. Every on-board unit, RBC, RIU and KMS endpoint is a machine identity, first holding symmetric KMAC keys and increasingly X.509 certificates whose common name is an FQDN built from the ETCS ID. Manage them as an identity lifecycle: register at commissioning, rotate on schedule, revoke when a unit is stolen, scrapped or sold, and reconcile the key database and certificate inventory against the fleet register. For people, the System Pillar guideline calls for a shared user authentication service with single sign-on, driver authentication and a physical credential; broker and record supplier diagnostic access. See the Transportation Identity and OT Access Guide and the OT and ICS Identity and Access Guide.

Threats and controls

Threat (defensive view)ATT&CK for ICSPrimary controls
Radio jamming or interference causing loss of ETCS sessionsT0814 Denial of Service; T0813 Denial of ControlInterference monitoring with the radio network operator, degraded-mode rules, incident reporting to the spectrum authority
Interception of unencrypted radio or maintenance trafficT0887 Wireless SniffingRisk decision on TLS payload encryption; no sensitive data over GSM-R without protection
Rogue base station or compromised radio accessT0860 Wireless Compromise; T0830 Adversary-in-the-MiddleMutual authentication (Euroradio or TLS), core network monitoring, FRMCS 5G security controls
Theft or misuse of KMC credentials or key materialT0859 Valid AccountsHSM-protected keys, dual control, privileged access workstations, operation audit
Supplier remote access to RBC, KMS or EVC diagnosticsT0822 External Remote ServicesBrokered, time-limited, MFA-protected access, session recording
PKI outage or mass certificate expiryT0827 Loss of Control (impact)CA redundancy, expiry monitoring, renewal alarms, tested recovery

How to implement

  1. Inventory interfaces and keys: list every Euroradio, TLS, KMS and PKI interface, every KMAC entity and its Home KMC, every APN and every certificate profile. Reconcile with the fleet and trackside asset registers.
  2. Assess the radio and crypto layers explicitly: extend the TS 50701 risk assessment to GSM-R or FRMCS, voice functions, KMC and PKI zones, using the ESCG zone list as a starting point.
  3. Harden the KMC: HSM-backed key generation, separated operator roles, dual control for bulk operations, offline backups of key databases, and a written key compromise procedure.
  4. Stand up or contract the PKI: root offline, CMP enrolment with controlled initial passphrases, CRL and OCSP services with monitored availability, and NTP or NTS time sources that are themselves protected.
  5. Pilot TLS on a limited line or fleet subset: run TLS-capable units alongside existing Euroradio where the specifications permit, monitor syslog errors and renewal alarms through a full certificate cycle, and confirm the operational effect of fail-secure behaviour.
  6. Integrate with safety change control: route crypto, PKI and configuration changes that touch ATP equipment through the safety case, and use the security and safety layer separation to keep pure security updates on a faster path where the safety case allows it.
  7. Plan rollback: keep the previous key set or certificate chain recoverable, document how to reinstate a known-good KMS database, and rehearse recovery from a failed key distribution before going live.
  8. Write FRMCS security into tenders: require SUBSET-146 conformance, TS 50701 security levels and a vulnerability handling commitment, and bundle the security layer into the FRMCS on-board upgrade.

Decision guidance

  • Off-line versus on-line key management: off-line suits small, single-domain fleets but depends on physical handling; on-line suits multi-domain and cross-border operation but needs a PKI and a hardened KMS on its own APN.
  • Encrypt the payload or not: SUBSET-146 makes encryption a risk decision. Encrypt where messages reveal operationally sensitive data or carry maintenance and diagnostic content; record the decision either way.
  • Own the PKI or buy it as a service: the System Pillar guideline allows shared cybersecurity services to be run by third parties. Smaller operators can contract a CA, but stay accountable for the root and revocation.
  • Infrastructure manager versus railway undertaking: infrastructure managers typically run RBCs and trackside KMCs; railway undertakings and fleet owners hold on-board units. Agree in writing who revokes what, how fast, and how cross-domain key requests are authorised.

Detection and measurement

Collect syslog from RBCs, on-board units and KMS (SUBSET-146 defines syslog over TLS with error codes), KMC operator audit logs, PKI issuance and revocation logs, radio network alarms and interference reports, and ETCS session loss events from operations. Watch for bursts of TLS handshake failures, unexpected key deletions or validity changes, unknown enrolment requests and clustered radio session loss.

  • Key and certificate coverage: percentage of KMAC entities and certificates reconciled with the asset register each month.
  • Renewal health: certificates renewed before the one-month threshold, and failed-renewal alarms closed within the agreed time.
  • Revocation speed: time from a reported lost or decommissioned unit to its keys deleted and certificate revoked.
  • PSK exit: number of entities still using pre-shared keys, trending to zero.
  • Radio resilience: ETCS radio session losses per thousand train kilometres, separated by cause (coverage, interference, equipment, security).

Framework mapping

Control areaNIST CSF 2.0NIST SP 800-53 Rev. 5IEC 62443 / TS 50701 theme
Euroradio and TLS message protectionPR.DS-02SC-8, SC-13, SC-23Communication integrity, data confidentiality
Device authentication of OBU, RBC, RIUPR.AA-03IA-3, IA-5Device identification and authentication; PKI certificates (SR 1.8)
KMC and key lifecyclePR.DS-02SC-12Cryptographic key management
ERTMS PKIPR.AA-03SC-17PKI certificates (SR 1.8)
Radio availability and jamming responseDE.CM-01SC-5, SI-4Resource availability, wireless use control (SR 2.2)
Inventory of entities and keysID.AM-01CM-8Asset inventory for the system under consideration
Supplier security requirementsGV.SC-05SR-3Cybersecurity requirements specification
Change control through the safety casePR.PS-01CM-3Security aligned with the RAMS life cycle

Common failure patterns

  • Assuming Euroradio encrypts: teams treat ETCS radio traffic as confidential and carry sensitive data on it, when the safety layer only authenticates and protects integrity.
  • KMC run as an engineering tool: key management workstations sit on general engineering networks with shared logins and no dual control, making the most sensitive system in ERTMS one of the least protected.
  • Keys outliving trains: scrapped, sold or stolen on-board units keep valid keys and certificates because decommissioning is a fleet process with no link to the KMC or PKI.
  • PKI without operations: a CA is commissioned for the project but renewal alarms go to nobody, so fail-secure behaviour turns a certificate expiry into a service outage.
  • Radio left out of scope: the risk assessment covers RBCs and interlockings but postpones the radio layer, leaving jamming and voice-triggered functions without detection or operating rules.

Practitioner checklist

  • Confirm which CCS TSI version and Appendix A specification set (SUBSET-037, -038, -114, -137, -146) your contracts and fleet implement.
  • Inventory every KMAC entity, its Home KMC and every ERTMS certificate, reconciled with asset registers.
  • Protect KMC keys in HSMs, separate operator roles and require dual control for bulk key operations.
  • Monitor certificate expiry and renewal alarms through a staffed function.
  • Record the payload encryption decision for each application using SUBSET-146.
  • Set an exit date for TLS pre-shared keys and track it.
  • Include GSM-R or FRMCS, voice functions and jamming in the TS 50701 risk assessment.
  • Link fleet decommissioning to key deletion and certificate revocation.
  • Bundle security layer upgrades into FRMCS on-board migration plans.

Standards and references

Related NHI Mgmt Group resources: Rail Cybersecurity Guide (TS 50701) · TSA Pipeline and Rail Cybersecurity Directives Guide · IEC 62443 Guide · OT Remote Access Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 14 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org