Boot-time code execution is code that runs during system startup before normal user-space services are fully available. It usually comes from firmware, bootloaders, startup scripts, or early kernel components, and it can establish persistence, initialise drivers, or load security controls.
What Boot-Time Code Execution Means
Boot-time code execution is significant because it runs before the operating system has fully brought normal services online. That early position gives the code unusually high leverage: it can shape what gets loaded, what security checks start, and what persists into the full system session.
In practice, boot-time execution can live in firmware, a bootloader, an initramfs or startup chain, early kernel components, or platform-specific pre-OS mechanisms. The security meaning is the same, even if the implementation differs: code at this stage can influence the trust boundary the rest of the machine depends on.
Why Early Execution Is Security-Sensitive
Startup code is attractive because it can run before many visibility and control layers exist. That means it may initialize drivers, alter boot configuration, disable protections, or stage later payloads before endpoint tools, logging, and user-space controls are fully active.
It is also sensitive because startup code often sits inside a chain of trust. If an attacker can change one trusted early component, they may gain persistence or influence every later stage of execution. That is why boot-time code execution is often discussed alongside persistence, firmware tampering, and secure boot trust assumptions.
For defenders, the key question is not only whether code runs early, but whether it is expected, signed, measured, and recoverable. A legitimate boot component that is poorly governed can create the same operational exposure as malicious code, especially if it is difficult to inspect after compromise.
Common Sources And Attack Paths
Boot-time code execution can be intentional and legitimate, such as disk encryption unlock logic, hypervisor startup routines, or security agents that must initialize before standard services. It becomes dangerous when attackers can replace, insert, or modify those early components. This is the same persistence pattern covered in Persistence Techniques Guide, where boot or logon autostart execution is one of the most durable footholds.
One common abuse pattern is to hide malicious logic in the boot sequence so that it executes before defensive software can start. Another is to tamper with firmware or bootloader settings so the machine repeatedly launches attacker-controlled code. In environments with weaker startup integrity, that can survive reboots and complicate eradication.
The related ATT&CK pattern is documented in T1547 Boot or Logon Autostart Execution Defensive Guide, which shows how run keys, startup folders, and boot-path mechanisms are used for persistence and how defenders can detect them.
Verification, Detection, And Recovery
Exposure checks should start with inventory: which platforms use firmware-based startup logic, which startup scripts run before user space, and which security controls depend on early boot initialization. Teams should compare expected boot components with vendor documentation, platform baselines, and measured boot or secure boot data where available.
Detection is often strongest when it combines configuration review, boot-chain integrity checks, and post-reboot behaviour analysis. If a machine repeatedly boots with altered settings, unexpected modules, or missing security controls, that can indicate pre-user-space tampering rather than an ordinary software issue.
Recovery usually requires more than deleting a file. When boot-stage code is suspected, teams may need to validate firmware, rebuild trusted boot components, rotate secrets exposed during the compromise, and confirm that the system returns to a known-good boot path before putting it back into production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547 — Boot or Logon Autostart Execution | Boot-time code execution is an autostart persistence path attackers abuse. |
| Recommendation — Map boot-stage execution points to T1547 and monitor for unauthorized autostart changes. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Boot-time code depends on integrity of firmware and early startup components. |
| Recommendation — Enforce integrity checks for firmware and boot components before allowing normal startup. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Early boot compromise is harder to see, so startup and integrity evidence must be retained. |
| Recommendation — Collect and review boot and integrity events so early-stage tampering is detectable. | ||
| NIST CSF 2.0 | PR.DS-09 — Integrity and authenticity of data are protected | Boot-stage trust relies on integrity of the code and configuration that starts the system. |
| Recommendation — Protect boot code and startup configuration with integrity controls and trusted provenance. | ||
Practitioner Guidance
What to watch for: Treat boot-time execution as part of the trust boundary, not just a startup detail. If a component runs before normal telemetry, authentication agents, or EDR are active, it deserves stronger provenance checks, tighter change control, and explicit recovery planning.
Governance implication: Owners should know which early boot components are allowed, who can change them, and how those changes are verified. A clear baseline for firmware, bootloader, and startup-chain integrity is essential because compromise at this layer can outlive ordinary remediation.
Practitioner takeaway: If the boot path is not measured and recoverable, it is not fully trusted, no matter how routine it appears in operations.
Related resources from NHI Mgmt Group
- Guide: AI Agent Sandboxing and Code Execution Guide
- Execution (MITRE ATT&CK Tactic)
- Who is accountable when a critical platform flaw affects identity and code execution at the same time?
- Why does import-time code execution increase supply-chain risk so much?
- Why does install-time code execution in npm packages increase secret theft risk?
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 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org