Cloud IGA vs On-Premises IGA: Deployment Risks, Costs and Migration Choices

Choosing between a cloud (SaaS) identity governance platform and one you install and run yourself is really a choice about where the risk sits: in connectors that must reach back into your network, in customisation you will have to carry through every upgrade, and in identity data that leaves your jurisdiction. Both models deliver the same governance functions: joiner, mover and leaver automation, access requests, access reviews, roles and segregation of duties. What differs is the threat model, who patches what, how on-premises targets are reached, how audit evidence is obtained, and how badly a migration can go wrong. This guide compares the two deployment models on those points, gives a worked scenario and a decision checklist, and covers how each handles service accounts, API keys and AI agents. It is for identity architects, IGA programme owners and auditors deciding on a platform or planning a move from an installed suite to SaaS. For feature evaluation and RFP questions, see the IGA Buyer's Guide; for the underlying concepts, see IAM and IGA Basics.

Key takeaways

• The connector estate decides the answer. If most governed applications are SaaS with SCIM or vendor APIs, cloud IGA fits naturally; if the hardest applications are mainframe, custom databases or isolated networks, every cloud option still needs an on-premises agent or appliance, and that component becomes your critical path.
• Cloud moves patching, not accountability. The provider runs the platform, but you still own the policies, the connector hosts inside your network, the service accounts those connectors use and the evidence that removals actually happened.
• Customisation is the hidden cost of on-premises. Workflows and scripted connectors built into an installed suite have to be retested at every upgrade, which is why many estates drift several versions behind. Cloud platforms limit customisation, which forces process change up front.
• Identity data is personal data. HR attributes, entitlements and review history held in a SaaS tenant raise data residency and international transfer questions that an on-premises deployment answers by default.
• Migrations fail on the edges. Lost review history, mismatched account correlation and leaver processing that silently stops during cut-over cause more harm than the platform choice itself, so plan parallel running and reconciliation before the switch.

The short answer

Choose cloud IGA when your governed applications are mostly SaaS, your team cannot sustain platform engineering (patching, scaling, database administration, upgrade testing) and you are willing to adapt processes to the product's model. Choose or keep on-premises IGA when a large share of targets sit in networks with no outbound internet path, when regulation or contract requires identity data to stay in a specific location under your own control, or when deep customisation is essential and you have the engineers to carry it. Most large organisations end up hybrid: a cloud platform as the governance plane with on-premises agents or appliances for the legacy estate. The design question is then how much of the old customisation you retire rather than recreate.

The NIST definition of cloud computing (SP 800-145) treats software as a service as one of three service models. In SaaS the provider runs the application and the infrastructure under it, and the customer works through configuration. That split is the root of every difference below.

Comparison table

Connector reach to on-premises targets

An IGA platform is only as useful as the systems it can read from and write to. In an installed suite, connectors run on servers inside the network and talk to Active Directory, LDAP directories, databases and mainframe security systems directly. A SaaS platform cannot reach those systems from the internet, so every major provider ships a component you install locally that makes outbound calls to the tenant. Platforms are listed alphabetically; the order is not a ranking.

• Microsoft Entra: on-premises application provisioning uses a provisioning agent plus, for non-SCIM targets, the ECMA Connector Host, which can run ECMA2 connectors such as the generic SQL connector. Microsoft's architecture page states that the agents use only outbound connections, so no inbound firewall rules or perimeter network are needed. It recommends one active and one passive agent per data centre for ECMA connectors, two active agents per application for SCIM, and says the agent must be updated manually for this scenario.
• Okta: the Okta Provisioning Agent links on-premises applications to Lifecycle Management through a SCIM server or custom connectors. The installation guidance lists Windows and Linux (x64) builds, requires TLS 1.2, and allows one agent to serve several on-premises apps, each with its own SCIM server URL.
• SailPoint: Identity Security Cloud uses a Linux-based virtual appliance (VA) to connect on-premises sources. SailPoint's documentation says the VA makes outbound-only calls, the service does not connect to the VA directly, and SailPoint maintains, patches and upgrades the VA software through those calls.

Three practical consequences follow. First, the agent host is now a tier 0 asset: it holds credentials that can create and delete accounts in your directories and databases, so it needs the same hardening as a domain controller or PAM vault. Second, agent redundancy is your responsibility even when the tenant has an SLA: a single agent in one data centre is a single point of failure for leaver processing. Third, isolated or air-gapped networks with no outbound path at all still need either a local platform, a relay design approved by the network owner, or a manual (ticketed) fulfilment process with reconciliation.

SCIM makes this easier but does not remove testing. RFC 7644 defines /Users, /Groups and /Bulk endpoints, and marks filtering, sorting and PATCH as optional for service providers, so "supports SCIM" says little about whether a target handles group membership updates the way your platform sends them. See the SCIM Provisioning Guide.

Threat model for each option

Cloud IGA

• Tenant takeover: an attacker with a tenant administrator session or API token can grant access in every connected system. Phishing-resistant MFA, a small number of named admins, and separate break-glass accounts matter more here than on any single application.
• Agent compromise: the on-premises agent or appliance holds connector credentials for internal systems. Compromise gives write access to directories and databases from inside the network.
• Provider and subprocessor risk: a provider incident or a compromised support path affects every customer. This is supply chain risk, assessed through contracts, assurance reports and exit plans rather than technical controls you operate. See the ISO/IEC 27036 Supplier Relationships Guide.
• Integration tokens: OAuth clients and API tokens the platform uses to manage SaaS applications are high-privilege non-human identities in their own right.

On-premises IGA

• Server and database compromise: the IGA database holds every entitlement, often connector passwords, and the workflow engine can write to all targets. Unpatched middleware on these servers is a common entry point.
• Connector service accounts: installed suites typically run connectors under domain or database accounts with broad rights and passwords that are rarely rotated. See How to find service accounts with Domain Admin rights.
• Customisation flaws: custom scripts, stored procedures and portal changes are written by integrators and rarely security tested after go-live.
• Version drift: an estate several releases behind carries known vulnerabilities in the platform and its application server, plus the risk of reaching end of support.

Customisation debt and upgrade burden

Installed IGA suites allow almost anything: custom workflow code, connector scripts, direct database changes and portal modifications. That flexibility let many organisations encode every local exception, and each exception must be retested when the product is upgraded. The result is a familiar pattern: upgrades become multi-month projects, they are deferred, and the platform falls behind its vendor's support window. As one example of the timelines involved, Microsoft's lifecycle page for Microsoft Identity Manager 2016 (checked November 2026) shows mainstream support ended in January 2021 and extended support for Service Pack 2 running to January 2029. Any installed suite has an equivalent date that should be in the risk register.

Cloud IGA inverts the problem. The provider upgrades continuously, so you never run an old version, but you only customise through the extension points the product offers. Behaviour changes arrive on the provider's schedule, which means you need a lightweight regression test (a set of test identities run through joiner, mover and leaver flows) that you can run after release notes announce changes. The practical rule: before migrating, classify each customisation as retire (the process can change), configure (the product does it natively), or extend (needs a supported extension point). Customisations that fit none of the three are the true cost of the move.

Data residency and audit evidence

An IGA platform holds a concentrated set of personal data: names, job titles, managers, locations, employment dates and a complete map of what each person can access. In SaaS that data sits in the provider's regions and may be accessible to support staff in other countries. The UK ICO's international transfers guidance treats making data accessible to a separate organisation outside the UK as a restricted transfer, which then needs adequacy regulations, an appropriate safeguard such as the International Data Transfer Agreement or Addendum with a transfer risk assessment, or a narrow exception. Ask providers where tenant data, backups and logs are stored, where support staff sit, and which subprocessors handle the data. See the Data Sovereignty and Residency Guide and the GDPR Article 28 Processor Guide.

Audit evidence also changes shape. On-premises, auditors test your servers, change records and database directly. In SaaS, they rely on the provider's assurance reports for the platform and on your tenant's configuration, logs and exports for the controls you operate. The NCSC's cloud security principles include principle 13, audit information and alerting for customers: the provider should supply the audit information you need to find out how and when an incident happened. Confirm log retention in the tenant, export to your SIEM, and whether review decisions and their evidence can be exported in a form auditors accept.

Availability and resilience

IGA is rarely in the authentication path, so a short outage does not stop people working. It does stop joiners getting access and, more importantly, stops leavers losing it. Measure availability as time from HR termination to access removed in every target, not as platform uptime.

• Cloud: the tenant SLA covers the service, but leaver processing also depends on your HR feed, your agents and the target systems. Run at least two agents or appliances per site for critical connectors, monitor their heartbeat, and keep a documented manual disablement procedure for when the tenant is unavailable.
• On-premises: you design clustering, database replication and a disaster recovery site. Test failover, and include the IGA platform in your identity recovery plan. See the Identity Recovery Guide.

Non-human identity and AI agent coverage

Both models were built around people with HR records. Service accounts, API keys, OAuth applications, workload identities and AI agents have no HR feed, so governance depends on how each platform discovers them and assigns owners. Cloud platforms tend to integrate with cloud provider and SaaS APIs quickly; installed suites often see on-premises directories and databases more completely. Neither is complete by default. Test four things on your own data: discovery of non-human accounts in each connected system, owner assignment when no HR record exists, review campaigns that make sense for machine accounts (purpose, last use, credential age), and offboarding that revokes credentials rather than only disabling an account. See How to Run an Access Review for Service Accounts, the NHI Inventory Reconciliation guide and the Identity Governance for AI Agents Guide.

Remember that the IGA platform itself creates non-human identities: connector accounts in every target, API tokens for SaaS integrations and the agent registration credential. Put them in the same inventory, with owners and rotation dates.

Decision guidance

Small organisations rarely have a case for running IGA themselves. Large regulated organisations usually land on hybrid, and the decision then becomes which on-premises targets stay behind agents and which processes are redesigned.

Worked scenario: a bank moving from an installed suite

A mid-sized bank runs an installed IGA suite, two major versions behind, with 140 connectors, 60 of them custom scripts, and quarterly access reviews for SOX-relevant systems. It wants to move to SaaS. The team inventories connectors and finds 85 SaaS targets that the new platform supports natively, 40 on-premises directories and databases reachable through an agent, and 15 core banking and mainframe targets in a segmented zone with no outbound internet access. It deploys two agents per data centre for the 40, keeps the 15 on ticketed fulfilment with weekly reconciliation exports, and classifies the 60 custom scripts: 35 retired through process change, 18 configured natively, 7 needing a supported extension. It runs both platforms in parallel for one review cycle, compares leaver timings and reconciliation results, keeps the old platform read-only for evidence for the audit retention period, and only then decommissions it, revoking every connector service account the old suite used.

Migration failure modes and how to implement safely

1. Inventory first: list every connector, its target, its credential, its customisation and its owner. Classify customisations as retire, configure or extend.
2. Settle data location: agree residency, transfer mechanism and subprocessors with legal and privacy before any production data is loaded.
3. Harden the agents: place agents on dedicated hardened hosts, at least two per site for critical targets, with outbound-only firewall rules and monitoring of heartbeat and version.
4. Correlate accounts carefully: account-to-identity correlation rules differ between products. Run correlation in read-only mode and compare orphan counts with the old platform before enabling writes.
5. Run in parallel: keep the old platform authoritative while the new one runs aggregation and reviews in shadow mode. Compare leaver completion times and entitlement counts.
6. Cut over in rings: move low-risk SaaS targets first, then directories, then regulated systems. Keep the old connector configuration so a ring can roll back.
7. Preserve evidence: export review history, approvals and SoD exceptions in a format auditors accept before decommissioning.
8. Decommission cleanly: disable old servers, delete or rotate every connector credential the old suite held, and remove its accounts from targets.

Detection and measurement

• What to log: tenant or console admin sign-ins and role changes, connector credential changes, agent registration and heartbeat, provisioning failures, and policy or workflow changes. Forward them to your SIEM.
• Leaver latency: median and maximum time from HR termination to access removed in all targets, by connector.
• Connector health: percentage of scheduled aggregations completed on time, and number of agents below the vendor's supported version.
• Reconciliation drift: accounts in targets with no correlated identity, tracked weekly through the migration.
• Customisation count: number of custom scripts or extensions in production, trending down.
• NHI coverage: share of service accounts and agent identities with a named owner and a review in the last cycle.

Framework mapping

SA-9(5) addresses restricting the location of processing, storage and service, which is the control most directly engaged by a SaaS IGA decision. CIS Controls v8.1 Control 5 (Account Management), Control 6 (Access Control Management) and Control 15 (Service Provider Management) cover the same ground.

Common failure patterns

• One agent, one site: a single connector agent fails and leaver processing for every on-premises target stops without an alert.
• Lifting customisation unchanged: recreating every custom workflow on the new platform through extension points, so the cloud move carries the old debt with a new bill.
• Forgotten connector accounts: the old suite's domain and database service accounts stay active with their old passwords after decommissioning.
• Review history lost: the old platform is switched off before review evidence is exported, leaving an audit gap for the retention period.
• Residency agreed after go-live: production identity data loaded to a region before the transfer mechanism and subprocessor list are approved.
• Machines left out: only HR-sourced identities migrate, and service accounts and agent identities are never correlated to owners on the new platform.

Practitioner checklist

• Classify every governed application as SaaS, reachable on-premises, or isolated, and count each group.
• For each on-premises connector, name the agent host, its credential and its redundancy.
• Classify each customisation as retire, configure or extend before choosing a platform.
• Record the end-of-support date for any installed suite in the risk register.
• Confirm data location, support access locations, subprocessors and transfer mechanism in writing.
• Protect tenant or console admin roles with phishing-resistant MFA and keep break-glass accounts separate.
• Set and monitor a leaver latency target per connector.
• Export and retain review evidence before any decommissioning.
• Bring connector accounts, integration tokens and agent identities into the NHI inventory with owners.

Standards and references

• NIST: SP 800-145, The NIST Definition of Cloud Computing
• IETF: RFC 7644, System for Cross-domain Identity Management: Protocol
• NCSC: The cloud security principles
• ICO: International transfers, a guide
• Microsoft: On-premises application provisioning architecture
• Okta: On-premises provisioning
• SailPoint: Virtual appliances
• Microsoft: Microsoft Identity Manager 2016 lifecycle

Related NHI Mgmt Group resources: IGA Buyer's Guide · Joiner-Mover-Leaver Guide · Identity Governance Maturity Model · AI Agent Registry vs CMDB vs IGA