Topic starter
14/09/2026 10:09 am
TL;DR: Enterprises are increasingly separating business operational systems from business-critical ones, and Curity argues IAM now belongs in the latter category because IdP outages, per-identity pricing, regulatory obligations, and AI agents have turned deployment control into a board-level issue. The core shift is that access is now critical infrastructure, and the assumptions behind shared multi-tenant delivery no longer fit crown-jewel identity control.
Editorial analysis by NHI Mgmt Group, based on content published by Curity: “Reclaiming the Control Plane: Why Business-Critical IAM Isn't a SaaS Job”.
Key questions
Q: How should security teams decide which IAM systems must stay under direct control?
A: Use business criticality, continuity, jurisdiction, and key custody as the decision criteria.
Q: Why do outages and provider concentration risk change IAM governance?
A: Because if the identity provider fails, every downstream application that trusts it can fail with it.
Q: What breaks when IAM pricing is tied to users rather than access events?
A: Per-user pricing breaks down when identities are machine-driven, agent-driven, or scale into the millions.
Practitioner guidance
- Define which systems cannot tolerate third-party operated IAM Create an explicit list of crown-jewel applications, customer identity paths, and regulated services that require direct control over the access layer.
- Separate business-critical from business-operational workloads Use continuity, jurisdiction, and key custody as the criteria for deciding whether IAM can sit in a shared SaaS model or must run in your tenancy.
- Test IAM against machine and agent access patterns Validate whether token issuance, scoping, and revocation still work when access is consumed by non-human actors rather than interactive users.
Bottom line: IAM is increasingly judged as a business-critical control plane rather than a default SaaS workload.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:10 am
Deployment control has become an identity governance decision, not a hosting preference. IAM now sits inside the business-critical category because the access layer determines whether crown-jewel systems are reachable at all. When availability, jurisdiction, and key custody are part of the risk model, the old SaaS default stops being a neutral choice. Practitioners should evaluate IAM the way they evaluate other tier-one controls: by boundary, continuity, and accountability.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How do regulatory requirements affect where IAM should run?
A: Regulations such as DORA and NIS2 make supplier concentration, oversight, and continuity part of the governance decision. If the access layer is critical to operations, the organisation has to be able to explain who controls it, where it runs, and how it stays available during disruption.
👉 Read our full editorial: Business-critical IAM is moving off SaaS for control and resilience