Identity Governance TCO Across SaaS, Cloud, and Legacy Systems

The subscription is the easiest line to price, but it is often not the biggest workstream. If you are trying to forecast identity governance TCO, the safer question is not “what does the tool cost?” It is “what will this cost after signing, during rollout, and every year after?”

That is what this article gives you: a CIO-ready 3-year and 5-year worksheet, a clean way to separate one-time from recurring costs, and a practical view of why SaaS, cloud, and legacy systems produce very different cost curves. Keep the model simple enough to use, but complete enough to trust.

What does identity governance TCO include beyond the subscription?

Identity governance TCO includes the work around the platform, not just the platform itself. The subscription is only one bucket. A real model also includes implementation, connectors, internal staffing, infrastructure and telemetry, audit work, ongoing operations, and transition costs.

That matters because identity governance and administration is the discipline of deciding which identities may access which resources, why they need that access, who owns the decision, how access is provisioned or revoked, how it is reviewed, and how evidence is retained. In other words, the cost follows the operating model. If the program has to govern employees, contractors, partners, vendors, privileged accounts, service accounts, workload identities, cloud roles, automation identities, and AI agents, then the denominator is not just headcount.

A practical starting point is to map the cost buckets before you ask for any pricing input:

• licensing and consumption

• implementation and transformation

• connectors and integration

• internal staffing

• infrastructure and telemetry

• audit and control operations

• ongoing operations

• transition and retirement

That gives you a better view of identity governance TCO than a subscription quote ever will.

One useful rule keeps the model honest: include a cost only when the IGA program must buy it, operate it, integrate with it, or supply labor to govern it. That avoids accidentally folding every IAM or security expense into the same bucket.

If you want a product lens later, Citadel Identity360 is the kind of platform a CIO would evaluate for lifecycle automation, access certifications, risk analytics, SoD, non-human identity governance, audit evidence, and connectors across cloud, SaaS, on-premises, and legacy systems. The point is not the product itself. The point is to measure the work it would replace or reduce.

How should a CIO build a 3-year and 5-year IGA TCO model?

Build the model in layers, not as one big number. Start with the one-time work, add the annual run rate, then add known transition or renewal events. That is the cleanest way to model IGA total cost of ownership over three years and five years.

The dossier’s core formula is simple:

TCO over N years = one-time implementation and transition costs + recurring run-rate costs for each year + variable scale and exception costs + planned contingency.

For three years, use:

TCO3 = Year 1 implementation + Year 1 transition + Year 1 run rate + Year 2 run rate + Year 3 run rate + scale/exception costs.

For five years, extend the same ledger through Year 5 and add known renewal, expansion, upgrade, hardware-refresh, or decommission events instead of assuming Years 4 and 5 look exactly like Year 2.

Your annual run rate should usually include:

• license and support

• connector maintenance

• internal operations labor

• infrastructure and telemetry

• audit and certification labor

• service-desk operations

• training and vendor management

If finance wants present value, discount each year separately and keep the undiscounted total visible too. That way the CIO sees both budget cash flow and economic value.

A good worksheet also normalizes the result in more than one way. Use at least these four views:

• total cost per governed identity per year

• total cost per connected application per year

• cost per access request or lifecycle event

• cost per access-review campaign or reviewer-hour

Those numbers are diagnostic, not universal benchmarks. A legacy-heavy environment can drive high cost per application. A large SaaS estate can drive high cost per identity. Report the denominator beside every result so the model stays grounded.

Here is the minimum workbook structure to use:

Cost item	Owner	Unit	Quantity	Unit rate	One-time or recurring	Year 1	Year 2	Year 3	Year 4	Year 5	Confidence	Source

And here are the inventory inputs you should collect before you price anything:

1. Human, contractor, partner, privileged, service, workload, and AI-agent populations.

2. Applications by SaaS, cloud, on-premises, legacy, protocol, business criticality, and owner.

3. Entitlements, roles, groups, accounts, orphaned accounts, and duplicate identity records.

4. Joiner, mover, leaver, access-request, password-reset, and service-desk volumes.

5. HR events, termination timing, review campaigns, reviewers, applications in scope, and exceptions.

6. Existing identity tools, contracts, support, infrastructure, middleware, and retirement dates.

7. Connector count and complexity, including read-only versus write-back requirements.

8. Identity-data quality, authoritative-source coverage, missing owners, and reconciliation effort.

9. Cloud accounts, subscriptions, projects, workloads, regions, log volume, retention, and SIEM destinations.

10. Internal labor hours and loaded rates for IAM, application, HR, service desk, cloud, security, audit, and change teams.

11. Regulatory scope, control frequency, evidence requirements, external-audit calendar, and remediation backlog.

12. Growth, acquisitions, new applications, new regions, and non-human identity creation expected during the horizon.

If you only change one thing this month, make it this: stop asking for a subscription number before you have the workbook.

Why is legacy system integration cost so difficult to estimate?

Because the legacy system integration cost is rarely just a connector build. Legacy systems often lack reliable APIs, clean ownership data, stable test environments, or even clear provisioning and deprovisioning semantics. That makes discovery and maintenance part of the cost, not a side note.

The dossier’s practitioner guidance gives a useful planning band:

• a straightforward REST API connector with basic create, read, update, and delete operations: 4–8 weeks

• a complex integration with custom business logic, multiple data sources, or heavy transformations: 12–16 weeks

Use that as a sensitivity band, not as a promise. The actual application team still needs to validate the estimate.

What drives the cost up is usually not hard to name:

• proprietary or non-standard APIs

• no API, requiring database, JDBC, LDAP, file, SFTP, SOAP, mainframe, or screen-scraping approaches

• incomplete create, update, or disable semantics

• multiple authoritative sources or conflicting ownership data

• custom transformations, entitlement hierarchy, approval logic, or SoD rules

• batch-only windows, firewall changes, VPN paths, certificates, and network segmentation

• poor error handling, retry, idempotency, rate limits, and API throttling

• no non-production environment or test data

• application-owner availability and change-control windows

• a requirement to read access but not write it back

• legacy specialist knowledge concentrated in one person

• regression testing after target-system releases

That is why the connector line item needs its own model:

connector TCO = discovery and mapping + design + build/configuration + security review + test environment + unit/integration/UAT + deployment + documentation + annual break/fix and version maintenance.

Do not stop at go-live. Break/fix investigation, patching, testing, redeployment, health checks, minor target-API updates, compatibility testing, and retesting after platform-version changes belong in Years 2 through 5.

A useful action here is to wave-plan the applications. Price the first ten high-value systems separately from the next wave, and give legacy systems their own business case. That keeps a migration from hiding real cost inside a single average.

How do SaaS, cloud, and legacy environments change the cost curve?

They change where the cost lands, not whether the cost exists. SaaS tends to shift spend away from platform infrastructure and toward subscription, integration, telemetry, data export, and internal governance. Cloud adds consumption-based logging, retention, query, and network costs. Legacy adds specialist labor, custom integration, and old-tool coexistence.

SaaS-dominant environments

In SaaS-heavy estates, the provider generally carries the platform compute, patching, and availability responsibility. That does not mean the governance cost disappears. The buyer still pays or staffs for subscription, integrations, tenant configuration, data export, log routing, SIEM ingestion, retention, backup requirements, identity-source connectivity, API usage, support, and internal administration.

The hidden trap is assuming the platform layer gets cheaper than the governance layer. It may not. The work can simply move.

Cloud-dominant environments

Cloud governance is driven by the number of accounts, subscriptions, projects, workloads, regions, identities, entitlements, API calls, event volume, log ingestion, query volume, retention, cross-region replication, data export, and security tooling. That means cloud cost often scales with telemetry and activity, not just with the number of users.

Public pricing pages show why the unit matters. CloudTrail, S3, Azure Monitor Log Analytics, and Google Cloud Observability all tie cost to events, storage, ingestion, retention, and query behavior. The exact bill depends on region, plan, discounts, free allowances, log type, destination, compression, retention, and routing architecture.

The takeaway is simple: do not convert cloud pricing examples into a generic cost per identity. Use the organization’s actual event counts, retention periods, and destinations.

Legacy and on-premises environments

Legacy and on-premises environments bring a different set of costs. You may need servers or virtual machines, database licensing, high availability, disaster recovery, storage, backup, network paths, certificates, firewall or VPN changes, monitoring, patching, vulnerability remediation, capacity planning, power and facilities, and specialist administrators.

Even if existing capacity is available, allocate a share of that capacity and its operating labor. Otherwise the comparison looks artificially cheap.

None of the three models is automatically cheapest. SaaS is not always lower TCO, cloud is not always lower TCO, and on-premises is not always worse. The cost simply moves between categories.

If you are comparing deployment models, use one question: where does this environment push the work, into subscription, telemetry, infrastructure, or specialist labor?

How should internal staffing, audit, and service-desk work be priced?

Price them as real labor and real activity, not as zero-cost overhead. That is where many identity governance TCO models break down. The invoice does not show every hour, but the organization still pays for those hours.

The internal team usually includes an executive sponsor, program manager, IAM architect, integration engineers, platform administrators, security and risk staff, cloud or infrastructure staff, application owners, HR, service desk, audit and compliance, legal and privacy, procurement, communications, trainers, and business reviewers. Application owners and managers are often the most overlooked labor in entitlement mapping, approvals, testing, certification, and remediation.

For a planning anchor in the U.S., the dossier provides these May 2024 median annual wages, with a loaded proxy using about 1.43x:

Role used as a proxy	Median annual wage	Approximate loaded annual proxy (1.43×)	Approximate loaded hourly proxy
Information security analyst	$124,910	about $178,621	about $86/hour
Computer systems analyst	$103,790	about $148,420	about $71/hour
Software developer	$133,080	about $190,305	about $91/hour
Network and computer systems administrator	$96,800	about $138,424	about $67/hour
Project management specialist	$100,750	about $144,073	about $69/hour

The loader is only a U.S. labor-market proxy. Replace it with your own finance or HR rates when you have them.

Use this formula:

internal labor cost = role FTE × months assigned × loaded annual cost / 12.

Model project staffing and run-state staffing separately. Implementation may need temporary application SMEs, data stewards, change managers, and testers. After go-live, you still need platform administration, connector ownership, access-policy maintenance, review support, incident handling, and vendor management.

Audit work needs the same treatment. Budget separately for:

• control and policy mapping

• application and entitlement scope decisions

• reviewer population and manager certification time

• campaign preparation, reminders, escalation, delegation, and exception handling

• SoD analysis and remediation

• orphan, dormant, duplicate, and excessive-access investigation

• evidence packaging, report reconciliation, and auditor questions

• control testing and sample selection

• failed-control remediation and retesting

• policy, role, and entitlement changes between campaigns

Do not assume automation removes review labor. It can reduce collection, routing, reminders, evidence assembly, and low-risk decisions. It does not remove accountability.

For service desk economics, use your own ticket data when possible. A simple formula works:

cost per ticket = total monthly service-desk operating expense / monthly ticket volume.

Then calculate avoidable savings separately:

avoidable ticket savings = avoidable access/password tickets × internal cost per ticket.

Keep hard savings, capacity released, avoided hiring, and productivity value separate. A faster approval is not always a cash saving, but it is still valuable.

Here is a practical next step: pull the last six to twelve months of access, password, and certification tickets, then split them by avoidable versus unavoidable. That gives you a much cleaner run-rate input than any outside benchmark.

What should the CIO measure after go-live?

Measure the operating friction, not just the launch. The point of the model is to see whether run-rate cost and service quality are moving in the right direction. After go-live, track access fulfillment time, deprovisioning time, avoidable tickets, connector failures, review completion, remediation, audit effort, and run-rate cost per governed identity.

A good post-launch scorecard should include:

• access request and fulfillment time

• joiner, mover, and leaver cycle times

• deprovisioning timing after termination or role change

• access-review completion and exception rates

• orphaned, dormant, duplicate, and excessive-access findings

• connector failures and regression-test issues

• audit evidence assembly time

• service desk volume tied to identity processes

• run-rate cost per governed identity and per connected application

You should also watch non-human identity growth closely. Survey data from 2025 reported 82 machine identities for every human and 42 percent of machine identities with privileged or sensitive access. Another research signal reported a 44 percent increase in non-human identities from the first half of 2024 to the first half of 2025. Those are not forecasts for your environment, but they are a strong reminder that machine and AI identities need to be counted separately.

That means your TCO model should treat service accounts, machine identities, API identities , cloud workloads, and AI agents as first-class identities with ownership, lifecycle, credential or secret controls, least-privilege policy, incident paths, and evidence. Human headcount alone will understate the operating scope.

If your platform can reduce manual lifecycle work, review work, connector work, and audit work across the estate, that is where the value shows up. If it cannot, the model should make that visible too.

Video: How Citadel Identity360 Saves IT Cost

This demo is useful if you want to see how lifecycle automation, access reviews, non-human identity governance, and audit evidence can be discussed in one platform conversation. Treat it as a product demonstration, not as proof of savings.

FAQ

Is the IGA subscription usually the biggest cost?

Not necessarily. Implementation, custom integrations, internal labor, audit work, and legacy maintenance can dominate the first year or the five-year total.

How do we estimate legacy system integration cost?

Inventory each target’s protocol, data quality, owner, provisioning semantics, test environment, and change process. Use a bottom-up estimate, then validate it with the application team.

Is SaaS identity governance cheaper than on-premises governance?

There is no universal answer. SaaS often reduces platform infrastructure and patching, but adds subscription, integration, telemetry, data-export, and governance work. On-premises may reuse existing capacity but carries infrastructure and specialist operations.

How should machine identities and AI agents appear in the TCO model?

Count them separately. Budget for discovery, ownership, lifecycle, credential or secret controls, policy, monitoring, review, and incident work, because human headcount alone will understate the scope.

The cleanest way to forecast identity governance cost is to inventory identities, applications, connectors, labor, review scope, and telemetry before you ask for a price. Start there, and the rest of the model becomes much easier to defend.

If you want the strongest version of the business case, begin with the current operating model, not the vendor pitch. Take it one line item at a time.