Long-Term Maintenance, Security Updates, Hardware Diversity and the Future of Industrial Linux

Embedded products live on a very different timescale from consumer software. While applications and operating systems on consumer devices may change every few weeks or months, industrial systems can remain deployed for 15 or even 20 years. During that time, hardware stays in the field, vulnerabilities are discovered, software dependencies evolve and new security requirements emerge.

For the engineers responsible for these systems, the challenge is not simply to build a Linux image that works today. It is to establish a stable software foundation that can be maintained, updated and secured throughout the product lifecycle.

In the second episode of the SYSGO TechCast on ELinOS 8, we take a closer look at exactly this challenge—and at the engineering processes behind the platform.

Designing for a long Software Lifecycle

Long-term support starts with the components that go into the system.

The team around ELinOS carefully selects the packages and Linux kernel versions integrated into its product, with a focus on long-term support. Standard maintenance is provided for up to five years, including software updates, bug fixes and security fixes. This is followed by a long-term support phase of up to ten years, during which security updates and regular updates for packages and the Linux kernel continue.

But long-term support does not necessarily mean simply keeping every component unchanged forever.

After ten years, the question becomes more nuanced. Open-source projects continue to evolve, new vulnerabilities emerge and major package versions may become available. Rather than automatically forcing a major update, SYSGO works with customers to assess which components actually need to change and when an update makes sense.

This is an important distinction for industrial systems: Maintainability is not the same as constantly being on the latest version.

Backporting Security without destabilizing the System

One of the biggest challenges in maintaining embedded Linux is the Linux kernel itself. Security patches are released regularly, but applying them is not always as simple as updating to the newest kernel. A customer's product may already be deeply integrated with a particular kernel version, hardware configuration or vendor BSP. Moving to a completely new kernel could introduce changes that require extensive testing.

ELinOS therefore integrates relevant security patches from the Linux community while also monitoring the BSPs provided by hardware vendors. Vendor updates may not contain every security patch, or the vendor may have already moved to a newer kernel version that is outside the customer's current scope. The goal is to maintain the customer's stable baseline while still addressing security issues.

This process is supported by automated board testing. Updates are tested across the supported hardware platforms to identify problems and ensure that security fixes do not unintentionally compromise system functionality.

Hardware Diversity requires Automation

Embedded Linux no longer means running on a handful of standardized PC platforms. Industrial systems use a wide range of processors, boards and hardware configurations. At the same time, security updates, kernel changes and BSP updates have to be validated across those platforms.

For ELinOS, automated testing is therefore an important part of maintaining hardware support. The development team uses automated processes to run software on supported boards and identify issues as changes are introduced. The approach also prepares the platform for emerging architectures.

RISC-V, for example, is becoming increasingly relevant, with more boards and application possibilities entering the market. ELinOS and PikeOS already support the architecture, with further expansion expected as RISC-V develops across different industries.

Bringing Linux into a Mixed-Criticality Architecture

ELinOS does not exist in isolation from the rest of the SYSGO ecosystem. For applications requiring strict separation and different levels of criticality, ELinOS can run as a Linux personality within a PikeOS partition.

PikeOS provides the separation, isolation and hypervisor functionality, while ELinOS provides the Linux environment and access to the broad open-source ecosystem. Depending on the architecture, ELinOS can run using hardware virtualization or paravirtualization.

This combination can be particularly useful when a system needs both:

• a controlled and isolated environment for critical functions, and
• Linux functionality, applications or drivers for less critical parts of the system.

A Linux partition can also be used for specific hardware where an appropriate Linux driver is already available, avoiding the need to develop every driver independently. The result is a flexible architecture that combines the strengths of both technologies.

Rust and the Evolution of embedded Development

Security requirements are also influencing the programming languages used in embedded systems. Rust is gaining a lot of momentum because its language design addresses several classes of memory-safety issues historically associated with C code. The ELinOS development environment already provides Rust support, including the Rust compiler and development capabilities within CODEO.

Rust is also increasingly finding its way into the Linux kernel and the wider open-source ecosystem. The expectation is that this trend will continue: Existing C-based tools and components may increasingly be complemented or replaced by Rust implementations where the security characteristics of the language provide advantages.

For industrial embedded Linux, this could become increasingly relevant as cybersecurity requirements continue to grow.

The next Challenge: Keeping Systems updated

Looking further ahead, one of the strongest trends identified in the TechCast is not necessarily a new processor or programming language. It is the growing need to keep embedded systems up to date.

Many deployed embedded systems are still not updated as frequently as modern cybersecurity demands would suggest. At the same time, OEMs may not have the resources to build dedicated teams that continuously monitor vulnerabilities, rebuild software and determine how security fixes should be integrated into a stable product. This becomes particularly challenging when using highly customizable build environments.

A community project may have already moved to a new package version, while the product itself cannot simply follow that change because of hardware dependencies, testing constraints or the maturity of the current product.

Someone therefore needs to make the engineering decision:

Can we update? Should we update? Or should the security fix be backported to our existing version?

This is an area where professional maintenance can provide significant value. With ELinOS, customers receive a stable baseline together with security updates and support for understanding and integrating those updates, allowing their own engineering teams to focus more on the application itself.

Small Systems can still be powerful

The discussion also touches on one of the less obvious strengths of ELinOS: Its ability to create very small, purpose-built systems. One example is the way ELinOS handles systemd.

Rather than automatically bringing hundreds of services into an embedded system, the feature configurator allows developers to strip the environment down to what is actually needed. The result can be a smaller system and a faster boot process, adapted to the specific application requirements.

This reflects a broader philosophy behind industrial Linux: More functionality does not necessarily mean a better embedded system.

For many products, controlling exactly what runs can be just as important as what the system is capable of running.

Embedded Systems are no longer "small Computers"

One of the common misconceptions is that embedded systems are necessarily limited in terms of processing power, memory or connectivity.

Modern embedded platforms can be extremely powerful. Automotive systems, mobile platforms and industrial devices increasingly combine powerful processors with numerous interfaces, wireless connectivity and complex software stacks.

But increased capability also means increased complexity.

Every additional driver, interface, network stack or software layer can potentially introduce another security consideration. Highly connected devices can therefore require continuous monitoring and maintenance to identify and address newly discovered vulnerabilities.

Cybersecurity is becoming a Lifecycle Issue

Another major lesson from the development of ELinOS 8 is how closely software development is now connected to cybersecurity regulation.

The Cyber Resilience Act, for example, requires companies to consider cybersecurity across the product and its associated processes. For the ELinOS development team, understanding these requirements involved looking beyond individual technical features and considering their impact across the overall product lifecycle.

This reinforces an important point: Security is not something that can simply be added at the end of development.

It influences architecture, software selection, maintenance, update processes and the way suppliers and customers work together.

Fast Development without waiting for Hardware

Despite all this complexity, development itself does not have to become slow. One of the key messages is the speed at which an ELinOS project can be configured, built and tested.

With a supported board and an ELinOS installation, creating a project, selecting the required features and building and deploying an image can take less than two minutes. Developers can also use the included QEMU virtual machine to begin development and test the system before hardware is available.

Features can be enabled, the project rebuilt and the result tested in QEMU or deployed to hardware without having to rebuild a large collection of unrelated packages. For developers, that short feedback loop can make a significant difference.

Building for today, maintaining for tomorrow

The story of ELinOS 8 is not simply about a new version of embedded Linux. It is about addressing the reality that industrial software has to live much longer than most software products. It has to adapt to new vulnerabilities, changing hardware, evolving open-source components and new cybersecurity expectations—without sacrificing the stability that industrial customers depend on.

From long-term package maintenance and automated hardware testing to PikeOS integration, Rust support and fast development workflows, ELinOS is designed around that reality.

And perhaps the simplest way to summarize the engineering philosophy is this:

Build only what you need. Test what you build. Keep it secure.

And make it maintainable for as long as the product needs it.