Multi-tenant SaaS centralises operational control inside the vendor’s environment, while customer-hosted SaaS places the runtime inside the buyer’s cloud and splits approval, support, and accountability across organisations. That shift makes change control and delegated access far more important than in a standard shared-tenancy model.
How the tenancy model changes the governance boundary
For identity governance, the tenancy model changes who owns the runtime, who can change it, and who is accountable when something goes wrong. Multi-tenant SaaS keeps the service control plane in the vendor’s environment, so the buyer mainly governs configuration, roles, and policy outcomes. Customer-hosted SaaS shifts more operational responsibility into the buyer’s cloud, which makes hosting posture, delegated administration, and change approval part of the governance model.
That matters because identity governance is not only about access decisions, it is also about where those decisions are enforced and who can alter them. In a customer-hosted model, the buyer usually has more control over infrastructure dependencies, but also more responsibility for identity governance and administration fundamentals, especially where approvals, recertification, and entitlement changes need to align with the buyer’s own cloud and change-management processes.
Why approval, support, and accountability split differently
In a multi-tenant SaaS model, the vendor can standardise support, patching, scaling, and incident handling across all customers, which simplifies operations but limits tenant-specific control. In customer-hosted SaaS, support and accountability are more distributed: the vendor may still own the product, but the buyer often owns the cloud environment, network exposure, and some release coordination. That split is the practical difference practitioners feel first.
It also changes how you think about access paths. A customer-hosted deployment can expose additional admin roles, cloud permissions, secrets handling, and integration points that do not exist, or are abstracted away, in a shared-service model. The buyer therefore needs stronger controls around delegated access and privileged change paths, not just end-user entitlements.
Where the deployment includes machine or service access, the distinction becomes even sharper. A customer-hosted product may require the buyer to manage connectors, service principals, or workload credentials inside its own environment, which makes cloud workload identity practices relevant to identity governance even when the application itself is delivered as SaaS.
What changes operationally in identity governance
The main operational change is that customer-hosted SaaS forces the buyer to govern more of the lifecycle. That includes environment segregation, configuration drift, cloud role assignment, secret rotation, and the approval trail for administrative changes. Multi-tenant SaaS still needs governance, but much of the runtime control is vendor-managed, so the buyer’s main task is validating the provider’s controls and governing their own tenant settings.
For practitioners, the useful question is not which model is “more secure” in the abstract, but which model better matches the organisation’s operating discipline. Customer-hosted SaaS gives more control over data location, network boundaries, and change windows, but it also creates more places where ownership can blur. In identity governance programmes, blurred ownership is where recertification, emergency access, and connector administration often become weak.
The buyer should also expect more dependency on cloud-specific roles and handoffs. If the SaaS stack is hosted in the buyer’s cloud, then cloud admins, application owners, and identity governance teams must coordinate more tightly than they would in a vendor-run tenant model. That is the difference that tends to drive audit questions and approval delays.
Risk and Threat Considerations
Customer-hosted SaaS increases exposure to misconfiguration, delegated-access drift, and unclear responsibility for privileged changes. Multi-tenant SaaS concentrates operational risk inside the vendor, but it reduces the customer’s ability to inspect or constrain the runtime. The governance risk is not just theoretical: when boundaries are split, it becomes easier for stale access, lingering connectors, or overbroad admin rights to survive approval cycles.
Failure mechanism: Shared responsibility gaps can leave cloud permissions, service credentials, or administrative bypass paths in place longer than intended, especially when support, hosting, and approval live in different teams.
Impact: The result is weaker change control, slower revocation, and a larger blast radius if a privileged account, connector, or integration is misused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Customer-hosted SaaS changes who can administer and change the runtime. |
| IA-5 — Authenticator Management | Customer-hosted SaaS often relies on service credentials and connector secrets. | |
| CM-3 — Configuration Change Control | The question turns on how change control shifts between vendor and customer. | |
| Recommendation — Limit delegated admin and cloud access to the minimum required for support and changes. Rotate and protect connector secrets and service credentials on a defined lifecycle. Require approval and traceability for changes that affect the hosted SaaS runtime. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The model difference materially affects who can administer, support, and approve access. |
| A.8.9 — Configuration management | Customer-hosted SaaS increases the need to govern runtime configuration drift. | |
| Recommendation — Define and enforce access rules for buyer and vendor administrative paths. Track and approve configuration changes that can alter SaaS behaviour or exposure. | ||
| CIS Controls v8 | CIS-5 — Account Management | The model changes how privileged accounts and delegated access are owned and reviewed. |
| Recommendation — Review and remove dormant or excessive administrative access across hosted components. | ||
Practitioner Guidance
What to verify: Confirm which team owns hosting, patching, connector administration, secret rotation, and emergency access before you approve the deployment model. If those responsibilities are split, the operating model should state exactly who can make and who can approve each change.
Decision rule: If the SaaS is customer-hosted, treat cloud permissions, runtime changes, and delegated support access as part of the identity governance design, not as separate infrastructure detail.
What good looks like: The provider, platform team, and identity governance function all have explicit ownership boundaries, and every privileged path is traceable to a named approval or support process.
Practitioner takeaway: The real difference is not just where the software runs, but where control authority sits. The more the buyer hosts, the more identity governance must cover delegated access, cloud change control, and proof of ownership.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
- What is the difference between patching a vulnerability and reducing identity blast radius?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org