Reclaiming the Control Plane: Why Business-Critical IAM Isn't a SaaS Job

Three years ago, the opening question in most product evaluations was which platform to buy. Okta or Entra, Ping or ForgeRock. Deployment barely came up because the answer was assumed. It would be SaaS, because everything was SaaS.

Anyone who went the other way was met with another assumption: having a legacy problem they hadn't got around to solving yet. Hosting your identity and access management infrastructure yourself meant operating it somehow, and from the outside this looked hard.

It’s 2026; the AI race is officially on. But are leaders of heavily regulated large enterprise organizations and national government digital programs looking at SaaS the same way? We can date the answer to this question from our own pipeline. In regulated sectors and among organizations where trust is the business, the first questions on the call are now different ones:

• Where does this run?

• Who holds the signing keys?

• Can we ensure that customer identity data never leaves our jurisdiction?

And most importantly:

Do we have business continuity when the backend infrastructure experiences an outage?

These are not the questions of organizations resisting modern architecture. Quite the opposite. They come from teams—banks, insurers, payment providers, telcos, health providers, energy and utility operators, public sector bodies, and even large retailers—that have thought carefully about what they can afford to hand over to a 3rd party. In most cases, they conclude that access to Crown Jewel apps is absolutely not on that list.

But the evaluation frameworks have not caught up. In most of them, SaaS delivery still sits where it has sat for a decade as an entry requirement rather than as one of the things you are supposed to be deciding.

Why enterprises are moving IAM off SaaS: four drivers

Four things happened at roughly the same time, and each one moved a different part of the decision. Together they turned the default SaaS model from a shortcut into an accountability question.

1. IdP outages exposed concentration risk

Incidents like the 2023 Okta support-system breach and periodic outages at major identity providers have taught the industry the same lesson: how many of our systems stop working if this happens to us?. Every one of those incidents produced the same board-level question inside customer organizations: how many of our systems stop working if this happens to us? For most enterprises, the honest answer was "all of them." 

2. Per-identity pricing broke at enterprise scale

Per-identity and per-monthly-active-user models are reasonable at thousands or tens of thousands of identities and punishing at a million. Organizations that grew into those tiers discovered that their IAM cost curve had become a strategic constraint on their own growth. A large share of the deals we see start with a renewal quote rather than a technical requirement. Someone opens a document, finds a number that has tripled, and starts looking for an architecture where cost is tied to what they actually get value from.

3. DORA and NIS2 made third-party risk a legal obligation

DORA became enforceable in January 2025 and moved third-party concentration risk from good practice to obligation. NIS2 comes at it from a different angle, extending supply chain security obligations across essential sectors and putting personal accountability on the management body for approving and overseeing them. Data control requirements across the public sector and the defense supply chain add a second layer that a shared-tenancy platform in another jurisdiction struggles to satisfy. The conversations we are in now often start with a specific clause and a specific auditor, not with a feature list.

4. AI agents turned access into real-time infrastructure 

Machine identities have outnumbered human ones and generate millions of automated API requests. Access decisions that used to gate a periodic human login now gate autonomous action at microsecond speed. That makes per-user pricing unsustainable, and it turns the access engine into even more critical real-time infrastructure. This is the newest of the four in our conversations and the fastest growing. Teams are asking:

• how an agent gets a token

• what that token is allowed to do on a customer's behalf, 

• how it is scoped down 

• how it is revoked in the ninety seconds after something goes wrong.

None of these four is decisive alone. Together they moved deployment from an implementation detail to a question the board has an opinion about.

Enterprises are not rejecting SaaS, they are prioritizing

The most common misreading of this shift is that it represents a full retreat from the cloud. But the truth is that the enterprises having these conversations are not repatriating commoditized SaaS and they have no intention of doing so.

What they are doing is prioritizing business operational vs. business critical. 

The former are supporting systems. If the vendor has a bad week, the business has an inconvenient week. SaaS is the obvious answer here and remains so.

The latter constitute the systems the business would not survive losing. Core transaction processing. Customer data. The systems that constitute the actual product. For these, the calculus is different and control over their continuity is a CEO problem.

This prioritization is relatively new. For a decade the default was to cloud-shift everything possible; then deal with the exceptions. Now organizations start from the question of which systems they would accept running a 3rd party operational model and work outward from there.

Access is the critical infrastructure that can't be outsourced

IAM is not an application, among others. It is the control plane over all of them and that is what determines which pile it falls into.

If you are a digital business and your identity provider is unavailable, your customers cannot gain access and business stops. Every downstream application may be perfectly healthy and yet entirely unreachable. Availability of the access layer is availability of the business.

If your business model is ‘trust’ but your identity provider is compromised, the blast radius is every system that trusts its tokens and credentials, and the casualty is your business. An attacker who can mint valid credentials does not need to breach anything else. 

Organizations that work through this reasoning tend to arrive in the same place. If a system is business critical, then the thing that controls access to it belongs there too. Placing crown-jewel applications under strict deployment control while running access from a shared multi-tenant service in another jurisdiction is not a coherent position, and enterprise leaders operating in regulated industries know this.

This is the position Curity has held since we started and it is the reason the product only ships one way. Curity’s Access Intelligence offering runs in the environment of your choice, under your control, with your keys. We do not operate a multi-tenant service that your customers use for access because we think that is the wrong place for the control plane to sit.

Self-hosted is not what it was

The strongest objection to all of this is a fair one. Self-hosted IAM carries a reputation earned over years of on-premises deployments that were painful to run, slow to update, and staffed by a team that could not take holidays at the same time. Operational burden and deployment control were bundled together for so long that evaluation frameworks stopped treating them as separate variables. They have since come apart.

A modern deployment runs in the customer's own cloud tenancy, is containerized, is integrated into existing pipelines, and is upgraded on a standard release cadence, with configuration held as code. Jurisdiction, tenancy, keys, and data stay with the customer. In practice, this looks like any other tier-one workload. Deployment control is not a hosting preference. It is an architectural fact with consequences you can point a regulator at:

• Signing keys are generated in your HSM and never leave it with FIPS 140-3 validated cryptography, where the certification matters. 

• Tokens are issued by a service you operate, with claims assembled from your data sources. 

• Authentication traffic terminates inside your boundary, so there is no third party sitting between your customers and their accounts and no shared control plane.

That leaves three questions worth putting to any vendor arguing this position, us included.

What is the release cadence, and what share of the installed base is actually running current versions? 

Slow-moving self-hosted software is a real failure mode, and the answer should be specific.

How does the product compare on standards support and authorization capability when tested against your requirements rather than against release-note volume, which favours SaaS by construction?

Ask for OAuth, OpenID Connect and FAPI conformance, token exchange, and how delegated and machine-to-machine access is modelled, then test it against your own use cases.

And what replaces the threat signal that a multi-tenant operator gets from seeing everyone's traffic?

That last one is a real difference and deserves a proper answer. A multi-tenant operator sees breadth across everyone's traffic and very little depth into yours. Running the access layer yourself inverts that. Every token issued, refreshed, exchanged, and revoked in your environment is data about your environment. Anomalous refresh patterns. Tokens presented from an unexpected context. Scope escalation across services. Agents behaving unlike the agents they were issued for. This is what we mean by Token Intelligence, and it is only available to someone who holds the token service. Breadth is useful, but depth is what tells you that this session, on this account, right now, is not what it claims to be.

The question every enterprise should be asking

The useful exercise here is not choosing a deployment model but making a very specific list: which of your systems would you accept a third-party operating and which would you not? Most enterprises have never written that list down. But the organizations moving fastest right now are the ones that have because once the list exists, the deployment questions mostly answer themselves.

There is a window for this, and it is a narrow one. Teams facing the end-of-support of their existing solution, or an open-source deployment that two people understand and nobody has time to upgrade, or a renewal quote that no longer bears any relation to the value delivered, are all making a decision they will live with for the next decade. That is the right moment to make the list rather than inherit someone else's.

When you make it, identity and access sit at the very top. Because if you don't control the access layer, you don't actually control the crown jewels.