diamond_full diamond diamond_half diamond_euro search-icon menu chat-icon close-icon envelope-icon smartphone-call-icon

Embedded Security Assessment

What is an Embedded Security Assessment?

Embedded systems are increasingly integral to both industrial applications and consumer products, particularly in the smart home sector, where they frequently connect to internal networks or the Internet. This connectivity is often referred to using terms like the Internet of Things (IoT) or cyber-physical systems (CPS). Typical use cases encompass a range of scenarios that highlight the importance of embedded software development and security. As these systems evolve throughout their development lifecycle, addressing potential vulnerabilities becomes paramount.

Static analysis and side channel analysis are critical testing methods that assess the security aspects of embedded software systems, helping to uncover weaknesses that could be exploited in an embedded system. By taking control of the system through thorough embedded software tests, organizations can better secure embedded systems against cyber security threats.

The integration of security frameworks and a software bill of materials into the development process is essential to maintaining hardware security features and meeting cyber security requirements. The ongoing evolution of embedded software security testing will play a important role in safeguarding the future of many embedded devices.

Typical use cases for embedded systems include:

  • Industry 4.0, Process IT (systems to control and monitor machines and facilities in the areas of production and logistics)
  • Automotive (automobiles, control units, head units or combined instruments, sensor technology, driver assistance systems, etc.)
  • Consumer products (smart home, office and network technology, multimedia systems, household appliances, home automation and monitoring, electronic fitness devices, etc.)
  • Health and medical technology (clinical devices, systems to monitor patients and important body functions)
  • Home automation and process control

placeholder for background/embedded.jpg

Objective

Identification of vulnerabilities in IoT devices or other embedded systems with a risk assessment for specific threat scenarios


Question

How secure is the embedded system and what can external attackers or malicious users and employees achieve in the worst case?


Scope

IoT devices or other embedded systems including hardware and interfaces

Embedded Security Assessment Process: Methodology & Approach

In a comprehensive security assessment of embedded systems, both hardware and software components are scrutinized to identify potential vulnerabilities. The auditor assumes the role of an external attacker or a privileged user, simulating various attack vectors. These can include techniques such as reading storage chips, man-in-the-middle attacks, and infiltrating systems by exploiting weaknesses in exposed interfaces.

In general, the assessment is based on the approach of an examination that is as comprehensive as possible. However, depending on the type of application or system and the relevant threats, a risk-based approach is also possible (comparable to a penetrationtest ). In this case, the focus is on particularly security-critical or endangered areas, whereby the scope of the test is determined by the time budget agreed upon in advance.

Core Components of a SCHUTZWERK Embedded Security Assessment

The embedded security assessment usually consists of the following parts:

  • Analysis of hardware
  • Analysis of firmware and operating systems together with existing update processes
  • Analysis of specific security features
  • Analysis of cryptographic methods
  • Analysis of SoC-specific features
  • Analysis of communication within the embedded system
  • Analysis of communication with external components or backend services
  • Analysis of passive and active side channel attacks
  • Analysis of application layer
  • Documentation, including a risk evaluation and proposed measures

Embedded Security Assessment: Testing Areas & Methods

Click on a topic to learn more about the specific testing approach.

During hardware analysis, the physical circuit board (PCB) and its components are examined. This includes visual inspection and identification of chips, tracing signal paths, and probing communication buses such as UART, SPI, I2C, or JTAG. Accessible debug and diagnostic interfaces like JTAG or SWD are particularly critical — if left enabled or insufficiently protected, they can provide full control over the processor, allowing memory readout, firmware extraction, or runtime manipulation. Our security consultants use specialized tools to identify, access, and exploit these interfaces, evaluating whether adequate debug protection mechanisms are in place.

Embedded devices store sensitive data such as cryptographic keys, credentials, configuration parameters, and proprietary firmware on non-volatile memory (e.g., flash, eMMC, or EEPROM). Our assessment evaluates whether this data is adequately protected at rest. This includes verifying that encryption is applied to sensitive partitions, that key material is stored in dedicated secure elements or hardware security modules (HSMs) rather than in accessible flash memory, and that readout protection mechanisms (e.g., chip-level read protection or secure fuses) are correctly configured.

We also assess whether data remnants from previous operations or firmware versions can be recovered, and whether physical access to storage chips (e.g., via chip-off or direct bus probing) can bypass the implemented protections. Secure storage is also a key requirement under the CyberResilienceAct(CRA) , which mandates the protection of stored data in products with digital elements.

Firmware analysis involves extracting the software running on the embedded device and examining it for vulnerabilities. Extraction methods range from reading flash storage chips directly (e.g., via SPI or chip-off techniques) to intercepting update mechanisms. Once extracted, the firmware is reverse-engineered using static and dynamic analysis techniques to identify hardcoded credentials, insecure configurations, known vulnerable libraries, or exploitable vulnerabilities. Where applicable, we also assess the integrity and security of over-the-air (OTA) update processes and whether firmware images are properly signed and encrypted.

In addition, we perform an SBOM analysis (Software Bill of Materials) upon request. If an SBOM is provided, we use it as the basis for our assessment. For any identified CVEs, we conduct a deep reachability analysis: we do not merely check for the presence of a vulnerability, but verify whether the affected functions can actually be invoked within the specific context of your firmware, thereby posing a real risk.

Many embedded systems run Linux-based or real-time operating systems that require proper hardening to reduce the attack surface. Our assessment examines the OS configuration for unnecessary services, overly permissive file system permissions, default or weak credentials, and missing security mechanisms such as ASLR, stack canaries, or SELinux/AppArmor policies. We also evaluate privilege separation — whether processes run with minimal required privileges and whether privilege escalation paths exist.

For devices with network connectivity, we assess exposed services and their configurations. A well-hardened OS forms a critical defense layer: even if an attacker gains initial access, proper hardening limits lateral movement and privilege escalation. These aspects are also increasingly relevant under the CyberResilienceAct(CRA) , which requires manufacturers to minimize attack surfaces and ship products in a secure-by-default configuration.

The boot chain is the sequence of software components that execute when a device powers on — from the initial bootloader through to the operating system. Secure boot ensures that each stage cryptographically verifies the integrity and authenticity of the next before handing over execution. Our assessment examines whether the root of trust is properly anchored in hardware, whether signature verification is correctly implemented at every stage, and whether known bypass techniques (such as SPI code injection at in-place execution or exploiting bootloader vulnerabilities) can circumvent the chain of trust.

Side channel attacks exploit unintentional information leakage from the physical implementation of a system rather than its logical design. During power analysis, we measure the device’s power consumption while it performs cryptographic operations — the variations in power draw can reveal secret key material. Electromagnetic (EM) analysis follows a similar principle but captures EM emanations using specialized near-field probes, which can provide even more localized and precise measurements.

Techniques such as Simple Power Analysis (SPA), Differential Power Analysis (DPA), and Correlation Power Analysis (CPA) are employed to extract cryptographic keys from the measurements. Our blog series on poweranalysisbasedreverseengineering , EMprobesandCPA , and statisticalmodellingoftimingsidechannels provides further technical depth on these techniques. EM probe side channel measurement setup

Fault injection attacks deliberately introduce transient faults into a device to alter its behavior — for example, to skip a signature check, bypass access controls, or corrupt cryptographic computations. Common techniques include power glitching (briefly disrupting the supply voltage), clock glitching (injecting spurious clock edges), and electromagnetic fault injection (EMFI). These attacks can cause a processor to skip instructions, misread memory, or produce incorrect computation results. Our security consultants use precision glitching equipment to evaluate whether the device is susceptible to such attacks and whether adequate countermeasures (e.g., redundant checks, voltage monitoring, or glitch detectors) are in place. ChipWhisperer glitching and power analysis setup
Modern Systems-on-Chip (SoCs) often include security features such as Trusted Execution Environments (TEEs, e.g., ARM TrustZone or RISC-V enclaves) and hardware-enforced memory isolation. Our assessment evaluates whether these features are correctly configured and effectively isolate sensitive operations from the rest of the system. This includes testing SoC-internal communication channels between security domains, verifying that memory isolation mechanisms prevent unauthorized cross-domain access, and performing vulnerability analysis of trusted applications (TAs) running inside the TEE. We also assess whether the TEE’s attack surface is minimized and whether known vulnerability classes (such as CacheWarponAMDSEV ) apply to the specific implementation.
We assess the cryptographic methods employed by the embedded system, including encryption algorithms, signature verification procedures, challenge-response authentication, and key management. A particular focus is the quality of random number generators (RNGs), as weak entropy sources can undermine the entire cryptographic system. We evaluate whether hardware RNGs are available and properly seeded, test for biases and predictability in generated values, and examine whether cryptographic keys are securely stored and protected against extraction. Our blog post on attackingarandomnumbergenerator illustrates this assessment approach in practice.
Fuzzing is an automated testing technique that feeds a target system with large volumes of malformed or unexpected input data to trigger crashes, instabilities, or other anomalous behavior indicative of vulnerabilities. In the context of embedded systems, fuzzing presents unique challenges: source code and debug symbols are often unavailable, and interaction with the device happens through constrained communication buses rather than standard software interfaces. To address this, we employ debugger-assisted greybox fuzzing techniques that leverage hardware debug interfaces and tracing capabilities to monitor code coverage and guide input generation — even without access to source code. This feedback-driven approach systematically explores firmware code paths that blind fuzzing or manual testing would miss. Our blog series on embeddedfuzzingwithLauterbachTRACE32 provides further details on this approach.
Embedded devices increasingly expose application-level interfaces such as web-based administration panels, REST APIs, mobile companion apps, or command-line interfaces via serial consoles. Our assessment evaluates these interfaces for common vulnerability classes including injection flaws, authentication and session management weaknesses, insecure direct object references, and insufficient input validation. We also examine backup and restore functionality, file upload mechanisms, and firmware update interfaces accessible through the application layer. Where embedded devices expose web or mobile interfaces, our specialized WebApplicationSecurityAssessment(WASA) and MobileApplicationSecurityAssessment(MASA) methodologies complement the embedded assessment. For broader network-exposed services, our penetrationtesting methodology applies.
Embedded systems communicate both internally (between chips, processors, or security domains on the PCB) and externally (with backend services, other devices, or user interfaces via field buses, Bluetooth, NFC, Wi-Fi, or mobile connections). Our assessment analyzes these communication channels for confidentiality, integrity, and authentication. This includes man-in-the-middle testing on internal buses, protocol fuzzing, and evaluating whether transport encryption (e.g., TLS) is correctly implemented for external connections. We also assess whether communication protocols are resilient against replay attacks and whether proper mutual authentication is enforced.

Embedded Security Assessments and Relevant Regulations & Standards

The security of embedded systems is subject to a variety of regulations and standards that can be relevant depending on industry and application area. A comprehensive embedded security assessment takes these requirements into account and helps you achieve regulatory compliance:

  • Cyber Resilience Act (CRA) - This new EU regulation establishes concrete requirements for the cybersecurity of connected products. An embedded security assessment helps you meet these requirements and prepares your product for market launch. Learn more about our CRAcompliancesupport and EUfundingopportunitiesforSMEs .

  • IEC 62443 - This series of standards defines security requirements for industrial automation systems and covers both technical and organizational aspects. Our assessments are conducted with these requirements in mind.

  • EU Radio Equipment Directive (RED) - Products with radio interfaces are subject to specific security requirements according to EU RED. We verify compliance with the relevant security provisions.

  • ISO/SAE 21434 - This standard for cybersecurity in the automotive industry defines requirements for cybersecurity management throughout the entire vehicle life cycle, for example with regard to threat analysis and risk assessment (TARA) or the verification of security measures. Our embeddedsecurityassessmentsforautomotivecomponents for automotive components are tailored to this standard and meet the requirements of technical verification in particular.

  • UNECE R 155 - This regulation contains binding requirements for cybersecurity in vehicle type approval. We support you with our automotivesecurityassessment in meeting these requirements during the homologation process.

By working with our experts, you ensure that your embedded systems are not only technically secure but also comply with relevant regulatory requirements.

Embedded Security Assessment Results: Risk Evaluation & Countermeasures

As a result of the assessment we will provide a detailed report. Depending on the type and scope of the project, the final report will include the following parts:

  • Management summary with a description of the results and the security level
  • Description of the project approach, scope, schedule and methodology
  • Detailed description of identified vulnerabilities in order to understand underlying issues and to enable reconstruction of possible attacks (where necessary with proof-of-concept implementation)
  • Detailed description of the iterative exploitation process when using chained vulnerabilities
  • Risk assessment of identified vulnerabilities taking into account the IT environment or the application context (risk classification: low, medium, high, critical)
  • Description of measures to remedy the vulnerabilities
  • If necessary, a description of higher-level strategy, concept and process-related measures or optimization suggestions.

Blog & News

Blogposts about: embedded security

Blog & News Archive

Latest 2025 2024 2023

How can we help you?

Call us or schedule an appointment directly

Free Consultation