Embedded System Architecture from a Cybersecurity Perspective

In the first article, Introduction to Embedded Cybersecurity, we established why cybersecurity has become an essential engineering requirement for modern embedded products. We explored the fundamental security principles, examined common attack surfaces, and introduced mechanisms such as secure boot, cryptography, secure communication, and hardware-based protection.

However, understanding these security mechanisms in isolation is not sufficient to design or evaluate a secure embedded device. Their effectiveness depends heavily on the underlying hardware and software architecture, the way individual components interact, and the trust relationships established between them.

For example, secure boot depends on a trusted starting point within the processor architecture. Memory protection depends on the capabilities of the processor and memory management mechanisms. Firmware security depends on how executable code is stored, loaded, verified, and executed. Similarly, communication security depends on the interfaces and protocol stacks implemented within the device.

Consequently, before examining individual security technologies in detail, it is necessary to understand the internal architecture of an embedded system and identify where security boundaries exist.

This article explores the major hardware and software components of embedded platforms, explains how they interact during system initialization and normal operation, and examines the security implications associated with each architectural layer. The discussion covers both microcontroller-based systems and more sophisticated embedded Linux platforms, providing a common architectural foundation for the subsequent articles in this series.

1. Overview of Embedded System Architecture

An embedded system is a combination of hardware and software components designed to perform specific functions within a larger product or infrastructure. Although implementations vary significantly depending on application requirements, most embedded platforms follow a common architectural structure.

At the hardware level, the system contains a processing unit, memory, peripheral controllers, communication interfaces, and supporting electronic components. At the software level, it contains startup code, bootloader components where applicable, firmware, device drivers, middleware, operating systems, and application software.

These components work together to initialize the hardware, execute application logic, process external inputs, communicate with other systems, and control connected devices.

A simplified embedded architecture can be represented as follows:

The processor acts as the central execution unit, accessing memory and controlling peripheral devices through the available hardware interfaces. Firmware provides the instructions that determine how the system behaves, while the operating system, when present, manages execution, scheduling, memory, and system resources.

From a cybersecurity perspective, this architecture should not be viewed merely as a collection of functional components. Each component has a particular level of access, executes within a defined privilege context, and interacts with other components through specific interfaces.

These interactions establish the security boundaries of the device. A weakness in one component may affect other components if appropriate isolation and access controls are not implemented.

Understanding this relationship between architecture and security is therefore the first step toward developing an effective embedded security design.

2. Processing Architecture: Microcontrollers and Microprocessors

The processing unit is one of the most important components of an embedded platform because it determines how instructions are executed, how memory is accessed, and how hardware resources are controlled.

Two commonly encountered processing platforms are microcontrollers (MCUs) and microprocessors (MPUs). Although both execute software instructions, their architectural characteristics and application requirements differ.

2.1 Microcontroller Architecture

A microcontroller integrates the primary computing resources required for embedded operation into a single integrated circuit. These resources typically include a processor core, flash memory, RAM, timers, interrupt controllers, and peripheral interfaces.

Microcontrollers are widely used in applications where deterministic operation, low power consumption, compact hardware design, and cost efficiency are important.

Examples include ARM Cortex-M-based devices and microcontrollers based on RISC-V architectures.

A typical microcontroller architecture contains the following components:

• CPU core: Executes instructions and performs arithmetic, logical, and control operations.
• Flash memory: Stores firmware and other persistent information.
• SRAM: Provides temporary storage for runtime variables, stack, and heap.
• Interrupt controller: Manages hardware and software interrupts.
• Timers and counters: Support scheduling, timing, and event measurement.
• Communication peripherals: Provide interfaces such as UART, SPI, I2C, CAN, and USB.
• GPIO: Allows the processor to interact with external digital signals.

Because many of these resources are integrated into a single device, microcontrollers are commonly used in systems that operate without a full operating system or with a lightweight RTOS.

From a security perspective, this integration creates both advantages and challenges. A smaller software footprint may reduce the number of exposed services and dependencies. However, limited hardware isolation, constrained memory resources, and direct peripheral access can make security implementation more dependent on the capabilities of the microcontroller itself.

For instance, an MCU without hardware-backed isolation may require additional care when separating security-sensitive operations from ordinary application functionality.

2.2 Microprocessor Architecture

A microprocessor-based embedded system typically relies on an external memory subsystem and additional supporting components to provide the complete computing platform.

Unlike many microcontrollers, microprocessors commonly support more sophisticated memory management, privilege separation, and operating system environments.

ARM Cortex-A and application-class RISC-V processors are examples of architectures commonly used in these systems.

A microprocessor-based platform may contain:

• A processor core or multicore processor.
• External DDR memory.
• Flash storage or eMMC.
• Memory management hardware.
• Interrupt and timer controllers.
• Hardware cryptographic accelerators.
• Network and peripheral controllers.
• A boot firmware environment.
• An embedded operating system such as Linux.

These platforms are capable of supporting complex applications, multiple processes, network services, graphical interfaces, and advanced security frameworks.

However, the additional functionality also increases software complexity. A typical embedded Linux platform may contain thousands of software packages, third-party libraries, device drivers, and system services.

Every additional component introduces dependencies that must be evaluated and maintained from a security perspective.

2.3 MCU vs. MPU: Architectural and Security Differences

Characteristic	Microcontroller (MCU)	Microprocessor (MPU)
Integration	CPU, memory and peripherals commonly integrated	Often uses external memory and supporting components
Memory	Typically limited on-chip flash and SRAM	Often larger external RAM and storage
Operating system	Bare-metal or RTOS	Commonly embedded Linux or another full OS
Memory management	MPU or limited protection mechanisms, depending on device	Often supports MMU-based virtual memory
Application complexity	Low to moderate	Moderate to high
Attack surface	Often smaller, but highly platform-dependent	Often larger due to OS and network services
Security mechanisms	Secure boot, hardware isolation, protected storage where supported	Secure boot, process isolation, permissions, SELinux, hardware security features

3. Memory Architecture and Its Security Implications

While the processor determines how instructions are executed, the memory architecture determines where instructions and data are stored, how they are accessed, and how they are protected during system operation.

Memory is particularly important in embedded cybersecurity because firmware, cryptographic keys, authentication credentials, configuration parameters, and runtime application data may all reside in different memory regions.

A typical embedded platform uses multiple memory technologies, each with different characteristics and security considerations.

3.1 Flash Memory

Flash memory is a nonvolatile storage technology that retains information even when power is removed. It is commonly used to store firmware, bootloader code, device configuration, and persistent application data.

In microcontroller-based systems, firmware is frequently stored in internal flash memory. More sophisticated embedded platforms may use external NOR flash, NAND flash, eMMC, or other storage devices.

Flash memory is an important security boundary because it contains executable software and potentially sensitive information.

For example, consider a microcontroller that stores its application firmware in internal flash. If an attacker obtains unauthorized write access to this memory, it may be possible to replace the legitimate firmware with a modified image.

Similarly, if cryptographic keys or credentials are stored without appropriate protection, an attacker with sufficient physical or logical access may attempt to extract them.

Security mechanisms associated with flash memory include:

• Flash readout protection.
• Write protection for security-critical memory regions.
• Secure boot and firmware authentication.
• Hardware-backed key storage where available.
• Memory access restrictions.
• Secure firmware update mechanisms.

It is important to understand that flash readout protection and secure boot address different security objectives. Readout protection attempts to restrict unauthorized memory access, whereas secure boot verifies the authenticity of executable software before execution.

Both may be required as part of a comprehensive security architecture.

3.2 RAM and Runtime Memory

Random Access Memory (RAM) provides temporary storage for data and instructions required during system execution.

Unlike flash memory, conventional RAM is volatile and generally loses its contents when power is removed.

During operation, RAM may contain application variables, stack frames, heap allocations, communication buffers, temporary cryptographic data, and other runtime information.

This makes RAM an important target from a security perspective.

Consider an embedded application that performs TLS-based communication with a remote server. During the communication process, sensitive information such as session keys, authentication tokens, and decrypted application data may temporarily exist in RAM.

If an attacker obtains unauthorized memory access through a debugging interface, software vulnerability, or other attack path, this information may become exposed.

Memory-related vulnerabilities can also affect the execution of firmware itself. Stack overflows, heap corruption, buffer overflows, and use-after-free vulnerabilities may allow an attacker to influence application behavior or compromise execution.

Security mechanisms for runtime memory include:

• Stack protection and stack canaries.
• Memory Protection Units (MPUs).
• Memory Management Units (MMUs).
• Address Space Layout Randomization (ASLR), where supported.
• Data Execution Prevention (DEP) or equivalent execute-never controls.
• Secure memory clearing.
• Runtime bounds checking and memory-safe programming practices.

The availability of these protections depends on the processor architecture, operating system, compiler, and software implementation.

3.3 ROM and Boot ROM

Read-Only Memory (ROM) is commonly associated with code or data that is programmed during manufacturing and is not intended to be modified during normal operation.

Many modern microcontrollers and application processors contain an internal Boot ROM.

Boot ROM typically contains the initial code responsible for starting the processor and initiating the boot process.

Because this code is established during manufacturing and may be immutable, it can serve as an important foundation for the platform’s root of trust.

For example, a processor may execute Boot ROM code immediately after reset. This code may initialize essential hardware resources, identify the next boot stage, and verify its authenticity before allowing execution.

The security of this initial stage is critical. If the initial trust mechanism is compromised, subsequent firmware verification may no longer provide the intended protection.

Therefore, Boot ROM design, manufacturing controls, cryptographic verification, and vulnerability management are important considerations when evaluating the security of an embedded platform.

3.4 EEPROM and Other Nonvolatile Storage

Some embedded platforms use EEPROM or other nonvolatile memory technologies to retain configuration parameters and persistent information.

Typical examples include:

• Device identifiers.
• Calibration parameters.
• Configuration settings.
• Manufacturing information.
• Security counters.
• Authentication-related data.

These values may influence the behavior and security state of the device.

For instance, a device may store its authentication credentials or security configuration in nonvolatile memory. If these values can be modified without authorization, an attacker may be able to alter the device’s security configuration or compromise its identity.

Consequently, persistent data must be protected through appropriate access controls, integrity verification, and secure provisioning procedures.

3.5 Memory Protection as a Security Boundary

The different memory regions within an embedded system should not automatically be considered equally trusted.

Executable firmware, security-critical data, application memory, peripheral memory, and external storage may require different access permissions.

A well-designed architecture defines which components can access particular memory regions and whether those regions can be read, written, or executed.

For example, a security-sensitive memory region containing cryptographic material should ideally be inaccessible to ordinary application code.

Similarly, memory containing executable firmware should not be writable by untrusted application components during normal operation.

These restrictions establish the foundation for memory isolation and privilege separation, which will become increasingly important when examining RTOS and embedded Linux architectures.

4. Boot Architecture: From Power-On to Firmware Execution

The boot process is one of the most security-sensitive stages in an embedded system because it determines which software components are initialized and ultimately trusted to control the device.

When power is applied or the processor is reset, the device does not immediately begin executing its main application. Instead, the processor follows a predefined startup sequence that establishes the initial execution environment.

The exact implementation varies between microcontrollers and application processors, but the general principle remains similar: execution begins from a defined reset location and progresses through a sequence of initialization stages.

Figure 4: Simplified embedded system boot sequence.

4.1 Reset and Initial Processor Execution

When the device receives power or a reset signal, the processor enters its defined reset state.

The processor then begins execution from a predefined reset address or boot location determined by the hardware architecture.

On many microcontrollers, the initial startup mechanism involves a reset vector and an initial stack pointer configuration.

On application processors, the initial execution environment may be established through internal Boot ROM code.

At this stage, the processor has not yet initialized the complete application environment. Its initial responsibilities are generally limited to establishing the minimum conditions necessary for subsequent execution.

From a security standpoint, this initial stage is especially important because it determines the starting point of the device’s trust chain.

4.2 Bootloader Initialization

Following the initial startup stage, execution may transfer to a bootloader. A bootloader is a software component responsible for preparing the system for application execution.

Depending on the platform, it may perform tasks such as:

• Initializing memory controllers.
• Configuring clocks.
• Initializing essential peripherals.
• Selecting the firmware image.
• Validating firmware authenticity.
• Loading the next software stage.
• Transferring execution to the application.

In a simple microcontroller, the bootloader may be relatively small and execute directly from internal flash.

In an embedded Linux platform, the boot process may involve multiple stages, such as a first-stage bootloader, secondary program loader, and a more sophisticated bootloader such as U-Boot.

The bootloader is a critical security component because it controls which software is allowed to execute next.

If the bootloader accepts unsigned firmware or does not validate the integrity of the application image, an attacker may be able to introduce unauthorized executable code.

4.3 Firmware Verification

In a secure boot architecture, firmware verification occurs before the relevant software component is executed.

The device typically uses a trusted public key or another hardware-established trust mechanism to verify a digital signature associated with the firmware image.

The verification process establishes whether the firmware was signed by an authorized entity and whether the signed content has been modified.

A simplified secure boot sequence is:

• The processor begins execution from a trusted initial stage.
• The bootloader identifies the firmware image.
• The device obtains the required verification key or trust anchor.
• The firmware signature is verified.
• The device checks additional image requirements, such as version or security state, where implemented.
• Execution is permitted only if the required checks succeed.

The actual architecture may involve multiple verification stages and different cryptographic implementations.

An important distinction is that a cryptographic hash alone does not establish authenticity. A hash can detect changes only when compared against a trusted expected value. Digital signatures provide a mechanism for verifying both integrity and the origin of signed firmware.

4.4 Application Initialization

After the required startup and verification stages are completed, execution proceeds to the application firmware or operating system.

In a bare-metal microcontroller, startup code typically initializes runtime memory, configures clocks and peripherals, and transfers control to the main application.

The startup code in an RTOS-based system may initialize the kernel, create tasks, configure interrupt handling, and start the scheduler.

The bootloader in an embedded Linux platform transfers control to the Linux kernel, which initializes hardware, mounts the root filesystem, and eventually starts user-space applications.

The boot process therefore establishes the execution environment upon which all subsequent security mechanisms depend.

This is why secure boot should be considered part of the overall platform architecture rather than simply a firmware feature.

5. Firmware Architecture and Execution Flow

Firmware forms the software foundation of an embedded device. It translates the intended functionality of the product into executable instructions that interact with the processor, memory, and peripherals.

Unlike general-purpose application software, firmware often has direct access to hardware registers, memory-mapped peripherals, interrupt controllers, and device-specific resources.

This close relationship between software and hardware makes firmware security particularly important.

5.1 Bare-Metal Firmware

A bare-metal system operates without a conventional operating system or RTOS.

In this architecture, the firmware directly manages hardware resources and controls the execution flow.

A typical bare-metal application contains:

• Startup code.
• Hardware initialization.
• Peripheral configuration.
• Interrupt service routines.
• Application logic.
• Main execution loop.

The main application may repeatedly execute a control loop that reads sensor data, processes inputs, and updates outputs.

For example, a simple temperature monitoring application may continuously read a sensor, calculate the temperature, and transmit the result through a communication interface.

The architecture is relatively straightforward, which can reduce software complexity. However, the absence of an operating system also means that application code may have broad access to hardware resources.

If the application contains a memory corruption vulnerability, the consequences may affect the entire device.

5.2 Firmware Components and Layering

As embedded applications become more sophisticated, firmware is often divided into multiple logical layers.

A representative firmware architecture includes:

Layer	Responsibility
Application layer	Implements product functionality
Middleware	Provides protocol stacks and reusable services
Hardware abstraction layer	Provides a common interface to hardware
Device drivers	Controls individual peripherals
Startup and platform code	Initializes processor and hardware
Bootloader	Loads and verifies application firmware

This separation improves maintainability, portability, and software organization.

However, it also introduces security dependencies between layers.

For example, an application may rely on a communication middleware component to validate network packets. If the middleware contains a vulnerability, the application may be exposed even if its own source code is secure.

Similarly, a driver with excessive hardware access may allow a compromised application component to manipulate resources outside its intended responsibility.

Therefore, firmware architecture should incorporate security boundaries, access restrictions, and clear trust assumptions between software components.

5.3 Firmware as an Attack Surface

Firmware may contain vulnerabilities resulting from unsafe memory operations, incorrect input validation, weak authentication, insecure update mechanisms, or vulnerable third-party components.

Common examples include:

• Buffer overflows.
• Integer overflows.
• Improper pointer handling.
• Hardcoded credentials.
• Insecure cryptographic implementations.
• Missing authorization checks.
• Unsafe deserialization.
• Insufficient firmware integrity verification.

These weaknesses can become particularly serious when firmware executes with extensive hardware privileges.

For this reason, secure coding, software component management, code review, static analysis, and firmware security testing must be integrated into the development process.

A detailed treatment of firmware architecture and secure coding will be provided in the upcoming firmware security articles.

6. Operating System Architecture: RTOS and Embedded Linux

As embedded applications grow in complexity, managing all software execution directly within a single application becomes increasingly difficult.

An operating system provides structured mechanisms for managing tasks, scheduling, memory, communication, and hardware resources.

Two major operating environments are commonly encountered in embedded products: real-time operating systems and embedded Linux.

Although both provide system-level software services, their architecture, resource requirements, and security characteristics differ considerably.

6.1 Real-Time Operating Systems

A Real-Time Operating System (RTOS) is designed to manage concurrent activities while satisfying defined timing requirements.

RTOS-based platforms are commonly used in automotive electronics, industrial controllers, medical equipment, robotics, and other systems where predictable response times are important.

Examples include FreeRTOS, Zephyr, and Azure RTOS ThreadX.

An RTOS typically provides:

• Task and thread scheduling.
• Interrupt management.
• Inter-task communication.
• Synchronization mechanisms.
• Timers.
• Memory management services.
• Device driver integration.

An RTOS allows different application functions to execute as independent tasks.

For example, an industrial monitoring controller may contain separate tasks for sensor acquisition, communication, control processing, and diagnostics.

The scheduler determines when each task executes based on the configured scheduling policy and priority.

From a security perspective, task separation can help organize application functionality. However, it should not automatically be interpreted as strong security isolation.

On many MCU-based RTOS platforms, tasks execute within the same processor privilege level and may share the same address space unless hardware memory protection is explicitly configured.

This means that a vulnerability in one task may affect other tasks or compromise the entire system.

Some RTOS implementations support MPU-based task isolation, privilege separation, and protected execution environments. These features can provide stronger security boundaries when correctly configured.

6.2 Embedded Linux Architecture

Embedded Linux is commonly used in devices that require advanced networking, multimedia capabilities, storage management, graphical interfaces, or complex application processing.

Examples include industrial gateways, network routers, smart cameras, automotive infotainment systems, and connected consumer devices.

Unlike many traditional MCU-based RTOS implementations, Linux provides a more sophisticated execution environment with user-space applications, kernel-space services, process isolation, virtual memory, and access control mechanisms.

A typical embedded Linux architecture can be divided into several layers.

Bootloader layer: Initializes the platform and loads the Linux kernel.

Kernel layer: Manages processor scheduling, memory, device drivers, interrupts, filesystems, and networking.

System libraries: Provide reusable interfaces and services for user-space applications.

System services: Manage background activities such as networking, logging, device management, and communication.

Application layer: Implements the product-specific functionality.

Linux provides several useful security capabilities, including:

• User and group permissions.
• Process isolation.
• Memory protection.
• Mandatory access control mechanisms.
• Linux capabilities.
• Secure boot integration.
• Filesystem access restrictions.
• Network filtering and access controls.

Technologies such as SELinux and AppArmor can provide additional restrictions on application and service behavior.

However, these mechanisms are not automatically secure simply because Linux is being used. Their effectiveness depends on kernel configuration, application privileges, filesystem permissions, enabled services, software maintenance, and the overall security architecture.

6.3 RTOS vs. Embedded Linux: Security Perspective

Characteristic	RTOS	Embedded Linux
Primary focus	Predictable real-time execution	General-purpose application and system management
Typical hardware	Microcontrollers	Application processors
Memory footprint	Generally small	Generally larger
Process isolation	Platform-dependent	Built-in process and virtual memory isolation
Privilege separation	Depends on RTOS and hardware	Kernel and user-space separation
Security services	Often application- and platform-specific	Broad range of built-in and additional security mechanisms
Attack surface	Depends on enabled features and interfaces	Often larger due to system services, packages, and networking

The selection between an RTOS and embedded Linux should be driven by the product’s functional and operational requirements.

From a cybersecurity perspective, neither architecture is inherently secure. Each requires a security design appropriate to its execution model and hardware capabilities.

7. Peripheral Interfaces and Communication Architecture

Peripheral interfaces connect the processor to external devices and enable the exchange of control signals and data.

They are essential to embedded functionality because the processor rarely operates independently. It must interact with sensors, actuators, storage devices, communication modules, and other controllers.

However, these interfaces also create potential security exposure.

Understanding their operation is therefore important when examining the physical and logical attack surface of an embedded device.

7.1 UART

Universal Asynchronous Receiver/Transmitter (UART) is a serial communication interface commonly used for debugging, configuration, and communication between embedded components.

UART communication typically uses transmit and receive signals, along with a common reference ground.

During development, engineers frequently use UART consoles to access bootloader logs, system diagnostics, and command-line interfaces.

If such interfaces remain accessible in production devices without appropriate restrictions, they may expose sensitive debugging information or provide access to privileged commands.

Security considerations include authentication, production debug policies, protection of diagnostic commands, and avoidance of sensitive information in logs.

7.2 SPI

Serial Peripheral Interface (SPI) is a synchronous serial communication protocol frequently used to connect microcontrollers to flash memory, sensors, displays, and other peripherals.

An SPI interface commonly uses clock, data-in, data-out, and chip-select signals.

External SPI flash devices are particularly important from a security perspective because they may store firmware, configuration data, or other persistent information.

An attacker with sufficient physical access may attempt to inspect or manipulate data exchanged over an inadequately protected external memory interface.

Appropriate security measures depend on the processor and memory architecture and may include authenticated boot, encrypted storage, hardware access restrictions, and physical protection.

7.3 I2C

Inter-Integrated Circuit (I2C) is a two-wire communication protocol commonly used for connecting low-speed peripherals.

It uses a serial data line and a serial clock line to support communication between controllers and peripheral devices.

I2C is widely used for sensors, EEPROM devices, power management components, and other hardware modules.

From a security perspective, devices connected through I2C may expose sensitive configuration information or control functions if physical access is not sufficiently restricted.

The security of the interface depends on the trustworthiness of connected components and the protections implemented by the controller and peripheral devices.

7.4 CAN

Controller Area Network (CAN) is widely used in automotive and industrial applications for communication between electronic control units.

CAN was designed primarily for reliable communication between distributed controllers rather than cryptographic authentication of message sources.

Consequently, the security of a CAN network depends heavily on network architecture, physical access restrictions, gateway filtering, and additional security mechanisms.

An attacker who gains access to an inadequately protected CAN network may attempt to inject, replay, or manipulate messages.

Automotive cybersecurity architectures may incorporate additional protections such as Secure Onboard Communication (SecOC), message authentication, and secure gateway mechanisms.

CAN security will receive a dedicated treatment in a later article covering embedded communication protocols.

7.5 Ethernet and Wireless Interfaces

Modern embedded systems frequently use Ethernet, Wi-Fi, Bluetooth, and cellular interfaces to communicate with external systems.

These technologies introduce network-level attack surfaces involving authentication, authorization, protocol handling, encryption, and service exposure.

A network-connected embedded device must therefore be designed with appropriate protections for its communication channels and the services exposed through them.

The presence of encryption alone does not guarantee security. Proper certificate validation, device identity management, authentication, access control, and secure protocol configuration are equally important.

8. Security Boundaries, Privilege Levels, and Hardware Isolation

The preceding sections have examined the individual hardware and software components of an embedded system. However, one of the most important architectural security considerations is how access is controlled between these components.

A security boundary defines a separation between components or execution environments with different levels of trust.

Without clearly defined boundaries, a vulnerability in one component may allow an attacker to access resources or functionality belonging to another component.

For example, an ordinary application task should not necessarily have unrestricted access to cryptographic keys, bootloader memory, security configuration registers, or sensitive peripheral controls.

Similarly, an application running in user space on an embedded Linux platform should not automatically have the same privileges as the Linux kernel.

Several hardware and software mechanisms can help establish these boundaries.

8.1 Privilege Levels

Modern processor architectures often support different execution privilege levels.

These levels determine which instructions, memory regions, and system resources software can access.

In a simplified architecture, privileged code may configure hardware resources and manage memory, while less privileged code executes ordinary application functionality.

ARM architectures, for example, provide different exception levels or privilege modes depending on the processor profile.

The ARM Cortex-M architecture provides privileged and unprivileged execution modes, while ARM Cortex-A processors support more sophisticated exception levels.

Privilege separation helps limit the consequences of compromised software by restricting the operations available to each execution context.

8.2 Memory Protection Unit

A Memory Protection Unit (MPU) provides hardware-assisted access control over defined memory regions.

It can be configured to restrict whether particular execution contexts are permitted to read, write, or execute specified memory regions.

In MCU-based systems, an MPU may be used to isolate RTOS tasks, protect privileged memory, and restrict access to peripheral regions.

For example, a sensor acquisition task may be permitted to access sensor-related buffers while being prevented from modifying a protected memory region containing security-sensitive information.

However, MPU capabilities and region configurations vary between processors, and the MPU does not provide the same virtual memory functionality as an MMU.

8.3 Memory Management Unit

A Memory Management Unit (MMU) provides address translation and memory access control, typically supporting virtual memory and process isolation.

MMUs are commonly found in application-class processors used for embedded Linux.

The operating system uses the MMU to establish separate virtual address spaces for processes and control access to physical memory.

This isolation reduces the likelihood that an application can directly access the memory of another process or protected kernel region.

8.4 Hardware Isolation and Trusted Execution

Some modern embedded processors provide dedicated hardware mechanisms for isolating security-sensitive execution.

One example is Arm TrustZone, which establishes separate Secure and Non-secure execution environments.

On supported Cortex-M processors, TrustZone-M can be used to isolate security-sensitive services from ordinary application firmware.

A secure application may manage cryptographic operations, authentication credentials, and trusted device services while non-secure application code performs normal product functionality.

Such isolation is particularly useful when a device contains multiple software components with different levels of trust.

However, hardware isolation must be accompanied by secure configuration, controlled interfaces, and appropriate software design. An improperly configured isolation boundary may still allow unauthorized access.

The detailed architecture and implementation of hardware roots of trust and trusted execution environments will be explored in a dedicated advanced article.

9. Putting the Architecture Together: A Practical Embedded System Example

The architectural concepts discussed in this article become easier to understand when considered within a representative embedded product.

Consider an industrial IoT gateway built around an ARM Cortex-A processor. The gateway collects information from multiple industrial sensors and controllers, processes the received data, and forwards it to a centralized cloud platform.

The device contains the following components:

• ARM Cortex-A application processor.
• External DDR RAM.
• eMMC or NAND flash storage.
• Bootloader.
• Embedded Linux operating system.
• Ethernet and Wi-Fi interfaces.
• UART, SPI, and I2C peripheral interfaces.
• Cryptographic hardware acceleration, where supported.
• Application software responsible for industrial communication and cloud connectivity.

The complete architecture can be understood as a sequence of interacting hardware and software layers

9.1 Normal System Execution

When the gateway is powered on, the processor begins executing its initial boot code.

The boot firmware initializes the required hardware resources and verifies the next software stage. Once verification succeeds, the bootloader loads the Linux kernel into memory and transfers execution to it.

The Linux kernel initializes the processor’s memory management, device drivers, interrupt handling, and communication interfaces.

After kernel initialization, the root filesystem is mounted and the required system services are started.

Finally, the application software begins executing. It communicates with industrial controllers, collects measurements, processes the received information, and transmits relevant data to the cloud platform.

This sequence demonstrates how the individual architectural components work together to provide the intended product functionality.

9.2 Identifying Security Risks Across the Architecture

Although the gateway may perform its intended functions correctly, each architectural layer introduces potential security concerns.

Architectural component	Potential security weakness	Security consideration
Boot ROM	Vulnerability in initial boot code	Hardware root of trust and vendor security validation
Bootloader	Unauthorized firmware loading	Signature verification and secure boot
DDR RAM	Runtime memory corruption	MMU protections and memory-safe coding
eMMC storage	Unauthorized firmware or data modification	Authenticated storage and access controls
Linux kernel	Kernel vulnerabilities	Security updates and kernel hardening
Device drivers	Improper input handling	Driver security reviews and testing
Ethernet/Wi-Fi	Unauthorized network access	Authentication, TLS and firewall policies
UART/JTAG	Unauthorized debugging	Debug authentication and production restrictions
Applications	Insecure services or credentials	Least privilege and application hardening

This mapping provides a practical way of connecting system architecture with security requirements.
Instead of treating cybersecurity as a separate activity, engineers can identify security controls at the exact architectural layer where they are required.

9.3 Establishing a Security-Oriented Architecture

A secure implementation of this gateway should incorporate multiple layers of protection.

At the hardware level, the platform should establish a trusted starting point and provide appropriate protection for security-sensitive resources.

During boot, each software stage should verify the authenticity of the next stage before transferring execution.

At the operating system level, kernel and user-space separation should be maintained, and applications should execute with only the permissions required for their functionality.

At the communication level, device authentication, secure communication protocols, and network access restrictions should be implemented.

Finally, firmware and software maintenance mechanisms should allow vulnerabilities to be corrected through authenticated updates.

This layered approach is commonly associated with the principle of defense in depth.

The underlying idea is that a security failure in one layer should not automatically result in complete compromise of the device.

10. Architectural Principles for Secure Embedded System Design

Having examined the major components and their associated security concerns, several engineering principles emerge that should guide the development of embedded platforms.

10.1 Establish a Hardware Root of Trust

The platform should have a trusted starting point from which subsequent software components can be authenticated.

Depending on the processor, this may involve immutable Boot ROM, hardware-protected public keys, secure boot configuration, or dedicated security hardware.

The root of trust must be protected against unauthorized modification and supported by a well-defined key management process.

10.2 Apply the Principle of Least Privilege

Every software component should receive only the permissions required to perform its intended function.

For example, a communication service should not automatically receive unrestricted access to memory regions containing cryptographic keys or bootloader configuration.

Similarly, embedded Linux applications should avoid running with unnecessary root privileges. Restricting privileges reduces the potential impact of software vulnerabilities.

10.3 Separate Security-Critical Functions

Security-sensitive operations should be separated from ordinary application functionality wherever the hardware and software architecture permit.

Examples include:

• Cryptographic key management.Device authentication.
• Secure boot verification.
• Security configuration management.
• Firmware update authorization.

Hardware isolation mechanisms and protected execution environments can help establish these boundaries.

10.4 Protect Debug and Manufacturing Interfaces

Debugging interfaces are essential during development, but unrestricted access in production can create significant security risks.

The product lifecycle should define how debugging access is managed during development, manufacturing, testing, deployment, and maintenance.

Production devices should not expose unnecessary debugging or manufacturing functionality.

10.5 Design for Secure Updates and Recovery

Embedded products often remain deployed for many years.

The architecture should therefore support secure firmware updates, software vulnerability remediation, and recovery from failed updates.

Where appropriate, it should also prevent unauthorized firmware downgrades and provide mechanisms for maintaining a known-good software state.

10.6 Consider Security During Hardware Selection

Security requirements should influence the selection of the processor and supporting components.

For example, if a product requires hardware-backed key storage, secure boot, memory isolation, and authenticated debugging, these capabilities should be evaluated before finalizing the hardware platform.

Adding complex security mechanisms after hardware selection may introduce unnecessary development effort or require architectural changes.

The most effective approach is to establish security requirements during the initial product architecture and component selection stages.

11. Conclusion

Embedded system architecture provides the technical foundation upon which all embedded cybersecurity mechanisms are implemented.

The processor determines the execution and privilege model, memory establishes the storage and access boundaries, boot architecture determines the software trust chain, and firmware and operating systems provide the functionality that controls the device.

Peripheral interfaces and communication technologies connect the embedded platform to its external environment, creating additional opportunities for interaction and potential security exposure.

As explored throughout this article, each architectural component introduces different security considerations. Consequently, an effective embedded security design must account for the complete hardware and software architecture rather than focusing exclusively on individual firmware vulnerabilities or communication protocols.

The distinction between microcontrollers and microprocessors, the characteristics of flash and RAM, the role of bootloaders, and the execution models of RTOS and embedded Linux platforms are particularly important when selecting appropriate security mechanisms.

These architectural concepts also establish the foundation for more advanced topics such as secure boot, firmware authentication, memory protection, hardware roots of trust, cryptographic key management, and trusted execution environments.

With the architectural foundation established, the next step is to examine how security requirements are formally defined and evaluated.

In particular, understanding how confidentiality, integrity, and availability translate into practical engineering requirements is essential before attempting to identify threats, assess vulnerabilities, or design appropriate security controls.

The next article will therefore examine the fundamental cybersecurity concepts in greater technical depth, including threat classification, vulnerability analysis, risk assessment, and security objectives within embedded environments.