Industry Expert Blogs

SoC designers are increasingly challenged to integrate robust security measures into their designs. Modern connected devices, such as automotive Electronic Control Units (ECUs), Internet of Things (IoT) nodes, and industrial control systems, face increasing susceptibility to cyberattacks. This escalating threat landscape underscores the critical importance of mandatory security requirements. 

In previous articles, we gave an overview about secure SoC architectures (Part I), about the importance of key management (Part II) and secure boot (Part III) - the first line of defense. Part IV of the series focuses on runtime integrity protection, a paramount, ensuring the application remains secure even during active operation.

1. Why Runtime Integrity Protection?

Runtime integrity protection is the continuous safeguarding of an SoC's critical assets—code, data, and configuration—from unauthorized modification or exposure during active operation. It extends secure boot's foundational security, ensuring system trustworthiness post-initialization through dynamic, continuous monitoring and enforcement. Modern connected devices, from automotive ECUs to IoT nodes, face escalating cyberattacks, necessitating robust security for integrated circuits. While secure boot verifies firmware authenticity at startup , many sophisticated attacks target the system after booting, exploiting vulnerabilities in running applications, memory, or even physical hardware. Such compromises can lead to data breaches, system takeovers, and IP theft.

2. Key Mechanisms of Runtime Integrity Protection

Achieving robust runtime integrity requires a suite of hardware-assisted mechanisms working in concert.

2.1 Runtime Memory Protection and Memory Protection Units

Runtime Memory Protection continuously verifies application code and data integrity during operation. The Memory Protection Unit (MPU) is the core hardware component, defining granular memory access permissions (read, write, execute, privilege levels) for distinct regions. Violations trigger a Memory Management Fault, preventing unauthorized operations. MPUs prevent tasks from corrupting memory, block unprivileged access to peripherals, and enable non-executable memory to prevent code injection. MPUs must be configured by privileged instances.

2.2 Trusted Execution Environments

A Trusted Execution Environment (TEE) is a secure, isolated area within the SoC, guaranteeing confidentiality and integrity of loaded code and data at runtime. This hardware-based isolation protects sensitive operations from potentially compromised by a rich execution environment or normal world where the main operating system and general applications reside. As an example, ARM TrustZone is a hardware based security technology that provides the foundation for a TEE. It creates an isolated, secure world separated from the normal operating environment. This secure world is where the TEE’s trusted OS and applications run, protected from threads in the normal world. 

2.3 Hardware Root of Trust in Runtime Operations

The Hardware Root of Trust (HRoT) is an immutable, hardware-based security foundation, typically in ROM or OTP memory, serving as the unalterable anchor for the chain of trust during secure boot. Additionally it is able to store keys for cryptographic operations at runtime. In comparison to TEE, HRoT establishes the foundational trust and verifies the system’s integrity, primarily starting at boot but also underpinning runtime trust by protecting keys and critical functions. HRoT is a specific, often small, hardware component or a set of fixed hardware functions. TEE is a broader execution environment that includes hardware isolation features, a trusted operating system running within that isolated area, and the trusted applications that run on that trusted OS.

2.4 The Role of the Security Subsystem 

That subsystem operates in its own isolated domain, separate from the application domain, and has privileged access to system resources. This architectural separation is crucial because it allows the security subsystem to:

• Enforce Security Policies: The security subsystem monitors, validates, and controls the application and its environment to ensure adherence to predefined security policies. Violations can lead to sanctions, such as resetting the application processor or restricting access to security services and assets.
• Independent Operation: To operate independently and in complete isolation, the security subsystem requires exclusive access to its own resources and robust isolation from other components of the SoC. Communication between the security subsystem and its environment occurs through well-defined interfaces, ensuring secure and controlled interactions.
• Centralized Control: By centralizing security-related functions, the security subsystem provides a unified and robust approach to platform security that would be challenging to achieve through distributed software solutions or external components.

2.5 Emerging Architectures: RISC-V Security Extensions

The RISC-V architecture, being an open and extensible Instruction Set Architecture (ISA), offers a flexible foundation for implementing runtime security mechanisms. While the base ISA provides fundamental building blocks, specific security features are often realized through standard extensions, vendor-specific enhancements, or open-source TEE frameworks. RISC-V defines multiple privilege levels to enforce isolation between different software components, which is a cornerstone of runtime security. The primary modes are machine mode (highest privilege level), supervisor mode, and user mode. Transitions between these modes are strictly controlled, typically via exceptions, interrupts, or environment calls. The Physical Memory Protection (PMP) unit is a standard RISC-V extension that allows M-mode software to define memory regions with specific access permissions (read, write, execute) for S-mode and U-mode. Several TEE frameworks and enclave technologies as open and closed source solutions are being developed for RISC-V, leveraging its PMP and privilege levels. Additionally, cryptographic extensions, custom instructions as well as side channel and fault attack countermeasures improve runtime integrity protection.

2.6 Post Quantum Cryptography supports Runtime Integrity Protection

Using Post-Quantum Cryptography (PQC) for runtime integrity in SoCs is an emerging and important area, driven by the anticipated threat quantum computers pose to current classical cryptography. It's crucial to understand that PQC doesn't typically provide direct mechanisms for runtime integrity protection in the same way features like MPUs, HRoTs, or TEEs do. Instead, PQC primarily ensures the long-term security and trustworthiness of the cryptographic operations that underpin or support various runtime integrity protection mechanisms. So, PQC might support secure boot and firmware updates, runtime attestation, securing runtime policies and configuration data, authenticating trusted applications and communication with TEE etc.

3. SoC Design Considerations

Designing SoCs with robust runtime integrity requires a holistic approach.

3.1 Performance, Power, and Area Trade-offs

Security measures introduce overhead. TEEs, for instance, incur overhead from memory isolation and encryption. To mitigate, hardware cryptographic accelerators maintain performance while saving power. Inline Memory Encryption integrated with DDR controllers offers low latency. Integrity and Data Encryption for interfaces provides confidentiality and integrity with ultra-low latency. Designers must balance security with performance based on specific requirements.

3.2 Integration Complexity

Integrating diverse security IP blocks (MPUs, TEEs) presents challenges in ensuring secure interaction across the SoC's bus system. The security subsystem needs exclusive access to its resources and robust isolation. Third-Party IP components introduce risks if vulnerable or insecurely integrated. Advanced co-verification methods are essential to track information flow and ensure security across all components, including Third-Party IP.

3.3 Secure Development Lifecycle and Hardware-Software Co-design

A "secure-by-design" philosophy is paramount, embedding security from the earliest design phases. It integrates security into every phase: requirements, planning, design, implementation, testing, and maintenance. Key activities include threat modeling, static/dynamic analysis, code reviews, and penetration testing. Hardware-software co-design is fundamental, ensuring concurrent and synergistic development for functional, performance, and security goals.

3.4 System Security Policies and Lifecycle Management

System security policies define SoC behavior, usage conditions, and restrictions, configured during provisioning, updates, or runtime. Examples include debug access controls, secure boot failure behavior, memory partitioning, firmware protection, and access restrictions to security services. The security subsystem enforces these policies, with violations leading to sanctions like system resets or restricted access. SoCs employ lifecycles (production, open, in-field) reflecting manufacturing and operation stages. Security policies are tied to these states; for instance, an "in-field" device may restrict further reconfiguration, hardening runtime integrity. The automotive industry uses a multi-stage lifecycle to accommodate distributed manufacturing and protect assets at each stage.

4. Conclusion: Building Resilient SoCs for a Secure Future

Runtime integrity protection is a core requirement for securing modern SoCs. As threats evolve beyond initial boot stages, SoC designers must extend trust into runtime through hardware-backed mechanisms like MPUs, TEEs, HRoTs, and security subsystems. These features—when combined with platform-level policies, lifecycle management, and emerging technologies like PQC and RISC-V extensions—build the foundation for resilient, attack-aware systems.

But technical capability alone isn’t enough. Secure SoC design requires a mindset shift: a commitment to "secure-by-design" principles, hardware-software co-development, and thoughtful trade-offs between performance, area, and integration complexity. The challenge is steep—but the cost of ignoring runtime security is steeper.

If you’re designing secure SoCs or embedded systems, runtime integrity protection should be part of your threat model and implementation strategy from day one. And if you need support implementing these mechanisms, we’re here to help.