What should organisations do when high-risk cloud permissions are needed for operations?

Why This Matters for Security Teams

High-risk cloud permissions are not a theoretical exception. They are the point where operational availability, change control, and identity governance collide. If a team leaves elevated access standing, it creates a permanent path for misuse, lateral movement, and accidental damage. That is especially dangerous for non-human identities, where access is often broader than a human operator would receive and harder to review consistently. Current guidance suggests treating these permissions as time-bound operational events, not as routine entitlements.

The practical issue is that cloud environments change quickly, but static IAM does not. When emergency access is always on, incident responders, platform engineers, and automation all inherit a larger attack surface than needed. NHI Management Group research on the 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than they would give a human doing the same job, which is a strong signal that privilege creep is already normalised. For security teams, the lesson is that breakglass must be governed as a controlled exception, not an informal workaround. In practice, many security teams encounter misuse only after an outage, escalation, or breach has already made the exception visible.

That is why NHI governance guidance from OWASP Non-Human Identity Top 10 and identity-oriented controls in NIST Cybersecurity Framework 2.0 both point toward least privilege, traceability, and fast revocation.

How It Works in Practice

The best operational pattern is a tightly scoped breakglass or just-in-time workflow tied to a specific change, incident, or maintenance window. Access is approved only for the named task, then issued with a short TTL, monitored during use, and revoked automatically when the task completes. For cloud operations, that usually means pairing approval logic with cloud-native policy controls, session recording, and an identity layer that can prove who or what is acting at request time.

Practitioners typically separate the control into four parts:

• Request: the operator or automation declares the exact change, target resource, and expiry window.
• Approval: a verified approver with authority over that system grants time-bound access.
• Execution: the session is authenticated with strong identity proof and continuously logged.
• Revocation: the credential, role, or session token is invalidated automatically after completion.

For non-human workflows, the identity primitive should be the workload, not a person. That is where workload identity standards such as SPIFFE become relevant, because they support short-lived cryptographic identity rather than long-lived shared secrets. In parallel, policy should be evaluated at request time, not only during provisioning. Tools and models such as policy-as-code, OPA, or Cedar are useful here because they can consider the current context, the requested action, and the time window before authorising access.

NHIMG guidance on Ultimate Guide to NHIs — Key Challenges and Risks and the OWASP NHI Top 10 both reinforce the same operational pattern: keep elevated access ephemeral, auditable, and task-specific. These controls tend to break down when emergency access is granted through manual console steps because the approval chain, session duration, and revocation point become hard to enforce consistently.

Common Variations and Edge Cases

Tighter breakglass control often increases response overhead, so organisations must balance speed against exposure. That tradeoff becomes sharper in 24/7 operations, regulated environments, or teams that support both humans and automation.

There is no universal standard for this yet, but current guidance suggests a few common variations. Some organisations use two-person approval only for production-impacting changes, while others require pre-approved escalation paths for defined incident classes. Some issue temporary cloud roles, while others issue short-lived tokens that call down to a privileged automation service. For high-risk NHI usage, the important point is not the mechanism itself but the combination of scope, expiry, and auditability.

Edge cases usually appear when identity boundaries are unclear. Shared admin accounts, long-lived API keys, and automation that can self-escalate all weaken the breakglass model. In those environments, a time-limited role is still better than standing privilege, but it should be paired with secret rotation, approval logging, and a review process that confirms who actually used the access. The 2024 ESG Report: Managing Non-Human Identities is a useful reminder that compromised NHIs often recur, which makes revocation discipline more important than convenience. Best practice is evolving, but the operational rule remains simple: high-risk access should exist only long enough to complete the approved task.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• Why do service-level permissions increase cloud risk?
• What breaks when organisations JIT users instead of permissions?
• Why do strong IAM controls still leave organisations exposed to audit and fraud risk?