Topic starter
25/06/2026 5:18 pm
TL;DR: Single-tenant SaaS in identity security behaves much like hosted on-prem software, with manual upgrades, downtime, and slower feature adoption, while multi-tenant SaaS gives customers shared code and faster access to fixes and automation, according to SailPoint. The practical issue is not deployment preference but whether the operating model preserves agility, continuity, and control.
Editorial analysis by NHI Mgmt Group, based on content published by SailPoint: “Multi-tenant SaaS vs. single-tenant SaaS: It matters”.
Key questions
Q: What breaks when identity security SaaS still needs manual upgrades?
A: The main break is operational continuity.
Q: Why does multi-tenant SaaS often reduce governance friction in identity programmes?
A: Multi-tenant SaaS reduces governance friction because fixes, feature updates, and automation improvements reach all customers through the same codebase.
Q: What are the signs that a cloud identity platform is not true SaaS?
A: Frequent upgrade tickets, planned downtime, customers sitting on different versions, and long delays before new capabilities are available are all signs.
Practitioner guidance
- Define the tenancy model precisely Document whether the platform is truly multi-tenant, single-tenant, or merely cloud-hosted software, and tie that classification to upgrade responsibility, downtime expectations, and version consistency.
- Assess release cadence and downtime Ask how often new capabilities arrive, whether upgrades are customer-coordinated, and what operational interruption the identity team must plan for when patches or features ship.
- Limit customisation debt Prefer workflows, forms, notifications, and other configuration paths over bespoke code so future upgrades do not require rework every time the platform changes.
Bottom line: Single-tenant SaaS for identity security often shifts upgrade responsibility, downtime, and version management back to the customer.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 5:54 pm
The real SaaS test in identity security is operational ownership, not deployment branding: if the customer must schedule upgrades, absorb downtime, and track versions manually, the model has already drifted away from the promise of SaaS. That pattern shifts burden back to the buyer and makes identity governance improvements dependent on release projects rather than product cadence. Practitioners should evaluate who truly owns change management before accepting the cloud label.
A few things that frame the scale:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
A question worth separating out:
Q: When should IAM teams prefer configurability over custom code?
A: Whenever the business process can be met with workflows, forms, notifications, or policy settings rather than bespoke extensions. Configurability preserves upgrade paths, keeps the platform on a common release track, and prevents the rework that customisation creates every time the product changes.
👉 Read our full editorial: Multi-tenant SaaS vs. single-tenant SaaS in identity security