NIST SP 800-155

NIST Special Publication 800-155 is a framework for measuring BIOS firmware integrity and identifying unauthorized changes to critical system components. Its principles help enterprises assess endpoint firmware security, where sophisticated attacks can operate beyond conventional operating system defenses. For cybersecurity architects and security operations teams, the publication introduces key concepts in firmware integrity verification, platform attestation, and incident response. These capabilities help organizations evaluate the trustworthiness of computing devices and identify security risks that traditional endpoint monitoring may overlook.

What Is NIST SP 800-155?

NIST Special Publication 800-155 (NIST SP 800-155), BIOS Integrity Measurement Guidelines, describes a security architecture for measuring and reporting the integrity of Basic Input/Output System (BIOS) firmware and its configuration. Developed by the National Institute of Standards and Technology (NIST), it addresses the risks associated with unauthorized firmware changes on enterprise desktops and laptops. Its central objective is to establish a dependable process for collecting, storing, and reporting firmware measurements. Organizations can then compare these measurements against approved reference values to identify unexpected modifications. Although the publication uses the term BIOS, the underlying concepts also apply to modern platforms that use Unified Extensible Firmware Interface (UEFI) firmware.

NIST released SP 800-155 as an initial public draft in December 2011 and discontinued further development in October 2024. Its technical guidance was contributed to the Trusted Computing Group (TCG) for incorporation into the PC Client Firmware Integrity Measurement specification. Although SP 800-155 was never finalized, its principles remain relevant to enterprise endpoint security. Hardware-based roots of trust, cryptographic measurements, and platform attestation enable security teams to evaluate firmware integrity independently of many operating system controls.

Why BIOS Integrity Is Critical to Enterprise Cybersecurity

BIOS and UEFI firmware initialize system hardware and establish the execution environment required to start an operating system. Their privileged position in the boot process makes them valuable targets for attackers seeking persistent access or control over enterprise devices.

• Privileged Execution Environment: System firmware initializes processors, memory, and other hardware before transferring control to the operating system bootloader. A compromised firmware component can interfere with this sequence, alter security settings, or influence the execution of trusted software. Certain firmware functions, including those operating in System Management Mode (SMM), have privileges beyond those available to normal operating system processes.
• Firmware-level Threats: Attackers may exploit firmware vulnerabilities, abuse update mechanisms, or modify firmware storage to introduce malicious code. UEFI bootkits can manipulate the boot sequence to load unauthorized components, while firmware implants may provide concealed execution capabilities. Attackers can also alter UEFI variables or platform configurations to weaken security controls without replacing entire firmware images.
• Persistence and Evasion: Malicious firmware can sometimes survive operating system reinstallation or storage replacement because it resides outside the affected disk. Early execution also allows certain threats to operate before EDR agents and other endpoint defenses become active. An attacker who controls the firmware may interfere with security monitoring or compromise the integrity of information reported by the operating system.
• Enterprise Attack Scenarios: Firmware attacks can support cyberespionage, persistent remote access, destructive operations, and targeted attacks against high-value systems. Compromised devices introduced through hardware procurement, servicing, or supply chain processes create additional risks. A successful attack may undermine a device’s integrity before it enters the production environment.
• Limitations of Conventional Defenses: Antivirus software, EDR systems, and vulnerability scanners generally focus on operating system activity, applications, and network behavior. Although some products offer firmware inspection, their visibility may be incomplete. Detecting modifications below the operating system requires measurement mechanisms designed specifically for firmware components and platform configurations.

Core Security Architecture and Technical Requirements of NIST SP 800-155

NIST SP 800-155 describes a coordinated architecture for collecting firmware measurements and presenting them to an assessment authority. Its security model depends on protecting the measurement process and ensuring reported evidence reflects the platform’s actual state.

• Roots of Trust: The architecture relies on three foundational capabilities: the Root of Trust for Measurement (RTM), Root of Trust for Storage (RTS), and Root of Trust for Reporting (RTR). The RTM establishes a trustworthy starting point for measuring firmware components. The RTS protects accumulated measurement values against undetected modification, while the RTR provides mechanisms for authenticated reporting. These functions establish the trust boundaries on which subsequent integrity assessments depend.
• Measurement Architecture: Specialized agents perform the operations required to collect, protect, and transmit integrity evidence. The Measurement Agent obtains measurements from designated firmware components, while the Storage Agent maintains the resulting information. The Reporting Agent prepares authenticated evidence for assessment. Collection and Transmission Agents support communication between the monitored platform and the assessment authority. Separating these functions clarifies security responsibilities and helps identify where evidence could be manipulated.
• Firmware Measurements: Cryptographic hash functions generate fixed-length digests representing measured firmware code or configuration data. A change to the measured content normally produces a different digest, enabling detection of modifications. Measurement coverage must include the components and settings relevant to platform security. The selected measurement boundaries, execution stage, and access to firmware storage determine which modifications can be detected.
• Reference Measurements: Integrity assessment requires known-good reference values associated with approved firmware versions and configurations. These values may originate from equipment manufacturers or trusted enterprise provisioning processes. Reference records should identify the platform model, firmware release, and relevant configuration attributes. Protecting their provenance and integrity is essential because altered reference values could cause unauthorized firmware to appear legitimate.
• Measurement Assessment Authority (MAA): The MAA evaluates reported measurements against expected reference values and organizational security requirements. Assessment policies may account for authorized firmware versions, platform configurations, and device-specific exceptions. The resulting determination indicates whether the evidence satisfies established integrity criteria or requires further investigation.
• Integrity Reporting: Reporting mechanisms must protect evidence against substitution, unauthorized modification, and replay attacks. Cryptographic authentication links measurements to trusted reporting components, while freshness mechanisms such as nonces help prevent reuse of older reports. Secure communication channels protect evidence in transit to the assessment authority.

How BIOS Integrity Measurement and Verification Work

Firmware integrity verification combines cryptographic measurement with procedures for assessing the authenticity and acceptability of the results. The process creates evidence that can be evaluated locally or by a centralized enterprise attestation service.

• Boot-time Measurement: During platform initialization, trusted components measure designated firmware code and configuration data. Measurements must occur at appropriate execution stages to capture the components relevant to system startup. In a chain-of-measurement architecture, earlier trusted components establish the basis for measuring subsequent components. This process records the firmware state encountered during initialization rather than directly determining whether the code is malicious.
• Measurement Collection and Storage: TPM-based implementations can accumulate measurement results in Platform Configuration Registers (PCRs). A PCR extend operation calculates a new register value from the existing PCR value and an additional measurement digest. An associated event log identifies measured components and records their digests. The accumulated PCR values provide compact evidence of the measurement sequence, while the event log supplies the details needed for interpretation.
• Reference Baseline Comparison: A verifier evaluates collected measurements against approved firmware images and configuration baselines. The comparison must account for the device model, firmware release, and supported security settings. Legitimate changes, including firmware upgrades, can alter measurement values. Baseline management must therefore distinguish authorized maintenance from unexplained modifications.
• Attestation and Verification: Remote attestation allows an external verifier to evaluate authenticated platform evidence. In a typical TPM-based implementation, the verifier requests a quote containing selected PCR values and a freshness challenge. The TPM signs the quote using an attestation key. The verifier validates the signature and nonce, evaluates the accompanying event log, and determines whether the measurements satisfy applicable policies. This process requires a trustworthy association between the attestation key and the device being assessed.
• Integrity Assessment Outcomes: Verification can produce a successful assessment, a policy violation, or an indeterminate result when sufficient evidence is unavailable. Enterprises can use these outcomes to initiate investigations, apply access restrictions, or require device remediation. Assessment decisions should consider maintenance history and the reliability of the reported measurements.
• Technical Limitations: Cryptographic measurements establish whether selected content matches expected values, not whether the measured software is free of vulnerabilities. Incomplete measurement coverage may leave firmware components unexamined. Runtime attacks can also occur after boot-time measurements have been collected. Therefore, interpret verification results within the documented scope and trust assumptions of the implementation.

Applying NIST SP 800-155 to Enterprise Threat Detection and Incident Response

Firmware integrity evidence can improve security operations by providing information about platform state that conventional endpoint telemetry does not always provide. Its greatest operational value comes from correlating integrity findings with other security events and device activity.

• Firmware Threat Detection: Unexpected changes to firmware measurements may indicate unauthorized updates, configuration tampering, or malicious implants. Security teams can prioritize findings involving unapproved firmware versions, modified boot components, or disabled platform protections. Investigation should distinguish suspicious activity from legitimate maintenance and firmware recovery operations.
• SIEM and XDR Integration: Centralized attestation systems can export firmware assessment results to SIEM and XDR platforms. Useful fields include device identity, firmware version, measurement status, baseline identifier, assessment timestamp, and verification outcome. Correlation rules can associate integrity failures with suspicious authentication events, unauthorized administrative activity, or endpoint alerts. This context helps analysts prioritize devices presenting multiple indicators of compromise.
• Threat Intelligence Correlation: Firmware integrity findings can complement threat intelligence describing adversary tools, tactics, techniques, and procedures. MITRE ATT&CK identifies Pre-OS Boot (T1542) as a persistence technique that includes firmware-related attacks. Intelligence about known bootkits, vulnerable firmware releases, and threat actor behavior can guide investigations, although measurement differences alone rarely identify a specific threat.
• Incident Investigation: Analysts can examine firmware versions, historical attestation results, change records, and related endpoint telemetry to determine when suspicious modifications occurred. Comparing affected devices can reveal whether an incident is isolated or associated with a common firmware image, update process, or hardware platform. Preserved measurement evidence can also support forensic analysis and incident reconstruction.
• Response and Recovery: Confirmed firmware compromise may require device isolation, vendor-approved firmware recovery, or hardware replacement. Recovery operations should use trusted images and secure update mechanisms. Analysts should validate the restored firmware state and investigate potential credential exposure or operating system compromise before returning the endpoint to production.

NIST SP 800-155 and Related Firmware Security Standards and Technologies

NIST SP 800-155 addresses firmware integrity measurement within a broader system of platform security controls. Related standards establish requirements for firmware protection, boot security, trusted computing, and device integrity assessment.

• NIST SP 800-147 and SP 800-147B: NIST SP 800-147, BIOS Protection Guidelines, addresses preventing unauthorized BIOS modification through secure update mechanisms and related protections. SP 800-147B extends BIOS protection guidance to server platforms. These publications focus on protecting firmware against unauthorized changes, whereas SP 800-155 addresses measurement and reporting. Together, their concepts support both firmware protection and independent integrity assessment.
• Trusted Computing Group Specifications: TCG develops standards supporting trusted computing, platform measurement, and attestation. SP 800-155’s technical guidance was contributed to TCG’s PC Client Firmware Integrity Measurement specification. The TCG TPM specifications define cryptographic functions and protected storage mechanisms that can support attestation architectures. Modern implementations should follow the applicable TCG and platform specifications rather than relying on SP 800-155 as an active implementation standard.
• UEFI Secure Boot and Measured Boot: UEFI Secure Boot uses authenticated signatures and trusted key databases to control which boot components may execute. Measured Boot records cryptographic evidence describing components encountered during startup. Secure Boot therefore provides an enforcement mechanism, while Measured Boot supplies evidence for later assessment. The two technologies address different security objectives and can operate together.
• NIST SP 1800-34: NIST SP 1800-34, Validating the Integrity of Computing Devices, examines methods for assessing the integrity of computing equipment. Its guidance addresses broader device integrity concerns, including verification techniques that can help organizations evaluate hardware and firmware trustworthiness. It provides practical context for enterprises implementing device integrity assurance programs.
• Zero Trust Architecture: Platform attestation can supply device integrity evidence to Zero Trust security systems. Access policies may incorporate this evidence alongside device identity, authentication strength, endpoint management status, and contextual risk. A failed platform assessment can influence access decisions without requiring the organization to treat firmware verification as a standalone security control.

Enterprise Implementation Challenges and Security Best Practices

Deploying firmware integrity measurement across a large enterprise requires consistent hardware capabilities, trustworthy reference data, and defined operational procedures. Security architects must also account for differences in device platforms and the evidence available from each implementation.

• Platform and Vendor Dependencies: Firmware measurement capabilities vary across hardware models, BIOS/UEFI implementations, TPM configurations, and equipment manufacturers. Procurement requirements should address measurement coverage, attestation support, secure firmware updates, and recovery capabilities. Vendor documentation should identify supported measurements and relevant implementation limitations.
• Baseline Governance: Enterprises need controlled processes to establish and maintain trusted firmware reference values. Baselines should link to specific device models, firmware releases, and approved configurations. Configuration management systems can record authorized changes and preserve historical measurement data for audit and investigation.
• Operational Scalability: Enterprise deployments require automated evidence collection, centralized verification, and integration with asset management systems. Attestation infrastructure must handle distributed devices, intermittent connectivity, and different firmware update schedules. Organizations should distinguish devices that fail verification from those unable to provide sufficient evidence.
• Detection Confidence and Coverage: Integrity policies must account for measurement reliability, component coverage, and expected platform variations. False positives can arise from legitimate changes or mismatched reference data. Security teams should document which firmware components are evaluated and identify gaps requiring complementary controls.
• Security Program Integration: Firmware integrity monitoring should be incorporated into endpoint lifecycle management, vulnerability management, incident response, and device access policies. Security teams need defined responsibilities for investigating failed assessments, approving firmware changes, and validating devices after remediation.

Conclusion

NIST SP 800-155 established a technical foundation for measuring BIOS firmware integrity and assessing whether critical platform components match trusted reference values. Its architecture describes how measurement agents, protected evidence, reporting mechanisms, and assessment authorities contribute to firmware integrity assurance. Although the publication remained a draft and further development ended in 2024, its principles continue to inform modern trusted computing and platform attestation technologies.

For enterprise cybersecurity teams, these capabilities address an important security challenge: determining whether the firmware supporting an endpoint can be trusted. Incorporating firmware integrity assessment into broader security architectures can improve the detection of unauthorized platform changes, support investigations of persistent threats, and strengthen device assurance. Combined with secure firmware updates, endpoint monitoring, and established response procedures, firmware integrity measurement contributes to a more resilient defense against attacks targeting the earliest stages of system execution.

Deepwatch® is the pioneer of AI- and human-driven cyber resilience. By combining AI, security data, intelligence, and human expertise, the Deepwatch Platform helps organizations reduce risk through early and precise threat detection and remediation. Ready to Become Cyber Resilient? Meet with our managed security experts to discuss your use cases, technology, and pain points, and learn how Deepwatch can help.

Related Content

• Move Beyond Detection and Response to Accelerate Cyber Resilience: This resource explores how security operations teams can evolve beyond reactive detection and response toward proactive, adaptive resilience strategies. It outlines methods to reduce dwell time, accelerate threat mitigation, and align SOC capabilities with business continuity goals.
• The Dawn of Collaborative Agentic AI in MDR: In this whitepaper, learn about the groundbreaking collaborative agentic AI ecosystem that is redefining managed detection and response services. Discover how the Deepwatch platform’s dual focus on security operations (SOC) enhancement and customer experience ultimately drives proactive defense strategies aligned with organizational goals.
• 2024 Deepwatch Adversary Tactics & Intelligence Annual Threat Report: The 2024 threat report offers an in-depth analysis of evolving adversary tactics, including keylogging, credential theft, and the use of remote access tools. It provides actionable intelligence, MITRE ATT&CK mapping, and insights into the behaviors of threat actors targeting enterprise networks.