Try segregation of duties, SailPoint, or Oracle ERP Cloud access review.
SafePaaS governs segregation of duties, privileged access and configuration change inside SAP ECC and S/4HANA — reading your roles, profiles, authorization objects and transaction codes, and testing policy against them.
Inside SAP ECC and S/4HANA, not beside it — the same rule book that governs every other system you run.
| Area | Reads | Controls | Monitors |
|---|---|---|---|
| Access and SoD | Roles, composite roles, profiles, authorization objects, field values, transaction codes and user assignments | SoD rules at object and t-code level; request-time prevention; role simulation before a change is applied; FireFighter ID for emergency access | New conflicts introduced by a role change, expired assignments, and standing privilege such as SAP_ALL |
| Transaction and configuration | Posted documents, change documents (CDHDR / CDPOS), vendor and customer master data, tolerance groups and release strategies | Policy on the settings that control the money — payment terms, tolerance groups, company code settings | Duplicate payments, threshold splitting, bank-detail change followed by a payment run, and configuration drift from baseline |
| Audit, risk and compliance | Control test results, exceptions, approvals and the versioned SAP rule set | One SAP control mapped to SOX, ITGC and internal policy; exceptions with an owner and an expiry | Test status against each SAP control, and exceptions approaching expiry |
| Identity 360 — NHI and AI | Dialog, service, system, communication and RFC users, plus the agents acting on a user’s behalf | The same SoD policy applied to non-human identities and AI agents as to people | Standing authorization held by unattended integrations, and what each non-human identity can actually do |
SafePaaS reads the SAP security model as SAP defines it. A user is assigned roles; each role carries profiles; each profile grants authorization objects; each object is qualified by field values including activity and organizational level. Transaction codes are checked against the same objects through S_TCODE.
Only the last two layers say what a user can actually do, and where. Everything above them is a container.
A role’s authorization data can be edited in PFCG and its profile regenerated while layer 2 keeps its name, and layer 5 differs with every assignment. That is why SafePaaS tests the snapshot rather than the role list.
Each of these is a combination the role name will not reveal — which is why it survives an access review and surfaces in an audit.
A user who can post a journal and approve the payment run in the same company code
F_BKPF_BUK activity 01 and F_REGU_BUK activity 21, granted through two different roles, colliding on company code 1000. Neither role name suggests it.
A vendor bank detail changed, then paid, by the same identity
The master-data change sits in CDHDR and the payment in the posted document. No access rule sees the sequence — only transaction monitoring does.
A remediated conflict reintroduced by a role change
The role keeps its name while its authorization data is widened in PFCG and its profile regenerated. Enterprise Roles Manager simulates the change before it moves.
An RFC or batch user holding SAP_ALL that no joiner-mover-leaver process ever reviews
Standing privilege on an account with no owner, running unattended between systems — invisible to a people-shaped access review.
SafePaaS Enterprise Access Monitor tests SoD rules against an ERP Snapshot of your SAP security model — roles, profiles, authorization objects and transaction codes — and Enterprise iAccess prevents the next violation at the point of request.
Modules Enterprise Access Monitor Enterprise iAccess Enterprise Roles ManagerSafePaaS MonitorPaaS watches what actually happened in SAP — the posted document, the changed vendor bank detail, the altered tolerance — rather than only who could have done it.
Modules MonitorPaaSSafePaaS ARCPaaS turns SAP control activity into the evidence an auditor asks for — the rule, the test, the result, the exception and its approval — without anyone assembling a spreadsheet.
Modules ARCPaaSSafePaaS Identity 360 — SafeInsight and SafeIQ — covers every identity with access to SAP, including the RFC users, batch accounts, interface users and AI agents that hold standing authorization and never appear in a joiner-mover-leaver process.
Modules SafeInsight SafeIQA single SafePaaS add-on sits on the SAP ABAP stack. It collects the security model and transaction data inside SAP and pushes it out through DataProbe.
Because every governance module tests the snapshot rather than the live system, the same rule book applies to SAP ECC, S/4HANA and every non-SAP system in the same process.
No — and that is the point of federated identity governance. What your identity platform cannot see is what a role permits once the user is inside SAP, because the authorization object is not an identity concept.
So a certification in your IGA reflects the entitlement rather than the role name, and an access request is checked for SoD before it is approved.
SafePaaS can replace SAP GRC Access Control or run alongside it. The difference is reach: SAP GRC governs SAP, while SafePaaS applies one rule book across SAP and the non-SAP systems in the same process, so a conflict between an Ariba duty and an SAP ECC duty is detected rather than falling between two tools.
A working walkthrough against a demo environment, with an SAP specialist who can map what you see onto the roles, org structure and audit pressure you actually have.
