Cuesys Learning Hub

Authorization Object

A container of related fields that control access to a specific SAP function. Example: S_TCODE controls which transactions a user can run. Over 1000 authorization objects exist in standard SAP.

Authorization Field

A field within an authorization object that holds specific values. Example: ACTVT (Activity) field in most objects uses values like 01=Create, 02=Change, 03=Display, 06=Delete.

Authorization Check

The runtime verification that happens every time a user tries to perform an action in SAP. If the check fails, the user gets an "authorization error" and transaction SM19 logs it.

Profile

The technical representation of roles. Profiles are generated automatically when you save a role in PFCG. Users should be assigned roles, not profiles directly.

User Buffer

The in-memory store of all authorization values for a logged-in user. Rebuilt every time the user logs in. Changes to roles only take effect after the user logs out and back in.

SU53

Transaction that shows the LAST failed authorization check for a user. First tool to use when debugging missing access. Shows exact authorization object, field and value that failed.

SU24

Transaction to maintain the authorization objects checked by each transaction code. Used to customise which auth checks are relevant for custom transactions.

SUIM

SAP User Information System — a powerful reporting tool. Run reports like: Who has access to SU01? Which users have SAP_ALL? Where is authorization object X used?

Remediation (Best)

Mitigation (Alternative)

Role Redesign

Process Redesign

CRITICAL No users with SAP_ALL in production — this gives unrestricted access to everything.

CRITICAL No users with SAP_NEW — removes authorization checks for new functionalities.

CRITICAL Debug access (S_DEVELOP with ACTVT=02) limited to basis team only in production.

HIGH Emergency users (Firefighter) usage logs reviewed by controller within 24 hours.

HIGH No shared user IDs — each person must have their own unique SAP login.

HIGH Dormant users (no login in 90+ days) locked or deleted after review.

HIGH SU01 access (user admin) limited — who can create and change users must be controlled.

HIGH Password policy active: min 8 chars, complexity, 90-day expiry, 5 wrong attempts = lock.

MEDIUM Batch job ownership: automated jobs should run under system users, not dialog users.

MEDIUM Security Audit Log (SM19) activated and monitored for critical events.

MEDIUM All SOD conflicts either remediated or mitigated with signed-off controls.

MEDIUM User access recertification done at least annually — business approves access.

MEDIUM Segregation of Duties in security team itself — different people create vs approve roles.

MEDIUM Transport requests for security changes go through proper change management.

MEDIUM No generic or shared passwords — each user sets their own password on first login.

LOW Role naming convention is consistent and documented.

LOW Unused roles (no users assigned) cleaned up to avoid confusion.

LOW Authorization documentation is up to date for each custom role.

LOW Test users and training system users are separated from production.

LOW Compliance reports from GRC scheduled and reviewed monthly by risk owners.

Q1: Explain the SAP authorization concept end to end. +

A: The SAP authorization concept works at the application layer. When a user tries to execute a function, SAP performs an AUTHORITY-CHECK against authorization objects assigned to that user via their roles. First, S_TCODE checks if the transaction is in the user's menu. Then, each object relevant to that transaction is checked against the user's authorization values. If any check fails, the user gets an authorization error. SU53 shows the last failed check — the security team uses this to determine what access to add to the user's role in PFCG. Roles generate profiles automatically; profiles store the actual authorization values in the database.

Q2: What is Segregation of Duties and give 3 examples of SOD conflicts? +

A: SOD (Segregation of Duties) ensures no single person controls all steps of a critical process to prevent fraud. Example 1 (P2P): Same person creates vendor (FK01) AND processes payment (F110) — they could create fake vendors and pay them. Example 2 (Financial): Same person posts journal entries (FB01) AND approves them — they could manipulate accounts. Example 3 (HR): Same person creates employee (PA40) AND processes payroll — they could add ghost employees. GRC's Access Risk Analysis (ARA) detects these conflicts by comparing user access against a configured Rule Set of conflicting function pairs.

Q3: What is the difference between ARA, ARM, EAM and BRM in SAP GRC? +

A: All four are components of SAP GRC Access Control. ARA (Access Risk Analysis) identifies SOD conflicts and security risks by comparing user access against ruleset definitions — it is detective in nature. ARM (Access Request Management) manages the workflow for requesting, approving, provisioning and revoking access — it is preventive. EAM (Emergency Access Management / Firefighter) provides temporary elevated access for emergencies with full audit logging — it is a compensating control. BRM (Business Role Management) manages the lifecycle of business roles — defining, approving, testing and maintaining roles that are then used in ARM and ARA.

Q4: A user calls saying they cannot run transaction FB01. How do you resolve this? +

A: Step 1: Ask the user to run SU53 immediately after the failed attempt — this shows the exact authorization object and field value that failed. Step 2: Note the authorization object (e.g. F_BKPF_BUK — company code authorization). Step 3: Check the user's roles in SU01 to understand what they currently have. Step 4: Identify which role should contain the missing authorization. Step 5: Open the role in PFCG, go to the Authorizations tab, find the failing object, and add the correct value (e.g. company code 1000). Step 6: Generate the profile and test with the user. Always follow change management — raise a ticket and get approval before making the change in production.

Q5: What are the key security changes from SAP ECC to S/4HANA? +

A: There are several significant changes. First, Fiori is the primary UI — security now requires three layers: PFCG backend role, OData service authorization (IWSG and IWOM objects), and Fiori catalog/group assignment in the launchpad. Second, Business Partner replaces separate Vendor and Customer master records — requiring new authorization objects (e.g. BP_BPTC, F_BKPF_BUK still relevant but BP-specific objects added). Third, the financial data model changed to Universal Journal (ACDOCA table) — some authorization objects changed. Fourth, many classic T-codes are replaced by Fiori apps — roles must be redesigned around business functions, not T-codes. Fifth, Embedded Analytics requires separate authorisation for report access.