Secure boot verifies firmware at start-up, and read-only file systems prevent easy tampering with stored files, but neither stops malicious code already running from abusing memory, APIs, or inter-process calls. An attacker can hijack a legitimate process, load code into RAM, or misuse authorised diagnostics after boot. Runtime controls such as memory protection and control flow integrity are needed to limit that abuse.
Why boot-time trust checks do not stop code that is already executing
Secure boot establishes trust in the firmware and boot chain before the operating system starts, but it does not continuously police what happens after control has been handed over. Once a trusted kernel and user processes are running, malicious code can still exploit those running privileges, inject into memory, or abuse the same interfaces legitimate software uses.
That is why a machine can be “secure at boot” and still be compromised at runtime. The boundary shifts from startup integrity to process integrity, memory integrity, and control over inter-process behaviour.
Boot-time trust also has a narrower job than many teams assume. It can stop unsigned or tampered components from starting, but it cannot by itself prevent a signed component, a trusted admin tool, or a live process from being turned against the system after the fact.
Why read-only file systems still leave runtime attack paths open
Read-only file systems mainly reduce persistence and make offline tampering harder. They do not stop code that is already in memory from invoking libraries, opening sockets, calling system services, or abusing diagnostics and management APIs that remain available after boot.
A read-only root may prevent an attacker from dropping a new binary onto disk, but it does not prevent process injection, in-memory patching, environment manipulation, token abuse, or hijacking a trusted process that already has the access needed to act.
For that reason, read-only storage is a hardening measure, not a runtime containment control. It lowers one class of change, but it does not remove execution paths that exist entirely in RAM or through authorised operating interfaces.
What runtime abuse actually looks like in practice
Runtime abuse usually depends on stealing or reusing trust that is already present. Common patterns include hijacking a legitimate process, loading malicious code into memory, abusing inter-process communication, or using allowed administrative and diagnostic functions after compromise.
The same distinction applies in containers, embedded devices, and locked-down appliances. If an attacker can execute code within the trusted environment, they may not need to modify the filesystem at all. They can instead target memory, credentials in use, environment variables, IPC channels, or exposed control endpoints.
That is why runtime control matters even when the platform looks immutable on disk. The meaningful security question is not only whether files can be altered, but whether running code can be constrained from impersonating trusted software or abusing the privileges it inherits.
Risk and Threat Considerations
The main risk is false confidence. Teams can overestimate the protection offered by boot integrity and filesystem immutability, then miss the fact that the live system still has rich attack surface in memory, process space, and management interfaces. Once a trusted process is abused, the attacker often inherits the authority of that process rather than needing to bypass the filesystem again.
Failure mechanism: A legitimate boot chain and read-only storage block some tampering, but they do not stop code execution in RAM, process injection, or abuse of authorised runtime interfaces after the system has started.
Impact: The attacker can alter behaviour without changing files, persist inside a trusted process, bypass file-based integrity assumptions, and reach sensitive actions that the operating system still permits at runtime.
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 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-16 — Memory Protection | Runtime abuse here hinges on memory tampering after boot. |
| AC-6 — Least Privilege | Abuse succeeds when running code retains more authority than it needs. | |
| SI-7 — Software, Firmware, and Information Integrity | Boot trust and integrity checks are central to the question's startup-versus-runtime split. | |
| Recommendation — Enforce memory protections that limit code injection and memory corruption at runtime. Constrain running processes to the minimum privileges they require. Use integrity controls to verify trusted components and detect tampering. | ||
Practitioner Guidance
What to verify: Confirm that your hardening model includes runtime controls, not just boot assurance. If the environment can execute untrusted code or host third-party modules, you need a plan for memory protection, process isolation, and control over inter-process communication.
What good looks like: A secure platform should make it difficult for one process to tamper with another, restrict unsigned or unexpected code paths, and limit the usefulness of live diagnostics and admin channels if an attacker reaches user space.
Decision rule: If the threat is post-boot abuse, treat boot verification and read-only storage as baseline hygiene, then prioritise runtime containment measures that reduce what running code can do even after initial compromise.
Practitioner takeaway: Immutable startup does not equal immutable execution, so the real control objective is to limit what trusted-looking code can do once the system is alive.
Related resources from NHI Mgmt Group
- Guide: Firmware and Boot Security Guide
- What should teams do immediately when a runtime file-read flaw exposes secrets?
- What breaks when organisations secure AI only at the model file and not at runtime?
- How should security teams secure autonomous Salesforce agents that can read CRM data and call external services at runtime?
- How should enterprises secure AI systems that access sensitive data at runtime?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org