Custom system integration
Embedded Redesign
Board Support Package for System Houses
Security risks in field operations
Many embedded systems are functionally stable, but their security has evolved over time. Vulnerabilities often do not arise from a single point, but from the interplay between system boot-up, the operating system, update paths and access policies. This is precisely why embedded security must be taken into account at an early stage in the system architecture.
Unstable system start-up
Excessive surface area in the targeting system
Insecure update paths
Partial protection rather than a security architectureTechnical security components of embedded security
A robust safety concept for embedded systems is not achieved through a single function. What is crucial is the interaction of several technical components, which must be suited to the platform, the application scenario and subsequent field operation.
Secure Boot & Chain of Trust
The foundation of trust in an embedded system is established right from the start. If boot components are not verified, tampered software may be executed before higher-level protection mechanisms even come into play.
Secure Boot ensures that only authorised and unmodified components are loaded. Depending on the platform, this involves verifying several stages of the boot chain – for example, from the bootloader through the kernel and device tree to other boot-related artefacts. This is precisely where the technical chain of trust begins.
A robust chain of trust is particularly important when devices are operated in a networked environment, updated in the field or maintained over long lifecycles.
Operating system hardening
A functioning embedded system is not automatically a hardened system. Operating system hardening reduces the attack surface and translates security requirements into a controlled system configuration.
The focus is solely on those components, services and access paths that are actually required for the device’s real-world deployment. The aim is to achieve a target system that is functionally complete but deliberately stripped back in terms of security.
Secure updates & OTA
An embedded system can only remain manageable in the long term if software updates can be distributed, verified and activated securely. That is why the update architecture – comprising signature verification, validation and a fallback strategy – is a key component of embedded security.
Check integrity and origin
Spotting manipulated images
Ensure rollback and recoverySecure updates are not achieved through signatures alone, but through the coordinated interplay of verification, activation and fallback strategies. For embedded Linux systems, established mechanisms such as RAUC can provide a sound foundation when signed images, controlled activation and robust fallback paths need to be integrated.
Deploy the update
Check origin and integrity
Carry out the installation in a controlled manner
Ensure activation
Trigger a rollback or recovery in the event of errors
Cryptography & Device Identities
Cryptography only works reliably in embedded systems if keys, identities and trust relationships are properly integrated into the device architecture.
Hardware-based security features
Modern embedded platforms often offer security features that go beyond purely software-based measures. When used correctly, they can provide targeted protection for particularly sensitive functions.
Regular system area
This is where normal device functions and application processes run within the intended operational context.
Protected security area
Sensitive functions can be processed in separate execution areas, for example using TEE approaches or OP-TEE.
Defined transitions
Controlled communication between the regular and protected areas is crucial to ensure that the separation remains architecturally effective.
Communications & Access Security
As soon as embedded systems communicate with back-ends, other devices or service access points, it is necessary to secure not only data channels but also trust relationships. Communication security is a key component, but it is no substitute for a secure boot chain, hardening or a robust key management scheme.
Taking service access into account
Depending on the type of device, locally accessible interfaces, debug ports or service ports should also be included in the security assessment – particularly if they are accessible in the field or can be activated for servicing.
The focus here is less on specialised measures for physical protection and more on the question of which local access paths are actually necessary during routine operation and how they are assessed, restricted or secured within the overall concept.
Security in the development process
Embedded security within the development process (security by design) should not be considered only after implementation. Robust security mechanisms are created when requirements, architecture, the threat landscape and technical implementation are integrated at an early stage, rather than being added as an afterthought.
Analysing requirements
Clarify the application scenario, security objectives and field conditions.
Assessing the threat landscape
Identifying attack surfaces and typical misconfigurations.
Define the security architecture
Integrate appropriate mechanisms into the boot, OS, update and communication concepts.
Integrating implementation
Embed security functions into the platform, system software and device architecture.
Carrying out reviews and audits
Identifying vulnerabilities, inconsistencies and anomalies at an early stage.
Platforms & Security Requirements
Security requirements arise across platforms, but their technical implementation depends heavily on system architecture, device context and lifecycle.
Embedded security encompasses security mechanisms for embedded systems – from system boot-up, through the operating system and updates, to communication, identities and security checks during the development process.
Yes, because embedded security should be taken into account as early as possible in the project. In particular, secure boot, update architecture, key management and hardening can be implemented much more robustly if they are factored into the system architecture from the outset.
No. Security requirements also apply to Windows Embedded and Android-based devices. However, the technical implementation varies depending on the platform and device context.
Secure Boot ensures that an embedded system boots only with authorised and unmodified boot components. To this end, components of the boot chain – such as the bootloader, kernel or other boot-related artefacts – are verified before execution. This provides the technical foundation for a trusted boot chain and, consequently, for downstream security mechanisms within the system.
OTA stands for ‘Over The Air’ and refers to software updates that a device receives via a network connection – in other words, directly whilst in operation in the field, without any local intervention. This process is only secure once the origin, signature and integrity of the update packages have been verified, activation has been checked, and rollback or recovery mechanisms are in place in the event of an error. From a technical perspective, it is particularly important that a device remains in a controllable state even in the event of connection failures, incomplete packages or faulty software versions.
When particularly sensitive functions or security-critical operations need to be separated from the regular system context. A TEE (Trusted Execution Environment) is a protected execution environment running alongside the normal operating context. OP-TEE is a well-established open-source implementation of this principle. Such approaches are useful when security-critical processing needs to be specifically isolated and controlled, separate from the rest of the system.
Yes, this is often possible. The extent to which hardening is applied depends on the platform, the initial architecture, the update mechanism and the existing access paths.
We will be happy to present solutions for your industry and your processes. Talk to the specialists for SMEs.
request now
