Why do IGA programmes fail when organisations underestimate shadow IT and non-human identities?

Why This Matters for Security Teams

IGA fails fastest when it is scoped to humans and a polished application inventory, because the real identity surface includes shadow IT, service accounts, API keys, machine tokens, and autonomous agents. NIST Cybersecurity Framework 2.0 treats identity as part of governance and access control, but many organisations still discover that their entitlement model does not match how work actually gets done. That gap is exactly where orphaned access, unreviewed privileges, and audit surprises begin.

Shadow IT expands the number of systems that never enter the joiner-mover-leaver process, while non-human identities operate outside the assumptions behind periodic access reviews. A service account can outlive the team that created it. An API key can be copied into multiple environments. An AI agent can chain tools faster than any manual reviewer can follow. NHIMG research on The State of Secrets in AppSec shows how fragmented secrets management and delayed remediation can persist even in mature programmes, which is a strong signal that identity governance cannot rely on registry completeness alone.

In practice, many security teams encounter the coverage gap only after a leaked secret, an unexpected permission path, or a failed audit reveals that the “known” identity estate was never the whole estate.

How It Works in Practice

Effective IGA for shadow IT and non-human identities starts by expanding discovery beyond the IdP. That means ingesting cloud inventories, CI/CD systems, secrets stores, SaaS admin logs, container platforms, and machine identity telemetry. The goal is to build an identity graph that includes people, apps, workloads, and agents rather than forcing every actor into a human-centric workflow. Where possible, use workload identity primitives such as OIDC-backed federation or SPIFFE-style cryptographic identity so that systems can prove what they are, not just present a long-lived credential.

For non-human identities, the control model should shift from static entitlement assignment to runtime governance. That usually means just-in-time issuance, short TTLs, scoped secrets, and automatic revocation when a task completes. Current guidance suggests pairing this with policy-as-code so that access is evaluated at the moment of use, not only during quarterly certification. This is especially important for agentic systems, where behaviour is dynamic and tool use can change from one request to the next. The NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework both reinforce the need for continuous control assurance, while LLMjacking: How Attackers Hijack AI Using Compromised NHIs shows how quickly exposed credentials can be abused once they leave governance.

• Discover identities from logs, code, cloud, and secrets inventories, not just the IdP.
• Classify each non-human identity by owner, purpose, environment, and expiry.
• Replace standing secrets with short-lived tokens wherever the platform supports it.
• Automate recertification for machine identities based on use, not calendar dates alone.
• Revoke abandoned keys and accounts when the owning workload, pipeline, or vendor changes.

These controls tend to break down in legacy environments where shared service accounts, hard-coded credentials, and manual exception handling are still embedded in production release processes.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance fast delivery against stronger discovery, classification, and lifecycle control. That tradeoff is especially visible in environments with many ephemeral workloads, third-party integrations, or business-managed SaaS tools that bypass central IT. Best practice is evolving, and there is no universal standard for how every shadow system should be governed, but the direction is clear: if an identity can act, it needs ownership and lifecycle controls.

One common edge case is the “legitimate exception” that becomes permanent. A test token kept for convenience, a vendor account with broad access, or an AI agent granted broad tool permissions for a pilot can quietly become production dependency. Another is shared infrastructure identity, where multiple services reuse the same credential and make access reviews nearly meaningless. NHIMG’s DeepSeek breach coverage and Code Formatting Tools Credential Leaks both underline a practical point: the identity boundary often fails at the places teams treat as “temporary” or “non-production.”

For IGA programmes, the safest assumption is that any unregistered system, secret, or agent already has access somewhere. The programme must therefore govern discovery as aggressively as it governs approvals.

Related resources from NHI Mgmt Group

• How should organisations govern non-human identities inside IGA programmes?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?