Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1542.001: System Firmware

Adversaries may modify system firmware to persist on systems.The BIOS (Basic Input/Output System) and The Unified Extensible Firmware Interface (UEFI) or Extensible Firmware Interface (EFI) are examples of system firmware that operate as the software interface between the operating system and hardware of a computer.[1][2][3]

System firmware like BIOS and (U)EFI underly the functionality of a computer and may be modified by an adversary to perform or assist in malicious activity. Capabilities exist to overwrite the system firmware, which may give sophisticated adversaries a means to install malicious firmware updates as a means of persistence on a system that may be difficult to detect.

EnterpriseT1542.001Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

System Firmware persistence matters because it sits below the operating system. If BIOS, UEFI/EFI, or network device firmware is modified, normal endpoint controls and rebuild procedures may not be enough to restore trust. For leaders, this is a resilience and assurance issue: the organization needs to know which critical Windows systems and network devices have firmware integrity controls, accountable privileged access, and a reliable firmware update process.

Executive priority

Prioritize this where compromise of a workstation, server, or network device would undermine business continuity, incident containment, or audit confidence. Key executive questions: Which assets depend on firmware-level trust? Who can update or alter firmware? Can security teams prove boot integrity and firmware currency? Do incident response playbooks include scenarios where persistence survives OS reinstallation?

Technical view

ATT&CK maps this sub-technique to Pre-OS Boot persistence and stealth on Windows and Network Devices. MITRE does not provide native detection text for this object, but a related detection strategy DET0099 exists. SOC and IR teams should validate whether they can observe firmware version/state changes, boot integrity status, privileged actions that enable firmware modification, and firmware update activity. Treat this as a high-assurance validation problem rather than a simple signature problem.

Likely telemetry

  • Firmware, BIOS, UEFI/EFI, and network device firmware inventory and version history
  • Boot integrity or secure boot status where available
  • Privileged account authentication, authorization, and administrative action logs
  • Firmware update, configuration change, and maintenance records
  • Endpoint or asset management evidence showing hardware model, firmware baseline, and update state

Detection direction

  • Validate the related DET0099 detection strategy against local Windows and network device telemetry rather than assuming default EDR coverage is sufficient.
  • Tune for unauthorized or unexpected firmware changes, especially outside approved maintenance windows or without matching change records.
  • Correlate firmware changes with privileged account usage because M1026 is a related mitigation for this technique.
  • Account for blind spots: operating-system-level logs may not show pre-OS tampering, and sparse or inconsistent firmware inventory can prevent meaningful baselining.
  • Use relationship context from known software examples—Trojan.Mebromi, Hacking Team UEFI Rootkit, and LoJax—as validation prompts for persistence concepts, not as evidence of current exposure or activity.

Mitigation priorities

  • Start with privileged account management: restrict and audit who can perform firmware or boot-related administrative actions.
  • Implement boot integrity controls where supported, including hardware-rooted trust and verification of the boot process as described by the related Boot Integrity mitigation.
  • Maintain a governed firmware update process for Windows systems and network devices, including version tracking and vendor update cadence.
  • Include firmware integrity checks and re-flashing or hardware trust decisions in incident response recovery criteria when this behavior is suspected.
  • Use asset criticality to prioritize coverage, beginning with systems where persistent compromise would materially affect operations or recovery confidence.
Analyst notes and limits

This technique replaced the older T1019 System Firmware object and is a sub-technique of T1542 Pre-OS Boot. ATT&CK lists Windows and Network Devices as platforms and stealth/persistence as tactics. The supplied relationships support defensive emphasis on privileged account management, boot integrity, software/firmware updates, and detection strategy validation.

The official ATT&CK detection field is not provided, and the related DET0099 content is referenced only by name. This take therefore avoids claiming specific detection logic or guaranteed coverage. Local hardware, firmware management tooling, boot integrity capabilities, and administrative logging determine practical defensibility.

Official MITRE ATT&CK definition

System Firmware

Adversaries may modify system firmware to persist on systems.The BIOS (Basic Input/Output System) and The Unified Extensible Firmware Interface (UEFI) or Extensible Firmware Interface (EFI) are examples of system firmware that operate as the software interface between the operating system and hardware of a computer.[1][2][3]

System firmware like BIOS and (U)EFI underly the functionality of a computer and may be modified by an adversary to perform or assist in malicious activity. Capabilities exist to overwrite the system firmware, which may give sophisticated adversaries a means to install malicious firmware updates as a means of persistence on a system that may be difficult to detect.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1019 System Firmware System Firmware revoked by this object.
Enterprise T1542 Pre-OS Boot This object subtechnique of Pre-OS Boot.
Associated objects

Groups, software, and campaigns

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1046: Boot Integrity Enterprise mitigates · Mitigation M1051: Update Software Enterprise detects · Detection Strategy DET0099: Detection Strategy for T1542.001 Pre-OS Boot: System Firmware Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise uses · Malware S0397: LoJax Enterprise uses · Malware S0001: Trojan.Mebromi Enterprise uses · Malware S0047: Hacking Team UEFI Rootkit Enterprise revoked by · Technique T1019: System Firmware Enterprise subtechnique of · Technique T1542: Pre-OS Boot Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1046: Boot Integrity

Boot Integrity ensures that a system starts securely by verifying the integrity of its boot process, operating system, and associated components. This mitigation focuses on leveraging secure boot mechanisms, hardware-rooted trust, and runtime integrity checks to prevent tampering during the boot sequence. It is designed to thwart adversaries attempting to modify system firmware, bootloaders, or critical OS components. This mitigation can be implemented through the following measures:

Implementation of Secure Boot:

- Implementation: Enable UEFI Secure Boot on all systems and configure it to allow only signed bootloaders and operating systems. - Use Case: An adversary attempts to replace the system’s bootloader with a malicious version to gain persistence. Secure Boot prevents the untrusted bootloader from executing, halting the attack.

Utilization of TPMs:

- Implementation: Configure systems to use TPM-based attestation for boot integrity, ensuring that any modification to the firmware, bootloader, or OS is detected. - Use Case: A compromised firmware component alters the boot sequence. The TPM detects the change and triggers an alert, allowing the organization to respond before further damage.

Enable Bootloader Passwords:

- Implementation: Protect BIOS/UEFI settings with a strong password and limit physical access to devices. - Use Case: An attacker with physical access attempts to disable Secure Boot or modify the boot sequence. The password prevents unauthorized changes.

Runtime Integrity Monitoring:

- Implementation: Deploy solutions to verify the integrity of critical files and processes after boot. - Use Case: A malware infection modifies kernel modules post-boot. Runtime integrity monitoring detects the modification and prevents the malicious module from loading.

Mitigation Enterprise

M1051: Update Software

Software updates ensure systems are protected against known vulnerabilities by applying patches and upgrades provided by vendors. Regular updates reduce the attack surface and prevent adversaries from exploiting known security gaps. This includes patching operating systems, applications, drivers, and firmware. This mitigation can be implemented through the following measures:

Regular Operating System Updates

- Implementation: Apply the latest Windows security updates monthly using WSUS (Windows Server Update Services) or a similar patch management solution. Configure systems to check for updates automatically and schedule reboots during maintenance windows. - Use Case: Prevents exploitation of OS vulnerabilities such as privilege escalation or remote code execution.

Application Patching

- Implementation: Monitor Apache's update release notes for security patches addressing vulnerabilities. Schedule updates for off-peak hours to avoid downtime while maintaining security compliance. - Use Case: Prevents exploitation of web application vulnerabilities, such as those leading to unauthorized access or data breaches.

Firmware Updates

- Implementation: Regularly check the vendor’s website for firmware updates addressing vulnerabilities. Plan for update deployment during scheduled maintenance to minimize business disruption. - Use Case: Protects against vulnerabilities that adversaries could exploit to gain access to network devices or inject malicious traffic.

Emergency Patch Deployment

- Implementation: Use the emergency patch deployment feature of the organization's patch management tool to apply updates to all affected Exchange servers within 24 hours. - Use Case: Reduces the risk of exploitation by rapidly addressing critical vulnerabilities.

Centralized Patch Management

- Implementation: Implement a centralized patch management system, such as SCCM or ManageEngine, to automate and track patch deployment across all environments. Generate regular compliance reports to ensure all systems are updated. - Use Case: Streamlines patching processes and ensures no critical systems are missed.

*Tools for Implementation*

Patch Management Tools:

- WSUS: Manage and deploy Microsoft updates across the organization. - ManageEngine Patch Manager Plus: Automate patch deployment for OS and third-party apps. - Ansible: Automate updates across multiple platforms, including Linux and Windows.

Vulnerability Scanning Tools:

- OpenVAS: Open-source vulnerability scanning to identify missing patches.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
aa7c53e0369e1822...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle aa7c53e0369e…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Wikipedia BIOS

    Wikipedia. (n.d.). BIOS. Retrieved January 5, 2016.

    Open source URL
  2. [2]
    Wikipedia UEFI

    Wikipedia. (2017, July 10). Unified Extensible Firmware Interface. Retrieved July 11, 2017.

    Open source URL
  3. [3]
    About UEFI

    UEFI Forum. (n.d.). About UEFI Forum. Retrieved January 5, 2016.

    Open source URL
  4. [4]
    mitre-attack T1542.001
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use