They become expensive when most of the work is custom integration, exception handling, and connector maintenance rather than durable governance architecture. If the application estate is fragmented and standards like SCIM are rare, teams keep paying for the same operational problem in every renewal cycle. Cost rises because work is repeated, not because the licence alone is large.
Why IGA Costs Keep Rising After the Initial Rollout
The expensive part of IGA is rarely the first deployment. Ongoing cost usually comes from manual exceptions, fragile connectors, and repeated custom work for each application, so the programme behaves more like a recurring integration service than a governed capability. When standards such as SCIM are unevenly adopted, every new system adds another maintenance burden instead of reducing operating effort.
That is why many IGA programmes look efficient in year one and expensive by year three: the platform licence stays visible, but the hidden effort in remediation, onboarding, offboarding, certification support, and connector repair keeps accumulating.
What Actually Drives the Operating Model Cost
The main cost driver is fragmentation. If applications expose inconsistent identity data, role logic, and approval workflows, the IGA team must translate each system into a local integration pattern. That creates permanent labour demand for mapping, testing, rework, and production support. A durable programme reduces this by standardising how identities, entitlements, and lifecycle events are represented across the estate.
Custom integrations are expensive because they are brittle. Each one must be maintained through application upgrades, vendor changes, schema drift, and audit requests. Connector sprawl also pushes teams into one-off scripts and ticket-driven workflows, which increases dependency on a few engineers who understand the exceptions rather than the process.
Manual exception handling adds another layer of cost. Every exception may be defensible in isolation, but a high volume of temporary approvals, special cases, and compensating controls turns governance into a queue of operational work. In practice, the programme becomes harder to automate because the exception path is treated as the normal path.
Why Fragmented Application Estates Make IGA Hard to Scale
Fragmented estates create repeated onboarding effort. Different applications support different identity formats, different entitlement models, and different evidence requirements, so the same governance activity has to be re-engineered repeatedly. That is why the cost curve rises with each new application family unless architecture standards and joiner-mover-leaver patterns are enforced centrally.
Lifecycle controls are especially important here. When provisioning, deprovisioning, and recertification are not driven by a shared identity model, teams spend more time reconciling data than governing access. The result is a programme that is busy but not necessarily effective, because it is constantly compensating for missing upstream standardisation.
Standards adoption changes the economics. Where systems can consume common identity attributes and event flows, the marginal cost of another application falls. Where they cannot, each onboarding project becomes a bespoke integration and the operating model never matures beyond project-by-project support.
Risk and Threat Considerations
Cost pressure is not the only issue. As operating complexity grows, organisations usually accumulate more standing access, slower remediation, and weaker visibility into who still has access to what. That increases both audit exposure and the blast radius of missed deprovisioning, especially when exceptions and manual fixes are the only way the programme can keep moving.
Failure mechanism: Repeated custom integrations, exception approvals, and connector maintenance create brittle control points that are difficult to test, hard to retire, and easy to bypass when teams need speed.
Impact: The programme absorbs more labour over time, governance quality becomes uneven across applications, and access errors or stale entitlements persist longer because the control model is too operationally heavy to run consistently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | IGA cost growth is driven by lifecycle and access administration overhead. |
| Recommendation — Automate account and entitlement workflows to reduce recurring manual governance effort. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control design and consistency directly affect IGA operating burden and exceptions. |
| A.8.2 — Privileged access rights | Privileged access reviews and exceptions often create disproportionate IGA effort. | |
| Recommendation — Standardise access control rules to reduce bespoke governance handling. Tighten privileged access handling to cut recurring review and exception costs. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud identity governance cost rises when app and identity integrations are fragmented. |
| Recommendation — Use IAM controls to centralise lifecycle and entitlement governance across applications. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential and authenticator lifecycle work contributes to ongoing governance overhead. |
| Recommendation — Manage credential lifecycle centrally to reduce repetitive operational effort. | ||
Practitioner Guidance
What to prioritise: Focus first on the applications and workflows that generate the most recurring manual effort, not the loudest audit findings. The quickest cost reduction usually comes from removing repeat exceptions, standardising lifecycle events, and retiring brittle point integrations.
What to verify: Measure how much of the programme’s monthly effort is spent on connector repair, ticket handling, and entitlement reconciliation. If the same class of issue appears every quarter, the problem is architectural, not operational.
What good looks like: New applications should join the governance model with minimal custom code, and the number of special-case approvals should shrink as standards coverage improves. A healthy programme is one where operating effort declines as the estate grows, rather than rising in lockstep with it.
Practitioner takeaway: IGA becomes expensive when it is treated as a perpetual integration workaround; the durable fix is to reduce exception volume and standardise the identity model so governance scales with the estate instead of being rebuilt for each application.