By NHI Mgmt Group Editorial TeamPublished 2025-06-25Domain: Breaches & IncidentsSource: Astrix Security

TL;DR: Astrix’s recognition in KuppingerCole’s CIEM Leadership Compass underscores a broader problem: traditional CIEM and IGA controls still leave service accounts, OAuth integrations, secrets, and other non-human identities only partially governed, especially across SaaS and cloud environments. That gap is now a core identity security issue, not a side case, according to KuppingerCole and Astrix Security.


At a glance

What this is: Astrix’s CIEM recognition highlights the gap between traditional identity governance and the realities of non-human identities across cloud and SaaS environments.

Why it matters: IAM teams have to govern service accounts, OAuth apps, and automation tokens as first-class identities because the blind spots they create can expand privilege, hide ownership, and weaken CIEM and IGA programmes.

By the numbers:

👉 Read Astrix Security's analysis of CIEM gaps in non-human identity governance


Context

Astrix’s CIEM recognition lands in a part of identity security that many programmes still under-model: non-human identities. These include service accounts, OAuth-connected apps, API tokens, automation secrets, and cloud entitlements that act without a human user at the keyboard. When these identities are outside clear ownership and policy scope, CIEM and IGA lose a large portion of the access graph they are supposed to govern.

That matters because NHI sprawl is not just a visibility problem. It is a governance problem that cuts across cloud, SaaS, and identity provider environments, where permissions can persist without meaningful review and third-party connections can outlive the business relationship that created them. The result is an access layer that traditional identity programmes often see only after it has already become operational risk.


Key questions

Q: What breaks when non-human identities are not included in CIEM scope?

A: CIEM becomes an incomplete visibility layer rather than a governance control. Service accounts, OAuth grants, and automation tokens can keep broad access outside the review model, which means excessive privilege, hidden ownership, and weak offboarding persist even when cloud entitlements look covered.

Q: Why do non-human identities complicate access governance more than human accounts?

A: They are often created for technical convenience, not reviewed as business identities, and left active long after the original use case changes. That makes ownership, recertification, and revocation harder, especially when third-party access and machine credentials are spread across multiple platforms.

Q: How do security teams know if NHI governance is actually working?

A: Look for whether every machine identity has a named owner, a documented purpose, a clear expiry or rotation rule, and evidence of removal when no longer needed. If those signals are missing, the programme may have discovery but not real control.

Q: Who should own governance for service accounts and OAuth integrations?

A: Ownership should sit with the business or platform team that depends on the access, with identity and security providing control requirements and review. If ownership is only technical, offboarding and privilege reduction usually fail because nobody is accountable for the access lifecycle.


Technical breakdown

Why CIEM often misses non-human identities

Cloud Infrastructure Entitlement Management is designed to map entitlements, reduce excessive access, and surface privilege across cloud resources. The gap appears when the actor is a non-human identity such as a service account, OAuth app, or automation token, because those identities often sit outside the ownership and lifecycle controls that CIEM tools assume exist. Discovery can show that access exists, but governance still breaks if the identity has no accountable owner, no offboarding path, and no policy boundary tied to its actual use. In practice, that means CIEM can improve visibility without fully closing the governance loop.

Practical implication: Map every machine-to-machine identity into the same entitlement inventory used for humans, then verify that each one has an owner, lifecycle, and revocation path.

OAuth third-party access as an identity perimeter

OAuth integrations are not just application connections. They are delegated identity relationships that can grant long-lived access to SaaS data and workflows without a password in the middle. That makes them a governance problem, not only an integration problem. If a third-party app keeps its grant after the business need has ended, the access path remains active even when nobody is watching it closely. The security issue is compounded when the grant is broad, hidden behind admin convenience, or never revisited during access reviews.

Practical implication: Treat OAuth grants as governed identities and include them in entitlement reviews, third-party risk checks, and offboarding processes.

Policy enforcement for secrets and automation tokens

Secrets, automation tokens, and service credentials often become the practical control plane for non-human work. If they are stored outside formal secrets management, over-scoped, or left valid longer than necessary, then policy enforcement becomes reactive instead of preventive. Real-time monitoring helps, but the deeper issue is that many identity programmes still model these credentials as technical artifacts rather than governed access. Once that distinction is lost, remediation happens after exposure rather than before misuse.

Practical implication: Bring secrets, tokens, and certificates under explicit policy, rotation, and expiry rules, and make their use observable in identity governance tooling.


Threat narrative

Attacker objective: The attacker aims to turn trusted machine-to-machine access into persistent operational reach across cloud and SaaS environments.

  1. Entry happens through a legitimate non-human identity such as a service account or OAuth integration that has been granted access for operational convenience.
  2. Credential access or abuse follows when that identity has excessive privilege, poor ownership, or no lifecycle offboarding, allowing access to persist beyond its business purpose.
  3. Impact emerges as cloud, SaaS, or identity-provider access is used to move through systems, extract data, or alter entitlements without strong identity governance controls.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

NHI governance blind spots are now CIEM blind spots. CIEM programs that focus only on cloud entitlements without modelling service accounts, OAuth grants, and automation secrets are working with an incomplete access graph. KuppingerCole’s recognition of Astrix reflects the market’s recognition that machine access must be treated as a governed identity class, not an edge case. Practitioners should read this as a signal that entitlement visibility without NHI lifecycle control is only partial governance.

Third-party access without lifecycle offboarding is the failure mode this category keeps exposing. OAuth-connected apps, vendor integrations, and service credentials often survive the business relationship that justified them. That is not a tooling gap alone, it is a governance assumption failure: access is assumed to be temporary when in practice it becomes standing. The implication is that identity governance must account for delegated access that persists beyond the human or contractual trigger that created it.

Non-human identity sprawl is a policy problem before it is a discovery problem. Discovery and monitoring matter, but the deeper issue is that many enterprises still do not assign explicit ownership, acceptable-use boundaries, or revocation workflows to machine identities. When those controls are absent, even strong visibility leaves a programme with alerts but no accountable action path. Practitioners should treat NHI governance as a control design issue, not a dashboard issue.

CIEM will keep expanding into broader identity governance because machine identities already sit in the control gap. The market is moving toward identity platforms that can reason across human, machine, and delegated access paths rather than treating them as separate administrative domains. That does not eliminate IGA or PAM, but it does force them to incorporate NHI discovery, policy enforcement, and cleanup into the same operational model. Practitioners should expect their identity stack to converge around lifecycle-aware entitlement governance.

Identity programmes that cannot see non-human access will keep underestimating blast radius. Service accounts and automation tokens frequently hold the kind of broad access that makes incidents harder to contain and reviews harder to trust. The practical conclusion is that enterprises need governance that follows the access path itself, not just the user behind it, because that is where modern privilege now accumulates.

From our research:

  • 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which explains why hidden machine access remains difficult to govern.
  • That visibility gap makes NHI Lifecycle Management Guide the right next step for teams trying to connect discovery to offboarding and rotation.

What this signals

NHI governance is converging with CIEM because access without lifecycle control is no longer defensible. The practical shift for enterprises is from inventorying entitlements to proving that every machine identity has ownership, scope, and removal logic. Where those controls are absent, cloud and SaaS permissions will continue to accumulate outside normal review cadences, even when the control stack looks mature.

Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. That mismatch is a warning sign for broader machine identity governance, because the same pattern appears when teams discover access first and formalise policy later. Practitioners should expect policy, lifecycle, and telemetry to converge into one operating model rather than separate workstreams.

Ephemeral credential trust debt: this is the growing burden created when organisations keep granting temporary machine access without a corresponding cleanup process. Once that debt accumulates, access reviews become a reporting exercise rather than a control, and the fastest path forward is to align entitlement governance with revocation and expiry discipline.


For practitioners

  • Inventory every non-human identity in the entitlement graph Pull service accounts, OAuth grants, API tokens, certificates, and automation secrets into the same inventory you use for human entitlements. Require each identity to have an owner, a business purpose, and a revocation path.
  • Add delegated SaaS access to access review scope Include third-party OAuth applications, connected apps, and admin-consented integrations in periodic entitlement reviews. Verify that access still matches the current business need and remove grants that have outlived the relationship.
  • Enforce lifecycle controls on machine credentials Apply rotation, expiry, and offboarding workflows to secrets and service accounts with the same discipline used for human access. Where the platform allows it, move from static credentials to short-lived credentials and monitor for unused grants.
  • Tie NHI policy exceptions to named risk owners Make exceptions visible in CIEM or IGA workflows and require a named approver to accept the risk. Exceptions should expire automatically so standing access does not become permanent by default.

Key takeaways

  • Traditional CIEM coverage is incomplete when service accounts, OAuth grants, and automation secrets sit outside lifecycle governance.
  • The scale problem is already visible: machine identities routinely carry excess privilege, and most organisations still lack full visibility into them.
  • Enterprises should bind discovery to ownership, offboarding, and rotation so non-human access can be governed as a first-class identity class.

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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Machine credentials need rotation and lifecycle control, which this article shows is often missing.
NIST CSF 2.0PR.AC-4Least privilege and access governance are central to CIEM coverage of machine identities.
NIST Zero Trust (SP 800-207)PR.AC-1Zero trust requires continuous verification for delegated and machine access paths.

Apply zero-trust principles to OAuth grants and service accounts so trust is explicit and continuously validated.


Key terms

  • Non-Human Identity: A non-human identity is any digital identity used by software, services, or automation rather than a person. It includes service accounts, API keys, OAuth grants, certificates, tokens, and workload identities, all of which can carry access that must be owned, reviewed, and revoked like human access.
  • Cloud Infrastructure Entitlement Management: Cloud Infrastructure Entitlement Management is the discipline of discovering, analysing, and reducing entitlements across cloud environments. In practice, it is only effective when it covers machine identities, delegated OAuth access, and service credentials, not just human users and obvious cloud roles.
  • OAuth Grant: An OAuth grant is delegated authorization that allows an application or integration to access a user or tenant's resources without sharing the primary password. For governance, it behaves like an identity relationship and must be reviewed, scoped, and removed when the business need ends.
  • Lifecycle Offboarding: Lifecycle offboarding is the process of removing access when an identity, integration, or business need ends. For non-human identities, that means revoking tokens, disabling service accounts, removing third-party app consent, and verifying that no shadow access remains in adjacent systems.

What's in the full analysis

Astrix Security's full report covers the operational detail this post intentionally leaves for the source:

  • Detailed capability mapping for discovering internal service accounts and external OAuth connections across SaaS and cloud
  • The platform-level visibility and remediation workflow details behind real-time monitoring of non-human identities
  • How the policy engine enforces least privilege and acceptable use rules for machine identities in day-to-day operations
  • Integration coverage across Microsoft Entra ID, Okta, Google Workspace, public cloud platforms, and SaaS apps

👉 Astrix Security's full report covers the NHI discovery, monitoring, and remediation detail behind the summary here.

Deepen your knowledge

NHI governance, lifecycle control, and access review design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is still closing the gap between CIEM visibility and machine identity control, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-06-25.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org