A memory protection unit is hardware that enforces access restrictions on memory regions, usually in embedded or constrained systems. It helps separate code and data, block unauthorised access, and contain faults. If protection regions are absent or too permissive, malformed input or compromise can overwrite sensitive memory or disrupt control flow.
What a memory protection unit does
A memory protection unit, or MPU, is a hardware control that divides memory into regions and applies access rules at run time. In embedded systems, it is one of the main ways a processor can stop code from reading, writing, or executing memory it should not touch.
That matters because MPU rules are enforced by the CPU itself, not by application logic. When the region layout is correct, the MPU can separate privileged and unprivileged code, isolate data structures, and reduce the blast radius of a fault or buggy component.
Why MPU boundaries matter for security and reliability
The security value of an MPU is that it turns memory layout into an enforcement boundary. If sensitive buffers, control data, or code sections are left unprotected, a defect or malicious input can overwrite memory, redirect execution, or corrupt state in ways that are hard to recover from.
MPUs are especially important in constrained devices where full virtual memory protection may not exist. They help preserve system integrity by making illegal accesses fail immediately, rather than allowing silent corruption to spread through the device.
How MPU design affects attack surface
An MPU is only as strong as its region design. Too few regions, overly broad permissions, or shared read-write memory between unrelated components can leave security-critical data exposed even when an MPU is present.
Conversely, well-designed regions can contain a fault in one task, prevent accidental access to secrets or control structures, and limit the impact of memory safety bugs. That containment is often the difference between a recoverable exception and a full device compromise.
MPUs in embedded system architecture
MPUs are common in microcontrollers, real-time systems, and other constrained environments where predictable performance and small hardware footprints matter. They are often used alongside privilege separation, stack guards, and secure boot to create a layered defence model.
They do not replace secure coding, but they do make unsafe code less catastrophic. When developers assume the MPU will compensate for poor memory handling, they can end up with a false sense of isolation, so MPU policy must match the actual software architecture.
Risk and Threat Considerations
MPU failures create direct integrity and availability risk because memory isolation is often the last line of defence in embedded platforms. A weak region map, missing execute protection, or permissive shared memory can let malformed input or exploitation overwrite sensitive state, disrupt control flow, or crash the device.
Failure mechanism: The attacker or fault condition succeeds when protected and unprotected regions overlap, when access permissions are too broad, or when critical data is placed in memory that the MPU does not constrain.
Impact: The result can be privilege abuse, persistent corruption, denial of service, or full compromise of the embedded control path, especially where the device has no stronger isolation layer to fall back on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | MPUs enforce memory isolation between software components. |
| SI-16 — Memory Protection | The MPU is a direct mechanism for enforcing memory protection rules. | |
| Recommendation — Apply SC-39 to isolate critical memory regions from less trusted code. Use SI-16 to constrain memory access and prevent unauthorized overwrite. | ||
| ISO/IEC 27001:2022 | A.8.27 — Secure system architecture and engineering principles | MPU design is part of secure architecture for constrained systems. |
| Recommendation — Build MPU region design into secure architecture reviews for embedded systems. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | MPU permissions depend on secure, validated firmware configuration. |
| Recommendation — Harden firmware configuration so MPU regions and permissions stay restrictive. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | MPU protection is an architectural safeguard against memory corruption impact. |
| Recommendation — Design software so critical data and control paths remain isolated by architecture. | ||
Practitioner Guidance
Why practitioners should care: Treat the MPU as an architectural control, not a checkbox. Its value depends on whether region boundaries reflect real trust boundaries in the software, including code, stacks, buffers, and control registers.
What to watch for: Review region size, alignment, permission flags, and overlap whenever firmware changes introduce new tasks or memory objects. If the design cannot clearly explain why a region is shared, it is usually too permissive.
Practitioner takeaway: The best MPU designs are simple, explicit, and tightly tied to the device’s actual execution model.
Related resources from NHI Mgmt Group
- What is the difference between endpoint protection that blocks suspicious files and memory analysis that inspects running code?
- What happens when attackers get access to Windows memory without LSA Protection in place?
- Memory Protection
- What is the difference between runtime protection and NHI lifecycle management?