XSP IAM Connector:
Rethinking IAM Architecture

Why SAP IAM must be Reevaluated

Integrating SAP into modern identity and access management (IAM) landscapes has long been more than a technical detail. Hybrid system landscapes, cloud transformation, and regulatory requirements such as SOX, NIST CSF, or critical-infrastructure regulations demand traceable, end-to-end control over access risks – especially in business-critical SAP systems.

At the same time, many organizations are facing an architectural turning point: SAP Identity Management (SAP IDM) is being phased out (end of maintenance in 2027, extended maintenance until 2030). Modern IAM platforms such as SailPoint, Omada, or Saviynt reliably handle the identity lifecycle.

But one central question remains open:

Is provisioning alone enough to reliably control SAP-specific risks, SoD conflicts, and license impacts – before access is actually granted?

The Core Problem: Provisioning without SAP Context

Modern IAM systems fulfill their core tasks very reliably today. They manage identities, orchestrate joiner, mover, and leaver processes, control request and approval workflows, and automatically provision access into target systems.

What is often missing is the SAP-specific governance context before provisioning. That’s because risks in SAP don’t arise solely from simple role combinations, but from technical details such as:

IAM platforms, by contrast, work with abstract entitlements, role-based models, and generic rule sets. This abstraction makes sense for the identity lifecycle – but it is not enough to reliably assess the SAP-specific depth of risks and license impacts before access is granted.

Three underestimated Risks in the Direct-Provisioning Model

1

Missing Preventive Risk Analysis

When access is provisioned directly, without SAP-specific analysis, SoD conflicts can arise without being detected. In SAP, these risks are often tied to objects, field values, and transactions – not to simple role pairs.

2

Unclear License Changes

Even individual authorizations can change an identity’s SAP license type. Without an upfront license check, these effects remain invisible – with potentially significant extra costs.

3

Audit Gaps

Approvals are documented. What’s often missing, though:

  • Was the risk assessed in advance?
  • Was there a mitigation?
  • Who bears responsibility – and for how long?

Under tightening regulatory requirements in particular, this gap quickly becomes critical.

The missing Layer: Governance between IAM and SAP

The solution usually isn’t to replace existing IAM systems, but to complement them in a targeted way. This is exactly where the XSP IAM Connector comes in.

It implements a dedicated governance layer between IAM and SAP that takes effect before provisioning. SAP-specific logic – from authorization objects and field values through transactions to license impacts – is analyzed upfront. At the same time, the connector integrates seamlessly into existing IAM processes.

The IAM workflow is specifically enriched with:

  • preventive risk decisions
  • well-founded license assessments
  • traceable, auditable governance logic

without calling the IAM system’s leading role into question.

Architecture Principle: IAM remains leading – XSP takes over Governance

The XSP IAM Connector is a service on the Xiting Security Platform (XSP) and connects existing IAM solutions such as SailPoint, Omada, Saviynt, or EmpowerID with XSP’s SAP governance.

The division of responsibilities is deliberately kept clear:

  • IAM: identity lifecycle, requests, approvals, provisioning
  • XSP: SAP governance – analyze, assess, mitigate

Technically, the connector acts as an API-first orchestrator:

Request → IAM decision → XSP analysis → result → provisioning

The decisive advantage: no migration of the existing IAM landscape.

How the Workflow Works in Practice

  1. A user requests access in the IAM system.
  2. Managers or role owners approve as usual.
  3. The request is passed to XSP for SAP-specific analysis.
  4. Risks (SoD, critical authorizations) and possible license changes are analyzed across systems.
  5. The result flows back into IAM – with mitigation or additional approvals if needed.
  6. Provisioning is carried out automatically by the IAM system.

→ This means risk and license decisions are made before access is granted – not after the fact.

Why SAP Governance does not belong in IAM

IAM systems are built for identity lifecycle, workflows, and provisioning. SAP governance, however, is a distinct business and technical domain.

It requires:

  • a deep understanding of authorization objects and field values
  • cross-system risk aggregation
  • SAP-specific license logic

The XSP IAM Connector consistently separates these domains:

  • IAM = lifecycle
  • XSP = governance

This lets both worlds play to their strengths – without functional overload or architectural compromises.

Provisioning is solved – SAP Governance often is not

If you’re facing the replacement of SAP IDM, or want to integrate SAP governance preventively into your IAM processes, it’s worth taking a look at the XSP IAM Connector in practice.

Let’s schedule a demo and walk through your specific use cases →

Fabian Honervogt

Identity Governance and Administration
Manager

Conclusion: From Provisioning to accountable Control

Conventional IAM solution solve the provisioning problem, but the question of SAP governance remains open.

The XSP IAM Connector closes this gap in a targeted way through:

  • preventive SoD and risk analysis
  • transparent license assessment before access is granted
  • auditable decisions, including mitigation
  • integration into existing IAM processes without a system break

The result is an IAM architecture that not only works technically, but also remains accountable in the long run under governance and regulatory requirements.

FAQ

What is the XSP IAM Connector?

Our XSP IAM Connector is a service on the Xiting Security Platform (XSP) that adds SAP-specific governance to existing IAM solutions before provisioning – including risk analysis, license assessment, and mitigation

Conventional IAM connectors provision reliably, but they often don’t capture SAP-specific risks in enough depth (objects, field values, transactions) and usually don’t account for license logic.

Depending on process design, there are two options:

  • Mitigation within XSP, or
  • Returning it to the IAM system to extend the approval flow (additional approvals).

Identity lifecycle processes need to be migrated to a new IAM solution. SAP-specific governance is often not automatically covered in this process and requires a complementary approach.

Stay up to date.

Sign up for the newsletter to receive more information.

Follow @Xiting and @xiting.global on social media.

Melden Sie sich jetzt an!

Get in touch now!

Nehmen Sie jetzt Kontakt auf!