RTOS Security for Safety-Critical Embedded Systems

RTOS Security for Safety-Critical Embedded Systems Cybersecurity is becoming an evidence challenge For safety-critical embedded systems, cybersecurity is about understanding the software at the heart of the product, managing its vulnerabilities and being able to demonstrate how security has been addressed throughout its development lifecycle. The Real Time Operating System (RTOS) is an important part of that picture. Ask Us a Question For pricing, licensing, or any other sales or product related questions, please contact us. Contact Us What is RTOS security? RTOS security refers to the processes, controls and engineering practices used to protect an RTOS and the applications that depend on it from cybersecurity threats. Effective RTOS security considers how the software is designed, developed, tested and maintained through secure software development practices. This can include: • Threat analysis and risk assessment (TARA) • Security requirements and risk analysis • Secure design and coding • Security testing and verification • Security and software requirement traceability • Vulnerability management • Ongoing maintenance and support The objective is to understand how security has been addressed and what evidence supports that claim. Foundational software Foundational software includes components such as an RTOS and middleware that support the applications running above them. Because these components play a critical role within a system, organisations often look for strong assurance evidence, rigorous development processes and independent verification when selecting them for safety-critical applications. Download white paper: Performing The TARA Analysis Does an RTOS need to be connected to the internet to be a security risk? No. An RTOS may have no direct network interface or cloud connection but it is still an important part of a product’s security architecture. The RTOS provides the foundation on which the connected application software runs. It manages resources and system services that other software depends on. If that foundational software contains a vulnerability, the potential impact can extend into the wider system. This is particularly important when the same RTOS is reused across multiple products. A vulnerability in a widely deployed component can affect every product that incorporates it. Common RTOS security considerations RTOS security needs to be considered in the context of the complete embedded system. Depending on the architecture and application, this can include: Memory protection Memory corruption and invalid memory access can create security vulnerabilities and affect system behaviour. Privilege and resource access Software should only have access to the system resources and services it requires. Interfaces and communications APIs, communication paths and external interfaces need to be considered as potential routes into the system. Third-party software Libraries, middleware and other software components can introduce vulnerabilities into the product supply chain. Secure boot and software updates Products may need mechanisms to establish trust during start-up and securely manage software throughout the product lifecycle. These considerations cannot be separated completely from the wider application architecture. The RTOS is one layer of the overall security model. RTOS security and the EU Cyber Resilience Act The EU Cyber Resilience Act (CRA) introduces cybersecurity requirements for products with digital elements, including requirements covering secure development, vulnerability handling, security updates and documentation. For manufacturers and software suppliers, this means cybersecurity needs to be considered throughout the product lifecycle. An RTOS can form part of a product with digital elements. Information about its development, verification, vulnerabilities and maintenance may contribute to the manufacturer’s overall cybersecurity activities. The exact CRA obligations depend on the product and the organisation’s role in the supply chain. An RTOS does not, by itself, make a complete product compliant with the CRA. However, having appropriate software assurance evidence can help manufacturers build and demonstrate their own compliance. Download the white paper Why security evidence matters Security claims are difficult to assess without supporting evidence. Customers, procurement teams and auditors may want to understand how an embedded software component was developed, tested and maintained. They may also need evidence that requirements have been addressed and that the software can be traced back to its verification activities. This makes software assurance an important part of RTOS security. For safety-critical embedded systems, evidence can include, but is not limited to, risk and hazard analysis, verification and validation results and maintenance processes. The ability to provide this information gives engineering teams greater visibility into the software they are integrating. How SAFERTOS® supports RTOS security and software assurance For organisations that need additional assurance evidence, the SAFERTOS® Design Assurance Pack (DAP) provides supporting artefacts, traceability information and verification evidence. Explore the safertos dap Safety and security are intertwined Functional safety focuses on protecting systems from accidental failures. Cybersecurity focuses on protecting systems from intentional attacks. A cyberattack that compromises system behaviour may also affect safety-related functions. For this reason, many organisations now address safety and security together throughout the development lifecycle. Security considerations are most effective when addressed early in the design process, before silicon and architectural decisions become difficult to change. Read the blog Safety vs Security to understand the differences Top five RTOS security best practices Together, these CIA(AG) principles provide a practical foundation for securing RTOS-based embedded systems: Confidentiality Ensure information is only accessible to authorised users and that systems expose only the minimum data required for a given task. Integrity Protect software, communications and data from unauthorised modification, corruption or tampering throughout the system lifecycle. Availability Maintain reliable operation of critical services, resources and communications so the system can perform its intended function when needed. Authenticity Verify that users, devices and systems are genuinely who they claim to be before access is granted or trusted communications are established. Governance Implement policies, processes and access controls that clearly define responsibilities and ensure appropriate separation between user and administrator privileges. Explore the ESM RTOS security: frequently asked questions How do you secure an RTOS? RTOS security should be considered throughout the software lifecycle. Typical activities include security requirements, risk analysis, secure design, secure development, code review, security testing, verification and vulnerability management. What is the relationship between RTOS security and the CRA? The CRA introduces cybersecurity requirements for products with digital elements. Where an RTOS forms part of such a product, information about its development, vulnerabilities, security practices and maintenance may contribute to the manufacturer’s cybersecurity and compliance activities. How are RTOS vulnerabilities managed throughout the software lifecycle? Vulnerability management does not end when an RTOS is released. Suppliers should have processes for reporting, assessing, tracking and communicating security-relevant issues throughout the supported lifetime of the product. Related blogs on embedded cybersecurity, the CRA and ISO 21434 Stay informed with expert insights on embedded system security, functional safety, and ISO 21434 alignment. These blog articles explore real-world challenges and solutions for securing safety-critical applications. • Securing Embedded Devices: A Multi-Layered Approach Outlines how SAFERTOS® and the Enhanced Security Module work together to protect against evolving cyber threats. • Performing the TARA Analysis Explains how Threat Analysis and Risk Assessment (TARA) is applied in line with ISO 21434 to identify and mitigate risks in automotive software. Free Demos & Manuals Download fully functional, time-limited SAFERTOS® demos, plus manuals, datasheets, and more. Download Centre