Advanced Configuration and Power Interface is the firmware and operating-system interface for power management and hardware control. Security teams must account for attack surface in firmware, boot behaviour, sleep states, and device control paths. Check for firmware updates, unauthorised hardware changes, and settings that affect secure boot, measured boot, or platform integrity.
What ACPI changes in the security model
ACPI matters because it sits below normal application security and gives the operating system structured control over firmware-backed functions that affect how the platform starts, sleeps, wakes, cools, throttles, and exposes devices. That makes it part of the trust boundary, not just a hardware convenience layer. Security teams need to treat ACPI behavior as something that can change platform integrity, not merely performance.
When ACPI tables, firmware objects, or device methods are altered or implemented badly, the result can be unexpected privilege paths, unstable boot behaviour, or controls that behave differently after resume from sleep. The practical issue is that these failures often look like “device weirdness” before they look like a security problem, which delays investigation.
For firmware and boot integrity context, see Firmware and Boot Security Guide, which covers secure boot, measured boot, TPM attestation, bootkits and firmware updates.
Why security teams care about attack surface and integrity
ACPI expands the attack surface because it bridges firmware, OS kernel behavior, and device control. A weakness here can undermine the assumptions that secure boot, measured boot, and platform trust rely on, especially when the platform resumes from sleep or hands control to peripheral management paths. The security significance is that control is shared across layers, so a flaw at one layer can change the behaviour of the others.
Security teams should care most when ACPI-related changes affect boot chain trust, device initialization, power transitions, or hardware configuration visibility. Those are the moments when a platform can be most vulnerable to firmware-level tampering, persistence, or bypass of normal OS enforcement.
Harden the endpoint baseline around firmware, patching, local admin and verification by following the Endpoint Hardening Checklist so ACPI-related issues are handled as part of device integrity, not as isolated troubleshooting.
Review NIST SP 800-53 Rev 5 Security and Privacy Controls for the configuration management, integrity and access-control controls that map to platform firmware and hardware settings.
What to check when ACPI is part of your environment
The most useful checks are the ones that confirm the platform is still in the state you expect. Verify firmware revision and update status, compare hardware inventory against approved builds, and watch for BIOS, UEFI, sleep-state or device-control settings that drift away from the secure baseline. If secure boot or measured boot is part of your trust model, those settings need to be verified after updates, repairs, docking changes, or sleep-related instability.
It is also worth checking whether unexpected power-state transitions, resume failures, or device anomalies coincide with firmware updates or newly attached hardware. In practice, those are often the first visible signs that a control path has changed. The best investigations correlate firmware state, OS logs, and physical-change history rather than treating the issue as a single-layer defect.
Use CISA Secure by Design as a reference point for expecting default-secure configuration and resilient platform behaviour from the products you deploy.
Risk and Threat Considerations
ACPI-related weaknesses can create a quiet but meaningful security gap because they sit in firmware-adjacent control paths that are hard to observe from standard endpoint tools. If attackers or unauthorized changes can influence those paths, they may gain persistence, affect boot integrity, or weaken the reliability of security controls that depend on a clean hardware state.
Failure mechanism: A compromised or misconfigured firmware control path can change power-state behavior, hardware initialization, or boot-time trust decisions in ways the OS cannot fully validate.
Impact: The result can be hidden persistence, degraded platform integrity, unreliable secure boot assumptions, and investigation blind spots after a suspected compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | ACPI changes are configuration state that should be approved and tracked. |
| SI-7 — Software, Firmware, and Information Integrity | ACPI affects firmware-backed integrity and boot trust paths. | |
| CM-6 — Configuration Settings | Secure boot, sleep-state and device-control settings are security-relevant platform settings. | |
| Recommendation — Baseline and track firmware-related settings as controlled configuration items. Verify firmware integrity and investigate unauthorized platform changes. Define and enforce secure firmware and hardware configuration settings. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | ACPI risks are reduced by hardened firmware and device configuration baselines. |
| Recommendation — Harden firmware and hardware settings with approved secure baselines. | ||
Practitioner Guidance
What to verify: Confirm that firmware updates are tracked, approved and rolled out in the same discipline as OS patching, because ACPI risks often appear only after sleep, wake or hardware-change events. If a device has unexplained stability or trust issues, treat firmware and hardware state as part of the evidence set, not as background noise.
Common mistake: Teams often focus on the OS symptom and ignore the platform control plane underneath it. That misses cases where the setting, table, or firmware behavior is the real source of exposure.
Practitioner takeaway: ACPI is not just a power-management detail, it is part of the trust fabric that determines whether the platform boots, resumes and exposes hardware in a way security controls can rely on.
Related resources from NHI Mgmt Group
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 October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org