Business-critical IAM is moving off SaaS for control and resilience

At a glance

What this is: This is an independent analysis of why regulated enterprises are reclassifying IAM as business-critical infrastructure and moving it out of default SaaS assumptions.

Why it matters: It matters because IAM availability, jurisdiction, key control, and runtime access decisions now sit inside the same governance boundary as the systems they protect across NHI, autonomous, and human identity programmes.

👉 Read Curity's analysis of why business-critical IAM is moving off SaaS

Context

Business-critical IAM is not just another hosting preference. It is the question of whether the control plane for access should sit inside the same operating boundary as the crown-jewel systems it governs, especially when outages, jurisdiction, and key custody can directly affect business continuity.

The article frames this shift around four pressures: IdP concentration risk, per-identity pricing at enterprise scale, regulatory obligations under DORA and NIS2, and AI agents that need real-time access control. For identity programmes, that means deployment architecture, governance, and resilience can no longer be separated cleanly.

The first paragraph is about a security and governance line being redrawn, not a retreat from cloud. That distinction matters because many enterprises now accept SaaS for business-operational systems while treating IAM as infrastructure that must be controlled more tightly than the workloads it authorises.

Key questions

Q: How should IAM teams evaluate single-tenant SaaS for identity security?

A: IAM teams should treat single-tenant SaaS as a deployment model with customer-owned operational burden, not as equivalent to shared-code SaaS. The key questions are who performs upgrades, how long the environment stays on an older version, and whether downtime affects identity controls. If those answers create maintenance drag, the model may undermine governance consistency.

Q: Why does an identity provider outage become a business outage so quickly?

A: Because the identity layer gates authentication, federation, and token validation for everything downstream. If that service cannot issue or verify access, the applications may still be healthy but remain unreachable to users and systems. The operational effect is immediate, which is why identity resilience has to be treated as business continuity, not only platform reliability.

Q: What are the main risks of treating IAM as an ordinary SaaS application?

A: The biggest risks are concentration, jurisdiction, and loss of control over the access boundary. A shared provider outage can halt access across many systems, a provider breach can widen the blast radius, and a multi-tenant model can make regulator-facing assurances harder to defend. IAM is not ordinary application software because it defines who can reach every other system.

Q: How should organizations manage the identity risks associated with AI agents?

A: Organizations should enhance visibility into AI agents by incorporating robust monitoring and evaluation processes within their IAM frameworks. Regularly reviewing access rights and implementing stringent access controls will help mitigate risks and ensure IAM strategies align with evolving technologies.

Technical breakdown

Why business-critical IAM changes the deployment model

IAM is the control plane for authentication, token issuance, federation, and authorisation. When that plane is delivered as shared SaaS, the organisation inherits a dependency on external availability, external jurisdiction, and external operating decisions. Modern self-hosted IAM changes the failure domain by running in the customer’s own cloud tenancy, using customer-controlled keys, and integrating with standard release pipelines. That does not eliminate operational burden, but it does separate operational convenience from control over the access boundary.

Practical implication: Classify IAM as a tier-one control plane and decide whether the failure domain must remain inside your tenancy.

How IdP outages and breaches become business continuity events

Identity provider outages are not ordinary application incidents because they stop downstream systems from being reachable even when those systems are healthy. If tokens cannot be minted, validated, or refreshed, access collapses across every service that trusts the IdP. The same logic applies to a compromised identity platform: if an attacker can mint valid credentials, the blast radius extends to every trusting application. In other words, identity availability and identity integrity are both business-critical properties, not backend details.

Practical implication: Treat identity platform resilience, recovery, and isolation as board-reportable continuity controls.

Why AI agents turn access decisions into real-time infrastructure

AI agents change the timing and frequency of access decisions. Instead of a human logging in periodically, the system may need to grant, scope, and revoke privileges during autonomous runtime action at microsecond or second-level speed. That pushes access controls closer to real-time infrastructure and makes static per-identity pricing and slow governance cycles harder to justify. The operational question is no longer only who can authenticate, but how dynamic authorisation follows agent behaviour as it unfolds.

Practical implication: Model AI agent access as ephemeral runtime authorisation, not as a normal user licensing problem.

Threat narrative

Attacker objective: The objective is to disable or subvert the access layer so the attacker can interrupt business operations or move through all systems that trust the identity provider.

1. Entry occurs when a shared identity service or its supporting control plane becomes unavailable or compromised, blocking downstream authentication and federation.
2. Escalation follows when a validly minted token or credential is abused to expand reach across services that trust the same identity boundary.
3. Impact is broad because every application that depends on that access plane inherits the outage or the compromise at once.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Business-critical IAM is now a control-plane governance problem, not a hosting debate. The article is really about which systems the enterprise will not permit a third party to operate, and identity sits at the top of that list because it governs access to everything else. That makes deployment control part of the security model, not an implementation preference.

Identity provider concentration risk has crossed from architecture concern into resilience policy. Once an organisation depends on one external access layer for authentication, federation, and token issuance, an outage becomes a business stoppage and a compromise becomes a trust cascade. This is why the conversation has moved from feature comparison to continuity accountability.

Access layer ownership changes the evidentiary quality of security operations. Running the identity service yourself gives depth into issued, refreshed, exchanged, and revoked tokens that multi-tenant providers cannot match for your environment. That does not mean every organisation must self-host, but it does mean the security value of token-level telemetry is now part of the deployment decision.

Token intelligence is the right concept for access-plane visibility. The article points to a named capability that comes from operating the token service where refresh patterns, scope escalation, and anomalous contexts can be observed directly. That concept matters because identity telemetry is only useful when it aligns with the runtime boundary that issues the token.

Regulated enterprises are reassessing SaaS not because cloud failed, but because accountability did. DORA and NIS2 push third-party concentration, jurisdiction, and oversight into formal obligations, which means IAM deployment is now something management must be able to justify. The practical conclusion is that identity architecture has become an auditable governance choice.

From our research:

• 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to The 2024 Non-Human Identity Security Report.
• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, which shows the maturity gap is still structural.
• A practical next read is Ultimate Guide to NHIs, which helps teams connect access governance, lifecycle control, and workload identity decisions.

What this signals

Business-critical IAM programmes now need a formal line between systems the enterprise can outsource and systems it must control directly. That line should be written into architecture review, vendor review, and continuity planning, because identity is the dependency that turns a local outage into enterprise-wide denial of access.

Token intelligence: access-plane telemetry becomes materially more useful when the organisation controls the token service and can see refresh, exchange, revocation, and scope anomalies in context. That changes how teams investigate identity risk and how they justify deployment choices in regulated environments.

For identity leaders, the practical signal is that SaaS versus self-hosted is no longer a binary preference question. It is a portfolio decision about jurisdiction, resilience, auditability, and the speed at which access must change for humans, machines, and AI agents.

For practitioners

• Define a business-critical IAM boundary Write down which identity services must remain inside your controlled tenancy because their outage would stop core operations or create unacceptable concentration risk.
• Map IAM dependencies to continuity risk Document which customer-facing and internal systems fail if your IdP, federation service, or token service is unavailable for one hour or one day.
• Test deployment control against regulatory obligations Review whether DORA, NIS2, and jurisdictional data requirements can be satisfied when signing keys, token traffic, and customer identity data are handled by a third party.
• Rework access for AI agents as runtime infrastructure Assign agents short-lived, tightly scoped access that can be revoked immediately when scope drift or unexpected token use appears in your environment.

Key takeaways

• IAM is being recast as business-critical infrastructure because outages, jurisdiction, and key custody now affect core access continuity.
• The control plane that issues and validates access has become part of the business continuity model, not just the IAM stack.
• Enterprises need a written boundary for what they will and will not outsource in identity, especially where AI agents and regulated workloads are involved.

Key terms

• Business-critical IAM: Identity and access management that directly protects systems the organisation cannot afford to lose. The distinction is operational, not marketing: if the identity layer fails, regulated services, customer access, or core transactions fail with it.
• Token Intelligence: Token intelligence is the practice of issuing credentials with explicit meaning about who is acting, who they represent, and what is allowed. For NHI governance, it turns tokens from generic access artifacts into policy-bearing controls that support tighter, more traceable authorization.
• Identity concentration risk: The exposure created when too many applications depend on one external identity control plane. A breach, outage, or jurisdiction problem in that plane can cascade across every downstream system that trusts it.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full article

Curity's full blog covers the operational detail this post intentionally leaves for the source:

• How the self-hosted runtime is containerized inside a customer cloud tenancy and integrated into existing release pipelines
• What standards support and authorisation capabilities are exposed for OAuth, OpenID Connect, FAPI, and token exchange use cases
• How token intelligence is derived from refresh, exchange, revocation, and scope patterns in the operated environment
• What practical questions enterprises should ask about release cadence, version currency, and deployment control

👉 The full Curity post covers deployment control, token intelligence, and the board-level trade-offs behind self-hosted IAM.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.