Don't be fooled: The SaaS label that's misleading your security team

I think 1 April is as good a day as any to ask whether your identity security vendor is playing a long con.

Intrigued? Find out more in this exclusive Q&A:

Q: Why are we talking about SaaS definitions on April Fools' Day?

Because the timing is apt. Every April, we celebrate the art of the convincing fake. The thing that looks entirely legitimate right up until the moment it isn't.

To me, that description fits a significant portion of what the enterprise software market currently sells as SaaS. The label has become so widely applied that it has gradually lost its meaning, and identity security is one of the areas where that gap between label and reality carries the most consequence.

Q: What's wrong with how SaaS is being marketed?

When I talk about true Software-as-a-Service, I mean a multi-tenant architecture: one codebase, shared infrastructure, logical data isolation. Updates are automatic and security enhancements land across the entire platform simultaneously. The vendor owns the operational burden, so the customer doesn't have to.

Yet what much of the market actually sells is a single-tenant hosted application. Each customer runs their own dedicated instance of the software, sitting in someone else's data centre. To me, it is, in essence, on-premise software with a new postcode.

From the outside, the two can look identical. From the inside, the experience is entirely different.

Q: What does that difference look like in practice?

I see single-tenant deployments requiring customers to manage their own upgrade cycles, test patches against their specific instance, commission bespoke integrations through custom code, and provision additional infrastructure when demand spikes.

Instead of offering cloud-native agility, it behaves more like a traditional IT project with the associated costs. It is not the licence fee that is the expensive part. The cost accumulates in the surrounding work: security teams managing deployment windows instead of reducing risk, engineers writing and maintaining custom code for integrations that should be handled by configuration, and upgrades slipping down the priority list because testing takes time and competing priorities are always more urgent.

Version drift sets in gradually. Months pass. Then years.

Q: Surely a dedicated instance is more secure, though? That's a common assumption.

It is a common assumption, but an incomplete one.

I believe security in a modern threat environment is not primarily about isolation. It is about speed of response, continuity of visibility, and the capacity to apply intelligence at scale. A true multi-tenant platform deploys security updates universally and immediately. It can train AI models on anonymised, aggregated data across its entire customer base, producing pattern recognition that no single organisation could generate alone.

A dedicated instance running a version from eighteen months ago because the upgrade was repeatedly deferred is not more secure. It is simply more exposed.

Q: When does this architectural gap cause the most damage?

At exactly the moments when speed matters most. When a critical vulnerability surfaces and the vendor cannot issue a universal fix because every customer environment has diverged. When your organisation has just acquired another company and needs to onboard thousands of identities quickly, only to find the platform requires manual infrastructure provisioning to handle the load. When a threat actor is already moving and your team is occupied scheduling a maintenance window.

These limitations rarely show up during procurement. They show up when something goes wrong.

Q: What should ANZ organisations be asking their vendors right now?

I would ask a few direct questions: Who owns patching and upgrade testing? How are security updates deployed across the customer base? What happens to our environment when you release a critical fix? What does scaling look like if we double our workforce or complete an acquisition?

If the honest answers involve your team scheduling maintenance windows and running regression tests against a dedicated instance, you are not consuming a service. You are managing a project.

Q: Final thought?

April Fools' Day is one day a year. A poorly architected identity platform is a longer commitment.

The ANZ market is navigating tightening privacy regulation, expanding machine identity estates, and increasingly AI-driven enterprise environments. In that context, identity architecture is not a procurement detail. It is the foundation your security posture is built on.

Do not let a label do the work that due diligence should.

This Q&A draws on SailPoint's whitepaper Not All SaaS is SaaS: A Decision-Maker's Guide to True Cloud Identity Security. The full architectural comparison, including evaluation criteria for CIOs and CISOs, is available here.