Back to the Overview

Beyond Secure Boot: Why Runtime Protection Matters for Embedded Linux Security

– Webcasts & Media, ELinOS, Linux, Security
Please accept functional cookies to watch this video.

As cyber threats evolve and regulatory demands increase, securing an embedded operating system is no longer enough. Together with Karamba Security, SYSGO explores how proactive runtime protection can strengthen embedded Linux platforms and help manufacturers stay ahead of emerging threats.

Modern embedded systems are becoming increasingly connected, software-driven and complex. From industrial automation and transportation to medical devices and other critical applications, embedded platforms rely on sophisticated software stacks, third-party components and remote connectivity. While these capabilities enable innovation, they also create new opportunities for cyberattacks.

Traditional security measures such as system hardening, secure boot and secure software updates remain essential. However, they cannot address every threat that emerges once a system is running.

In the latest episode of the SYSGO Techcast, SYSGO welcomes its technology partner Karamba Security to discuss why runtime protection is becoming an increasingly important part of embedded cybersecurity strategies and how the integration of Karamba's XGuard technology with SYSGO's ELinOS industrial Linux distribution provides an additional layer of protection.

A changing Threat Landscape calls for proactive Security

Embedded manufacturers face two developments that are fundamentally changing their approach to cybersecurity: The increasing sophistication of cyberattacks and growing regulatory expectations.

Artificial intelligence is accelerating vulnerability research and lowering the technical barriers to exploiting software weaknesses. Vulnerabilities in operating systems, open-source libraries and third-party applications can potentially be weaponized much faster than before.

For embedded manufacturers, this creates a particular challenge. Unlike conventional IT environments, embedded devices often operate under strict availability, reliability and safety requirements. Software updates may require extensive validation, and immediate patch deployment is not always feasible.

As a result, relying exclusively on a traditional detect-and-patch strategy is becoming increasingly difficult.

At the same time, regulatory frameworks such as the EU Cyber Resilience Act (CRA) are placing greater emphasis on cybersecurity throughout the product lifecycle, including vulnerability management and effective protective measures.

A proactive approach can help address both challenges by preventing unauthorized activities before they compromise the system, rather than relying solely on detecting vulnerabilities and deploying patches afterward.

Secure Boot is essential – But what happens after Startup?

Secure Boot establishes trust in the software loaded during system startup by verifying that the firmware or operating system image is authentic and has not been tampered with. Similarly, secure update mechanisms help ensure that only authorized software updates are installed. Both mechanisms are fundamental building blocks of a secure embedded architecture.

However, their primary purpose is to establish and maintain trust in the software being loaded or installed. They do not automatically prevent attackers from exploiting vulnerabilities in applications, services or the operating system after startup.

Consider an embedded Linux device with remote connectivity. Even if it boots from a verified image, an attacker might exploit a vulnerable network service to execute commands, manipulate configuration files or escalate privileges.

This distinction highlights an important principle: A trusted system at startup is not necessarily protected against every threat during operation.

Runtime protection addresses this gap by enforcing security policies while applications and services are executing.

ELinOS and XGuard: Combining a secure Linux Foundation with Runtime Protection

SYSGO's ELinOS provides an industrial-grade embedded Linux environment designed for long-term maintainability, reliability and security. Its capabilities include system hardening, secure boot, secure updates and support for managing software vulnerabilities.

Building on this foundation, Karamba Security's XGuard adds runtime security controls designed to prevent unauthorized activities, even when vulnerabilities are present in the system. One of its central mechanisms is binary allowlisting.

Rather than attempting to identify known malware through signatures or continuously updated blocklists, binary allowlisting defines which executable components are trusted and permitted to run.

XGuard uses cryptographic hashes to validate executable components, including applications, shared libraries, kernel modules and scripts. Software that does not match the trusted allowlist can be prevented from executing, regardless of whether it originates from persistent storage, temporary memory or external media.

This approach is particularly effective in embedded environments, where the software configuration is typically well defined and changes less frequently than on general-purpose computing platforms. The result is a proactive security mechanism that can significantly reduce opportunities for attackers to introduce and execute unauthorized code.

Preventing the Misuse of trusted Applications

Blocking unknown software is only one part of runtime protection. Attackers can also misuse legitimate applications already installed on the system. These techniques are commonly known as Living-off-the-Land (LotL) attacks.

For example, an embedded Linux device may legitimately use the iptables utility to configure firewall rules during startup. If an attacker exploits a command injection vulnerability, they might attempt to invoke the same trusted utility to modify those rules and expose previously restricted network services. Traditional allowlisting would not necessarily prevent this behavior because iptables itself is an authorized application.

To address this scenario, XGuard introduces a capability called Associated Execution. This mechanism restricts which applications or processes may launch specific executables. In the firewall example, the system can be configured so that only the designated initialization script is authorized to execute iptables. Any attempt to invoke the utility from an unauthorized context can then be blocked.

Associated Execution therefore extends protection beyond determining what software may run to controlling how and by whom trusted software may be used. This principle is particularly relevant for increasingly complex embedded systems, including platforms integrating AI inference capabilities and other sensitive software components.

Protecting sensitive Data and System Configuration

Not every cyberattack requires executing malicious software. In some cases, manipulating a configuration file or other sensitive data is sufficient to compromise a system.

During the Techcast, Karamba Security describes a practical example involving a device that could be switched into a privileged debug mode through a configuration setting. Instead of introducing malicious code, an attacker only needed to manipulate the configuration file and trigger a reboot. The device would subsequently start in debug mode, exposing capabilities that should not have been accessible during normal operation. This illustrates why protecting executable code alone is insufficient.

XGuard also provides file and directory protection mechanisms that control which trusted processes may access or modify sensitive assets. These mechanisms can help protect configuration files, databases, system logs and other critical resources against unauthorized modification. By associating access permissions with cryptographically identified applications, manufacturers can establish more granular controls over sensitive system data.

The same principle also applies to emerging use cases such as protecting AI models against unauthorized manipulation.

Building Security into the entire Embedded Lifecycle

The combination of ELinOS and XGuard reflects a broader shift in embedded cybersecurity: Moving from individual protective features toward a layered security architecture.

Secure Boot helps establish trust at startup. Secure update mechanisms protect the software delivery process. System hardening reduces the available attack surface, while runtime controls restrict unauthorized code execution, prevent the misuse of legitimate applications and protect sensitive resources.

Together, these complementary mechanisms strengthen the security posture of embedded devices throughout their operational lifecycle.

Importantly, proactive runtime protection does not eliminate the need for vulnerability monitoring, patch management or secure development practices. Instead, it provides an additional line of defense that can help reduce exposure while vulnerabilities are being investigated and remediated.

For manufacturers facing longer product lifecycles, increasingly connected deployments and evolving cybersecurity regulations, this layered approach offers a practical foundation for developing more resilient embedded systems.