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.
At a glance
What this is: Curity’s analysis says IAM is shifting out of default SaaS delivery and into the business-critical category because resilience, regulation, economics, and agent access control now hinge on who operates the access layer.
Why it matters: IAM leaders now have to decide which systems can tolerate a third-party operating model and which require direct control over keys, tenancy, and continuity to protect crown-jewel access.
Context
Enterprises are no longer treating all SaaS the same. For IAM, the key question is whether the control plane for access can be outsourced without weakening continuity, jurisdictional control, or accountability.
That shift matters most in regulated environments and in businesses where identity and access are part of the product, because availability of the access layer is availability of the business.
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. If a loss of access would stop revenue, customer service, or regulated operations, IAM is part of the control plane, not a shared support service. That is the point where direct operational control becomes an architectural requirement rather than a preference.
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. Concentration risk turns access availability into business availability, so the question becomes how many systems stop when the provider has a bad week. That is a resilience and accountability problem, not just an infrastructure issue.
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. The model can make access governance look more expensive exactly when it becomes more operationally important. In practice, licence structure can push architecture choices that no longer match how access is actually consumed.
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.
Technical breakdown
Why IAM control plane placement matters
IAM is the control plane for authentication, token issuance, authorization, and revocation. If that control plane sits in a shared multi-tenant service, the organisation inherits the provider’s outage domain, trust boundary, and key-handling model. If it runs inside the customer’s own cloud tenancy, the security and resilience model changes materially because the organisation can align keys, traffic, and data handling with its own boundary. In practice, the architectural question is not SaaS versus on-premises. It is whether the access service is operated where the business can enforce continuity, jurisdiction, and oversight.
Practical implication: map IAM architecture to the same boundary decisions you apply to other tier-one workloads.
How real-time access changes the economics of identity
Agentic systems and machine identities move access from human-paced events to high-frequency runtime decisions. That makes per-user or per-active-user licensing a poor fit when the subject being governed is no longer a human login, but continuous token issuance and reuse by software. The technical shift is that authorization becomes a live service dependency rather than a periodic authentication checkpoint. In that model, pricing, token policy, and revocation behaviour all influence the feasibility of operating IAM at enterprise scale.
Practical implication: test whether your IAM operating model can support machine and agent access without distorting cost or control.
What deployment control changes about token intelligence
A locally operated access layer sees issuance, refresh, exchange, and revocation events in the customer’s own environment. That creates depth of visibility into anomalous token behaviour, such as unusual refresh patterns, scope escalation, or agent activity that does not match the intended session profile. Curity’s framing treats this as token intelligence, which depends on holding the service that issues and governs tokens. The architectural point is that control of the token service is also control of the best telemetry on how identity is being used.
Practical implication: treat token telemetry as an operating requirement, not a side effect of deployment choice.
NHI Mgmt Group analysis
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.
Per-identity pricing breaks when the subject of access is no longer only a person. AI agents and machine identities turn identity from a seat-based economic model into a runtime control problem. The real issue is not simply cost inflation, but that the pricing model can shape architecture in ways that no longer match how access is consumed. Practitioners need to separate commercial fit from governance fit before the licence model becomes a design constraint.
Third-party concentration risk has moved from resilience theory into compliance reality. DORA and NIS2 make outsourced control of critical access harder to justify in regulated environments, especially where management accountability extends to oversight of the supplier model. That creates a governance line that many evaluation frameworks still do not reflect. Practitioners should expect deployment control, not feature parity, to drive procurement decisions for critical IAM.
Token intelligence is the new control-plane advantage. The most useful identity telemetry is now the telemetry that sits closest to issuance, refresh, exchange, and revocation. That is why operating the access layer yourself changes more than support responsibility: it changes what you can observe about identity behaviour in real time. Practitioners should treat token-level visibility as a design goal when the identity plane underpins core business services.
Business-critical IAM requires a named concept: identity control-plane locality. The control plane must live where the business can enforce continuity, key custody, and jurisdictional rules without relying on a third party’s operating model. That concept explains why many enterprises are not abandoning SaaS broadly, but drawing a hard line around access infrastructure. Practitioners should classify IAM by the criticality of the systems it governs, not by vendor delivery habit.
From our research library:
- 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.
What this signals
Identity control-plane locality: enterprises are starting to treat the access layer as a workload boundary, not just an application dependency. That changes the governance conversation from feature comparison to continuity, tenancy, and key custody, which is where NHI and agentic access decisions become operationally material.
Token intelligence becomes more valuable when the organisation controls token issuance and revocation inside its own boundary. That matters for agent access, because runtime visibility is strongest at the point where credentials are minted and scoped, not after a downstream system has already consumed them.
For practitioners
- 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.
- Review regulatory obligations against deployment control Map DORA, NIS2, and internal risk ownership to the decisions around where the identity plane runs and who can intervene during an outage.
- Demand evidence of token-level visibility Ask how the platform exposes refresh anomalies, scope escalation, and revocation events when access is governed inside your own environment.
Key takeaways
- IAM is increasingly judged as a business-critical control plane rather than a default SaaS workload.
- The shift is being driven by outage risk, scale economics, regulatory pressure, and machine access patterns.
- Practitioners need explicit boundary decisions that separate what can be outsourced from what must stay under direct control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article focuses on access scope, control boundaries, and business-critical IAM governance. |
| NHI-04 — Insecure Authentication | The article discusses token issuance, revocation, and trust in the access layer. | |
| Recommendation — Review IAM deployment boundaries and reduce overbroad access paths that expand blast radius. Strengthen token governance so authentication and revocation remain under direct operational control. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Identity-provider compromise and token abuse can spread across trusted systems. |
| Recommendation — Hunt for token abuse patterns that enable credential access and lateral movement through trusted identity flows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about who controls access permissions and where that control lives. |
| Recommendation — Align access permissions and entitlements with the systems whose availability the business cannot lose. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token issuance, refresh, and revocation are central to the article’s identity-control argument. |
| Recommendation — Apply authenticator management controls to keep token lifecycle and revocation inside your boundary. | ||
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.
- Control-plane locality: The requirement that the management and decision-making layer of a platform stays inside the environment it is protecting. In sensitive deployments, locality matters because metadata, orchestration, and automation can be as sensitive as the data being scanned.
- 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.
- Third-party concentration risk: The risk that too many downstream systems depend on a single external provider for availability or trust. For IAM, concentration risk means an outage or compromise at the provider can cascade into broad business disruption across applications and users.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org