Notifications
Clear all
Topic starter
06/06/2026 2:00 am
TL;DR: Cloud exposure findings can be connected to the non-human identities behind access, so teams can prioritize by privilege, ownership, usage, and blast radius instead of treating remediation as a generic exposure queue, according to Oasis Security. That shifts identity governance from visibility alone to safe action on NHIs, service principals, workload identities, and the AI agents that depend on them.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams handle cloud findings tied to non-human identities?
A: Security teams should enrich each finding with identity ownership, current usage, and privilege scope before deciding whether to rotate, restrict, or retire access.
Q: Why do service accounts and workload identities make exposure management harder?
A: They make exposure management harder because the risk is not just the exposed asset, but the machine identity that can reach it.
Q: What breaks when teams can see exposure but not identity context?
A: When teams lack identity context, they cannot safely decide whether an exposed permission is live, obsolete, or tied to a critical service.
Practitioner guidance
- Correlate exposure findings to identity ownership Require every high-severity cloud exposure to resolve to a named non-human identity owner before remediation is approved.
- Block rotation workflows without usage evidence Do not rotate or right-size production credentials until teams can confirm whether the service principal or key is actively used, where it is used, and what runtime dependency would break if it changed.
- Prioritise by blast radius, not finding count Score remediation by the access path to sensitive data, the privilege level of the NHI, and the operational criticality of the workload.
What's in the full announcement
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- How the Wiz Issues and DSPM findings are ingested into the Oasis identity graph for remediation workflows.
- The identity context fields used to prioritise exposure by privilege, ownership, and usage.
- The practical workflow for safe key rotation and hygiene actions once exposure is tied to a specific NHI.
- The joint use cases for customers who want to connect cloud exposure signals to identity-governed response.
👉 Read Oasis Security's analysis of cloud exposure and identity-governed remediation →
Cloud exposure to identity-governed action: what changes for IAM teams?
Explore further
06/06/2026 3:25 am
Identity-governed remediation is becoming the real control plane for cloud exposure. Visibility alone does not change risk if teams cannot map findings to the non-human identity behind them, establish ownership, and safely modify access in production. The market is moving from finding exposures to proving which identity can be changed without breaking the service. Practitioners should treat context enrichment as a governance requirement, not a convenience.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should own remediation when an NHI finding affects production services?
A: Accountability should sit with the team that owns the workload or service, with identity governance enforcing the decision path. If no owner can be named, the credential should be treated as unmanaged and escalated before any change is attempted. Production remediation without clear ownership turns a security issue into an operational risk.
👉 Read our full editorial: Identity-governed action for cloud exposure needs NHI context
