Case study: Maintaining a secure and up-to-date embedded system in the railway sector

Our customer came to us with a challenge that many railway manufacturers face today: keeping a 20 year lifecycle product secure in a world where vulnerabilities appear daily and regulations evolve faster than hardware cycles.
Here’s how we helped them turn a growing maintenance risk into a predictable, scalable process.

The challenge: maintaining secure railway systems over decades

Before diving into the heart of the matter, let’s clarify a few terms. In embedded system software maintenance, three main types stand out:

  • Corrective maintenance, aimed at fixing bugs and anomalies.
  • Adaptive maintenance, which supports functional or technical changes.
  • And finally, security maintenance, which we’ll focus on here.

This last point is becoming strategic: regulations are multiplying and so are cyberattacks. Organizations in the railway industry no longer have a choice: they must protect their products against intrusions and vulnerabilities. It’s a regulatory requirement, but also a commercial necessity.

A recent example illustrates the stakes well: a vulnerability was discovered in the tire pressure sensor of Tesla’s Model 3. This flaw allowed unauthorized communication on the vehicle’s CAN data bus, opening the door to critical manipulations. Even a seemingly minor component can have major consequences.

No one wants to make headlines for a security breach. That’s why maintaining security is now one of the key component of IoT and embedded product strategy.

railway embedded systems

Why traditional maintenance approaches fall short

Software maintenance in embedded railway systems has undergone a profound transformation in recent years. This shift is driven by a range of factors. Let’s break it down.

1. A changing technical landscape

One of the first major changes concerns how software dependencies are managed.

Twenty years ago, developing an embedded application meant working with a handful of well-known libraries, compiled locally. Today, every feature relies on dozens of external dependencies, often from diverse and sometimes unreliable sources.

This explosion of dependencies has brought with it a troubling trend: a decline in trust in the software supply chain. The number of supply chain attacks is on the rise, making preventive maintenance both more complex and more critical.

Another shift: deployment topologies. Systems that were once isolated in secure enclaves are now frequently connected to the internet, integrated into hybrid architectures. This dramatically increases the attack surface and demands heightened security vigilance.

2. More modular and interconnected products

Gone are the days of exhaustive, crystal-clear specifications that laid out every single requirement for building a product. Today, industrial players are asking for modular, interoperable, and interchangeable software components they can assemble as needed.
This shift calls for more frequent and fine-grained maintenance, since each technical building block can evolve independently.

3. More triggers for maintenance

Maintenance operations are no longer driven solely by functional upgrades or bug fixes. A third trigger has emerged: compatibility breaks between modules and interfaces.
With small, specialized teams releasing new versions at a steady pace, interfaces evolve rapidly. This leads to incompatibilities that require frequent adjustments and, inevitably, more maintenance…

4. Regulatory pressure and cybersecurity risks

Cyber risk has become a major trigger for corrective maintenance. Each week brings its share of newly discovered vulnerabilities and published exploits.
This growing awareness has had a positive effect, prompting institutions to formalize regulatory frameworks. Two European texts illustrate this trend:

What is the Cyber Resilience Act (CRA)

These regulations aim to ensure the security of IoT products and harmonize practices across the European Union. They mandate the integration of cybersecurity from the design phase: physical access control, secure boot implementation, data protection, documentation of security mechanisms, update policies, and more. Once the product is deployed, it must be regularly monitored, security flaws corrected, and all actions documented.

5. Maintenance ROI

Fifteen years ago, some companies were already investing in secure maintenance but mostly for branding or positioning reasons. Keeping a product up-to-date and secure enhanced its marketing value. Security solution providers, like firewall manufacturers, understood this well and had already built dedicated maintenance budgets into their offerings.

What’s changed is that maintenance is no longer a strategic choice reserved for a few proactive players. It’s becoming a necessity for a growing number of companies, driven by an unstable geopolitical climate, new regulations, and pressure from cyber threats.

In other words, where some used to take the time to do things properly, others now have to move fast, because they’re forced to. This doesn’t diminish the value of cybersecurity activities, quite the opposite, but it does shift engineering teams’ economic logic: the focus is now on cost optimization and streamlining maintenance efforts.

Building a risk-driven maintenance strategy

Rolling out an effective maintenance strategy hinges on a precise risk analysis and a well-structured organization. Here are a few steps followed by our customer to get it right.

railway secure maintenance

1. Platform-related risks assessment

It all started with a risk assessment:

  • Does the platform provide access to or control over critical systems?
  • Is that access physical, local, or remote?
  • Can the software be updated remotely, or does it require on-site intervention?

These factors directly influenced the type of maintenance to implement: update frequency, security level, validation procedures, and more.

2. Update and validation processes definition

Once the software were updated, the next logic step was to validate that everything still worked as expected:

  • Are critical features still fully operational?
  • Have the patches introduced any regressions?

This calls for automated testing, validation reports, and ongoing monitoring of functional quality.

3. Tailor the strategy to the types of packages used

The kind of software packages in use has a direct impact on maintenance:

  • Application packages are generally easier to update.
  • GNU packages, which are more numerous and diverse, can complicate operations.

4. Choose the right analysis frequency

The frequency of vulnerability scans depended directly on the level of risk identified by our customer:

  • Critical products → daily analysis
  • Moderate products → weekly analysis
  • Stable products → monthly analysis

Vulnerability remediation is prioritized based on their severity score and attack vector, whether access is physical, local, or remote.

The Embedded Kit - Reference DevOps platform for embdded Linux maintenance - CVE Scan and Pluma automated testing

5. Automation

Maintenance is an ongoing effort. Vulnerabilities evolve daily, and manual remediation simply isn’t scalable. That’s why automation was a key lever:

  • Automatic generation of vulnerability reports
  • Integration into CI/CD pipelines
  • Deployment of automated tests and remediation reports

This allows our customer to focus human efforts on high-value fixes.

6. Share fixes across platforms

When multiple platforms share common components, it makes sense to pool fixes:

  • A package validated on one platform can be reused on another.
  • This reduces maintenance workload and ensures functional consistency.

7. Mobilize the right skills

Maintenance requires a diverse pool of expertise:

  • Cybersecurity engineers for vulnerability analysis
  • Embedded systems engineers for low-level work (BSP)
  • Middleware developers for application logic
  • DevOps experts for automation

8. Integrate the right tools

CVE Scan web interface - Dashboard view

A well-integrated vulnerability scanning tool makes all the difference. That’s why our railway customer selected CVE Scan tool to manage vulnerabilities in its Linux systems. It’s used for:

  • Automated CVE detection via a command-line tool, configurable to run at the desired frequency
  • Annotation and remediation of vulnerabilities through a locally deployable web platform, complete with access rights management

Keeping maintenance costs under control

Software maintenance represents a significant investment within an R&D budget. Its cost varies depending on several factors: frequency of vulnerability scans, number of issues to fix, speed of response, number of platforms involved… Price ranges go from 20,000€ per year to several hundred thousand euros, depending on project complexity.

So how did our railway customer keep these costs under control and prevent their budget from spiralling out of control?

1. Structure teams to optimize resources

As mentioned earlier, maintenance requires multidisciplinary teams. These skills come at a cost, but they can be pooled intelligently.
That’s the approach our customer has taken via Witekio, offering a cross-functional team capable of working across multiple embedded projects. Each member brings specific expertise, but the synergy between them boosts efficiency. Skill redundancy prevents bottlenecks during absences and ensures operational continuity.

2. Anticipate costs tied to update cadence

As mentioned earlier, maintenance requires multidisciplinary teams. These skills come at a cost, but they can be pooled intelligently.
That’s the approach our customer has taken via Witekio, offering a cross-functional team capable of working across multiple embedded projects. Each member brings specific expertise, but the synergy between them boosts efficiency. Skill redundancy prevents bottlenecks during absences and ensures operational continuity.

3. Managing long product lifecycles in the railway industry

The railway sector has a unique characteristic: extremely long product lifecycles. A “short” lifecycle spans 10 years, a “standard” one 20 years, and some go up to 30 years.
This creates a mismatch with the pace of software evolution.

It’s essential to invest time in client communication to explain why a version needs to be certified, even if it doesn’t introduce new features. This effort is hard to quantify, but it’s crucial to ensure long-term security.

train railway system maintenance

4. Focus on their core value

In such a complex environment, it’s important to stay focused on your core expertise. For our customer, that means concentrating on railway telephony and supervision of signaling equipment.

Security maintenance can be entrusted to a specialized partner capable of absorbing workload fluctuations. This will help optimize internal resources while maintaining a high level of quality.

Conclusion

Software maintenance in the railway sector is a balancing act. You have to fix vulnerabilities without compromising functionality, enhance products without introducing new attack surfaces, all while managing long product lifecycles.

By relying on specialized partners and effective tooling, our customer streamlined their maintenance efforts and kept their teams focused on building high‑value railway systems.

If you face similar challenges, tools like CVEScan can help you automate vulnerability monitoring and take control of your Linux maintenance.
Want to see how CVEScan can support your security strategy? Get in touch.

 

This case study is based on a talk given at SIDO Lyon 2025, featuring embedded software experts from Witekio, The Embedded Kit, and an anonymized railway customer.

Discover more from The Embedded Kit

Subscribe now to keep reading and get access to the full archive.

Continue reading