Why do IGA programmes often break when access workflows are automated?

Why This Matters for Security Teams

IGA automation is supposed to reduce friction, but it often exposes the fact that the underlying access model was never stable enough to automate. When approvals are inconsistent, role definitions are overloaded, and exceptions are handled informally, the workflow engine simply turns ambiguity into scale. That is why identity governance can appear to “fail” the moment tickets, certifications, and provisioning steps are automated.

This problem is especially visible for non-human identities, where access is not driven by a fixed job function and where secrets, tokens, and service accounts can outlive the business context that created them. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which shows how quickly automation can preserve bad defaults instead of correcting them. In practice, many security teams encounter access sprawl only after the first automated recertification cycle has already approved it again.

How It Works in Practice

Automation works best when the access decision is deterministic: the same input should reliably produce the same outcome. IGA programmes break when the model depends on human interpretation, undocumented exceptions, or role mining that groups too many accounts into broad entitlements. For NHIs, this becomes even more fragile because the right decision is often context-dependent. An agent, pipeline, or service may need access for one task, one environment, or one short-lived session, not a standing entitlement.

That is why current guidance increasingly aligns with zero trust and workload identity rather than static approval chains. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls emphasises access control, accountability, and continuous enforcement, while the OWASP Non-Human Identity Top 10 highlights the operational risks created when machine identities are overprivileged or poorly governed. In practice, IGA workflows should be simplified before automation, then mapped to clear rules such as:

• Define one owner and one approval path per access type.
• Separate human joiner-mover-leaver logic from service account and API key governance.
• Use explicit entitlement criteria instead of broad role buckets where possible.
• Automate only repeatable steps, such as provisioning standard access or triggering revocation on termination.
• Route exceptions into a controlled review path with expiry dates and documented rationale.

The operational goal is not “more automation” but less ambiguity. NHIMG’s Ultimate Guide to NHIs - Key Challenges and Risks reinforces that long-lived credentials and weak lifecycle control are common failure points, which means automated workflows must be built around lifecycle state, not just approval status. These controls tend to break down when legacy applications cannot express entitlement granularity because the workflow has no reliable policy signal to act on.

Common Variations and Edge Cases

Tighter workflow automation often increases operational overhead at the start, requiring organisations to balance speed against governance quality. That tradeoff is real in environments with shared accounts, inherited entitlements, or application owners who cannot clearly name the business purpose behind an access request.

Best practice is evolving for agentic and machine-driven access. There is no universal standard for when an NHI should receive just-in-time access versus a standing service account, but current guidance suggests favouring short-lived access where the task is bounded and revocation can be automated. The main exception is infrastructure that cannot support ephemeral credentials, where teams may need compensating controls such as tighter secrets rotation, stronger monitoring, and periodic recertification.

NHIMG’s research also shows why this matters at scale: only 20% of organisations have formal processes for offboarding and revoking API keys, and 71% of NHIs are not rotated within recommended time frames. Those patterns make automated IGA fragile unless the lifecycle rules are cleaned up first. For teams modernising governance, the practical sequence is: standardise, classify, then automate. Trying to automate first usually just freezes bad access decisions into a faster process.

Related resources from NHI Mgmt Group

• Why do access reviews fail so often in traditional IGA programmes?
• How should healthcare teams implement MFA for ePHI access without breaking clinical workflows?
• Why do manual privacy workflows become a governance risk as programmes scale?
• Why do risk appetite statements often fail in security programmes?