Custom IGA breaks down because every new application, entitlement pattern, and identity type adds more schema, policy, and integration work. As the environment expands, review cycles slow down and exceptions multiply. The result is a control plane that becomes harder to maintain than the risk it is meant to reduce.
Why This Matters for Security Teams
Custom identity governance often starts as a practical workaround, but it becomes fragile when every application, cloud service, service account, and AI workflow needs a unique policy path. The problem is not just scale. It is schema drift, brittle integrations, and review logic that no longer matches how identities are actually used. NHI Management Group’s The NHI and Secrets Risk Report shows that NHIs now outnumber human identities by 144:1 in enterprise environments, which is why ad hoc governance patterns collapse so quickly.
As identity sprawl grows, security teams usually inherit a control plane that was designed for a handful of app teams and later stretched across cloud, DevOps, third-party automation, and agentic AI. That is where review queues slow down, exceptions pile up, and owners stop trusting the system. The operational issue is not only whether access is granted, but whether anyone can still explain why it was granted. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity as an ongoing governance capability, not a one-time onboarding task. In practice, many security teams encounter governance failure only after access reviews turn into exception management rather than through intentional design.
How It Works in Practice
Custom IGA breaks down because it usually depends on hand-built mappings between identity type, entitlement model, approval workflow, and evidence collection. That works until a new class of identity appears, such as a workload, bot, API key, or AI agent, and the existing model cannot express the right controls without another exception path. At that point, governance becomes a translation layer between inconsistent systems instead of a reliable policy engine.
The practical response is to simplify the governance model around identity primitives that scale: human, workload, service, and agent. For NHIs, this means prioritising lifecycle discipline, ownership, and secret hygiene, as outlined in Ultimate Guide to NHIs and reinforced by the failure patterns in 52 NHI Breaches Analysis. For agentic systems, static role models are a poor fit because agents act dynamically and may chain tools in ways that are impossible to enumerate up front. Current guidance suggests moving toward runtime authorisation, short-lived credentials, and workload identity so the system can decide based on context rather than fixed assumptions.
- Use policy as code to centralise decisions instead of copying rules into every application.
- Bind access to workload identity where possible, not to long-lived shared secrets.
- Issue JIT credentials for specific tasks, then revoke them automatically.
- Require ownership and expiration for every privileged NHI, service token, and agent grant.
- Continuously reconcile discovered identities against the governance inventory.
These controls tend to break down when organisations keep adding exceptions faster than they retire legacy integrations, because the review logic no longer reflects the actual access graph.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance control fidelity against delivery speed and support burden. That tradeoff is real, especially in environments with lots of inherited applications, mergers, vendor access, or legacy automation that cannot easily be redesigned. Best practice is evolving, but there is no universal standard for how many custom workflows an identity programme can sustain before it becomes unmanageable.
One common edge case is the attempt to govern every identity type with the same approval workflow. That usually fails because a human user, a CI/CD runner, and an AI agent do not present the same risk or lifecycle. Another is over-relying on periodic reviews when the underlying population changes continuously. Security teams should treat review as validation, not as the main control. The lifecycle guidance for managing NHIs is especially relevant when automation and secrets rotation are frequent, while the Top 10 NHI Issues helps identify where sprawl typically becomes control failure. Organisations that do not standardise early usually discover the weakest point when access recertification, incident response, and compliance evidence all depend on the same overworked custom workflow.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Custom governance fails when NHI lifecycle and rotation are not standardized. |
| NIST CSF 2.0 | PR.AC-4 | Identity sprawl weakens least-privilege enforcement and access review discipline. |
| NIST AI RMF | Autonomous AI and dynamic workloads need risk-based governance beyond static roles. |
Standardise NHI lifecycle controls and automate rotation so custom workflows do not accumulate stale access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
