Why do traditional IGA projects become slow and expensive?

Why This Matters for Security Teams

Traditional identity governance and administration becomes slow and expensive when it is forced to treat every access path as a hand-built exception. That model works poorly for machines, service accounts, and agentic workloads because their access patterns are not stable enough for spreadsheet-style review cycles. The result is prolonged delivery, brittle integrations, and controls that lag the actual environment.

This matters because identity debt compounds quietly. A team can finish an IGA program and still have unmanaged secrets, stale entitlements, and orphaned service accounts that sit outside the governance workflow. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is why governance projects often chase completeness that the underlying architecture cannot support. Current guidance in the NIST Cybersecurity Framework 2.0 points toward continuous, outcome-based control rather than one-time identity cleanup.

In practice, many security teams encounter IGA failure only after audit findings, access sprawl, or a production outage has already exposed how much manual exception handling the platform requires.

How It Works in Practice

IGA projects become expensive when every identity type is forced through the same lifecycle model. Human joiner-mover-leaver workflows are predictable; non-human identities are not. Service accounts, API keys, automation bots, and agentic workloads often need short-lived access, rapid revocation, and context-sensitive approvals that do not map cleanly to traditional role catalogs.

Practitioners usually discover three cost drivers. First, connector work: each application, vault, directory, and ticketing system requires custom integration or brittle configuration. Second, exception handling: every business-specific edge case becomes a policy debate instead of a simple operational change. Third, certification overhead: reviewers are asked to validate entitlements they do not understand, which leads to slow recertification and low-quality approvals. The Ultimate Guide to NHIs is useful here because it frames visibility, rotation, and offboarding as core lifecycle controls rather than optional add-ons.

A more efficient model is to separate governance intent from enforcement mechanics:

• Use policy to define who or what may obtain access, for how long, and under what conditions.
• Use automated provisioning and deprovisioning for routine cases, not manual approvals.
• Use short-lived credentials and token exchange where possible to reduce standing access.
• Use discovery and telemetry to find identities that never entered the IGA system in the first place.

For control design, the question is increasingly how well the governance layer can adapt at runtime, not how many workflows it can route. That shift aligns with the zero trust direction in the NIST Cybersecurity Framework 2.0, where continuous verification matters more than periodic approval. These controls tend to break down in heavily customised legacy estates because the integration cost of each system outweighs the value of standardised orchestration.

Common Variations and Edge Cases

Tighter governance often increases operational overhead at first, so organisations have to balance stronger control against delivery speed and integration cost. That tradeoff is especially visible in mergers, regulated industries, and environments with many legacy applications that cannot support modern identity standards.

There is no universal standard for this yet, but current guidance suggests that IGA should not be the only control plane for machine identities. In some environments, the most expensive part is not provisioning itself but the policy review process around exceptions, especially when secrets are embedded in code, CI/CD pipelines, or unmanaged vaults. NHI Management Group’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is exactly the kind of sprawl that makes IGA programmes balloon in scope.

The practical response is usually selective governance: prioritise high-risk identities, automate the common paths, and accept that some legacy systems need compensating controls rather than full-feature parity. That approach reduces programme drag without pretending every system can be made uniform.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• When does secret exposure become a broader identity risk?
• When does NHI compliance become an operational security issue?
• When do service accounts become a higher risk than ordinary user accounts?