SAP authorization objectObjectS_USER_SYSModuleSECURITY_GRC

S_USER_SYS — Authorization for CUA System Assignment

S_USER_SYS controls whether an administrator working in a Central User Administration (CUA) central system is allowed to assign, change, or remove a user's assignment to a specific child system. It checks the ACTVT and SUBSYSTEM fields and only fires in the CUA central system, never on a standalone system or on a child system itself.

This page covers what S_USER_SYS restricts inside a Central User Administration landscape, the two fields it evaluates, and where the check actually fires versus where administrators mistakenly look for it. It also covers the trace sequence for a failed check and the pitfalls that make a role look correct while still failing on system assignment.

Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 842 words

What it protects

S_USER_SYS guards one specific action inside a Central User Administration setup: assigning a user to, or removing a user from, a particular child (logical) system, and distributing that assignment out to the landscape. It has nothing to do with general user maintenance rights such as creating a user or changing a role assignment; those are covered by other objects. The structural fact that causes most confusion is that this object is only evaluated in the CUA central system. An administrator can have every authorization needed to run SU01 and maintain roles on a child system directly and still hit an S_USER_SYS failure the moment the same action is attempted centrally, because the check happens on the 'Systems' tab step, not on the role or profile maintenance steps that surround it.

Fields checked

ACTVT - the activity being performed against the system assignment, such as create or change an assignment, display it, or delete it.
SUBSYSTEM - the logical system name of the child system the assignment is being made to or removed from; this is what restricts which target systems a given administrator can touch.

Where it is checked

SU01 in the CUA central system, specifically when the 'Systems' tab is used to add or remove a child system for a user, or when the user is created with a system assignment already populated.
SU10 in the central system when a mass action touches the system assignment for a group of users.
The CUA distribution and compare processing that pushes the assignment change out to the affected child systems, which re-evaluates the same object for the target SUBSYSTEM value at the point the transfer is triggered.
The check is skipped entirely on a system that is not the CUA central system, and skipped for actions that do not touch the system assignment step, such as pure role or profile changes made locally on a child system.

How to trace a failed check

Start with SU53 immediately after the failure, run in the central system, not on the child system, because that is where the check fired. Confirm the failing object is S_USER_SYS and read off the SUBSYSTEM and ACTVT values that were checked against what the role actually grants. If SU53 is inconclusive or the session has moved on, start ST01 or the newer authorization trace transaction before repeating the exact same sequence: open SU01 in the central system, go to the Systems tab, attempt the same add or remove for the same user, then stop the trace and filter on S_USER_SYS. Hand the security team the user ID doing the assignment, the target user being assigned, the exact SUBSYSTEM value (spelled and cased exactly as it appears in the CUA model), and the ACTVT attempted. Do not hand over a generic 'no authorization to assign user' description; the SUBSYSTEM value is the detail that actually resolves the ticket.

Whose problem this is

Security owns S_USER_SYS because it enforces segregation between administrators who may only manage users in certain child systems versus those with landscape-wide reach. A good request states the requesting admin's ID, the exact logical system names needed (matching the CUA model spelling), and the specific activities required (assign versus display versus remove).

Common pitfalls

A role can carry S_USER_GRP and S_USER_AGR with wide-open values and still fail, because S_USER_SYS is a separate, narrower gate on the system assignment step specifically; people assume 'the role has full user admin rights' covers this and it does not.
SUBSYSTEM values are logical system names, which are case-sensitive text strings maintained in the CUA model; a role built with the wrong case or a stale name from before a system was renamed fails silently and looks identical to a missing authorization.
When a new child system is onboarded into the CUA landscape, existing roles are not automatically extended to the new SUBSYSTEM value; administrators who could assign users to every existing system suddenly cannot touch the new one, and this is read as 'the role broke' rather than 'the role was never updated'.
Because the check only fires centrally, testing the same action directly on a child system gives a false pass; the tester concludes the authorization is fine when the real failure only appears from the central system's SU01.
Confusing this object with the checks that run during a routine user compare or role distribution job leads to wasted time chasing S_USER_SYS when the actual failure is a different object tied to role or profile distribution rather than system assignment.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-auth-objects/s-user-sysERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.