Why does in-house IGA become more expensive over time?

Why the Cost Curve Keeps Rising After the First Build

In-house IGA is not a one-time software project, it behaves like a living control plane. As soon as the first applications are integrated, the team inherits a backlog of connector upkeep, policy tuning, exception handling, and release coordination. The core cost driver is ongoing change: business systems, roles, entitlements, and approval paths keep moving, so the internal platform must keep pace.

That change burden compounds because the organisation owns both the technology and the operating model. Every new source system, every merger, every role redesign, and every access review rule creates additional engineering and governance work. The result is that the internal team must fund not only the platform, but also the people and process needed to keep it trustworthy.

Over time, the marginal cost of each new integration or policy adjustment often rises rather than falls. Early implementations usually cover a few high-value systems, but later coverage tends to include older applications, edge-case workflows, and brittle exceptions that are harder to automate. Those long-tail cases consume more specialist time per unit of business value than the original rollout.

Where the Recurring Spend Comes From

The visible expense is hosting, testing, and upgrades, but the hidden expense is maintenance of identity logic. IGA systems must continually reconcile changing account states, entitlement structures, role models, and approval chains. When the environment shifts, the team has to retest whether automation still reflects reality, and that validation is what turns a “done” project into a recurring program.

Another cost source is exception management. Real organisations accumulate one-off approvals, temporary access, compensating controls, and application-specific workarounds. Each exception weakens standardisation and creates future work when the business asks for renewal, audit evidence, or cleanup. That is why IAM and IGA Basics matter: the more the access model drifts from clear rules, the more human intervention the platform needs to stay accurate.

Lifecycle work also drives expense upward. Joiner-mover-leaver flows, access reviews, role maintenance, and deprovisioning all require coordination across HR, application owners, security, and engineering. Joiner-Mover-Leaver (JML) Guide shows why offboarding and role changes are not administrative afterthoughts, they are recurring control activities that must be updated whenever the organisation or its applications change.

Why “Cheaper Than Headcount” Can Still Become Expensive

In-house IGA often starts as a cost-avoidance decision, but the economics shift once the organisation owns long-term change management. A vendor may spread product engineering, connector development, and release management across many customers; an internal team bears those costs alone. That means platform ownership, security testing, connector repair, and workflow redesign stay on the company’s books even when business demand is stable.

Cost also rises when the identity model becomes more complex than the original design. Role explosion, entitlement sprawl, and inconsistent application owners all increase the amount of manual triage required to keep certifications and approvals usable. Role Mining and Role Design Guide is a useful reminder that role design is not a one-off exercise, because a poorly governed role model creates repeated cleanup work.

At scale, the platform starts absorbing governance debt as well as technical debt. Access Reviews and Certification Guide reflects this reality well: if review campaigns are noisy, stale, or poorly targeted, the organisation pays twice, once to run the review and again to remediate the low-quality outcomes. That is one reason the long-term operating cost of in-house IGA can overtake the initial build cost.

Risk and Threat Considerations

As IGA grows more expensive, teams are tempted to cut corners by delaying connector updates, accepting stale entitlements, or broadening exceptions. That creates security exposure because the same maintenance gaps that raise cost also weaken access governance and increase the chance of excess privilege persisting unnoticed.

Failure mechanism: Drift between the IGA model and the actual application landscape forces manual fixes, which accumulate as stale accounts, broken reconciliations, and inaccurate certifications.

Impact: The organisation pays more to operate the control and becomes less able to trust it, which raises the likelihood of overprivilege, audit friction, and delayed deprovisioning.

Practitioner Guidance

What to prioritise: Treat connector maintenance, lifecycle automation, and exception burn-down as operating costs, not implementation leftovers. If those work streams are not funded explicitly, the platform will steadily degrade and become more expensive to repair later.

What to verify: Check whether the current cost base is driven by a small number of high-friction applications, a large exception backlog, or weak role and entitlement design. The most expensive IGA environments usually have all three, but one usually dominates and should shape the remediation plan.

Practitioner takeaway: In-house IGA becomes expensive when the organisation owns continuous change without a corresponding control strategy, so the real economic test is not build cost, it is whether the operating model can absorb drift without turning every update into custom engineering.

Related resources from NHI Mgmt Group

• Why does in-house authorization become more expensive over time?
• Why do IGA programmes become so expensive to operate over time?
• Why do SOAR playbooks become expensive to maintain over time?
• Why does on-premise IAM often become more expensive over time?