The Cyber Resilience Act, Applied To Rail
Regulation (EU) 2024/2847 puts product cybersecurity obligations on every supplier that places digital equipment on the EU market, from train builders to signalling and subsystem suppliers. This page summarises the sector guidance written by CER, UITP and UNIFE, and shows where our products help you meet specific obligations.
What The CRA Asks Of A Rail Supplier
The CRA is horizontal product legislation: one set of rules for every industry. It makes no special provision for rail, for TSIs, for vehicle authorisation or for fleets that stay in service for 30 years. It regulates any "product with digital elements" (PDE) placed on the EU market, from a balise to a complete train. For each PDE placed on the market from 11 December 2027, the manufacturer must run a cybersecurity risk assessment, meet the essential requirements of Annex I, perform due diligence on integrated third-party components, maintain a software bill of materials, handle vulnerabilities for a defined support period, and ship a CE marking backed by technical documentation.
Three points of interpretation matter most in rail, and the sector guidance (written jointly by operators and suppliers) confirms all three:
The contract decides what is a PDE, not the engineering. A router sold as a router is a PDE. The same router delivered inside a rolling stock contract is part of one larger PDE: the vehicle. An interlocking sold alone is a PDE; inside a signalling system contract, the system is the PDE. Whoever integrates and places the final product on the market carries manufacturer obligations for the whole, including due diligence on every component inside it.
Compliance applies per individual unit. When series production runs across 11 December 2027, the series splits. Units placed on the market before that date are exempt until they are substantially modified. Units placed after it must comply, even when they are identical. A fleet delivered across that date will legitimately mix CRA and non-CRA vehicles, and the vehicle authorisation framework accepts that. The guidance annex on vehicle authorisation confirms the CRA does not invalidate existing type authorisations; the applicant declares CRA conformity in the EC Declaration of Verification, and authorising entities do not re-assess it.
Security updates are not substantial modifications. A change whose purpose is to reduce cybersecurity risk, without new functionality or a new intended purpose, does not re-trigger CRA compliance for the product it is applied to (recital 39). The practical consequence: a supplier can patch and harden an in-service fleet, and add monitoring to it, without turning a legacy system into a new regulated product. Adding a new main function, a new interface or a new remote access path is different: that change is likely substantial.
Most Rail Products Self-Assess
The conformity route depends on the product class, and the product's own core functionality sets the class. Nothing is inherited in either direction: a train does not become "critical" because it contains a critical chip.
| Default Self-assessment (Module A) | TCMS, interlocking, RBC, EVC, CBTC, ETCS on-board, door and brake controllers, passenger information, CCTV, ticketing, complete rolling stock. Most rail-specific products belong in this class. |
|---|---|
| Important Class I Self-assessment only via harmonised standard or EU scheme | Routers, switches, network management, operating systems, SIEM, IAM, PKI, 4G/5G/FRMCS modems. |
| Important Class II Notified body, unless an EU certification scheme applies | Firewalls, intrusion detection and prevention systems, hypervisors. |
| Critical Notified body always | HSMs, TPMs, smartcards, secure elements. |
The key point for OEMs: nearly everything rail-specific sits in the default class, so third-party certification is rarely the issue. The real work is the risk assessment, the Annex I evidence, the vulnerability handling process, and the documentation that proves all of it. The security and network components you integrate (firewalls, IDS, switches) sit in the important classes, which means the due diligence you perform on them must be more thorough.
Classifications follow the sector guidance's examples and are illustrative; every product needs a case-by-case assessment against its own core functionality.
Five Practical Problems The Guidance Solves
1. Projects signed years before the CRA existed. A fleet contract signed in 2022 delivers vehicles into 2030. The guidance answer: every unit placed on the market after 11 December 2027 must comply, and compliance may rest on a system-level risk assessment. In it, the manufacturer justifies some essential requirements as not applicable and treats the residual risk with mitigating measures. Manufacturer and asset owner then record the result in a formal mutual agreement with documented security-related application conditions (SecRACs). The agreement transfers no accountability; it removes the ambiguity that can stall a project.
2. Legacy components inside new products. A component bought before the deadline and integrated afterwards does not stop the integrating product from complying. The integrator analyses the residual risk the component brings and manages it at product level. The guidance's worked examples name the typically achievable measures for parts that stay technically "as is": security monitoring, VLANs, encryption, hardening. Monitoring is first on that list for a practical reason: it reduces risk without changing a certified design.
3. Extending systems that predate the Act. A new coach for an existing fleet, or a new balise on an existing ETCS line, must itself comply, yet must interoperate with equipment that will never be CRA compliant. The guidance labels these compatible system extensions. Where interoperability legislation forces an interface requirement on you, you justify it in the technical documentation, treat the remaining risk with compensating countermeasures, and disclose it to the asset owner. The flexibility covers the legacy interface only, never the rest of the design.
4. Spare parts and 40-year obsolescence. Identical spares built to the original specification are exempt outright. The Commission reads "identical" strictly, so a functionally equivalent replacement with new hardware or software is not an exempt spare; it is a product in its own right. Fitting one still counts as repair, though: if the purpose, exposure and risk of the host system are unchanged, the host system does not need retrospective compliance, and no one has to recreate design documentation from the 1990s.
5. Support periods measured against rail lifetimes. Five years is the minimum, not the default. The support period must reflect expected use time, documented in the technical file, and rolling stock is expected to run for 25 to 50 years. Suppliers will carry vulnerability identification, risk-prioritised remediation and free security updates across decades, possibly fulfilled through planned hardware refresh cycles. Tailor-made products allow paid update arrangements by mutual agreement, but the obligations themselves remain.
Where RazorSecure Helps, Obligation By Obligation
We build monitoring, detection and secure access products for rail, in service on more than 3,200 vehicles. Each one does a specific job under the CRA. None of them makes a product "CRA compliant"; no product does. The CE marking and the declaration of conformity stay with the manufacturer. What we provide is detection capability and the evidence behind it.
| Become aware within hours, report within 24 (Art. 14, from 11 Sep 2026, in-service fleets included) | Delta detects anomalous behaviour on vehicle networks as it happens; the Dashboard holds the alert history and timeline you need for the 24-hour, 72-hour and final reports. With managed monitoring, our analysts triage the alerts. |
|---|---|
| Mitigate residual risk on legacy or as-is components in pre-existing projects | Security monitoring is the first "typically achievable measure" the sector guidance names for exactly this case. Delta deploys as software on EN 50155 hardware already on the vehicle, including Westermo switches, so the certified design does not change. |
| Annex I: log and detect security-relevant events inside the product | OEMs integrate our detection into their own PDE to implement the logging and anomaly detection requirements with components already in service on 3,200+ vehicles. The draft Commission guidance (section 7.3) names alerts on abnormal behaviour as the kind of product-level measure it expects. |
| Due diligence on integrated components, SBOM, vulnerability handling across the support period | Echo maintains the live asset and configuration inventory: what is actually fitted, at which software version, and whether it has drifted from baseline. Vulnerability triage depends on that record, and in rail it has to stay accurate for 25+ years. |
| Evidence behind SecRACs and manufacturer / asset owner mutual agreements | Dashboard reporting shows the agreed compensating measures running every month, with the alert records that support them. That evidence keeps the risk acceptance defensible. |
| Fitting security to in-service fleets without re-triggering compliance | Deploying detection or hardening is a risk-reducing change, not a substantial modification (recital 39). The regulation deliberately avoids penalising changes that reduce risk, so retrofitting monitoring does not re-trigger conformity assessment. |
Working with us as an OEM or system supplier? See Partners & OEMs, or the wider standards & compliance overview and the global regulations map.
Sources: Expert Guidance on the Implementation of the Cyber Resilience Act in Mainline and Urban Railways v1.0.0 (CER, UITP, UNIFE, April 2026, TLP:CLEAR) with its annex on vehicle authorisation, and the draft Commission guidance on the application of the CRA. Neither is legally binding; only the Court of Justice of the EU can interpret the CRA authoritatively. This page is a summary, not legal advice.