Cybersecurity in rolling stock has moved beyond a late-stage IT check and become a vehicle-engineering discipline. Network architecture, supplier responsibilities, software updates, secrets management and vulnerability handling all have to remain workable throughout a fleet’s service life.
We spoke with Remigiusz Kołłątaj, Cybersecurity Architect at Endego, about where rolling-stock programmes are most exposed, why component-level compliance can still leave system-level gaps, and what it takes to make cybersecurity buildable, verifiable and maintainable in the vehicle.
Remigiusz Kołłątaj: Compliance is the floor, not the ceiling. A standard such as IEC 62443 provides a framework for defining and implementing appropriate protection, but it does not tell you what your specific vehicle actually needs. That comes from your own risk assessment.
I see programmes where every supplier has ticked “compliant” in a table, and the vehicle still has a network path nobody documented. Compliance means you did the work in an organised way. Security means the vehicle is designed to resist the relevant threat scenarios and manage the residual risk. They usually overlap, but not always.
“Compliance is the floor, not the ceiling.”
Remigiusz Kołłątaj: Because the vehicle stopped being an isolated machine. A modern vehicle may include a train-to-ground link, remote diagnostics, passenger Wi-Fi, over-the-air updates and service interfaces such as USB ports in the cab.
Traditional enterprise IT security often focuses heavily on data and business systems. In rolling stock, we also protect a moving vehicle with people inside. The consequence of a cybersecurity failure is not only a data leak; it can affect availability and, depending on the function and architecture, may also have safety implications.
There is also a very practical difference. Enterprise IT may be able to patch on Tuesday evening. We often cannot. A vehicle may be in service, its configuration may already be approved for operation, and the next maintenance window may be months away. That makes cybersecurity an engineering problem, not simply an IT problem.
Remigiusz Kołłątaj: At the requirements stage, together with the architecture. In IEC 62443, the zones-and-conduits model and the architecture develop together — one feeds the other.
If you fix the network architecture first and do the risk assessment afterwards, the assessment can only confirm what you have already built. Every finding then becomes more expensive.
The cheapest security decision in the whole programme may be where you draw a network boundary on a diagram. The expensive discovery is finding during commissioning that infotainment and a control function share one computer.
“The cheapest security decision may be where you draw a network boundary on a diagram.”
Remigiusz Kołłątaj: It says who does what, and it says how you will check it. “The system shall be secure” is not a requirement.
A requirement such as “Every zone boundary shall have a named enforcement point, and a conduit without one shall not be commissioned” is different. A supplier can implement it, and a test engineer can verify whether it has been met.
I always write the verification method together with the requirement text. If I cannot describe the test, the requirement is not finished. Each requirement should also trace back to the relevant clause or risk decision, so nobody has to argue later about why it is there.
Remigiusz Kołłątaj: It is where I see the biggest gap. A supplier declares “requirement covered” and everyone moves on. But the component requirements in IEC 62443-4-2 do not map one-to-one to the system-level requirements in IEC 62443-3-3.
Some system-level requirements cannot be satisfied by a component in isolation and have to be addressed through system architecture and integration. That means you can have individually compliant components and still have a real gap at system level because everybody assumed somebody else was covering it.
The fix is not simply more pressure on suppliers. It is knowing exactly which requirements belong to you as the system integrator and writing them down explicitly.
Remigiusz Kołłątaj: Very much. Thirty years is longer than most of the software in the vehicle will be supported. The operating system you ship today may be end-of-life in eight years.
So the design-time question is not only “Is this secure now?” It is also “Who patches this in year twelve, and can it even be updated?” That is a commercial and contractual question as much as a technical one.
Long life also means the cryptography you choose today must be replaceable later. You should be able to change an algorithm without redesigning the product.
Remigiusz Kołłątaj: Yes, and regulatory expectations are moving in that direction too. But an SBOM by itself is only a list.
Its value appears when a new vulnerability is published and you can answer, in an hour instead of three weeks: which vehicles contain this component, in which version, and does it matter in this configuration?
That means the SBOM should be machine-readable, produced by the build process and delivered with every release — not written once in Excel at the end of the project.
Without the process behind it, an SBOM is just a document nobody opens.
Remigiusz Kołłątaj: I would start with separation. Control functions should not share a network or a computer with passenger and comfort functions without a defined and justified separation mechanism.
Then apply a default-deny principle at zone boundaries where appropriate: everything that is allowed should be listed and justified. For identity, avoid shared accounts and default passwords, and give every service account only the rights it needs.
You also need software integrity, so the vehicle refuses code that is not signed, and logging with a common time source — otherwise you cannot reconstruct an incident.
One important point is often forgotten: the vehicle must continue to operate appropriately when the connection to the ground is lost.
Remigiusz Kołłątaj: Three things. First, the current European rail-specific reference CLC/TS 50701 and the draft IEC 63452 standard that is being developed for the international railway domain. IEC 63452 is intended to adapt relevant IEC 62443 requirements to the railway context and align cybersecurity activities with the railway lifecycle, including their relationship with RAMS and safety processes.
Second, the EU Cyber Resilience Act, which applies to products with digital elements where they fall within its scope. The reporting obligations apply from 11 September 2026, while the main obligations apply from 11 December 2027. So this is not only a 2027 topic; engineering teams need to prepare now.
Third, NIS2. Its direct applicability depends on the entity, its role and national implementation, but OEMs can also see cybersecurity expectations arrive through operators, customer contracts and tenders.
Rail does not currently have one single sector-wide cybersecurity type-approval regulation equivalent to UNECE R155 for road vehicles. In practice, the cybersecurity annex of a tender can become the requirement set you actually have to deliver against — so read it carefully.
Remigiusz Kołłątaj: No, and I would be careful with anyone who says yes. The scope runs from risk assessment and requirements engineering through network architecture, embedded software and cryptography to penetration testing and operations over decades.
Those are different professions. What one person can do is own the structure: make sure requirements are consistent, responsibilities are assigned, and nothing falls between the system, component and application levels.
That coordinating role is often the one that is missing — more often than any single technical skill.
Remigiusz Kołłątaj: Penetration testing belongs in verification, once the architecture and requirements are sufficiently mature. It can be repeated at different stages, but it should not be the first serious cybersecurity activity in the programme.
A penetration test tells you what a tester found in the time you paid for. It cannot tell you that the vehicle is secure.
If the first time you seriously think about security is when the penetration-test report arrives, the findings are likely to be architectural. By then, they are much harder and more expensive to fix.
Used correctly, penetration testing verifies decisions you already made deliberately. Used incorrectly, it becomes a substitute for making them.
Remigiusz Kołłątaj: That is where the design pays off — or does not.
You need three things ready in advance: an SBOM to know whether you are affected, a way to receive vulnerability reports and make a decision quickly, and an update path that is safe to use on a vehicle in operation.
The hardest part is often not the patch. It is the decision. Not every published CVE affecting a component is exploitable in the vehicle’s actual configuration, so the first task is to assess relevance and exposure through a defined vulnerability-handling process.
You therefore need a written rule for how you decide and a record of that decision. Otherwise every CVE becomes a crisis meeting.
Remigiusz Kołłątaj: Not redesign — prepare. For a vehicle entering service now and potentially running into the 2050s, the question is real, but the answer is crypto-agility rather than a rewrite.
Algorithms and key lengths should be configurable rather than hard-coded. Certificates and keys should be replaceable in the field, and you should know where every key lives.
Then, when migration becomes necessary, it can be an update rather than a new product. The first place I would look is the software-update signing trust chain, because it has to remain trustworthy — and itself be maintainable — throughout the life of the fleet.
Remigiusz Kołłątaj: We work as part of the OEM’s engineering workflow rather than as a separate advisory layer.
Our role is to translate cybersecurity standards, risk decisions and vehicle-level security objectives into requirements that suppliers can implement and test teams can verify — from vehicle architecture through component and embedded-system implementation.
Just as importantly, we support traceability across that chain. A requirement should not get lost when it moves from the vehicle architecture into a supplier specification, and then into implementation and verification.
What differentiates our approach is that we treat cybersecurity as a vehicle-engineering discipline. The objective is not to create a separate set of security documents next to the programme. It is to make cybersecurity buildable, verifiable and maintainable within the vehicle development process.
Our focus is vehicle-level embedded and operational technology (OT) cybersecurity. We do not position this offer around corporate IT, SOC services or railway signalling systems such as ETCS or CBTC.
Remigiusz Kołłątaj: “How do you manage secrets in your vehicles?” It sounds like a small housekeeping question. It is not. The answer unfolds, and every layer tells you something about the maturity of the architecture.
Start with passwords. Everyone agrees they should be unique per vehicle. But the system image is identical for the whole fleet and the filesystem may be read-only — for good reasons. Someone therefore has to generate the password and write it into the one place that remains writable, during production or commissioning.
Then think about service ten years later. Somebody must still be able to retrieve the credential, which means it has to be stored and protected for the whole life of the fleet. Often the answer is a spreadsheet. Sometimes it is a proper secrets vault, which is better — but it is still another system that has to be operated, secured and funded, and it does not solve rotation by itself.
A better architectural answer is to remove password authentication where possible and move to certificates.
Take remote access. SSH keys are better than passwords, but managing authorized_keys across thousands of vehicles creates its own lifecycle problem. If an employee leaves, you do not want to touch every vehicle. SSH certificates signed by your own authority give you short-lived identities that can be controlled centrally without updating every endpoint.
The same applies to a service laptop joining the vehicle network. MAC-based admission is weak because a MAC address is not a secret. EAP-TLS with certificates gives you real device identity.
Certificates everywhere, and hardware tokens for people as the final step. The token also carries a certificate and has one very practical advantage: when a service technician leaves, the token can be reclaimed and the associated credential revoked. Access can then be removed centrally without touching every vehicle.
If I hear “EAP-TLS” and “SSH certificates” in the answer, I know the conversation is already at a more mature architectural level.
“How do you manage secrets in your vehicles?”
For rolling-stock OEMs, the challenge is not simply to prove that cybersecurity requirements exist. It is to ensure that they are correctly allocated, implemented, verified and maintained across the full vehicle lifecycle.
That means connecting risk assessment with architecture, supplier responsibilities, software configuration, verification, vulnerability management and long-term access control.
Endego will be available for technical discussions around vehicle-level embedded and OT cybersecurity ahead of and during InnoTrans 2026.
A first conversation can focus on one concrete engineering issue: a network boundary, supplier responsibility, update path, SBOM process, secrets-management approach or a gap between a cybersecurity requirement and the way it is implemented in the vehicle.
Rolling stock OEMs can reduce prototype risk by defining the validation scope early, connecting design with FEM analysis, checking critical joints and interfaces, and preparing traceable evidence before manufacturing begins. Simulation does not remove the need for physical testing. It helps make the prototype a confirmation of a mature design rather than the first place where major structural weaknesses are discovered.
Read moreAn electric motor is only one component of a vehicle’s e-drive system. Efficiency, range, performance and durability depend on the combined operation of the motor, inverter, battery, battery management system (BMS), cooling system, transmission, control software and mechanical integration. Electric powertrain development should therefore address the complete system and the vehicle’s real operating profile from the outset.
Read moreEndego, a portfolio company of Abris Capital Partners, has completed the sale of its Siemens and Altair software distribution business to Volupe Group. The transaction allows Endego to sharpen its focus on engineering and digitalization services for customers in the mobility and industrial sectors.
Read more
