Notifications
Clear all
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.
NHIMG editorial — based on content published by Curity: business-critical IAM is moving off SaaS
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Curity's analysis of why business-critical IAM is moving off SaaS →
Business-critical IAM off SaaS: what changes for security teams?
Explore further
14/09/2026 10:10 am
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.
A few things that frame the scale:
- 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 question worth separating out:
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.
👉 Read our full editorial: Business-critical IAM is moving off SaaS for control and resilience
