SoD is outgrowing classic SAP. Here is what we built for it.

How access actually works in SAP BTP

In classic SAP, a person's rights come from roles that bundle transactions and authorization objects. In SAP BTP the building blocks are different - and understanding them is the whole game. Authorizations in a BTP subaccount are managed by XSUAA, and they form a chain:

A user is assigned one or more role collections - the unit an administrator actually hands out, loosely comparable to a composite role. A role collection contains roles (instances of role templates that live inside an application). Each role grants a set of scopes - and the scope is where the real permission sits.

A scope is a string of the form xsappname.object.path.verb. It is not a transaction - it is a verb on a resource path, published by an application's API. For example, aicore!b164.scenarios.batches.write breaks down as:

So the unit of access in BTP is an API-level permission - "may write batches in this app" - not "may run transaction X". That single difference is why the traditional lens struggles.

Why the tcode / Fiori-object model doesn't fit

For twenty years, Segregation of Duties in SAP meant transactions and authorization objects: a conflict is a pair of transactions one person should never hold together, and the rule engines were built entirely around that shape. A Fiori app doesn't change the underlying model either - it still resolves down to catalogs, transaction codes and the same authorization objects.

BTP has none of those anchors. There is no transaction code, no S_TCODE, no dynpro authorization object to match on. The unit is a scope - an app-native string describing a verb on a resource. A transaction-bound engine has literally nothing to grab: its entire vocabulary (transaction, authorization object, activity) does not exist on this surface.

So the classic approach has two options - ignore BTP altogether, or force each scope into a transaction shape it was never in. Which brings us to the workaround.

When you have to disguise a scope as a transaction

The common way to bring BTP into a transaction-bound engine is to make the scope look like a transaction. Excellent engineering has been published doing exactly that: a custom adapter maps XSUAA users, role collections, roles and scopes into the engine's structures, and - because the engine's action-level analysis only recognises a hardcoded whitelist of resource types (SAP transactions, services) - emits a second, shadow row that dresses each scope up as a transaction so the analysis can see it at all.

It works, and it is clever. But the shadow row is the tell: the engine was never designed to reason about anything that isn't an SAP transaction, so every new access model has to be translated back into one.

An entitlement-model-agnostic SoD engine

smartGRC starts from a different assumption. Its risk engine is not wired to SAP transaction codes - it reasons about entitlements generically: an object and an activity, whatever system they came from. That single design choice is what makes the rest clean:

A BTP scope maps to a native entitlement, not a costumed transaction. An SAP transaction is one kind of entitlement; an XSUAA scope is another; a non-SAP permission is a third. They sit side by side in the same analysis - so a Segregation of Duties conflict can span BTP × SAP × non-SAP in a single rule. That hybrid conflict - for example, someone who can administer the BTP application that feeds a process and approve the outcome in S/4HANA - is exactly the kind an estate-spanning SoD picture needs, and exactly the kind a transaction-only engine struggles to express.

No shadow rows. No whitelist to satisfy. The scope is first-class because the engine was built to be.

Two tools, two shapes of the problem

To be fair to Access Control: this isn't AC done wrong, it is AC asked to do something outside its shape. SAP GRC AC is a full governance suite - request, approve, provision, analyse and audit - deeply wired into classic SAP. For the classic SAP request-to-audit lifecycle it is mature and hard to beat, and that breadth is real.

smartGRC is deliberately narrower and differently built: a focused, model-agnostic SoD engine. Where the two overlap - analysing access for Segregation of Duties across a modern, hybrid, increasingly non-SAP estate - the design choices pull apart:

The honest line: if the job is the end-to-end SAP request-to-audit lifecycle on classic SAP, AC is a heavyweight for a reason. If the job is Segregation of Duties across a hybrid estate - done lightly, without disguising every new surface as a transaction - smartGRC is built for that shape.

GET /Users?filter=userName eq "..." and origin eq "..."   (SCIM)   -> user + groups[]
GET /Groups?attributes=id,displayName                     (SCIM)   -> role collections
GET /sap/rest/authorization/v2/rolecollections/<name>               -> role_references[]
GET /sap/rest/authorization/v2/apps/<app>/roletemplates/<t>/roles/<r> -> scopes[].name

aicore!b164.scenarios.batches.write
   object   = aicore!b164.scenarios.batches
   activity = write

Three problems - and only the middle one is the moat

Everything above makes it sound like a connector story. It isn't. Bringing BTP into Segregation of Duties splits into three problems, and they are not equal: two are engineering, one is judgement. The middle one is where the advantage actually lives.

The connector is table stakes and the reporting is already ours. The scarce thing is knowing which BTP entitlement combinations are worth flagging in the first place - a ruleset that reflects how BTP actually grants power, not a translation of an SAP one. That is content, not code, and it is the part that has to be earned rather than shipped.

So what does "toxic on BTP" actually look like? Three illustrative conflicts a BTP-aware ruleset would carry - types worth defining, not a shipped rule pack. None of them exists in a transaction-based ruleset, because none of them is a transaction.

These are the conflicts that decide whether BTP SoD is real or theatre. Writing them well takes someone who knows how BTP grants power - which is precisely why the ruleset, not the connector, is where the value concentrates.

The same model covers service and AI identities

XSUAA does not only issue tokens to people. Client-credentials bindings authenticate application-to-application - the service accounts and AI agents that call BTP APIs. Because smartGRC treats non-human identities the same way it treats users - SoD analysis, sensitive-access flagging, and continuous monitoring on the accounts, not just the humans - BTP scopes and AI/service identities are the same frontier, handled by the same model. The SAP Audit Log gives the activity trail to close the loop.

It is an engine that treats an SAP transaction, a BTP scope, and a non-SAP entitlement as what they are - first-class, side by side, in one hybrid analysis. That is the bet smartGRC is built on.

Related reading