I need to make a confession. A few years ago, I was firmly in the “buy, do not build” camp for Identity and Access Management (IAM). I was the architect for a private SaaS vendor solution that met all requirements and even addressed data sovereignty concerns. SaaS IAM delivered the results– with fewer servers to patch, fewer midnight alerts, and easier access for customer understanding and success.
Since then, my perspective has shifted. Of course, SaaS vendors didn’t suddenly get worse. But as AI transforms the identity ecosystem, we need an approach better suited to its continued evolution.
In the current security landscape, identity is not a passive login screen. It’s the control hub for every action in the enterprise: data access, raising privileges, API permissions, machine-to-machine trust, session risk, and, increasingly, the governance of semi-autonomous AI. In 2026, identity drives the system.
With identity now in the driver’s seat, it’s time to repatriate IAM with an awareness of the risks and a willingness to address them. I know “repatriation” can sound like giving up, but IAM repatriation is not a step backward. This is not a call to "kill the cloud," turn off SaaS, or pull everything back into the data center. Instead, it’s a call for clarity about the risks that happen when your identity control plane is both mission-critical and externally rate-limited. Ultimately, repatriation is a move toward resilience, agility, cost predictability, and security at AI scale.
While it might sound like a step backward, IAM repatriation has potential to:
Within a repatriation approach, there is still a place for SaaS, leveraging it in places like user lifecycle workflows, while moving parts that must be deterministic, scalable, and always available to your repatriated Identity system. This flexible approach is ideal because fraud networks work best when the reach of SaaS services can be combined to better evaluate signals.
To fully grasp the value of repatriation, you must understand the game-changing impact of AI. AI adds a whole new class of actors to the environment:
Traditional IAM models were built on a series of assumptions:
AI upends those assumptions with:
Even if the AI agent is just another service account, the rate and fan-out of access checks multiplies. A single user prompt can start dozens or even hundreds of backend calls. When the AI agent does that across teams, the IAM system ceases to be a directory and becomes a high‑throughput transaction platform.
This reality complicates scalability. Many SaaS IAM discussions focus on availability, noting vendor outages that are real and painful. But those outages can’t compare to the scalability needs created by this new age of identity.
When IAM is SaaS hosted, you inherit the constraints. Those constraints are often fine, until…
At AI scale, IAM must be able to keep high-volume operations running without compromising security. But, in practice, rate limits push people into choices like:
When identity bottlenecks, engineering teams route around it, acting as humans do under pressure
Many SaaS IAM vendors charge enterprises by:
AI workloads upset the events side of the equation—issuance, self-checks, policy checks, step‑up challenges, device posture, anomaly detection, and logging. Even if the initial unit cost seems small, the total can become a bloated line item prompting everyone to look for ways to bypass costs. Unfortunately, a bypass like turning off controls weakens the whole system.
In order to resolve the latency challenge, we must consider:
Authorization affects application performance, with service-to-service calls routed through a SaaS decision point adding delay. If developers avoid these calls because of a slow SaaS decision point, the system loses enforcement. Neither lost performance nor lost enforcement is acceptable.
Even the best SaaS vendors operate multi-tenant platforms with shared risk. In these platforms, global incidents affect customers regularly, while platform-wide policy changes, deprecations, or behavior shifts affect everyone unequally. As for regional dependencies and cross-zone propagation delays, those are outside of your control.
The model has to work this way, but when IAM is the control plane, “shared fate” is a much bigger deal than “fate” was when the SaaS tool was only for expense reporting.
This entire blog may feel like “the bad news.” But even in an uncertain identity landscape characterized by rapid evolution and new risks, there’s reason for hope. That hope requires revisiting what we think we know. Hang tight for “the good news,” with actionable suggestions coming in Part 2 of this multi-part series. In that blog, we’ll explore vendor risk and give you some informed suggestions on the very best sequence for repatriating IAM while reducing risk.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。