Identity Governance TCO Benchmarks by Application Count and Integration Complexity

If you are trying to budget Identity Governance, the useful question is not “What does IGA cost?” It is “How many identities will be governed, how many applications will be connected, and how hard are those integrations?”

That is the right frame because identity count sets the recurring software and operating-cost floor. Application count sets the size of the onboarding workload. Integration complexity determines how large the implementation spike becomes and how much maintenance you carry after go-live.

For practical planning, a low-complexity program serving roughly 1,000 to 5,000 governed identities and 10 to 25 connected applications may require about $150,000 to $450,000 in Year 1 and $75,000 to $250,000 per year after stabilization. A 5,000 to 15,000 identity program with 26 to 75 applications and several custom or legacy integrations may require $450,000 to $1.2 million in Year 1 and $200,000 to $700,000 per year thereafter. Larger portfolios rise into the low millions, and a global program with hundreds of applications and many disconnected systems can exceed $8 million in Year 1 and $4 million per year at run-rate.

These are planning envelopes, not quotes.

The core rule: identity count sets the floor

The recurring cost baseline comes from the identities you actually govern, not from the size of your SaaS inventory. If the commercial model governs employees, contractors, partners, privileged accounts, service accounts, machine identities, cloud workloads, or AI agents, each category can affect licensing, lifecycle work, and review cadence differently.

That matters because a source identity, an application account, and an entitlement are not the same thing. If you count them interchangeably, the estimate will be wrong.

A practical way to think about identity governance benchmarks is this: identity count defines the recurring software and operating burden, but it does not tell you how hard implementation will be. A small identity population can still be expensive if the portfolio is integration-heavy or full of disconnected systems.

The application count and integration mix drive the spike

Application count is the better predictor of implementation effort than identity count. Each in-scope application brings an onboarding work package: data access, schema mapping, provisioning logic, approvals, certifications, testing, owner sign-off, and support planning.

The mix matters more than the raw count. One disconnected payroll or manufacturing system can consume more effort than many standard SaaS applications. That is why a good integration complexity benchmark looks at connector class, legacy share, entitlement depth, and write-back requirements, not just the number of apps.

The strongest planning approach is to classify every integration into four classes:

• Standard or prebuilt

• Configurable

• Custom

• Disconnected or deeply legacy

Once you do that, application count becomes a useful budget input instead of a misleading headline.

A practical Year 1 and run-rate planning table

Scenario profile	Directional Year 1 TCO, USD	Stabilized annual run-rate, USD
Foundation: 1,000–5,000 governed identities; 10–25 connected applications; 0–10% legacy; 0–2 custom or disconnected connectors	$150,000–$450,000	$75,000–$250,000
Hybrid mid-market: 5,000–15,000 identities; 26–75 applications; 10–25% legacy; 2–5 custom connectors	$450,000–$1.2 million	$200,000–$700,000
Enterprise portfolio: 15,000–50,000 identities; 76–150 applications; 25–50% legacy; 5–15 custom connectors	$1.2–$3 million	$500,000–$1.6 million
Global or highly complex: 50,000+ identities; 151–300+ applications; >50% legacy; 15+ custom or disconnected connectors	$3–$8 million+	$1.5–$4 million+

These values are 2026 USD and are intended for planning only.

The lower end assumes strong application ownership, usable identity data, standard connectors, limited role engineering, and a controlled first release. The upper end assumes more application-owner participation, data cleanup, complex entitlement models, multi-environment testing, custom code, regulated evidence, and coexistence with existing tools.

A program can move up a band without adding identities if it adds many applications, custom write-back, or undocumented legacy systems. Identity population alone does not reduce cost if the portfolio grows.

What Year 1 TCO includes, and what it does not

An IGA implementation cost benchmark is only useful if you separate implementation from run-rate. Year 1 TCO is not just platform setup. It includes the first-year subscription or license, internal labor, testing, migration, training, support, and initial operations.

A clean way to express it is:

TCO = platform subscription or license + core implementation + application and connector onboarding + identity and entitlement data work + testing and cutover + internal labor + training and change management + ongoing operations and support

Implementation cost is the one-time deployment and transformation component. Stabilized annual run-rate is the recurring subscription or license, platform administration, connector monitoring, exception handling, access-request support, certification campaigns, role maintenance, audit evidence, and normal new-application onboarding after initial stabilization.

Do not fold ROI into that number. Productivity, service-desk reduction, license reclamation, audit effort, and risk reduction belong in a separate benefits discussion.

What usually drives cost up

The biggest budget pressure comes from a few predictable sources:

• More connected applications

• More custom or disconnected connectors

• Poor identity and entitlement data

• Complex role and separation-of-duties design

• Multi-step approval and certification workflows

• Multi-environment testing

• Application-owner delays

• Coexistence with an existing IGA tool

• Custom code that must be owned and supported after go-live

That is why a program with the same identity count can sit in very different budget bands. If your application estate contains a high share of legacy systems or custom write-back requirements, the implementation spike can grow quickly, and the run-rate follows because custom connectors carry maintenance obligations over the application’s life.

How to use the benchmarks without overestimating or underestimating

The cleanest self-benchmarking method is to build the estimate from the portfolio outward:

1. Define the governed identity unit.

2. Build the application inventory.

3. Classify every integration as standard, configurable, custom, or disconnected.

4. Separate first wave from target state.

5. Baseline today’s cost.

6. Build Year 1 and run-rate separately.

7. Require an itemized SOW.

8. Clarify custom-code ownership.

9. Stress-test the estimate for more legacy, more environments, and more identity types.

10. Tie the investment to measurable outcomes.

That process matters because a 20-application first release and a 150-application target state are different budgets. If you want an estimate that survives scrutiny, you need the application-level plan, not just an identity headcount.

How to read the integration complexity benchmark

Legacy percentage is a proxy, not the whole story. Define legacy share as connected applications requiring bespoke, batch, file, manual, UI, or otherwise non-standard integration divided by total connected applications.

Also remember that on-premises is not automatically legacy. A cloud application can be harder than an on-premises system if it has poor entitlement semantics, weak APIs, or difficult approval logic.

The more useful question is whether the connector is:

• Standard or prebuilt

• Configurable

• Custom

• Disconnected or deeply legacy

That distinction matters because a disconnected system often supports attestation before it supports reliable automated provisioning. In other words, application count becomes misleading at that point. One difficult system can cost more than several easy ones.

Where public pricing anchors fit

There is no universal IGA price. What you can use are calibration points, not market medians and not competitor rate cards.

Public subscription anchors include Microsoft Entra ID P1 at $7 per user per month with annual commitment, P2 at $10, and Microsoft Entra Suite at $12. Okta positions its Starter Suite at $6 per user per month and Essentials at $17 per user per month. A vendor-authored category range also places enterprise IAM at $100 to $300+ per user per year.

For internal scenario modeling only, those anchors support a rough $60 to $300+ per governed-identity-year subscription placeholder. Customer-specific agreements, bundled suites, identity categories, modules, and regional terms can change the real subscription materially.

That is why a good estimate separates software cost from connector effort and from internal labor. A low license can still produce a high Year 1 bill if the integration mix is difficult.

What this means for budget holders

If you are a CIO or Head of IT, the decision is not whether IGA has a universal cost. It does not. The decision is whether your scope is shaped more like a foundation program, a hybrid mid-market rollout, an enterprise portfolio, or a global, highly complex deployment.

A foundation program often looks manageable because the identity base is small and the application set is limited. A hybrid mid-market program starts to show meaningful connector overhead. An enterprise portfolio adds role engineering, legacy coexistence, and more testing. A global program with many disconnected systems becomes a transformation program, not just a software purchase.

That is the right lens for identity governance benchmarks: budget by portfolio shape, not by vendor category label.

A simple way to sanity-check a proposal

A credible proposal should identify each application and its connector class, name the data and entitlement assumptions, state what the customer must supply, include test and cutover effort, define support for custom code, and separate one-time from recurring charges.

A weak proposal usually does the opposite. It gives you a per-user number, says connectors are included without naming which, excludes data cleanup and application-owner effort, treats custom code as configuration, or leaves post-go-live maintenance undefined.

If you see that pattern, the quote is probably too thin to trust.

Closing perspective

The most useful benchmark is transparent, not universal. Ask how many identities will be governed, how many applications will be connected, how many are genuinely legacy or disconnected, what provisioning and review depth is required, and who owns the custom code after launch.

If you are building the business case now, start with an application inventory and a connector-class map. From there, you can turn the scenario bands in this article into a scope-specific estimate.

For organizations evaluating Citadel Identity360 or any other IGA platform, the right next step is the same: request an inventory-based assessment, separate Year 1 from stabilized run-rate, and insist on an application-level integration plan. That is what makes an identity governance estimate credible.

FAQ

What matters more to IGA cost, identity count or application count?

Identity count sets the recurring floor. Application count sets the number of onboarding work packages. Connector class, legacy share, entitlement depth, and data readiness decide how heavy each package gets.

What is a reasonable IGA implementation cost benchmark?

There is no universal number. Use scenario bands. Foundation programs may run $150,000 to $450,000 in Year 1 TCO. Hybrid mid-market programs may run $450,000 to $1.2 million. Enterprise portfolios may run $1.2 million to $3 million. Global, highly complex programs can exceed $3 million.

How much more do legacy and custom connectors cost?

There is no reliable cross-vendor universal premium. A disconnected system may require tens of thousands of dollars or more in build effort, plus ongoing maintenance. The real cost depends on data quality, testing, write-back, release dependencies, and support ownership.

Does 150 SaaS applications in inventory mean the IGA project needs 150 integrations?

No. Enterprise inventory, first release, and target-governed portfolio are different numbers. Prioritize critical applications first, then classify every target by connector class, entitlement depth, and lifecycle requirement.