The controlled startup, shutdown, and operational state of virtual machines or desktops. It is not just an operations function, because whoever can change power state can indirectly influence availability, cost, and exposure of the underlying workload.
Expanded Definition
Power-state management refers to the controlled startup, shutdown, suspension, and restart of virtual machines, desktops, and related compute instances. In security and identity operations, it matters because power control can change workload exposure, session persistence, and the cost profile of infrastructure that may host sensitive data or privileged tooling.
Definitions vary across vendors when the term is used in cloud, virtual desktop, and endpoint management contexts, so it is best understood as an administrative control over runtime availability rather than a simple uptime toggle. In practice, it often intersects with access governance, because the ability to power on a system can become a de facto privilege if it enables execution, data access, or recovery of dormant assets. That makes it adjacent to the concerns covered in the NIST Cybersecurity Framework 2.0 and the lifecycle focus described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. The most common misapplication is treating power-state changes as routine operations, which occurs when teams grant broad console access without considering that start and stop rights can expose workloads to misuse.
Examples and Use Cases
Implementing power-state management rigorously often introduces operational friction, requiring organisations to balance fast recovery and cost control against tighter approval and audit requirements.
- Shutting down non-production virtual machines outside business hours to reduce exposure, while ensuring only authorised operators can restart them.
- Using scheduled desktop power policies for remote workers so dormant environments are unavailable unless a legitimate session request is approved.
- Allowing incident responders to power on isolated forensic systems without granting broader administrative access to the entire cluster.
- Coordinating power-state changes with lifecycle processes so retired workloads are not reactivated after offboarding, as discussed in the NHI Lifecycle Management Guide.
- Reviewing console permissions and start-stop privileges in line with NIST Cybersecurity Framework 2.0 to confirm that operational control matches business need.
In real environments, power-state controls often become visible only after a dormant machine is restarted for maintenance, revealing stale credentials, unpatched software, or hidden service accounts. NHIMG’s Top 10 NHI Issues highlights that 97% of NHIs carry excessive privileges, a pattern that can also extend to the control planes used to manage workload state.
Why It Matters for Security Teams
For security teams, power-state management is a governance issue because control over availability can become control over access. A virtual machine that is powered off may appear harmless, yet it can still contain secrets, persistent tokens, cached sessions, or tools that re-enter the environment when restarted. That makes the privilege to change state relevant to NHI governance, privileged access review, and operational resilience.
NHIMG research shows that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is directly relevant when power actions are exposed through scripts, automation accounts, or cloud consoles. The same applies when recovery workflows are automated through service accounts that can start, stop, or rebuild systems. Security teams should also consider auditability, because a power transition can change who can access data, when evidence is preserved, and whether an asset is still within policy. The security consequence is often missed until a disabled system is reactivated during an incident, at which point access paths, credentials, and ownership all need immediate verification. Organisations typically encounter that problem only after a dormant workload is brought back online, at which point power-state management becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions and privileged operations govern who can change system state. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Privilege over automation and runtime controls can expand NHI attack surface and misuse risk. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege applies to console and automation rights that can alter workload availability. |
| NIST Zero Trust (SP 800-207) | Zero trust assumes state-changing actions need continuous verification, not trust by location. | |
| NIST SP 800-63 | AAL2 | Sensitive administrative actions that change workload state should use strong authenticator assurance. |
Treat power-control automation as an NHI-adjacent privilege and audit its credentials, scope, and logging.
