Identity is no longer about granting rights. It should help the business move forward and decide.
For a long time, IAM mostly aimed at automating IT operations. That evolution actually mirrors a much broader transformation of the role of IT in the enterprise.
IT was long seen primarily as a cost centre to optimise. Organisations gradually understood that it could also accelerate the business, reduce time-to-market, enable new services and produce data useful for decision-making.
IAM follows exactly the same path. Ariovis therefore does not build its strategy from a vendor catalogue: we choose technologies because we believe in their place in the evolution of the IAM market.
The IAM market moves extremely fast. This page is our architects' reading, as of August 2026.
The boundaries between IGA, Access Management, fine-grained authorization, PAM, machine identities and AI agents may still shift significantly. Ariovis follows these transformations closely and will update this reading with them.
Three generations of value have followed one another in enterprise IT. IAM followed them, almost step by step.
Industrialise and reduce costs
How do we automate what IT does manually?
This first generation of IAM reflects the historical view of IT as a spending line to optimise.
Accelerate the business
How does identity help business teams move faster?
As IT becomes a business accelerator, IAM stops being only a tool operated by IT: it becomes a service consumed by the business.
Steer risk and decide better
How does identity support a better decision?
The parallel with business intelligence is direct: the information system no longer only executes, it also produces the information needed to decide.
Netwrix Identity Manager — historically Usercube — holds a particular place in our reading of the market.
For Ariovis, v5 is a major turning point: Usercube started extremely early on a transformation that many established IGA vendors had to undertake, or still have to: dealing with the architectural debt required to become SaaS.
The key point is not merely that "Usercube can run in the Cloud". The key point is that the vendor addressed its architecture early enough to become SaaS without sacrificing its on-premises model.
Today, Netwrix Identity Manager retains both SaaS and on-premises options. For Ariovis this is extraordinarily important: it lets an organisation change its hosting strategy without necessarily having to change IAM product.
Usercube's achievement is not simply that it became SaaS. It is that it became SaaS without condemning on-premises.
Among the IGA platforms we follow, Ariovis sees this SaaS / on-premises continuity as exceptionally differentiating. We promise no magical or transparent migration: real reversibility is demonstrated project by project.
Netwrix Identity Manager is today Ariovis' preferred solution for identity governance.
Historically, access management was quickly summarised in three blocks: authentication, SSO, MFA.
Today, SaaS, mobile applications, partners, customers, APIs, federation, adaptive authentication, session management and CIAM make identity the direct path to the company's services.
Access management has therefore become a business-critical infrastructure: when it goes down, it is not IT that stops, it is the business.
A good access management platform should make its complexity invisible to users without making it disappear for the architect.
The Ping / ForgeRock combination is a very interesting market trajectory: the platform is progressively broadening its identity footprint.
Our architect's caveat comes immediately: a platform broadening its functional coverage does not necessarily have to make every identity decision. That is precisely the debate of the next chapter.
Both worlds are moving closer functionally. Their architectural constraints remain deeply different.
More granularity → more context → more dynamism → more runtime
A meeting zone?
More policy lifecycle → more governance → more audit → more identity and organisational context
An IGA platform must represent the reality of the organisation, with rich business interfaces: managers, application owners, IAM teams, audit and security must all be able to work with it.
It mostly works on long time frames: joining, mobility, requests, certification, reconciliation, recalculation. It is perfectly compatible with a Web and SaaS logic.
A fine-grained authorization engine answers a different question: can this identity perform this action, on this resource, with this context, now?
It sits directly in the execution path. Its latency budget is therefore extremely low. It needs immediately usable policies and attributes — not to become a huge business application in order to return a decision.
IGA is the control tower. FGA sits as close as possible to the engine.
An IGA platform can add a "runtime authorization" capability. The architect then has to ask the real questions:
Functional convergence does not make the physics of a distributed system disappear.
Saviynt is a major, innovative player, and its evolution makes visible exactly the question we are asking about the market. With Agent Access Gateway, the vendor adds a capability designed to control certain actions at runtime, in particular those of AI agents.
We follow this module attentively, but that does not mean we are convinced by the convergence goal itself. It is a very interesting architectural experiment to observe, and it immediately raises the question of trade-offs.
Organisations that historically choose Saviynt are looking for a SaaS IGA platform: modern, functionally rich, with a strong user experience and governance cockpit, centralised, able to give a broad view of identity and access. That is exactly the control-tower logic described above — historically, it is not the same constraint as an authorization engine designed to sit in an application's runtime.
An IGA can live with a rich web interface, complex processing, workflows, calls to a remote SaaS, synchronisations and asynchronous jobs. A runtime authorization engine sits on the critical path of a transaction: the application waits for its decision before moving on. Its latency budget must stay extremely low, almost imperceptible. There is no universal figure — it depends on the architecture — but a few hundred milliseconds that are perfectly acceptable in some SaaS interactions become potentially problematic when added to every application decision.
The further a SaaS IGA platform moves down towards the runtime, the more it risks introducing components, caches and distributed mechanisms that take it away from the architectural simplicity that made the SaaS model attractive in the first place.
You choose a platform like Saviynt in part to get a clean, centralised SaaS control plane. But to make extremely fast decisions as close as possible to the applications, you may progressively have to push components back down into the infrastructure. That is exactly where our questions lie. Agent Access Gateway interests us above all because it makes visible the architectural trade-off the market will have to resolve. Today, Ariovis is more convinced by the complementarity of specialised technologies than by the search for a single platform able to absorb everything: an excellent IGA designed as a rich business control tower, and an excellent authorization engine designed from the start to decide fast in the runtime — rather than one platform forced to compromise on both architectures. This is our architects' conviction in August 2026, not a definitive truth: the market moves fast and we are watching Saviynt in particular to see how these constraints are actually resolved.
Today we would rather make two specialised architectures talk to each other extremely well than ask each of them to become the other.
Who is Matthieu? Which organisation does he work in? Which role does he hold? Who approved his access? Until when?
Can Matthieu perform this precise action on this precise resource, from this device, with this context and this level of risk, right now?
Why force the same platform to be simultaneously a rich governance business application and a minimalist, extremely fast engine placed on the critical path of every transaction?
The IGA knows that Matthieu holds a sales role. It knows why that role exists and who granted it.
But that does not necessarily answer: can Matthieu export 50,000 customer records from this device, in this context, right now? That is another problem.
The principle is simple. The PEP — application, API or gateway — intercepts the action and asks for a decision. The PDP evaluates identity, action, resource, context, attributes, risk and policy, then returns its decision.
An important authorization rule does not have to be re-coded and maintained independently in every application.
Our conviction is clear: we do not want Axiomatics to become an IGA. We want Axiomatics to be excellent at making a decision an IGA was historically not architected to make.
And conversely: Netwrix Identity Manager does not need to become Axiomatics in order to perfectly govern the identities, roles and attributes that decision relies on.
Axiomatics is Ariovis' preferred partner for fine-grained, dynamic authorization.
Three distinct responsibilities, three different moments. Information flows between the layers, but these platforms do not make the same decision.
These platforms do not necessarily make the same decision, and they do not act at the same moment. That is exactly what makes their complementarity interesting.
The first way to protect a privilege is not to grant it unnecessarily.
Depending on the use case, we work with Netwrix PAM / Privilege Secure and Keeper. These technologies serve an architecture, they do not replace one.
PAM complements a sound identity architecture. It replaces neither rights governance nor least privilege.
Our partnerships guide our expertise, not our diagnosis. Other platforms are perfectly legitimate depending on the context.
In a strongly Microsoft-first environment, Entra can be the best choice.
A sound Keycloak architecture can perfectly well be kept and extended.
Major platforms, followed by Ariovis and encountered at our customers.
Same logic: a mature, well-suited platform should not be replaced just to change partner.
A platform that is already relevant does not become bad because Ariovis has another preferred partner.
Our partnerships allow us:
But a partner is never an architectural conclusion.
Being a vendor partner gives us expertise. It must never take away our independence of judgement.
It could be an architecture in which:
Boundaries are shifting. Some functions will probably converge. Others may stay separate because of their architectural constraints.
Our job is not to predict which logo will end up absorbing which market. Our job is to build architectures today that can work, evolve and remain understandable once the market has changed again.
Security meets Business.
