How can security teams detect pre-OS boot activity?

What pre-OS boot activity actually looks like in telemetry

Pre-OS boot activity is the period where firmware, boot managers and EFI variables run before the operating system can provide logs or EDR visibility. That makes the evidence trail narrow but not absent: the most useful signals come from trusted boot measurements, firmware state, boot path configuration and any deviation from the device’s known-good startup chain.

Security teams should treat the boot path as a sequence, not a single event. A change in boot order, a modified bootloader, a new unsigned boot component or an unexpected EFI variable can all indicate tampering, even if the OS later looks healthy. The key question is whether the platform still matches the approved firmware and boot posture.

For teams building a deeper firmware baseline, the Firmware and Boot Security Guide is the most direct reference for secure boot, measured boot and pre-boot attack patterns. It helps connect boot integrity checks to the kinds of firmware changes that matter operationally, rather than treating them as isolated alerts.

Where detection should focus first

Detection is strongest when it compares current boot and firmware state against an approved baseline. That means watching for drift in UEFI Secure Boot state, bootloader hashes, firmware settings and TPM-measured values, then flagging anything that does not match the device’s expected trust chain. This is especially important for endpoints that can reboot without generating conventional operating-system events.

Teams should also look for the places attackers use to persist before the OS loads. Unsigned or newly introduced boot components, modified EFI files and unexpected boot entries are the practical indicators that matter most. If the device shows a clean OS but the pre-OS measurements changed, assume the risk is in the startup chain rather than the running workload.

That is why the Disk Encryption Guide: BitLocker and FileVault is relevant here as well, because pre-boot trust often overlaps with TPM-backed startup protection, recovery key handling and the controls that govern what can happen before the OS unlocks.

Why missing OS telemetry is a warning sign

When a device bypasses normal operating system telemetry, security teams lose the visibility that usually reveals persistence, tampering or credential abuse. That does not prove compromise by itself, but it does mean the most important evidence may live in firmware attestation, secure boot logs, endpoint configuration records or out-of-band management data instead of the usual SIEM feeds.

Devices that repeatedly reboot, fail attestation, or show firmware and boot state changes without an accompanying administrative change deserve priority review. The same is true when a platform returns to service but its boot measurements no longer align with the approved state. In practice, the issue is not only whether the OS starts, but whether the platform can still be trusted to start cleanly.

If you need a control-oriented lens for that kind of drift detection, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides the baseline control structure for configuration management, integrity monitoring and auditability that support this kind of detection program.

Risk and Threat Considerations

Pre-OS activity is attractive to attackers because it can sit below ordinary endpoint telemetry and survive operating system reinstalls. That makes firmware tampering, bootkit persistence and unauthorized boot-chain changes especially dangerous on high-value laptops, servers and admin workstations.

Failure mechanism: A hostile change in firmware, boot configuration or bootloader state alters the trusted startup chain before the OS can inspect itself, log the event or block execution.

Impact: The compromise can produce durable persistence, hidden execution, offline credential exposure or a platform that appears healthy while remaining untrustworthy.

Practitioner Guidance

What to verify: Check that your monitoring can compare boot order, secure boot state, bootloader signatures, EFI variables and TPM measurements against a known-good baseline. If you cannot prove that those elements are being recorded consistently, you do not yet have reliable pre-OS detection.

Common mistake: Treating a successful OS login as proof that the platform booted safely. A clean operating system can still be the result of a compromised startup chain, so boot integrity evidence must be reviewed independently of endpoint health.

Practitioner takeaway: The most useful pre-OS detection program is one that turns boot integrity into an auditable baseline, not a one-time check, because the attacker only needs one trusted startup path to stay hidden.

Related resources from NHI Mgmt Group

• How can security teams detect malicious Modbus activity early?
• How can security teams detect AI-mediated intrusion activity?
• How should security teams detect attacks that look like normal user activity?
• How should security teams detect cloud activity that is trying to hide in normal volume?