Astrix and CIEM expose the NHI governance gap in cloud identity

At a glance

What this is: This article says CIEM and IGA still miss important non-human identity pathways, especially in cloud and SaaS environments where service accounts, OAuth integrations, and secrets operate with weak governance.

Why it matters: IAM, IGA, PAM, and cloud security teams need to treat NHI discovery and lifecycle control as part of core identity governance, not as an adjacent monitoring problem.

Context

Cloud identity governance breaks down when service accounts, OAuth grants, automation tokens, and secrets are treated as secondary to human users. In practice, CIEM and IGA often model entitlements well enough for people, but not well enough for machine-to-machine access that behaves differently, moves faster, and is harder to own.

This article frames non-human identity governance as the missing layer in cloud identity programmes. The point is not that CIEM is obsolete, but that entitlement visibility alone does not create lifecycle control, policy enforcement, or accountability for identities acting on behalf of applications and services.

As SaaS and public cloud estates grow, the governance gap becomes more visible because the blast radius of an unmanaged NHI is not limited to one application. It can span integrations, workloads, and connected services without a clear human owner to certify or revoke it.

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: 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.

Q: How can organisations tell whether NHI governance is actually working?

A: NHI governance is working when every machine identity has an owner, a purpose, a minimum-necessary entitlement, and evidence of rotation and review. If teams can produce that chain without manual reconstruction, the programme is mature enough to withstand audit pressure. If they cannot, the governance model is still fragmented.

Q: What should IAM teams prioritise after discovering unmanaged NHI access?

A: Prioritise integrations and service identities with the widest blast radius first, especially OAuth connections and cloud service accounts that can reach multiple systems. Those are the identities most likely to turn visibility gaps into active exposure.

Technical breakdown

Why CIEM visibility stops short of NHI governance

Cloud Infrastructure Entitlement Management is designed to discover and analyse entitlements across cloud environments, but discovery is not the same as governance. Non-human identities include service accounts, OAuth app connections, automation tokens, and secrets that can be valid, active, and dangerous even when they are visible. The hard part is not only finding them. It is maintaining ownership, intended use, policy boundaries, and revocation paths across SaaS and cloud systems that do not share a single lifecycle model.

Practical implication: treat NHI discovery as the start of governance work, not the end of it.

Why OAuth integrations create a different entitlement problem

OAuth-connected third-party apps behave differently from standard user entitlements because the access is delegated, persistent, and often granted once but exercised repeatedly. That means the control problem is not only who approved the connection, but whether the connected application still has the right scope, whether it is still needed, and whether its privilege matches current business use. CIEM can enumerate access, but NHI governance has to evaluate whether delegated access is still appropriate and whether the integration is operating inside its intended boundary.

Practical implication: review OAuth grants as standing machine access, not as a one-time onboarding event.

How policy enforcement changes when the identity is non-human

Policy engines for NHIs need to focus on behaviour, ownership, and lifecycle status rather than just interactive authentication. A service account with a valid secret may never log in like a user, yet it can still move data, call APIs, and trigger downstream workflows. That makes least privilege necessary but insufficient unless the organisation can also detect overuse, link the identity to an accountable owner, and remove access when the workload or vendor relationship changes.

Practical implication: combine least privilege with ownership and offboarding controls for every non-human identity.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

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

NHI Mgmt Group analysis

CIEM exposes entitlement, but NHI governance decides whether that entitlement should still exist. KuppingerCole’s recognition of Astrix points to a structural limit in current identity programmes: visibility does not equal lifecycle control. Service accounts, OAuth integrations, and automation tokens can remain active long after the original business use has changed, and that leaves cloud identity governance with a blind spot that is operational, not theoretical. Practitioners should treat NHI governance as a separate control layer, not a feature of CIEM.

Non-human identity ownership is the missing governance primitive. Traditional IGA workflows assume a certifiable human owner, but many NHIs are created by teams, vendors, or pipelines without durable accountability. When ownership is unclear, recertification becomes performative and revocation becomes slow or inconsistent. The implication is that identity programmes need an explicit ownership model for NHIs before they can claim governance maturity.

OAuth delegation is a standing access problem, not an app-integration convenience. Delegated access to third-party applications often survives beyond the original intent and can operate across SaaS data, cloud actions, and downstream APIs. That pattern belongs in the same governance conversation as privileged access because it can widen blast radius without a corresponding review cycle. Practitioners should assume delegated access has a lifecycle and govern it like one.

NHI blast radius is now a cloud identity metric that matters on its own. The practical risk is not just the number of identities, but how many cloud and SaaS pathways a single non-human identity can reach. That makes discovery, remediation, and policy enforcement part of one control loop. Organisations that still model NHIs as edge cases will continue to undercount privilege exposure in CIEM and IGA programmes.

Identity programmes need a distinct control model for machine-to-machine access. Machine identities do not follow the same behaviour patterns as humans, so a human-centric governance process will miss key failure modes. The useful shift is to manage non-human access as a first-class identity population with its own discovery, ownership, policy, and offboarding requirements. That is where cloud identity governance becomes credible.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Non-human identity governance has become a programme design issue, not an inventory exercise. CIEM can surface access, but it does not by itself establish who owns a service account, whether an OAuth grant is still justified, or when a secret should be retired. Security teams that keep NHI governance inside a generic entitlement review process will continue to miss the identities most likely to outlive their purpose.

Cloud identity programmes now need a separate control path for delegated and machine access. The practical test is whether your process can distinguish a user entitlement from a workload identity, a third-party app grant, or an automation token. If it cannot, then the programme is still modelling identity around people and treating everything else as an exception.

For practitioners

• Define an NHI ownership model Assign a durable owner for every service account, OAuth grant, automation token, and secret so recertification and revocation have a clear accountability path.
• Inventory delegated third-party access Map all OAuth-connected applications and classify which ones have standing access to SaaS data, cloud APIs, or administrative actions.
• Separate NHI policy from human IGA Create governance rules for machine-to-machine access that cover discovery, intended use, monitoring, and offboarding instead of reusing human access review workflows.
• Tighten lifecycle offboarding for dormant NHIs Revoke access for integrations and service identities that no longer have an active business purpose, especially where ownership cannot be evidenced.
• Monitor for excessive NHI reach Track which NHIs can reach multiple cloud and SaaS systems and prioritise those with broad or cross-environment access for remediation.

Key takeaways

• Traditional CIEM still leaves important non-human identity paths under-governed, especially where cloud and SaaS access is delegated through service accounts and OAuth.
• The governance gap is not only about visibility, but about ownership, lifecycle control, and revocation for identities that do not behave like users.
• Practitioners should build explicit NHI ownership and offboarding controls into identity governance instead of relying on human-centric review workflows.

Key terms

• Non-Human Identity Governance: Non-human identity governance is the practice of managing, controlling, and auditing every machine identity across its full lifecycle. It covers service accounts, API keys, tokens, certificates, and AI agent credentials, ensuring each has a defined owner, scoped privilege, rotation schedule, and revocation path. Without governance, NHIs accumulate silently and become the primary attack surface in cloud and automated environments.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Standing machine access: Non-human or automated access that remains valid beyond the immediate task or session. This creates persistent reach across SaaS systems unless the organisation actively scopes, rotates, and removes it on a lifecycle basis.
• NHI Ownership Transfer: NHI ownership transfer is the reassignment of a non-human identity from one employee to another during a change event such as offboarding. It is used when the credential still supports a live business process and cannot simply be revoked. Effective transfer requires context, dependency mapping, and governance approval.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.