On-Prem vs SaaS IGA: A Deployment Decision Framework

The on-prem vs SaaS IGA choice is rarely about taste. It comes down to hard constraints: where identity records may live, which networks a governance platform may reach, how many engineers can run it and who carries each upgrade. Citadel Identity360 can be deployed on-prem, in a private cloud or as SaaS, so the hosting model follows those constraints instead of forcing a product change. This guide gives IT and security leaders a constraint-by-constraint framework, a pilot test for each one and a decision table to take into the shortlist.

Hosting is the second decision, not the first

Start with governance outcomes: verified leaver removal, contractor expiry, certifications with risk context and oversight of AI agents. Then ask which hosting model satisfies the rules that surround those outcomes. Reversing the order tends to bend requirements around a product.

Citadel Identity360 supports the outcome-first order. One product runs in all three models, so a security architect can set the boundary for data, networks and operations while keeping the same governance programme. The Citadel Identity360 product overview describes full-stack visibility across cloud, SaaS and on-prem systems, and that visibility is what each hosting choice has to preserve.

Terms used in this framework

• SaaS: Astranova Labs operates Citadel Identity360 as a service and your team consumes it. NIST sets out the wider service models in SP 800-145, the NIST definition of cloud computing.
• Private cloud: Citadel Identity360 runs in cloud infrastructure dedicated to your organisation, in a tenancy and region you choose.
• On-prem: Citadel Identity360 runs on infrastructure in your own data centre. On-prem places the platform inside your boundary; it is not a fully offline system, and it uses the connectivity you approve.
• Restricted network: a segment with tightly controlled inbound and outbound paths, close to air-gapped without being disconnected.
• Upgrade ownership: the party that schedules, tests and applies platform releases.
• Integration reach: the target systems the platform can read, change and verify, including legacy and UI-only applications.

What the framework covers and leaves out

In scope: data residency, regulated and sovereign workloads, restricted networks, operating team capacity, upgrade ownership, integration reach, and AI agent and non-human identity governance under each model.

Out of scope: vendor feature scoring, implementation calendars and licence pricing. For cost structure, read identity governance TCO across SaaS, cloud and legacy systems. For effort drivers in mixed estates, read what hybrid deployment effort implies for IGA teams.

Six constraints that decide on-prem vs SaaS IGA

Work through them in order. The first constraint that produces a firm rule usually decides the model, and the rest refine the design.

Constraint 1: where identity data is allowed to reside

An IGA platform holds a dense map of people, accounts, entitlements and approval history. Transfer rules, such as those the European Commission summarises on international transfers of personal data, turn that map into a residency question.

How Citadel answers it: when policy names a jurisdiction or facility, Citadel Identity360 in a private cloud region or your own data centre keeps the governance store where the rule requires. Without such a rule, SaaS takes platform operations off your team.

Pilot test: ask your data protection officer to list every location that identity records, audit evidence and backups occupy in the proposed design. Trace one leaver record end to end against that list.

Constraint 2: regulated and sovereign workloads

Banks, public bodies, defence suppliers and critical infrastructure operators often work under rules on who may administer a system and where its control plane sits. Those rules point toward private cloud or on-prem.

How Citadel answers it: a regulated business unit gets Citadel Identity360 under the stricter hosting, with joiner, mover and leaver automation, SoD and identity-risk controls, certifications and audit evidence in one product. Account management and audit control families in NIST SP 800-53 map cleanly to the evidence Citadel produces.

Pilot test: pick the three controls your auditors sample most, such as quarterly certification, leaver removal and privileged entitlement approval, and have Citadel produce the evidence pack for each from the pilot environment.

Constraint 3: restricted networks close to air-gapped

Some estates keep production systems in segments with very few approved paths. The requirement there is a governance platform that lives beside the restricted systems and talks only over sanctioned routes.

How Citadel answers it: on-prem Citadel Identity360 sits inside the segment, and integration methods such as JDBC, LDAP, files over SFTP and scheduled batch suit networks with limited outbound access. Treat on-prem as boundary control, not disconnected operation, and design the approved paths up front. The zero trust principles in NIST SP 800-207 are a sound reference for that path design.

Pilot test: give the pilot only the routes your security team would allow in production, then run a full leaver flow from trigger to verified removal over those routes.

Constraint 4: the size of the team that will run it

Private cloud and on-prem platforms need people for servers, databases, certificates, backups and monitoring. Where that capacity is thin, SaaS is the natural default.

How Citadel answers it: the Citadel plan includes installation, deployment and hypercare support, and routine administration is no-code-first, so day-to-day configuration stays with your own administrators. The analysis of identity governance staffing and FTE budgets helps size the rest.

Pilot test: have your own administrators build one approval workflow and one review campaign during the pilot, and record who needed help and why.

Constraint 5: who owns each upgrade

Under SaaS, the provider runs the release cycle. In private cloud and on-prem, your team owns the change window, the test environment and the rollback plan.

How Citadel answers it: the choice stays with you. Organisations that want releases off their plate take SaaS. Organisations that must approve every change inside a controlled window take private cloud or on-prem. Whichever model you pick, 400 hours of customization come with Citadel Identity360 and can be spent on reporting, workflow and policy changes, approval rules or connector adjustments, so tailoring is scoped from the start.

Pilot test: request a written upgrade runbook for your chosen model, walk your change advisory board through it and list each step your team owns.

Constraint 6: integration reach into legacy and UI-only systems

Reach often outweighs hosting. A platform in the right region that cannot touch the mainframe, the custom HR database or the vendor portal with no API leaves the riskiest access ungoverned.

How Citadel answers it: Citadel Identity360 integrates through mainframe, batch, SFTP and file transfers, JDBC queries, LDAP directories, SCIM, SOAP and REST APIs and custom methods, and supports RPA-based integration for applications whose administration happens on screen rather than through an API. The combined pattern reads accounts through an export or JDBC query, decides with ownership, policy and conflict checks, changes access through an approved RPA workflow, verifies against a fresh read and routes exceptions to a named administrator. See governance for applications without SCIM and our guide to enterprise connector coverage.

Pilot test: bring your hardest application, run one disablement through read, decide, change and verify, and confirm the record shows approved, attempted, fulfilled and verified as separate states.

Decision table: constraint, leaning model and Citadel response

Constraint	Leaning model	Citadel Identity360 response	Pilot evidence to collect
Named residency rule	Private cloud or on-prem	Governance store placed in the region or facility the rule names	Location list for records, evidence and backups
Regulated or sovereign workload	Private cloud or on-prem	Lifecycle, SoD, certification and evidence under the stricter hosting	Evidence pack for three sampled controls
Restricted network	On-prem	Platform inside the segment, using JDBC, LDAP, SFTP and batch paths	Leaver flow completed over approved routes only
Thin operations team	SaaS	Platform run as a service, with no-code-first administration	Workflow and review built by in-house admins
Strict change control	Private cloud or on-prem	Releases applied inside your own change window	Upgrade runbook reviewed by the change board
Connector reach, legacy and UI-only apps	Any	Broad connectors plus RPA, with the result verified	Disablement shown as approved, fulfilled and verified
Contractor lifecycle	Any	Sponsors, engagement dates, extensions and offboarding in one flow	Contractor expiry removes access and is verified
SoD and risk scoring	Any	Conflict checks and identity-risk context on requests and reviews	A flagged toxic combination with reviewer context
NHI and AI agents	Any	Built-in NHI detection and ownership, agent discovery from the Entra, AWS and Google Cloud registries, and MCP tool-level authorization	One agent limited to named tools, with its owner on record

Agent and machine identity oversight under any hosting choice

AI agents, workloads, keys and service accounts need the same owner, purpose, review and retirement discipline as people. Citadel Identity360 ships AI governance, agent discovery, and the detection and management of non-human identities as part of the core product.

• Discovery: Citadel pulls agents registered in AWS, Google Cloud and Microsoft Entra into a single governed list.
• Ownership: every MCP server is registered with an owner, and every agent has an accountable owner.
• Tool-level authorization: agents receive specific tools on a registered MCP server rather than the whole server, with usage controlled through organisational OAuth and optional allowlists.
• Distribution: Citadel’s AI governance produces a configuration file for MCP clients on Claude, OpenAI or Cursor to use when reaching governed MCP services, and the shared file carries no embedded secrets.
• Containment: Citadel includes an AI agent kill switch as an intervention and containment capability.

For the hosting decision, this means the agent inventory sits beside the human and service account inventory in one product. Vendors package these controls differently. In June 2026 SailPoint closed its purchase of Entro Security, with Entro’s non-human identity and credential security products offered to SailPoint customers on a standalone basis while work to integrate them natively into its platform goes on. Whichever vendors you shortlist, ask under each hosting model which agent and NHI controls are in the core platform and which are licensed or deployed on their own. See the agent governance page, MCP access control for AI agents and the non-human identity buyer checklist.

An illustrative scenario: one estate, two hosting pressures

Consider an illustrative manufacturer with a European HR system under a residency rule, a plant network with tightly limited outbound paths and a contractor workforce that changes every month.

1. The residency rule places the governance store in a private cloud region inside the approved jurisdiction.
2. Plant systems are read through JDBC and SFTP file drops over paths the security team already approves.
3. A maintenance application with no API is covered by an RPA disablement workflow, confirmed by a fresh export.
4. Contractor sponsors confirm or extend engagements, and expiry triggers removal across connected targets.

Hosting and governance stay separate questions, and Citadel answers both without splitting the programme across products. For wider context, see our overview of Citadel integrations across the estate and evaluating IGA deployment effort in hybrid environments.

Questions to put to every shortlisted vendor

• Which hosting models are available today, and what governance scope comes with each?
• Where do identity records, audit evidence and backups reside in the proposed model?
• Which network paths does the platform need inside a restricted segment, and in which direction?
• Who applies each release, and how are customised workflows handled at upgrade time?
• How are UI-only applications governed, and how is each change verified?
• Do AI agent discovery and non-human identity controls come in the same product?

Each of these has a direct Citadel Identity360 answer inside one product and one plan. For scoring the identity pillar answers, the CISA maturity model for zero trust gives a clear structure.

Frequently asked questions

How does on-prem vs SaaS IGA differ in practice?

With SaaS IGA, the provider operates the governance platform and your team uses it. With on-prem IGA, the platform runs on infrastructure you control, and your team owns hosting, patching and change windows. Citadel Identity360 offers both, plus private cloud.

Is a private cloud option available for Citadel?

Yes. Private cloud is one of three Citadel Identity360 hosting models, alongside on-prem and SaaS. Private cloud suits organisations that need a dedicated tenancy and a chosen region without running data centre hardware.

Does on-prem IGA mean the platform runs fully offline?

No. On-prem means the platform runs inside your boundary on infrastructure you control. It still relies on the integration and network paths you approve, so define those paths during the pilot.

Which deployment model suits a small IT team?

SaaS, because platform operations sit with the provider. Citadel adds no-code-first administration and includes installation, deployment and hypercare support in its plan.

Can a SaaS or private cloud IGA platform govern legacy on-prem applications?

Yes. Citadel Identity360 reaches older systems via database queries, directory binds, file drops, batch jobs, mainframe links and custom adapters, and governs UI-only applications through RPA workflows that are verified after each change.

Is AI agent governance a separate purchase with Citadel?

No. AI governance, non-human identity management and discovery of agents registered in AWS, Google Cloud and Entra come with Citadel Identity360, so agent owners, tool permissions and the kill switch live alongside lifecycle, reviews and SoD.

Test your hardest constraint with Citadel Identity360

Bring the constraint that decides your hosting model, whether a residency rule, a restricted plant network or a UI-only application, and run it through the matching Citadel deployment model in a defined pilot. Request Demo to set it up, and watch the Citadel video library as a preview.