---
{
  "title": "Pre-OS Boot",
  "summary": "Pre-operating-system persistence runs through firmware or startup components before ordinary operating-system controls.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1542"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1542: Pre-OS Boot",
      "url": "https://attack.mitre.org/techniques/T1542"
    }
  ],
  "editorialVersion": 2
}
---

## The operating system is not the first code to run

Pre-operating-system boot mechanisms execute before the main operating system takes control. Firmware and startup components establish important parts of the system's execution path. Unauthorized changes at this layer can provide persistence or undermine trust in what later software reports.

This is a specialized investigation area. A recurring infection after a restart does not automatically prove firmware compromise; ordinary services, startup entries, restored files, and cloud identities can also reintroduce access. Consider simpler explanations alongside the boot-layer hypothesis.

## A rebuild does not explain recurring behavior

In a fictional case, a device shows unexplained activity after an operating-system rebuild. The team first checks whether the rebuild source, configuration management, user profile, and restored data could have reintroduced the behavior. They then involve platform specialists if evidence suggests a lower-level trust issue.

Relevant evidence may include firmware versions, supported integrity measurements, boot configuration, update history, and independently trusted comparison information. The exact methods depend on the device and vendor; avoid unsupported procedures that could damage hardware or erase evidence.

A displayed firmware version is useful context but not a complete integrity guarantee. Likewise, a missing conventional startup artifact does not prove that the explanation lies below the operating system.

## Understand the observation limit

Host-based tools observe through the running environment and may not fully establish the integrity of earlier execution layers. Independent or vendor-supported verification may be necessary. Document what each method actually checks rather than describing a general scan as complete proof.

[[rootkit]] describes concealment and interference with visibility, while [[boot-or-logon-autostart-execution]] covers ordinary operating-system startup mechanisms. [[modify-system-image]] addresses embedded or network-device operating software changes. These related concepts require different evidence and recovery expertise.

Preserve available boot and platform information before remediation where practical. The response team should record any firmware updates, resets, or reimaging actions because those changes affect later interpretation.

## Recover through a trusted process

Coordinate with platform owners and the vendor-supported recovery procedure. Address the access that enabled modification and verify the approved firmware, boot configuration, and operating-system state. A normal application reinstall is not a complete response to a confirmed lower-level compromise.

For practice, compare a legitimate firmware update with a fictional unexplained boot-component change. Identify authorization, provenance, integrity, and independent verification evidence. Explain why repeated symptoms alone do not establish a bootkit. [[incident-response]] coordinates the specialist work, while [[incident-reporting]] should distinguish a suspected trust-layer issue from a confirmed modification.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]