About the New CPSA® – Advanced Level Module EMBED­DEDSEC: Embedded Security for Architects

On November 19, 2025, the iSAQB intro­duced the new Advanced Level module “EMBED­DEDSEC: Embedded Security for Archi­tects”.

The module EMBED­DEDSEC provides partic­i­pants with methods for designing an embedded system architecture that reflects their security goals. Building on the concepts of the Foundation Level, the module intro­duces partic­i­pants to analysis methods for identi­fying protection-worthy assets and deriving security goals for embedded systems. It presents qualities, design patterns, and technologies that help in achieving security goals and famil­iarize partic­i­pants with common attack patterns.
Finally, techniques for verifying and validating security properties are presented. At the end of the module, partic­i­pants know approaches to designing embedded archi­tec­tures with security as a quality in mind and are able to identify security risks and select suitable control measures.

We conducted an interview with the curators, Felix Bräunling and Isabella Stilk­erich, where they provide deeper insights into the module.

Why did the iSAQB decide to develop a dedicated Advanced-Level module on Embedded Security?

Embedded devices are at the heart of our everyday lives – whether in consumer electronics, smart home systems, or critical appli­ca­tions such as medical or automotive technology. Their secure operation protects the privacy and physical safety of their users. However, security cannot simply be added to a system after­wards; it must be considered from the very beginning. We often refer to this as Security by Design.

For software archi­tects, it is therefore essential to under­stand how security risks can be identified and appro­pri­ately mitigated. This is exactly what trainings based on the EMBED­DEDSEC curriculum aim to achieve.

What are the key differ­ences between Embedded Security and classic IT Security?

Depending on the degree of embedding, bound­aries between the two domains increas­ingly blur – for instance in the high-perfor­mance controllers of in-vehicle infotainment systems. Yet important differ­ences remain, regardless of system size: limited resources, specialized or propri­etary inter­faces, restricted user inter­faces, and in some cases very limited or no internet connec­tivity. Embedded systems are also designed for a specific purpose and optimized solely for fulfilling that purpose.

These charac­ter­istics require adapted solutions, such as resource-efficient encryption mecha­nisms, user-independent authen­ti­cation methods, or secure and resilient update strategies.

Partic­u­larly in safety-critical embedded systems, it must be ensured that attackers cannot harm users. This means that security goals like avail­ability often receive higher priority than confi­den­tiality – contrary to classic IT security. In emergency scenarios, for example, a medical system must remain available, even if a complex authen­ti­cation process would otherwise delay its use.

Why is the connection between Functional Safety and Security especially important in embedded systems?

By defin­ition, embedded systems are integrated into their environment and directly influence it – often in sensitive areas of our lives. This ranges from controlling an indus­trial robot to a vacuum-cleaning robot equipped with a camera. Attacks on such systems can therefore compromise both privacy and the physical safety of individuals.

Functional Safety and Security often complement each other and can work together to prevent such scenarios. However, conflicts between the two can arise: Typical security mecha­nisms such as access control or encryption may conflict with functional safety requirements, for example when very high avail­ability or strict real-time constraints must be met.

For this reason, it is essential to consider both aspects and their inter­ac­tions. Balancing them in accor­dance with quality requirements is a central part of architectural work.

What typical security risks occur in embedded systems, and how does the module help partic­i­pants identify and assess them?

Typical security risks often resemble those of conven­tional IT systems. The OWASP IoT Top 10, for example, lists “weak, guessable, or hardcoded passwords” or the “use of insecure or outdated compo­nents.” Embedded systems also add the physical dimension: hardware must be hardened against attacks such as side-channel attacks, glitching, and other forms of manipulation.

In addition, embedded systems are frequently developed in C or C++—languages known for high perfor­mance but limited guarantees regarding memory and type safety. Many vulner­a­bil­ities arise precisely at this point.

The training therefore covers not only common attack types, but also physical attacks, secure imple­men­tation techniques, and modern alter­na­tives to C/C++, such as Rust.

A key component is a systematic approach to identi­fying risks – the foundation for all further security measures.

The curriculum also covers cryptog­raphy and hardware aspects. What compe­tencies do partic­i­pants gain in these areas?

The module does not aim to provide a complete education in imple­menting cryptog­raphy. Instead, partic­i­pants learn to under­stand funda­mental opera­tions and assess which crypto­graphic mechanism suits which security objective – for example, why not every form of encryption ensures data integrity, or why update signa­tures are essential. Partic­i­pants also receive an overview of recom­mended algorithms, including those specif­i­cally designed for resource-constrained systems.

Regarding hardware aspects, the focus is not on building hardware from scratch but on under­standing typical physical attacks and common hardware security mecha­nisms such as Physical Unclonable Functions, redun­dancies, or Hardware Security Modules. Especially in embedded systems, security often emerges from the interplay between hardware and software.

What should partic­i­pants be able to apply in practice after completing the EMBED­DEDSEC module—and what value does this add to their work as software architects?

After completing the module, partic­i­pants should be able to analyze an initial system design for potential security risks, assess those risks, select appro­priate counter­mea­sures, and adapt them to the functional and quality requirements of the system.

They will also learn the funda­mentals of verifi­cation and validation techniques in security, enabling them to support testers and assess a system’s testa­bility. This equips them to design embedded systems with greater security in mind – without losing sight of other architectural qualities.

In addition, based on the methods and refer­ences provided, they will be able to expand their knowledge independently.